Well, with the release notes freshly trimmed for 1.14, it seems like a
good time to bring this up. A while back, someone or other removed
references in specific RELEASE-NOTES features to who submitted the
patch to fix the feature. Brion reverted that, calling it bad form.
The thing is, though, that's exactly the policy we follow for everyone
who contributes to the project: there's no mention in the release
notes. The only way you could find out who actually develops
MediaWiki at present is by hunting through commit logs and trying to
match up names with commit aliases somehow. Special:Version is very
incomplete, and most of the people listed aren't currently active.
A lot of projects mention who contributed to specific versions, and I
think it would be perfectly reasonable for us to do the same. I would
suggest two sections of contributors: people who contributed code to
the specific version, and people who contributed translations. Each
one could be ordered alphabetically by last name, or some other
criterion if people think of one. (Like putting Brion and Tim at top,
and maybe putting regular committers above one-time patch submitters.)
If someone contributes a patch via Bugzilla or whatever, they get
added to the list like anyone who personally committed code, not
inline with the feature they added.
What does everyone think?
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
simetrical(a)svn.wikimedia.org wrote:
> + if( $nt->equals( $wgTitle ) ) {
> + wfRunHooks( 'EditSectionLink', array( &$this, $nt, $section, $attribs, $url, &$result ) );
> + } else {
This comparison fails during API-based parsing, and perhaps at other
times when $wgTitle isn't available. (Bug 14965.)
I've reverted the change for now, so parsing works again.
Fun note on PHP debugging -- I had a heck of a time tracking this
problem down until I saw the bug report.
The original problem spewed errors like this to our error log:
PHP Fatal error: Call to a member function getInterwiki() on a
non-object in /usr/local/apache/common-local/php-1.5/includes/Title.php
on line 3005
that tells us that something is calling Title::equals() with a null
parameter, but not what.
I tried slipping in a check for null and throwing an exception, which
should be logged with more details.... but the exception didn't get logged!
Once I found the bug report with the same error in it I was able to
reproduce it locally with a copy of the parsed page, and could track it
down...
So two fun lessions:
1) I found that I could get useful error messages by adding a type hint
to Title::equals():
PHP Catchable fatal error: Argument 1 passed to Title::equals() must be
an instance of Title, null given, called in
/usr/local/apache/common-local/php-1.5/includes/Linker.php on line 1323
and defined in /usr/local/apache/common-local/php-1.5/includes/Title.php
on line 3003
This error now tells me *who called* the function with the bad
parameter, which is much more useful!
2) The separate exception handling paths in the API and the general UI
can cause trouble, as here where exceptions aren't being logged via
wfDebugLog().
Should be an easy fix, but it's the kind of thing we should avoid --
separate code paths for the same thing tend to lead to divergent behavior.
- -- brion
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkiOUVoACgkQwRnhpk1wk46TbwCeMgnCWKA/qfvJQ5wy6hOVS4Dy
p+wAn3z8SRhIIP/fL+S7EGe5dbGfe55F
=89jK
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Did a little refactoring on how stylesheets are set up and linked in
SkinTemplate skins (MonoBook & friends), which cleans up some icky
template code with the IE conditional styles and enables the ability to
configure a handheld stylesheet.
I wrote up some quick notes here:
http://leuksman.com/log/2008/07/27/handheld-css-variants/
Currently live I'm specifying the Chick skin's style as a handheld
variant for MonoBook. This in theory will only be picked up by browsers
which ignore the 'screen' style already, and it doesn't disrupt basic
loading much.
(Variants friendly to iPhone and Opera Mini's fancy display mode might
be nice, but need a lot more work.)
There's some open questions about which style pages should be explicitly
listed as for 'screen' and which should be left for all media -- screen,
print, and handheld. Behavior now may be slightly different than
previous (I think I list more as 'screen'-specific than before), but can
be easily tweaked.
Note you can now do &handheld=yes like the &printable=yes for a preview.
Yay!
Also, use of <link> consistently in place of @import means Firefox (at
least) will be willing to save styles to disk along with the .html file.
Yay!
- -- brion
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkiNaXQACgkQwRnhpk1wk44QZwCfUZ6109cRiARhY40z2FXX9ntS
D9gAoMU7ASEP1AOviabAhYTITHVnWumM
=oHdW
-----END PGP SIGNATURE-----
Hello all,
any news when the EditAPI will be enabled site-wide?
IMO it's been running long enough now on testwiki and has proven to be
stable enough.
Marco
On Fri, Jul 25, 2008 at 10:59 PM, <demon(a)svn.wikimedia.org> wrote:
> +The word "substall" can be customized by editing the "substall-hook"
> +message on your MediaWiki (navigate to [[MediaWiki:Substall-hook]]
> +and replace it with any single word you'd like).
This seems kind of scary. What happens if it's set to "ref" or "p" or
something? It also makes behavior inconsistent across wikis. It
would surely be better if you just used the usual method of magic word
localization.
I'm posting on behalf of a friend of mine whose username is "Cmglee".
Please could one of the admins check why his username was not turned
into a global account when single sign-on was introduced? It would be
nice if this could be remedied and his account turned global.
He created a new account (same username) at Commons today. Please merge
it into the new global account.
Thanks,
Timwi
A friend of mine just asked me why he couldn't upload an image to Wikipedia.
It turned out that he was trying to replace an image that exists at the
Commons.
The error message is confusing/misleading. It insists that you use a
different filename. It does not mention at all the possibility of
replacing the image on Commons. I think it should recommend to replace
the image at the Commons, and only if that is undesired, use a different
filename. Otherwise his image won't replace the old, and the old would
remain at the Commons and his improvement would go unused.
Timwi
UsernameBlacklist makes the servers crash when people try to create
accounts. This is due to the excessively complex regexes entered by
administrators. PCRE has lots of bugs which allow you to crash it with
arbitrary regexes, but as long as you keep them simple (like in
SpamBlacklist), it's not a problem.
The extension has been disabled pending a workaround.
-- Tim Starling
I've implemented a new feature, which allows users to automatically fix
double redirects which are created when they move a page. It's live now on
Wikimedia projects.
On the page move form, a checkbox is shown, checked by default, labelled
"update any redirects which point to the original title". Jobs are
inserted into the job queue in order to perform the edits. The edits are
performed by a user called "Redirect fixer", or the equivalent localised
by [[MediaWiki:double-redirect-fixer]]. This user is created in the user
table if it doesn't already exist, so it has a valid user ID. Its edits do
not show up in Recent Changes.
Before each edit is performed, the redirect fixer will follow the chain of
redirects to find the current final destination. It will then edit the
page to point to that final destination. If there is a circular reference
or invalid redirect, no action is taken. If the page is no longer a double
redirect (say because the move was reverted), then no action is taken.
If the page has changed since the move was performed, the edit is not done.
The number of job queue threads has been increased.
This feature was inspired by a meeting with White Cat at Wikimania, seeing
the terrible conditions his bots are forced to work under, shoulder to
shoulder in 15 tiled command prompt windows, fixing double redirects all
day and all night, working their poor little fingers to the bone. It was
very sad.
Comments would be appreciated.
-- Tim Starling
On Thu, Jul 24, 2008 at 5:54 PM, <alnokta(a)svn.wikimedia.org> wrote:
> Log Message:
> -----------
> Set $wgTranslateNumerals to false by default.
This needs to be documented in RELEASE-NOTES somewhere.