Hi there
I've coded a calendar which I can include in any wikipage. Now there's just one problem: the calendar has a function, that allows to "change date". So I can click on an arrow, to go to the next month. Really cool I thought.. but the problem is, that it won't change as long as I don't do a shift-reload (the informations are passed by 2 GET-variables and I catch them with $wgRequest->getVars). I suppose that's the caching-function :/. Now is there a way, to force a refresh of the cache? Or even deactivate it for a wikipage?
I'm using the latest stable mediawiki out of the box - I did no special configuration to the caching feature. I've implemented the calendar the same way, as the TOC or CURRENTMONTH were implemented.
Regards Joel
Joel Wiesmann wrote:
Hi there
I've coded a calendar which I can include in any wikipage. Now there's just one problem: the calendar has a function, that allows to "change date". So I can click on an arrow, to go to the next month. Really cool I thought.. but the problem is, that it won't change as long as I don't do a shift-reload (the informations are passed by 2 GET-variables and I catch them with $wgRequest->getVars). I suppose that's the caching-function :/. Now is there a way, to force a refresh of the cache? Or even deactivate it for a wikipage?
I'm using the latest stable mediawiki out of the box - I did no special configuration to the caching feature. I've implemented the calendar the same way, as the TOC or CURRENTMONTH were implemented.
It's not a very elegant solution, but you can suppress client-side caching with
global $wgOut; $wgOut->enableClientCache(false);
You could run this from the parser whenever your calendar tag is present. The problem with that is that the parser currently works even if $wgOut is not defined or if another OutputPage object is being used, this would break that behaviour. That shouldn't cause any observable effects in the current version, but I certainly wouldn't accept it into the main line of development.
We seem to have lost the mContainsOldMagic functionality at some stage. A long-term solution would be to put it back in. Caching information should be stored in the ParserOutput object. OutputPage::addWikiText and similar functions would retrieve the caching information and use it to set appropriate flags in the OutputPage object. OutputPage::sendCacheControl() and the parser cache would use this information.
It's important for Wikipedia that we are able to cache pages containing {{NUMBEROFARTICLES}}, {{CURRENTDAYNAME}}, etc., because these variables are often used on the main page and other heavily-visited pages. A global option to make caching more aggressive may be useful.
Joel, will you be publishing your modification under the GPL?
-- Tim Starling
Hi Tim
Hmm.. I'll try to find a proper way to implement this feature. Yet I'm pretty new to the whole mediawiki framework so I'm sure, that my code is a little bit unorganized. The calendar works but is very modified to meet my requirements (it also does a URL-fopen to include preg_matching - informations from other pages and so on) but I'll try to modify it so far, that it could be used with mediawiki and send you the code.
Of course I will publish the results under the GPL - no question ;-). At least if the code is good enough! If not, I'll do a mediawiki-section in my homepage with some hacks so people with low-hit-wiki's could implement the calendar.
Regards Joel
Tim Starling wrote:
It's not a very elegant solution, but you can suppress client-side caching with
global $wgOut; $wgOut->enableClientCache(false);
You could run this from the parser whenever your calendar tag is present. The problem with that is that the parser currently works even if $wgOut is not defined or if another OutputPage object is being used, this would break that behaviour. That shouldn't cause any observable effects in the current version, but I certainly wouldn't accept it into the main line of development.
We seem to have lost the mContainsOldMagic functionality at some stage. A long-term solution would be to put it back in. Caching information should be stored in the ParserOutput object. OutputPage::addWikiText and similar functions would retrieve the caching information and use it to set appropriate flags in the OutputPage object. OutputPage::sendCacheControl() and the parser cache would use this information.
It's important for Wikipedia that we are able to cache pages containing {{NUMBEROFARTICLES}}, {{CURRENTDAYNAME}}, etc., because these variables are often used on the main page and other heavily-visited pages. A global option to make caching more aggressive may be useful.
Joel, will you be publishing your modification under the GPL?
-- Tim Starling
Joel Wiesmann wrote:
Of course I will publish the results under the GPL - no question ;-). At least if the code is good enough! If not, I'll do a mediawiki-section in my homepage with some hacks so people with low-hit-wiki's could implement the calendar.
cool :-)
If you feel ready, please create a page on http://meta.wikimedia.org for it and sort it in the http://meta.wikimedia.org/wiki/Category:Mediawiki_Extensions so that it can be found by other people.
Maybe we can integrate the calendar one day as an extension in mediawiki and getting rid of the ugly temporary solution I set up at http://meta.wikimedia.org/wiki/Calendar
greetings, elian
wikitech-l@lists.wikimedia.org