Re: [Phpwiki-talk] Plugins Executed Twice, Displayed Only Once?

[Reini U. <ru...@x-...>]

Rui Carmo schrieb:
> On Dec 6, 2004, at 5:15 PM, Reini Urban wrote:
>> Rui Carmo schrieb:
>>
>>> I'm running a heavily customized version of PhpWiki at 
>>> http://the.taoofmac.com, and have come up with an interesting problem.
>>
>> This blog theme is exactly what I wanted to have also, but didn't had 
>> time yet. Very good work!
> 
> Thanks. It's a bit crufty around the edges (the edit template is still 
> broken, for instance), but it does the job for visitors.
> 
>>> It might be from my tweaks (I forked my code from PhpWiki sometime 
>>> around 1.3.7, I think), but plugins in the node contents seem to be 
>>> invoked twice, i.e:
>>> * if I use PageTrails as part of browse.tmpl, it is only invoked once
>>> * If I add <?plugin PageTrails ?> to my Sandbox, the plugin code 
>>> (i.e., run()) gets invoked twice, even though the output is only 
>>> shown once.
>>
>> If you have a plugin in a template it is invoced from there also, but 
>> no normal template should be processed twice.
>>
>>> This is tolerable for simple stuff like PageTrails, but a _major_ 
>>> nuisance for TitleSearch and whatnot (which is what I'm trying to 
>>> optimize).
>>> I'm blaming it on template expansion (which I haven't modified myself 
>>> and might have a few lingering bugs not present in current CVS), but 
>>> instead of upgrading (which would mean refactoring all my current 
>>> custom plugins and subpage handling) what I would _really_ like are 
>>> some pointers as to how to go about debugging this, namely:
>>
>>
>> I'll do the work and merge some of your stuff to our version as
>> another theme, ok? Our WikiBlog template smells awful.
>> Also an example how to add google ads to some sidebar is useful for 
>> some theme.
>> Do you have a tarball of your changes and the Kubrick theme somewhere 
>> to download?
> 
> No, there is no change tarball available. And the reason for that is 
> that I've basically butchered the code over the last two years to remove 
> PhpWiki features I don't like nor need (like multiple user support, 
> subpage handling, etc.).
> 
> So it's not really just a set of changes - I've edited just about 
> everything from the database driver to the block parser, and admittedly 
> not in a very elegant way. I also have a faint recollection of changing 
> the database schema, although I will probably do it again soon to store 
> post titles in a separate field upon page creation (saves me a lot of 
> trouble to generate the Alphabetical Index, searching, etc.) and add a 
> node creation date that stays put and doesn't get flushed away with 
> older revisions (which would help my Atom feed).
> 
> Not to mention a number of hard-coded regexps in the middle of the code 
> to block spam referrers and other niceties of the open Internet...
> 
> Actually, most of the stuff you see (the Kubrick theme, the ads, etc.) 
> is really _trivial_ to do - the real work is in the plugins and CSS, and 
> that isn't even halfway done yet (if you look at the CSS you'll still 
> see two different markup styles, mine and Michael's, that I haven't yet 
> merged). Adding the base theme took me all of two hours, most of it 
> spent moving CSS and images around, and Adsense takes all of two minutes.
> 
> Plus, it's not just PhpWiki anymore. I don't use any of the WikiBlog 
> stuff (as I recall, it was based on UnfoldSubPages), I rely on a 
> hardcoded blog/ prefix. There are also a couple of other things inside 
> (although I haven't re-themed them all yet), and releasing the sources 
> generally would mean I be expected to provide support and fix bugs for 
> other people, so I don't do it wholesale - I just throw a copy of my 
> plugins to whomever asks and make it plain that they're on their own. :)
> 
> I could try to isolate some of the bits that are my code and send you a 
> tarball, though. _After_ I fix the plugin calls.

Ah okay. I'll probably use just your blog theme then. And some 
js-buttons here and there.

>> I was also working today on more radio userland features, like RSS2 
>> and cloud support (pagechange notification via xml-rpc).
>> The atom format not yet, but you already have that.
> 
> Oh yes, I hacked a copy of RssWriter and added a new formatter to 
> RecentChanges. It does, however, rely on a lot of the internal caching 
> stuff I also added (to check If-Modified-Since headers), and almost 
> completely breaks your coding conventions :)
> 
>> Trackback is missing but almost the same.
> 
> I don't do trackback or comments - it's a free JavaScript add-on from 
> HaloScan.com (I don't want to bother with dealing with comment spam, and 
> I only added comments at all as an experiment).
> 
>>> * In which conditions are plugins expanded
>>
>> On every invocation only once :)
> 
> And, returning to my original question, where does that happen in the 
> code? The only thing I haven't done so far is to sanitize the templates 
> themselves to see if I've created some sort of loop...
> 
>>> * if dump_template() is useful for debugging that (the initial 
>>> results aren't satisfactory, but I might have missed something)
>>> I'm currently trying to wrap my neurons around printExpansion(), 
>>> which is what I see getting called more often. I would have used 
>>> PHP's call stack debugger if I could, but have to resort to browser 
>>> output and file logging, so it's tough going (some sort of call graph 
>>> for page generation would also be nice, since it is nigh on 
>>> impossible to just use error_log() with all the built-in error 
>>> handling mechanisms).
>>
>> Don't you have a GUI php debugger?
> 
> No. I have to access the machine via SSH and I don't know of any free 
> ones that run on Macs (or decent ones that I can run on Linux), so I 
> would really appreciate some pointers to where plugin invocation happens 
> in the source code and/or how to disable _all_ the extra error handling 
> so I can simply place a few calls here and there and see the output in 
> the system log...

Ah I forget to wrote that, sorry.

The only and main is in CachedMarkup.php:
   Cached_PluginInvocation::expand()
This is where you must put your debugprint statement.
expand() is called recursively through the HTML parse tree.

The expander for the Cached_PluginInvocation class is
a normal printExpansion() call.

-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/