[opensuse-wiki] Re: [opensuse-web] Theming Issues Fixed

newer
[opensuse-wiki] Wiki Status Update

older
[opensuse-wiki] Popular portals on...

Matthew Ehle

7 Dec 7 Dec

15:25

...
...
...
Christian Boltz opensuse@cboltz.de> 12/7/2011 4:44 AM >> ( mailto:opensuse@cboltz.de ) Am Dienstag, 6. Dezember 2011 schrieb Matthew Ehle:

...
Here's the entire rewrite: ... As you can see, if it's not a specific directory, PHP file, or search engine file, it gets translated to a wiki page.

From the remaining files that are not available to the public, there are 3 left where I'm not sure because I don't know what their usecase is: - opensearch_desc.php - thumb.php - trackback.php

Plus the maintenance directories, etc.

...

Maybe you can find out what they are used for and if they should be public. At least hiding them doesn't cause any obvious breakage, so this isn't high priority.

Those files have been around for awhile, and as far as I can tell, we never use them.

...

...
Without load.php in there, we were trying to look it up as a wiki page (hint, this doesn't work).

Well, it gave you the default "wiki page does not exist" wiki page, so it sort-of works - but it's far from the expected result ;-)

...
...
...
I don't know if that fixed the red link issue offhand, since I can't find any pages that have broken links. Anyone who knows of a page I can test?

General rule of thumb: http://en.opensuse.org/Special:WantedPages is a good starting point - or just use the sandbox and add a broken link yourself ;-)

I thought the WantedPages would have been right, but it was hard to tell, since they were all blue links ;)

Oh well...

My doorbell is broken since weeks, but the electrican never came to me. When I called him again, he said: "I went to you four times already and rang the doorbell, but nobody opened the door!"

;-))

...
...
I just checked it - links to non-existing pages have class=new, links to existing pages don't have any class= attribute. .................................................................... ............................ I just added those styles to Mediawiki:Common.css (another edit of Common.css? I already can see Rajko screaming ;-)

Note that it may take some hours to get all caches updated, especially if you are not logged in.

It works for me now!

I commited the fixed CSS to git. Please test it on ${not-en}.o.o and then deploy to all wikis.

I can't test it that way, as all the wikis use the same set of core files. Can you imagine how awful it would be to maintain them otherwise :) However, I will pull into stage and test there. -Matt

Christian Boltz

16:47

Hello, Am Mittwoch, 7. Dezember 2011 schrieb Matthew Ehle:

...

...
...
...
...
Christian Boltz opensuse@cboltz.de> 12/7/2011 4:44 AM

...

...
From the remaining files that are not available to the public, there are 3 left where I'm not sure because I don't know what their usecase is: - opensearch_desc.php - thumb.php - trackback.php

Plus the maintenance directories, etc.

Yes, of course - but for the maintenance directories etc. I'm quite sure that they will/should never be used by wiki visitors ;-)

...

...
Maybe you can find out what they are used for and if they should be public. At least hiding them doesn't cause any obvious breakage, so this isn't high priority.

Those files have been around for awhile, and as far as I can tell, we never use them.

I just found out that they are documented: http://www.mediawiki.org/wiki/Manual:Opensearch_desc.php The description sounds interesting, and the wiki HTML source code even points to it: <link rel="search" type="application/opensearchdescription+xml" href="/opensearch_desc.php" title="openSUSE (en)" /> so maybe you should allow access to it ;-) http://www.mediawiki.org/wiki/Manual:Thumb.php AFAIK we don't use this way of thumbnail generation. http://www.mediawiki.org/wiki/Manual:Trackback.php Trackback support ($wgUseTrackbacks) is deprecated, no need to enable it now ;-)

...

...
I commited the fixed CSS to git. Please test it on ${not-en}.o.o and then deploy to all wikis.

I can't test it that way, as all the wikis use the same set of core files. Can you imagine how awful it would be to maintain them otherwise :)

Hmm... for dir in *.o.o ; do ( cd $dir && git pull ) done doesn't look too awful ;-)

...

