Mailinglist Archive: opensuse-web (101 mails)

< Previous Next >
Re: [opensuse-wiki] Re: [opensuse-web] Theming Issues Fixed
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 :)

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.

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.

Keeping separate checkouts for every wiki means slightly more work, but
would allow to update or change each wiki individually.
Which is exactly what I don't want. We used to do it similar to that way, and
it is a huge pain to keep track about what is different about eack wiki.
Today, I can tell you that the French wiki is configured exactly the same as
the English wiki, they are both the same as the Japanese wiki, and so on. I
don't have to go to the wikis and do a 'git status' or anything like that to
figure out how they are set up.

You probably already know all those arguments ;-)
You are doing the upgrades, so it's your choice which way you prefer.
It may not seem like it after last week, but the upgrade process itself is
actually great the way it is. I can do each wiki individually, and it only
takes me a few minutes to upgrade all the wikis once we decided to pull the

Let's all take a look at stage and see if we need to change anything
before we go live with it. When I deploy to prod, it will instantly
be out on all the wikis, and we can test everywhere out there too.

( )
gives me an interesting result:

exception 'DBQueryError' with message 'A database error has occurred. Did you
forget to run >maintenance/update.php after upgrading? See: ( )
Query: SELECT md_module,md_deps FROM `module_deps` WHERE md_module IN
('mediawiki.legacy.commonPrint','mediawiki.legacy.shared') AND md_skin =
Function: ResourceLoader::preloadModuleInfo
Error: 1146 Table 'opensuse_en.module_deps' doesn't exist
' 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.

< Previous Next >
Follow Ups