Hello, Am Mittwoch, 7. Dezember 2011 schrieb Matthew Ehle:
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?
Well, keep in mind that we were not using git until two weeks ago.
yes, but "svn up" works the same way ;-)
I only ever used subversion for the themes and landing page, as it was a pain to use it for everything else. Seriously, git is so much better.
I know - you can store SVN checkouts in it. That's impossible with SVN ;-)
Also, there are a lot of little things that do not involve git. For example, adding a banner message to LocalSettings.php or testing out a new change on stage. Yes, I can use for loops, find, and sed all day long (believe me, I do). However, I still have yet to find a quicker and better way to keep 25+ directories in perfect sync than using symbolic links. There's a reason symlinks were invented :)> Indeed ;-)
Symlinks have the advantage that you can update all wikis at once, and have the disadvantage that you must update all wikis at once ;-) Not with my upgrade process :)
I simply check out into a new directory, switch the symlinks over one wiki at a time, and run the upgrade script for that wiki. I have it scripted, and it works quite well.
That sounds like the best of both methods ;-) Indeed, that's a good solution.
Error: 1146 Table 'opensuse_en.module_deps' doesn't exist (hugh.provo.novell.com) ' in /srv/www/htdocs/mediawiki-1.17.0/includes/db/Database.php:781
You probably need to run the database update on all stage wikis - destage shows the same error.
Unfortunately this also blocks testing the CSS changes because the CSS in skins/bentofluid/ is not loaded in the *stage wikis :-(
That is a problem, as I had run the upgrade script on them.
:-/
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 :-) Regards, Christian Boltz -- Wir leben in der Unterhaltungsbranche. Wuerde sonst jemand ernsthaft ueber "NT" als Server - OS nachdenken? [Hans Bonfigt] -- To unsubscribe, e-mail: opensuse-wiki+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-wiki+owner@opensuse.org