Hi! I have an extension, which submits and renders polls defined with parser tag hooks. To have the article view properly re-generate dymanical content of tag, the typical approach is to use $parser->disableCache() in hook's function. However, in my case, the dynamically generated content is changed only when the poll was successfully submitted. When a user just views the page and makes no vote, the content doesn't change, thus, should be cached to improve the performance. When I comment out $parser->disableCache() line, the content of page is not being updated, until one purges the page manually, which is very unhandy. So I used to have this call unconditionally, which is inefficient. But, I am (with my limited knowledge of core) cannot find out, which calls should I make to invalidate parser cache and article cache in the extension's code on demand (conditionally). In the point of code, where the user had successfully POSTed voting data and the results of vote were stored in the DB, I try to execute the following methods: $wgArticle->doPurge(); $wgTitle->invalidateCache(); then perform a a 302 redirect to show the same title with updated poll results. However, when I comment out the $parser->disableCache() line, tag function output content is not being displayed at all. Like if there were no tags at the page. What would you suggest? My only idea to implement GET action which will conditionally purge the page. I don't like such approach. Thanks, Dmitriy

It seems to be fixed. I got the following message when I tried to get data from a private wiki via API. <error code="readapidenied" info="You need read permission to use this module" xml:space="preserve"> On 1/10/10, Angela &lt;beesley(a)gmail.com&gt; wrote:

2010/1/10 Angela &lt;beesley(a)gmail.com&gt;om>: Actually, the API is now overly restrictive on private wikis, disallowing all actions except login from users without read rights. This means they can't get certain data that they could get through the UI (like the content of whitelisted pages such as the main page, the /name/ of the main page, the wiki's name and content language, etc.). For most users this is annoying and should be fixed, but for operators of private wikis it's probably a comforting thought that, for now, even the most innocent requests to do anything but log in will be denied to users without read rights. Roan Kattouw (Catrope)