Hey,

What is the difference between "$content instanceof TextContent" and

"$title->getContentModel() === CONTENT_MODEL_WIKITEXT"? -Niklas

The former will be true for any content deriving from TextContent, which currently includes WikitextContent, JavaScriptContent, CssContent and RevisionTestModifyableContent. The later will only be true for WikitextContent.

Cheers

-- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. --

On Wed, 10 Oct 2012 14:37:47 -0700, Rob Lanphier robla@wikimedia.org wrote:

On Wed, Oct 10, 2012 at 6:52 AM, Daniel Kinzler daniel@brightbyte.de wrote:

...

Since the ContentHandler stuff has been merged into the core, several much-used functions and hooks have been deprecated. I have tried to find and replace all calls in core, but a lot of extensions are still using the old stuff. They will still work for all text-based content, but will generate a ton of warnings, and will fail tests (and make core tests fail).

I'm very worried about converting all of the extensions to use new APIs now. If it turns out we need to revert ContentHandler, this will make the revert that much more difficult.

I'd rather we remove deprecation warnings for the newly deprecated APIs.

Rob

So use a conditional to check for the contenthandler classses/methods.

What is wrong with making extensions work right now both with and without it?

11 Октябрь 2012 г. 15:53:42 пользователь Jeroen De Dauw (jeroendedauw@gmail.com) написал:

Hey,

...

What is wrong with making extensions work right now both with and without

it?

+1. I don't see any harm done in adding such conditional checks, and they solve the problem at hand. We probably want to add them in any case, unless breaking compatibility with MediaWiki older then 1.21 is acceptable.

Also, it would be great, if WMF selected some old version of MediaWiki as LTS (Long Time Support) so extensions would be required to work with it. Currently that could be 1.17, first version which got ResourceLoader. Dmitriy

Dmitriy Sintsov.

11 Октябрь 2012 г. 16:13:02 пользователь Jeroen De Dauw (jeroendedauw@gmail.com) написал:

Hey,

Also, it would be great, if WMF selected some old version of MediaWiki as LTS (Long Time Support) so extensions would be required to work with it. Currently that could be 1.17, first version which got ResourceLoader.

My observation is that most WMF maintained extensions are not maintained with much regard to backwards compatibility but with a lot of effort being put in replacing use of deprecated code usage quickly. They thus tend to have compatibility broken early after MediaWiki releases. I'd be semi-surprised to find a single one that is still compatible with 1.17 at this point.

What's so major is preventing new extensions from running in 1.17? Page actions in separate classes? Router? Are these major obstacles?

Dmitriy

On 10/11/2012 09:56 AM, Daniel Kinzler wrote:

On 10.10.2012 23:37, Rob Lanphier wrote:

...

I'm very worried about converting all of the extensions to use new APIs now. If it turns out we need to revert ContentHandler, this will make the revert that much more difficult.

I'd rather we remove deprecation warnings for the newly deprecated APIs.

Ok. I discussed this a bit with Tim, and we came to the following conclusion:

• Don't update the extensions for a while. But make sure we do eventually.
• Disable the deprecation warnings for now by using ContentHandler::deprecated() instead of wfDeprecated(), so we have a single place to enable or disable these warnings.
• Define MW_SUPPORTS_CONTENT_HANDLER for easy B/C switches in extensions.

-- daniel

---

Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

I think instead of using individual constant, we should finally introduce a Capabilities class.

It should have a single static method, has(), which indicates whether a certain capability is registered within the system. At the beginning, capabilities will be listed as static members of that class, but we may do something more clever at the future.

I would also suggest that we introduce a policy of adding a capability for any new hook we add. Or we could parse docs/hooks.txt in order to avoid duplication (probably moving it somewhere).

Finally, backporting that interface into previous versions of MediaWiki might be a good idea.

—Victor.

On Thu, Oct 11, 2012 at 10:03 AM, Victor Vasiliev vasilvv@gmail.com wrote:

I think instead of using individual constant, we should finally introduce a Capabilities class.

It should have a single static method, has(), which indicates whether a certain capability is registered within the system. At the beginning, capabilities will be listed as static members of that class, but we may do something more clever at the future.

I would also suggest that we introduce a policy of adding a capability for any new hook we add. Or we could parse docs/hooks.txt in order to avoid duplication (probably moving it somewhere).

I think this is a good idea. The case for that is here: http://martinfowler.com/bliki/FeatureToggle.html

Gotta love an article that starts with "Imagine you are releasing into production every two weeks..." :)

Some bikeshedding: I'm a little concerned with using the term "Capabilities", since I generally hear that term more frequently in designing software security models: http://en.wikipedia.org/wiki/Capability-based_security

Rob

Hey,

Interesting idea. A few suggestions:

* Having static methods to access this is nice and convenient, but perhaps we can make a singleton with instance methods such as hasFeature and static methods such as "has" that then just do "return self::singleton()->hasFeature()"

* Having an array with string keys seems way more flexible and extendible then having static (or even non-static) members. It'd be pretty bad if the system did not allow for extensions to register present features.

How about Feature? I was thinking something like:

Feature::required( "Foo" ) -- for a hard fail if the feature doesn't exist Feature::desired( "Foo" ) -- for conditional behavior if a feature exists

+1, although I'd tweak the names a bit:

* Feature::require( 'foo' ) - throws an error or whatever when not present * Feature::has( 'cheesburger' ) - returns a boolean

The first name is still not ideal though. I'd expect "required" to return a boolean. But then again, "require" can be interpreted as loading the feature.

Cheers

-- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. --

I do not think, design-wise, this is a good idea. In addition to what Tim said, extensions would become needlessly complex if we started accounting for every possible MediaWiki feature that's added in a given release. *--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com

On Thu, Oct 11, 2012 at 8:33 PM, Tim Starling tstarling@wikimedia.orgwrote:

On 12/10/12 04:03, Victor Vasiliev wrote:

...

I think instead of using individual constant, we should finally introduce a Capabilities class.

It should have a single static method, has(), which indicates whether a certain capability is registered within the system. At the beginning, capabilities will be listed as static members of that class, but we may do something more clever at the future.

I would also suggest that we introduce a policy of adding a capability for any new hook we add. Or we could parse docs/hooks.txt in order to avoid duplication (probably moving it somewhere).

Finally, backporting that interface into previous versions of MediaWiki might be a good idea.

Then you would have to load a capability map with potentially hundreds of entries at registration time, despite the fact that on most requests, most of the hooks will never be called. It seems inefficient to me. At least with the current system, the number of support constants is small (4-5).

-- Tim Starling

---

Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

On 10/11/2012 08:33 PM, Tim Starling wrote:

Then you would have to load a capability map with potentially hundreds of entries at registration time, despite the fact that on most requests, most of the hooks will never be called. It seems inefficient to me. At least with the current system, the number of support constants is small (4-5).

-- Tim Starling

We can cache them. If we use APC, an individual call to Capabilities::has() should take about 5 to 6 μs.

—Victor.