Mailinglist Archive: opensuse-web (101 mails)

< Previous Next >
Re: [opensuse-wiki] Re: [opensuse-web] Theming Issues Fixed

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.

(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" 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

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

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

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
( ' in
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

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 :-)


Christian Boltz
Wir leben in der Unterhaltungsbranche. Wuerde sonst jemand ernsthaft
ueber "NT" als Server - OS nachdenken? [Hans Bonfigt]

To unsubscribe, e-mail: opensuse-web+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-web+owner@xxxxxxxxxxxx

< Previous Next >
Follow Ups