However, I will pull into stage and test there.

Yes, that should work. I just wanted to make sure that you don't test on en.o.o because it already has the fixed CSS in Mediawiki:Common.css. Regards, Christian Boltz --

...

Ich versuchs mal so zu sagen: Ich versuche gerade, dich laaaangsam ins kalte Wasser zu schubsen. ich mag kein kaltes Wasser, las uns die weiteren Tests nach Playa de Santiago verlegen, da dürfte das Wasser jetzt ca. 20° C haben. [> Ratti und Gerald Goebel in fontlinge-devel]

-- To unsubscribe, e-mail: opensuse-wiki+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-wiki+owner@opensuse.org

Matthew Ehle

17:11

...

...
...
...
Christian Boltz 12/7/2011 9:47 AM >>> Hello,

Am Mittwoch, 7. Dezember 2011 schrieb Matthew Ehle:

...
...
...
...
...
Christian Boltz opensuse@cboltz.de> 12/7/2011 4:44 AM

...
...
From the remaining files that are not available to the public, there are 3 left where I'm not sure because I don't know what their usecase is: - opensearch_desc.php - thumb.php - trackback.php

Plus the maintenance directories, etc.

Yes, of course - but for the maintenance directories etc. I'm quite sure that they will/should never be used by wiki visitors ;-)

Exactly why the redirect is there... keeping visitors from hitting files and directories they shouldn't, whether intentionally or not.

...

...
...
Maybe you can find out what they are used for and if they should be public. At least hiding them doesn't cause any obvious breakage, so this isn't high priority.

Those files have been around for awhile, and as far as I can tell, we never use them.

I just found out that they are documented:

http://www.mediawiki.org/wiki/Manual:Opensearch_desc.php The description sounds interesting, and the wiki HTML source code even points to it: <link rel="search" type="application/opensearchdescription+xml" href="/opensearch_desc.php" title="openSUSE (en)" /> so maybe you should allow access to it ;-)

We use a search extension, so we should not allow access to it. We never have before, and it hasn't been a problem.

...

http://www.mediawiki.org/wiki/Manual:Thumb.php AFAIK we don't use this way of thumbnail generation.

http://www.mediawiki.org/wiki/Manual:Trackback.php Trackback support ($wgUseTrackbacks) is deprecated, no need to enable it now ;-)

Exactly. I think we are just fine with what we have now.

...

...
...
I commited the fixed CSS to git. Please test it on ${not-en}.o.o and then deploy to all wikis.

I can't test it that way, as all the wikis use the same set of core files. Can you imagine how awful it would be to maintain them otherwise :)

Hmm...

for dir in *.o.o ; do ( cd $dir && git pull ) done

doesn't look too awful ;-) Well, keep in mind that we were not using git until two weeks ago. 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 :)

...

...
However, I will pull into stage and test there.

Yes, that should work. I just wanted to make sure that you don't test on en.o.o because it already has the fixed CSS in Mediawiki:Common.css. 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.

Christian Boltz

18:01

Hello, Am Mittwoch, 7. Dezember 2011 schrieb Matthew Ehle:

...

...
...
...
...
Christian Boltz 12/7/2011 9:47 AM >>> Am Mittwoch, 7. Dezember 2011 schrieb Matthew Ehle:

...
> Christian Boltz opensuse@cboltz.de> 12/7/2011 4:44 AM

...

...
http://www.mediawiki.org/wiki/Manual:Opensearch_desc.php The description sounds interesting, and the wiki HTML source code even> points to it: <link rel="search" type="application/opensearchdescription+xml" href="/opensearch_desc.php" title="openSUSE (en)" />

so maybe you should allow access to it ;-)

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

...

...
...
...
I commited the fixed CSS to git. Please test it on ${not-en}.o.o and then deploy to all wikis.

I can't test it that way, as all the wikis use the same set of core files. Can you imagine how awful it would be to maintain them otherwise :)

Hmm...

for dir in *.o.o ; do ( cd $dir && git pull ) done

doesn't look too awful ;-)

Well, keep in mind that we were not using git until two weeks ago.

