[opensuse-web] Theming Issues Fixed
Hello, A bunch of the theming issues have now been fixed. The problem came from the new MW software using a new PHP script (loader.php) to pull in the javascript and stylesheets instead of having the browser pull them in directly. For security and aesthetic purposes, I have an Apache rewrite that redirects all but a specific list of PHP files. Since loader.php is new, it was not on that list, and Apache wasn't letting it run. Adding that file in the RewriteCond fixed it right up. The good news is that we can now take advantage of centralized loading of css and javascript. Since the majority of page loading time comes from dozens of HTTP requests for these resources, these front end optimizations should make the wikis *much* faster. 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? -Matt
Am Dienstag, den 06.12.2011, 09:01 -0700 schrieb Matthew Ehle:
Hello,
A bunch of the theming issues have now been fixed.
The problem came from the new MW software using a new PHP script (loader.php) to pull in the javascript and stylesheets instead of having the browser pull them in directly. For security and aesthetic purposes, I have an Apache rewrite that redirects all but a specific list of PHP files. Since loader.php is new, it was not on that list, and Apache wasn't letting it run. Adding that file in the RewriteCond fixed it right up.
The good news is that we can now take advantage of centralized loading of css and javascript. Since the majority of page loading time comes from dozens of HTTP requests for these resources, these front end optimizations should make the wikis *much* faster.
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?
-Matt
Hey, the Toolbar from Wiki-Editor is Back! Yeah, hooray we have returned Toolbar ;-) And the "gallery" is back .... very cool! But wait, the gallery showed otherwise 4 images in series and not 6 pictures. With 4 images in series, the looks mach better .... Maybe this can plaese be corrected? Great Job, thanks! -- Grüße aus' m Schwabenland ↓ → Lisufa, der Linuxsusefan ↓ ################################## ********************************** ....::: openSUSE Member :::..... ************************************************************* Die 'SuS(i)E' sei mit euch, wo immer ihr auch seid .... *************************************************************
Am Dienstag, den 06.12.2011, 17:18 +0100 schrieb LisufasGnome3:
Hey,
the Toolbar from Wiki-Editor is Back! Yeah, hooray we have returned Toolbar ;-)
And the "gallery" is back .... very cool! But wait, the gallery showed otherwise 4 images in series and not 6 pictures. With 4 images in series, the looks mach better .... Maybe this can plaese be corrected?
Great Job, thanks!
Sorry, here the link to Screenshot Page: http://en.opensuse.org/Screenshots to look after what I mean. -- Grüße aus' m Schwabenland ↓ → Lisufa, der Linuxsusefan ↓ ################################## ********************************** ....::: openSUSE Member :::..... ************************************************************* Die 'SuS(i)E' sei mit euch, wo immer ihr auch seid .... *************************************************************
Hello, @Matthew: Thanks for the fix! (And looks like my hint about missing load.php wasn't that wrong...) Am Dienstag, 6. Dezember 2011 schrieb LisufasGnome3:
Am Dienstag, den 06.12.2011, 17:18 +0100 schrieb LisufasGnome3:
the Toolbar from Wiki-Editor is Back! Yeah, hooray we have returned Toolbar ;-)
And the "gallery" is back .... very cool!
That's all caused by fixing load.php.
But wait, the gallery showed otherwise 4 images in series and not 6 pictures. With 4 images in series, the looks mach better .... Maybe this can plaese be corrected?
Please open a bugreport "My screen is too large" ;-) Seriously: The gallery layout now is floating and depends on the window size. If you reduce the width of your browser window, you'll get the 4 columns back ;-) IMHO that's a good change because the gallery now fits every screen / browser window size. Regards, Christian Boltz -- [ X-Mailer: Microsoft Outlook Express 6.00.2800.1106 ] Damit ist deinem Kmail der Preis für die gruseligste Halloween-Maske dieses Jahres sicher. [Andreas Koenecke zu Martin Mewes in suse-linux] -- To unsubscribe, e-mail: opensuse-web+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-web+owner@opensuse.org
Christian Boltz
12/6/2011 11:55 AM >>> Hello, @Matthew: Thanks for the fix! (And looks like my hint about missing load.php wasn't that wrong...) No, it wasn't. It seemed like that to me too, except it was there! I thought maybe it was actually generating the 404 error (like how index.php does), until I remembered our special setup. What's worse, the revelation hit me just as I was falling asleep last night :)
Am Dienstag, 6. Dezember 2011 schrieb LisufasGnome3:
Am Dienstag, den 06.12.2011, 17:18 +0100 schrieb LisufasGnome3:
the Toolbar from Wiki-Editor is Back! Yeah, hooray we have returned Toolbar ;-)
And the "gallery" is back .... very cool!
That's all caused by fixing load.php.
Are there any problems that we are having that this didn't fix?
But wait, the gallery showed otherwise 4 images in series and not 6 pictures. With 4 images in series, the looks mach better .... Maybe this can plaese be corrected?
Please open a bugreport "My screen is too large" ;-) Seriously: The gallery layout now is floating and depends on the window size. If you reduce the width of your browser window, you'll get the 4 columns back ;-)
IMHO that's a good change because the gallery now fits every screen / browser window size.
That's nothing... it's 8 columns on my screen :)
Hello, Am Dienstag, 6. Dezember 2011 schrieb Matthew Ehle:
A bunch of the theming issues have now been fixed.
The problem came from the new MW software using a new PHP script (loader.php) to pull in the javascript and stylesheets instead of having the browser pull them in directly. For security and aesthetic purposes, I have an Apache rewrite that redirects all but a specific list of PHP files. Since loader.php is new, it was not on that list, and Apache wasn't letting it run.
Yes, such a "special configuration"[tm] bites back sooner or later.
Adding that file in the RewriteCond fixed it right up.
Can you post this whitelist, please? (or send it only to me off-list if you don't want to publish it) I'd like to check if there is anything missing... (See also my other mail regarding diff view/api.php.)
The good news is that we can now take advantage of centralized loading of css and javascript. Since the majority of page loading time comes from dozens of HTTP requests for these resources, these front end optimizations should make the wikis *much* faster.
Indeed.
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 just checked it - links to non-existing pages have class=new, links to existing pages don't have any class= attribute. The problem is that the style for a.new is defined in each skin's CSS. For example, vector.css has: a.new, #p-personal a.new { color: #ba0000; } a.new:visited, #p-personal a.new:visited { color: #a55858; } The bento skin has (skins/bento/main.css): a.new, #p-personal a.new { color: #ba0000; } a.new:visited, #p-personal a.new:visited { color: #a55858; } This color is overwritten by this more specific style from https://static.opensuse.org/themes/bento/css/base.css .box .ui-oo-box-shadow a, .box a { color: #006699; } Given the files containing those styles, I'm not sure if the red link formatting was broken by the wiki update - it might have been broken before already. Anyway, I'm more interested in a fix than in finding out the history of a bug ;-) So in the end we need: [1] /* make red links (to non-existing pages) red */ .box a.new, #p-personal a.new { color: #ba0000; } .box a.new:visited, #p-personal a.new:visited { color: #a55858; } 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. Regards, Christian Boltz [1] I'm not sure about the .ui-oo-box-shadow class - maybe we need another style if red links in such boxes are not red. Does anyone know where a box with the ui-oo-box-shadow class is used? -- [KDE3 vs. KDE4] My guess is the vocal minority will only be satisfied when KDE4 gets dropped. We need to let them know that might happen round about the release of KDE5.4 . [from a comment on http://blogs.warwick.ac.uk/bweber/entry/opensuse_110_kde4/] -- To unsubscribe, e-mail: opensuse-web+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-web+owner@opensuse.org
Hello, Am Dienstag, 6. Dezember 2011 schrieb Christian Boltz:
[1] I'm not sure about the .ui-oo-box-shadow class - maybe we need another style if red links in such boxes are not red. Does anyone know where a box with the ui-oo-box-shadow class is used?
Found it - this class is used for the boxes on portal pages etc. And yes, I needed to add another style ;-) Gruß Christian Boltz -- [Serieller Anschluss] Mittlerweile ist (fast) alles USB. OK, es gibt auch Adapter, aber die kosten wieder extra. Und der Rechner soll später nicht aussehen wie ein Tannenbaum, mit einem Bündel herabhängender Adaptern anstatt Lametta. [Ralph Müller in suse-linux] -- To unsubscribe, e-mail: opensuse-web+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-web+owner@opensuse.org
Christian Boltz
12/6/2011 1:22 PM >>> Hello, Am Dienstag, 6. Dezember 2011 schrieb Matthew Ehle:
A bunch of the theming issues have now been fixed.
The problem came from the new MW software using a new PHP script (loader.php) to pull in the javascript and stylesheets instead of having the browser pull them in directly. For security and aesthetic purposes, I have an Apache rewrite that redirects all but a specific list of PHP files. Since loader.php is new, it was not on that list, and Apache wasn't letting it run.
Yes, such a "special configuration"[tm] bites back sooner or later.
Adding that file in the RewriteCond fixed it right up.
Can you post this whitelist, please? (or send it only to me off-list if you don't want to publish it) I'd like to check if there is anything missing... (See also my other mail regarding diff view/api.php.)
Here's the entire rewrite: RewriteEngine on RewriteCond %{REQUEST_URI} !^/(skins|stylesheets|images|config|extensions)/ RewriteCond %{REQUEST_URI} !^/(redirect|texvc|index|load|api).php RewriteCond %{REQUEST_URI} !^/robots.txt RewriteCond %{REQUEST_URI} !^/sitemap.*?(xml|xml\.gz)$ RewriteRule ^(.*)$ /index.php?title=$1 [L,QSA] As you can see, if it's not a specific directory, PHP file, or search engine file, it gets translated to a wiki page. Without load.php in there, we were trying to look it up as a wiki page (hint, this doesn't work).
The good news is that we can now take advantage of centralized loading of css and javascript. Since the majority of page loading time comes from dozens of HTTP requests for these resources, these front end optimizations should make the wikis *much* faster.
Indeed. I've noticed a big difference, personally.
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 ;)
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!
Hello, Am Dienstag, 6. Dezember 2011 schrieb Matthew Ehle: > >>>> Christian Boltz12/6/2011 1:22 PM >>> > >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 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. > 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. Regards, Christian Boltz -- An NT server can be run by an idiot, and usually is. [Tom Holub,a.h.b-o-u] -- To unsubscribe, e-mail: opensuse-web+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-web+owner@opensuse.org
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
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-web+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-web+owner@opensuse.org
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.
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-web+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-web+owner@opensuse.org
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
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-web+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-web+owner@opensuse.org
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
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-web+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-web+owner@opensuse.org
On 07.12.2011 23:31, Christian Boltz wrote:
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 think it's not used and a leftover copy from creating the skin, so I removed it in git. Btw.: I think the lists opensuse-wiki and opensuse-web are merged to the latter, so no need to double post everything ;-) Greetings
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
-- Thomas Schmidt (tom [at] opensuse.org) openSUSE Boosters Team "Don't Panic", Douglas Adams (11.03.1952 - 11.05.2001) -- To unsubscribe, e-mail: opensuse-web+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-web+owner@opensuse.org
Hello, Am Donnerstag, 8. Dezember 2011 schrieb Thomas Schmidt:
On 07.12.2011 23:31, Christian Boltz wrote:
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 think it's not used and a leftover copy from creating the skin, so I removed it in git.
Thanks for checking and removing it ;-)
Btw.: I think the lists opensuse-wiki and opensuse-web are merged to the latter, so no need to double post everything ;-)
I'm not sure about that - it seems that the -wiki still exists as separate list. Please ask Henne about it - my guess is that he didn't merge the lists yet, or at least didn't shut down the -wiki list. (I sent him a mail about this a week ago, no response yet.) Regards, Christian Boltz -- [Evolution - Message-ID] Oh ja... Apropos: die libcamel (die fuer diesen Muell verantwortlich ist) ist, aehm. "interessant" zu lesen... Und NEIN! Ich habe keine Lust, den Muell zu fixen. Es sei denn, man zahlt mir Schmerzensgeld. [David Haller in suse-linux] -- To unsubscribe, e-mail: opensuse-web+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-web+owner@opensuse.org
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. However, it certainly won't kill anyone to allow it.
I just added the enstage search to my firefox search box, and I get the same results as with the search box in the wiki ;-) It looks like enstage doesn't have the Lucene indexing enabled, which makes searching somewhat pointless. The only thing that can be found are exact page title matches. (For both wiki search and firefox search box.) Nevertheless I'd vote to allow access to opensearch_desc.php on the "real" wikis ;-) - it will most probably provide the full-featured search there. BTW: enstage is quite fast now - thanks! Regards, Christian Boltz -- Are you complaining because we are lacking a time machine and are not able to backport fixes from the future into current kernels? [Hubert Mantel] -- To unsubscribe, e-mail: opensuse-web+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-web+owner@opensuse.org
Hi,
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?
for example watch here: http://it.opensuse.org/SDB:NVIDIA . The two links in "Driver Open Source" section are to a new empty page since they does not exist. They are yet blue and not red. Thanks for help and for fixing... ALL! :D Bye hawake -- Linux user number 433087 Linux registered machine number 351448 http://counter.li.org/ -- To unsubscribe, e-mail: opensuse-web+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-web+owner@opensuse.org
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?
for example watch here: http://it.opensuse.org/SDB:NVIDIA . The two links in "Driver Open Source" section are to a new empty page since they does not exist. They are yet blue and not red.
Thanks for help and for fixing... ALL! :D
It looks like Christian Boltz found the problem and a solution. If you follow the instructions that he gave on the mailing list about an hour ago, you should be all set! -Matt
participants (5)
-
Christian Boltz
-
G G
-
LisufasGnome3
-
Matthew Ehle
-
Thomas Schmidt