We use a search extension, so we should not allow access to it. We never have before, and it hasn't been a problem.
OK, then let's wait if somebody complains ;-)
People did complain, until we *stopped* using the default MW search :)
My understanding is that opensearch_desc.php has nothing to do with the search engine used. opensearch_desc.php just points to special:search, and that's is what the openSUSE wiki uses. The URL doesn't change just because we use another search engine.
BTW: http://en.wikipedia.org/w/opensearch_desc.php (Wikipedia has the MWSearch extension installed, which means they are using the Lucene search engine.)
My understanding of opensearch is that it it allows to add a "search en.opensuse.org" to firefox easily (which will then use special:search). Of course I'll survive without it, but it sounds useful, so we {c,sh}ould consider to enable it.
See also the description in http://en.wikipedia.org/wiki/OpenSearch
Just checked: visit any Wikipedia article with firefox, click the dropdown arrow in the search box of firefox and you'll get an option "add Wikipedia (en)".
Maybe you can allow access to opensearch_desc.php on stage so that we can test it a bit more?
Sure, I can try it. Like I mentioned, it's been like this for years and I haven't heard a single complaint. However, it certainly won't kill anyone to allow it. ...
I may have to import the database from production, like I did with the other wikis. I find it a good idea to do this once in awhile anyways.
Yes, that makes sense - especially before doing version upgrades as we all know now ;-)
Please send a short note when you have done this - I'll check the red link styling afterwards (but not on enstage, because it will then contain the Mediawiki:Common.css from en.o.o ;-)
If it takes too much time to import the databases, I vote for updating the CSS file in the production wiki without testing it on stage. It can only make things better ;-)
BTW: It looks like my newline fix in extensions/videoflash.php was correct - enstage doesn't have the superfluous newline anymore and delivers valid XML :-)
I second that vote. I went ahead and made the update in production. It's nothing permanent, thanks to git. If we have a problem, we can revert it. However, fixing the XML alone was worth deploying to production. -Matt