yes, but "svn up" works the same way ;-)

...

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 ;-) Keeping separate checkouts for every wiki means slightly more work, but would allow to update or change each wiki individually. You probably already know all those arguments ;-) You are doing the upgrades, so it's your choice which way you prefer.

...

...
...
However, I will pull into stage and test there.

Yes, that should work. I just wanted to make sure that you don't test on en.o.o because it already has the fixed CSS in Mediawiki:Common.css. 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.

http://enstage.opensuse.org/load.php?debug=false&lang=en&modules=mediawiki.legacy.commonPrint%2Cshared&only=styles&skin=bentofluid&* 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: http://www.mediawiki.org/wiki/Manual:Upgrading#Run_the_update_script Query: SELECT md_module,md_deps FROM `module_deps` WHERE md_module IN ('mediawiki.legacy.commonPrint','mediawiki.legacy.shared') AND md_skin = 'bentofluid' Function: ResourceLoader::preloadModuleInfo 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 :-( Regards, Christian Boltz -- Früher als ich noch alles mit vi auf der Kommandozeile gemacht und X11 nur im Notfall und dann auch nur mit fvwm2 gestartet habe (Modelines selbstredend noch zu Fuß errechnet nicht mit so Warmduscher-Tools wie SaX) da wusste ich jederzeit dass ich ein Mann bin. Das ehrfürchtige Staunen von minderbemittelnden Windows-Usern, die zufällig Zeuge meiner rituellen Arbeit wurden war mir sicher. Heute fragen die nur noch wo ich die schöne Icons her hab. Scheiße ... [Hartmut Meyer in suse-linux] -- To unsubscribe, e-mail: opensuse-wiki+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-wiki+owner@opensuse.org

Matthew Ehle

18:36

...

...
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 trigger.

...

...
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.

debug=false&lang=en&2Cshared&only=styles&skin=bentofluid&http://enstage.opensuse.org/load.php?>debug=false&lang=en&modules=mediawiki.legacy.commonPrint%>2Cshared&only=styles&skin=bentofluid&* ( http://enstage.opensuse.org/load.php? ) 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: >http://www.mediawiki.org/wiki/Manual:Upgrading#Run_the_update_script ( http://www.mediawiki.org/wiki/Manual:Upgrading#Run_the_update_script ) Query: SELECT md_module,md_deps FROM `module_deps` WHERE md_module IN ('mediawiki.legacy.commonPrint','mediawiki.legacy.shared') AND md_skin = 'bentofluid' Function: ResourceLoader::preloadModuleInfo 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. -Matt

Christian Boltz

19:48

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

Matthew Ehle

19:59

...

...
...
...
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

Christian Boltz

22:31

Hello, Am Mittwoch, 7. Dezember 2011 schrieb Matthew Ehle:

...

...
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.

It's only a "nice-to-have", nothing you really need. I'd guess most people didn't miss it.

...

However, it certainly won't kill anyone to allow it.

Indeed ;-)

...

...
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 ;-)

The "It can only make things better" hit back in a way I didn't expect: I made my changes in bento/main.css (because this file already contained the not-specific-enough styles for red links), but it turned out now that this file is just dead, unused code :-/ Is it intentional that bento/main.css is not used? If it is (please double-check!), the file should be deleted to avoid confusion... I added the "red link" styles to bento/css_local/style.css (which is used for sure) and commited it to git. Please deploy once more ;-)

...

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.

Yes, version control is a "good thing"[tm]. (I'm not explicitely talking about git because all version control systems are good, even the good old CVS. And no, I don't say that CVS is better than git ;-) Regards, Christian Boltz -- Das einzige Feature von OE das du unter Linux nicht nachgebaut bekommen wirst: Die Virenschleuder ;-) [Damian Philipp in suse-linux] -- To unsubscribe, e-mail: opensuse-wiki+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-wiki+owner@opensuse.org

4524

Age (days ago)

4524

Last active (days ago)

List overview

Download

8 comments

2 participants

participants (2)

Christian Boltz
Matthew Ehle