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

...

...

...

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?

...

http://en.opensuse.org/Screenshots

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

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

Hello,

Am Dienstag, 6. Dezember 2011 schrieb Matthew Ehle:
> >>>> Christian Boltz  12/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

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

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

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

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

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