Thanks aude for replying to Mark's questions! On 12.01.2013 17:08, aude wrote: >> Right now, I'm focused on non-WMF users of MediaWiki and this sounds >> like something they should be aware of. If they install a new wiki and >> have $wgContentHandlerUseDB enabled, then what new risks do they need to >> be aware of? What are things they should be thinking about?
Not that I can think of, no. ContentHandler itself just encapsulates knowledge about specific kinds of content, so it can easily be replaced by some other kind of content, with the rest of the wiki system still working the same. One thing to be aware of (regardless of how $wgContentHandlerUseDB is set) is that changing the default content model for a namespace may make content in that namespace inaccessible. Kind of like changing a namespace ID. This however shouldn't usually happen, since custom content models are generally governed by the extension the introduces them. There's just no reason to mess with them (as there's no reason to mess with the standard namespaces, and I'm sure you could have quite some fun breaking those). > I don't think there are many impacts, if any, of enabling the content > handler to use the database. By default, it stores the type in database as > "null". null === default content type (content_model) for the namespace. Slight correction here, about what $wgContentHandlerUseDB does. It's not directly related to namespace. Consider: * a pages default content model is derived from it's title. The namespace is only one factor. For .js and .css pages in the MediaWiki namespace and user subpages, the suffix determines the default model. * the namespace's default model is used if there are no special rules governing the default content model. There's also a hook that con override this. * if $wgContentHandlerUseDB is enabled (the default), MediaWiki can handle pages that have different content models for different revisions. It can then also handle pages with content models that are different from the one derived from their title. There is no UI for this atm, but it can happen e.g. through export/import. * with $wgContentHandlerUseDB disabled, MediaWiki has no record of the page's *actual* content model, but must go solely by the title. That's usually sufficient but less robust. The only reason to do this is to avoid db schema changes in existing large wikis like wikipedia. > It will set content type in the database for JavaScript or CSS pages, as > default content type for MediaWiki namespace is wikitext. No, MediaWiki will use the JS/CSS content type for these pages regardless of $wgContentHandlerUseDB. But if you want a page called MediaWiki:Twiddlefoo to have the CSS content model, you can only do that if $wgContentHandlerUseDB is enabled (and you hack up some UI for this). > One important change with introducing the content handler is that > JavaScript and CSS pages don't allow categories and such wiki markup > anymore. This is true regardless of how $wgContentHandlerUseDB is set. Indeed. They also don't allow section editing. >> If someone installs MW and wants to use and expand this feature (as the >> WorkingWiki people might want to), where do they go to find information >> on it? It's pretty useless on a vanilla install, unless you want to make a namespace where everything is per default JS or something. Generally, it's a framework to be used by extensions. >> Right now, the on-wiki documentation refers to docs/contenthandler.txt. >> It seems like this area is ripe for on-wiki documentation, tutorials, >> and how-tos. >> > > The information in docs/contenthandler.txt is probably the most useful at > this point, along with http://www.mediawiki.org/wiki/ContentHandler > > They can look at the Wikibase code to see examples of how we are > implementing new content types. > > It would certainly be nice to have more examples, tutorials, etc. but I'm > not aware of them yet. It would be great to have them, but I find it hard to anticipate what people may want or need. In any case, this would be aimed at extension developers, not sysops setting up wikis. As I said, there's not much you can do with it on a vanilla install, it just allows more powerful and flexible extensions. -- daniel _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
