I know there was talk here (or maybe on Bugzilla - I forget) about improving the edit links, and I guess someone is working on it, because currently they are screwed on en and mw.org (and presumably all other WM wikis - not checked).
They are appearing above the heading, i.e. at the bottom of the preceeding section to the one they apply to... which is _incredibly_ confusing! It even confused me - a long-time editor...
I'm sure someone is working on this right now, but they may not be aware that the changes are live.
- Mark Clements (HappyDog)
On 10/12/06, Mark Clements gmane@kennel17.co.uk wrote:
I know there was talk here (or maybe on Bugzilla - I forget) about improving the edit links, and I guess someone is working on it, because currently they are screwed on en and mw.org (and presumably all other WM wikis - not checked).
They are appearing above the heading, i.e. at the bottom of the preceeding section to the one they apply to... which is _incredibly_ confusing! It even confused me - a long-time editor...
I'm sure someone is working on this right now, but they may not be aware that the changes are live.
That was me borking up in one of my first commits, last night. I unhardcoded the section edit link style and moved it to stylesheets, but didn't bump the stylesheet number, so the old cached versions were being used, resulting in no style for the edit links.
Brion bumped the numbers up on Monobook and then resynchronized, so this should be fixed in Monobook now (it is for me, anyway). I just bumped up the numbers for all the other skins, so those will be fixed in the next resync. (Actually, I missed at least one, but Brion just bumped that up, so it should all be good.)
Does the problem still occur? It appears to be working correctly for me now.
"Simetrical" Simetrical+wikitech@gmail.com wrote in message news:7c2a12e20610121535u370b343p6046c097931c8030@mail.gmail.com...
On 10/12/06, Mark Clements gmane@kennel17.co.uk
wrote:
I know there was talk here (or maybe on Bugzilla - I forget) about
improving
the edit links, and I guess someone is working on it, because currently
they
are screwed on en and mw.org (and presumably all other WM wikis - not checked).
Does the problem still occur? It appears to be working correctly for me
now.
Yup, fine.... I guess you know that by now, but I didn't want to leave your question dangling. :)
- Mark Clements (HappyDog)
Simetrical wrote:
That was me borking up in one of my first commits, last night. I unhardcoded the section edit link style and moved it to stylesheets, but didn't bump the stylesheet number, so the old cached versions were being used, resulting in no style for the edit links.
Brion bumped the numbers up on Monobook and then resynchronized, so this should be fixed in Monobook now (it is for me, anyway). I just bumped up the numbers for all the other skins, so those will be fixed in the next resync. (Actually, I missed at least one, but Brion just bumped that up, so it should all be good.)
I've now centralized this in a single global config var, $wgStyleVersion. Bump this whenever making changes to .css or .js files in the core distribution. When adding new such files, don't forget to include "?$wgStyleVersion" on the link.
For those not familiar with the technique, this is an easy way to make style updates cache-friendly. Newly rendered pages which depend on the new styles will include the links with the bumped number -- the query string is ignored by the server (which is reading a static file) but the client will consider it a new URL and so pull the file fresh instead of using the previous cached version.
We had been using this haphazardly; now just bumping that one var in DefaultSettings.php will bump all imported styles consistently, so it's harder to forget something.
Note that there can still be problems sometimes with old cached pages and new styles/scripts, so it's best for new .css/.js file versions to remain reasonably compatible with older generated HTML.
-- brion vibber (brion @ pobox.com)
I've now centralized this in a single global config var, $wgStyleVersion. Bump this whenever making changes to .css or .js files in the core distribution. When adding new such files, don't forget to include "?$wgStyleVersion" on the link.
For those not familiar with the technique, this is an easy way to make style updates cache-friendly. Newly rendered pages which depend on the new styles will include the links with the bumped number -- the query string is ignored by the server (which is reading a static file) but the client will consider it a new URL and so pull the file fresh instead of using the previous cached version.
We had been using this haphazardly; now just bumping that one var in DefaultSettings.php will bump all imported styles consistently, so it's harder to forget something.
Just thinking aloud here, but what if the $wgStyleVersion string was determined automatically by MediaWiki?
For example, for a stable release, it could use the $wgVersion string as the $wgStyleVersion (and even though there'd be some erroneous cache-misses on a stable version upgrade, it wouldn't be a big deal, because stable version updates happen relatively infrequently). And in an SVN-tracking environment it could perhaps do something like ' max( "committed-rev" string in .svn/entries for skins/common/wikibits.js, "committed-rev" string in .svn/entries for skins/monobook/main.css, and so forth for the list of CSS/JS files) '. ( In other words, something sort of semi-similar to the way that the version string in [[Special:Version]] automatically displays the SVN revision number for a development tree, or just the $wgVersion for a stable install. )
The upside is that there'd be one less thing for us fallible humans to have to remember (and predictably forget).
The downside though is doing it in a way that doesn't kill performance.
All the best, Nick.
wikitech-l@lists.wikimedia.org