Hi, I've got a question: Why is the special page template as described in [1] not compatible with Media Wiki VERsion 1.6.9 ? Using this Template under 1.6.9 the Specialpage can be listed under Special:Version, but it is not visible at "Special pages" and if called directly, the created Specialpage doesn't exist.
[1] http://meta.wikimedia.org/wiki/Writing_a_new_special_page
Thank you very much.
Chris
On 11/06/07, Christoph ch95@rz.uni-freiburg.de wrote:
Why is the special page template as described in [1] not compatible with Media Wiki VERsion 1.6.9 ? Using this Template under 1.6.9 the Specialpage can be listed under Special:Version, but it is not visible at "Special pages" and if called directly, the created Specialpage doesn't exist.
[1] http://meta.wikimedia.org/wiki/Writing_a_new_special_page
As of MediaWiki 1.7.0, we started requiring PHP 5, which includes class autoloading. This feature, combined with a few others, meant that a more efficient method could be introduced for initialising special pages and preparing them to be called; the special page class is autoloaded when needed, and the special page list is lazy-loaded.
Since we can't guarantee that users of MediaWiki 1.6.9 aren't using PHP 4 (and most *are*), we state that the new method requires 1.7.x or greater, because we can then be confident that the PHP features we're using will be available.
Rob Church
Rob Church wrote:
On 11/06/07, Christoph ch95@rz.uni-freiburg.de wrote:
[1] http://meta.wikimedia.org/wiki/Writing_a_new_special_page
As of MediaWiki 1.7.0, we started requiring PHP 5, which includes class autoloading.
The page as quoted failed to note this, or at least was sufficiently subtle that I could not find anything relevant.
I have therefore added a ridiculously garish box to this effect which I invite somebody to copy-edit and tone down.
This reinforces my view that we should have some sort of mechanism like the parser-hook system for adding extension pages, so that the code can be written to a published interface and upgrade gracefully.
HTH HAND
Phil Boswell wrote:
I have therefore added a ridiculously garish box to this effect which I invite somebody to copy-edit and tone down.
Looks fine to me :)
This reinforces my view that we should have some sort of mechanism like the parser-hook system for adding extension pages, so that the code can be written to a published interface and upgrade gracefully.
This has been discussed a bit on Mediawiki-l. I think it's a very good idea. The discussion on the other mailing list tends toward a user-friendly interface for add/upgrade/delete of extensions, but this sort of internal interface standardization is part and parcel AKAIC.
Mike
On 11/06/07, Michael Daly michaeldaly@kayakwiki.org wrote:
This has been discussed a bit on Mediawiki-l. I think it's a very good idea. The discussion on the other mailing list tends toward a user-friendly interface for add/upgrade/delete of extensions, but this sort of internal interface standardization is part and parcel AKAIC.
I maintain a couple of extensions which are still backwards compatible with 1.6.x and that's required me to be ruthless, reverting incompatible changes, writing a lot of version-adaptive code while being as clean as possible about it, and in general sometimes sacrificing a potentially faster means of getting something done.
Ultimately, I think, the current means of registering a special page is certainly extremely efficient, quite well thought-out (hell, Tim Starling worked out the specifics, so...) and I am confident that the basic interface for doing so will remain stable for several major versions to come.
We have to balance backwards compatible code against taking advantage of significant opportunities to improve, and this is one of those cases where I argue in favour of the latter. To be fair to Tim, while ExtensionFunctions.php and extAddSpecialPage() did the job, it added another file, in a totally different location, which caused all manner of problems alone; sometimes, change has to happen.
Rob Church
wikitech-l@lists.wikimedia.org