New noinstructionscache flag

[solewniczak]

This commit adds a new flag: noinstructionscache to plugin syntax. This flag forces not to use an instruction cache for the included page. This flag allows using the struct serial aggregation inside the included page. More generally, it allows using any DokuWiki syntax which instructions are dependant on the current page id, inside the included page.

[michitux]

While I am not totally against this flag and the implementation is okay (apart from the missing initialization), I am really wondering why this is used and if what the struct plugin does is a good idea. Note that instructions can be processed in the context of any page, even without the include plugin. It suffices to have useheading on and a link to the page. If the other page is changed without being immediately shown (e.g., because the page has been updated on the disk), the instruction cache will be re-generated while the page with the link is shown. This can also happen due to a race condition if the linked page has been updated and the page with the link is shown before the instruction cache of the linked page could be written. In my opinion (but I have not looked deeper into the struct plugin) such processing that depends on the id should always happen in the rendering step for which the cache can be easily disabled to avoid such problems. Note that the rendering step is quite fast compared to the parsing step.

Can you provide any more insights (or provide a link to code/documentation) that explains why this is part of the parsing step and it is thus indeed necessary to disable that cache?

[solewniczak]

The new serial data feature of struct allows the user to store separate datasets for every page where it is inserted. So the following syntax:

---- struct serial ----
schema: certs
----

will display different data for every single page (different data for "data:cert1", "data:cert2" and so on) . The problem here is that the "id" of the page, for which the dataset is displayed, is saved directly in the instructions:

array (
  0 => 'plugin',
  1 => 
  array (
    0 => 'struct_serial',
    1 => 
    array (
      'limit' => 0,
      'dynfilters' => false,
      'summarize' => false,
      'sepbyheaders' => false,
      'target' => '',
      'align' => 
      array (
      ),
      'headers' => 
      array (
      ),
      'cols' => 
      array (
        0 => '*',
      ),
      'widths' => 
      array (
      ),
      'filter' => 
      array (
        0 => 
        array (
          0 => '%rowid%',
          1 => '!=',
          2 => '0',
          3 => 'AND',
        ),
        1 => 
        array (
          0 => '%pageid%',
          1 => '=',
          2 => 'data:cert1',
          3 => 'AND',
        ),
        2 => 
        array (
          0 => '%rowid%',
          1 => '!=',
          2 => '0',
          3 => 'AND',
        ),
        3 => 
        array (
          0 => '%pageid%',
          1 => '=',
          2 => 'data:cert1',
          3 => 'AND',
        ),
      ),
      'schemas' => 
      array (
        0 => 
        array (
          0 => 'certs',
          1 => '',
        ),
      ),
      'sort' => 
      array (
      ),
      'csv' => true,
      'withpid' => 1,
    ),
    2 => 5,
    3 => '---- struct serial ----
schema: certs
----',
  ),
  2 => 1,
)

So when we will insert the "struct serial" syntax to page "include:cert" and then include it on "data:cert1" and ""data:cert2":
{{page>include:cert&noheader&nofooter&noeditbutton}}
we will always see here the dataset of the first visited page (for which the instructions cache was generated), not for the current one.

I am really wondering why this is used and if what the struct plugin does is a good idea.

I also believe that what struct does here is not a good idea but the flag I've proposed can fix it very simply without reengineering the struct plugin itself. But maybe it should be fixed in struct not in include. @splitbrain what do you think about it?