Under some circumstances the metadata renderer can get into an endless loop.
- $conf['useheading'] = 1;
- a set of pages without metadata that link to each other.
- render some wiki text with a link into the above set of pages (perhaps one of those pages).
- In rendering the wiki text the xhtml renderer will, for each internal link, read the link destination page's metadata.
- If there is no metadata and the page exists DW will immediately render that page's metadata. For each internal link, the metadata renderer will attempt to read the link destination page's metadata.
- and so on. If one of the internal links should point back to a page which we are still in the process of rendering there will still be no metadata for that page, so DW will start rendering its metadata and we're now into an endless loop.
- extremely likely if upgrading from a wiki without metadata to the devel version. Whilst this isn't likely to affect most people who run devel version or anyone upgrading from 2006-11-06. If this went live it would affect anyone upgrading from 2006-03-09d or earlier.
One solution is to back out the patch of Dec-09, "render and save metadata fix". However that presents the problem of links to pages without metadata not displaying their "first heading".
Hmm what do you suggest? Should we remove the patch or should we add some recursion counter which aborts on too deep nesting? I guess the latter could be done in an elegant way with a static var?
I'm not sure - hence the bug report rather than a patch :)
Perhaps a deep/shallow parameter for the metadata renderer.
- Deep to indicate that all metadata should be rendered fully and the end result can be saved to disk.
- Shallow to indicate that metadata will not be saved and any external dependencies should not be resolved.
External requests for metadata (external to the renderer) should always be "deep". Internal requests made during rendering should generally be "shallow".
This kind of extends the $render parameter of p_get_metadata() into the renderer for those cases when its ignored because no metadata exists. Also, it has the added benefit of not attempting to render metadata not required for the current process. In the above description there is no current requirement for first heading information on any metadata but that in the original request.
*** additional note for any who experience this bug ***
The should be solution (untested). Turn off "first headings". Spider your wiki (perhaps with wget, httrack, winhttrack, etc). Turn on "first headings". Spider your wiki again. The first spidering generates metadata for all pages but without first headings. The second spider will update all the metadata to include first headings - but without the looping caused when no metadata files exist.
I just had a look at the mention patch from december and your shallow/deep suggestion. Isn't the real problem, that the patch adds a condition where metadata is rerendered even when the $render parameter is false? I changed the condition to
if( $render && (
(!file_exists($file) && file_exists(wikiFN($id))) ||
which seems to solve the problem. Am I missing something here?
iirc, the point of that patch is to override the $render parameter when there is no metadata. If there is no metadata use first heading won't have a first heading to use. We probably need to bring in Ben in as well.
New idea ...
unwind Ben's patch
xhtml renderer gets the metadata with $render = true
metadata renderer gets the metadata with $render = false
I think that will solve the problem. I'll test and get back to you.
It seems to work. Patch pushed.