Wikimedia Bugzilla is closed!

If done, like then OpenSearch output they'll need some customization:
* compatibility with existing URLs (index.php still has to catch the actions and redirect)
* possibly force default output mode to xml (or else require putting format=xml onto the new generated URLs)

Was ist das?

See:

http://www.mediawiki.org/wiki/Manual:$wgEnableDublinCoreRdf
http://www.mediawiki.org/wiki/Manual:$wgEnableCreativeCommonsRdf
http://meta.wikimedia.org/wiki/RDF_metadata

Note that these are off by default and on Wikimedia sites, and are probably good candidates for bumping out to an extension.

It looks like they will be rather trivial to move out to extensions.... The code isn't really intertwined

But RdfMetaData would presumably have to stay in core...?

Would they still need adding to OutputPage->getHeadLinks()...

I'd guess not?

r88868 and r88873 essentially just move them out to be Extensions, keeping the action=blah back compat on index.php

The only thing "lost" is the adding of them to getHeadLinks, as there isn't a hook or similar to add it in

Is that actually needed?


Also, the actual API modules need creating later

(In reply to comment #6)
> The only thing "lost" is the adding of them to getHeadLinks, as there isn't a
> hook or similar to add it in
> 

r88876 fixes that up

if this was done, you'd want those modules included in the tarball.

(In reply to comment #8)
> if this was done, you'd want those modules included in the tarball.

Not really.... we remove stuff to reduce bloat and to make stuff simpler. or are we just going to make that pointless and stick everything back in?

(In reply to comment #9)
> Not really.... we remove stuff to reduce bloat and to make stuff simpler. or
> are we just going to make that pointless and stick everything back in?

My goal is not to reduce "bloat", by which I assume you mean the size of the tarball (since modules are maintained outside of phase3).  While elegance and simplicity are good things to have in the code, those goals are orthogonal to bloat.

My goal (prejudiced by my daily grind through Bugzilla) is to reduce support costs.  If you look, you'll find several (hundred?) bugs in Bugzilla of people asking why MediaWiki doesn't support <ref> tags out of the box.  Each time, the response is the same: install the Cite extension.

If we bundled the Cite extension in the tarball and the new installer provided a clear explanation of what you get if you enable it, that would reduce the number of support requests in Bugzilla, 

That is why I aiming to have modules that are split out from core included in the tarball.

(In reply to comment #10)
> If we bundled the Cite extension in the tarball and the new installer provided
> a clear explanation of what you get if you enable it, that would reduce the
> number of support requests in Bugzilla, 

This analogy is flawed.

There's a reasonable argument that popular extensions should come bundled with MediaWiki (particularly Cite, ParserFunctions, RenameUser, etc.). However, as Brion notes above:

> Note that these are off by default and on Wikimedia sites, and are probably
> good candidates for bumping out to an extension.

It's a bogus argument to suggest that there is going to be a noticeably higher support cost when moving these ancient (seemingly forgotten) features from core to an extension. If you have evidence to support your claims, I'd love to see it. :-)

(In reply to comment #10)
> My goal (prejudiced by my daily grind through Bugzilla) is to reduce support
> costs.  If you look, you'll find several (hundred?) bugs in Bugzilla of people
> asking why MediaWiki doesn't support <ref> tags out of the box.  Each time, the
> response is the same: install the Cite extension.
> 

Several hundred?

I've been watching BZ for *years* and I haven't seen it crop up more than a small handful of times, if that.

> If you have evidence to support your claims, I'd love to see
> it. :-)

You're pretty familiar with bugzilla.  I'm sure you can find the bugs
about missing Cite functionality yourself.

Still, Chad is right.  Saying there are more than a few requests in
Bugzilla is hyperbolic.

(In reply to comment #8)
> if this was done, you'd want those modules included in the tarball.

I disagree on this too. As has been pointed out in several comments here, this is an *almost never used feature* that has been disabled on WMF sites since time immemorial (since inception?). 

As long as it's in the REL-NOTES that it's been bumped to an extension, there's zero reason to include this in the tarball.

(Mid Air Collision)
(In reply to comment #10)
> That is why I aiming to have modules that are split out from core included in
> the tarball.

Must of the things that are pulled out of core are done because either they are unloved, unwanted, disabled by default or just too complicated for the normal user.

There has been discussion multiple times for including extensions in our tarballs or to package them in core (which in this case would be basically the same for the sake of this discussion) such as cite which you bring up as as far as I can recall have never gained consensus.


But more to point, the features that have been removed recently are Maths and these twos, These are apparently disabled by default anyway and maths as was complicated and required dependencies which is why they were moved out.

Perhaps you should start a wider discussion about including these in the tarball packages.

(In reply to comment #15)

> Perhaps you should start a wider discussion about including these in the
> tarball packages.

Agreed.  In fact, it was because I was intending to do that that I was so drawn to this bug.  My apologies.

(In reply to comment #16)
> (In reply to comment #15)
> 
> > Perhaps you should start a wider discussion about including these in the
> > tarball packages.
> 
> Agreed.  In fact, it was because I was intending to do that that I was so drawn
> to this bug.  My apologies.

See bug 26261

marking fixed, pretty sure reedy has done this.

The only really outstanding issue is moving them from index.php to the api...