Hi List,
I wanted to file this bug in the bugtracker, but i never got an signup reply from this form https://bugzilla.wikimedia.org/createaccount.cgi - to sorry for posting this here and not in the bugtracker.
I observe some very strange behavior regarding template parsing in mediawiki 1.11.0 and 1.12.0: I created some very simple Templates and they worked as expected when creating them. After some time now these templates are simply not parsed anymore in some articles. Instead {{<template name|<parameter>}} appears on the article page. I have no idea how to debug this, since this effect has already disappeared on some articles simply by doing nothing.
Any Ideas?
Many Thanks, Markus
__________________________________________________________
Gesendet von Yahoo! Mail.
Dem pfiffigeren Posteingang.
http://de.overview.mail.yahoo.com
On Thu, May 22, 2008 at 9:11 PM, <simetrical(a)svn.wikimedia.org> wrote:
> - if ( 'success' == $action ) {
> - $f->showSuccess();
> - } else if ( 'submit' == $action && $wgRequest->wasPosted()
> + if ( 'submit' == $action && $wgRequest->wasPosted()
I meant to remark on this but forgot. This *does* give the annoying
"request was POSTed" dialog if you refresh, hit back, etc. (and if you
say to re-POST then it will try to re-move the pages!). The old way
of doing it was untenable for this due to the sheer length of the URL
if nothing else; plus I find this to be exceptionally creepy:
http://en.wikipedia.org/w/index.php?title=Special:MovePage&action=success&o…
Visiting the URL does absolutely nothing, but I'd be pretty terrified
if I ended up there by mistake. :) It's very misleading.
Is there any way to do this that works better? The result page needs
to be dependent on the initial POST, but the re-POST dialog is kind of
unpleasant. Especially if someone clicks confirm on it, they're an
admin, and they originally specified to delete the target page --
although I haven't tested that, it sounds like it might be scary
(unless only redirects are ever deleted on move, in which case the
scenario is fairly unlikely). The only thing I can think of is using
the database somehow, which seems like a bad idea.
A few PHP design basics for people who have forgotten them.
== Lazy load everything ==
The hottest hotspot is always initialisation. Initialisation runs on every
single request. Every extension adds its own initialisation overhead, and
there may be many extensions. Therefore, it is critical that
initialisation is heavily optimised.
So if you're writing an extension, don't do anything at initialisation
time (either file scope or $wgExtensionFunctions) except setting globals
to literals.
Don't initialise data that you think you might need. Wait until you're
asked for it and load it then. Cache it if necessary. Think in terms of a
pull model, not a push model.
Loading large amounts of code is slow and memory hungry, especially on
installations without an opcode cache. So lazy-load your code, by putting
everything into autoloaded classes. Use static member functions for hooks.
== Global variables are evil ==
In MediaWiki, global variables should be used for configuration, and
nothing else. There are some legacy object globals defined in old code,
and you might have to use them from time to time, but don't go adding more
of them. And don't reference any global variable unless you have to.
If you do need to use a legacy global variable such as $wgUser, just put
the global statement where it's needed. Don't pull the object out of the
global namespace and pass it from function to function unless there's a
concrete need for that versatility.
Passing global objects from function to function is not a reasonable
substitute for direct reference to a global variable. When the revolution
comes, you will know it.
== Objects are hashtables ==
Member variables can be added and removed dynamically. It is your
fundamental right as a PHP programmer to do this, nobody will ever take it
away from you.
You can test for existence with isset($this->var), delete a variable with
unset($this->var), reference variables with dynamic names using
$this->$name, and even convert to and from the array type, (array)$obj.
It is nice from a self-documentation standpoint to put var declarations at
the top of your classes. But understand that a var declaration takes up
time and space when the object is initialised. If you leave it out, that
overhead can be deferred, and maybe skipped altogether.
But the most important part of this paradigm is that extensions can create
custom member variables in core objects.
Say if you're writing a hook and you need to cache some data. You could
put it in a global variable or static member variable, but the trouble is,
unless you're very careful, you lose versatility in the hook caller.
Most hooks have an object as their first parameter. This object is a great
place to put your extension data relating to that object. When the caller
is done with the object, it will go out of scope and your data will be
deleted. And your code will implicitly be versatile enough to support any
number of objects present in the system at any given time.
Prefix your custom member variables with the name of your extension, to
avoid conflicts.
I'm having a weird problem on Arabic Wikipedia.
Here are the results of conventional Whatlinkshere: http://tinyurl.com/5dfj4x
And an equivalent API query produces a list of only 3 pages: http://tinyurl.com/6sarwh
Another example: http://tinyurl.com/686bts
This doesn't seem to be reproducable anywhere else.
What am I doing wrong?
--
Max Semenik ([[User:MaxSem]])
Aaron recently committed an update to Special:SpecialPages [1] which adds
the long-awaited functionality of splitting the list of pages up into
shorter manageable sub-lists. Hurrah! However he didn't notice bug 10457
[2] which deals with this issue and which (a) has a couple of suggested
groupings for the various pages and (b) already had a patch (which I
contributed) for solving this same problem.
Before 1.13 comes out and this ends up in an official release I would like
to open up some discussion about a couple of points:
#1 - Extensions
My patch was written to allow extensions to easily add themselves to a
particular section, with any non-categorised extensions falling through into
a 'misc' section at the bottom. This was deliberately designed to be
backward compatible and easy to use.
In Aaron's method, SpecialPage:setGroup( $pagename, $group ) is the code to
use, which has two potential drawbacks:
* Extensions need to explicitly check which version of MW they are running
on before calling the code, otherwise errors will occur in earlier versions
which don't have this function.
* It requires an extra function call - this may not be a major problem (and
may just be a subjective matter of coding style), but it is if it causes the
SpecialPage class to be loaded permaturely (I don't know if this is the case
or not).
It would be good to get a bit of feedback on the two methods used to see
which is considered better in terms of both future-proofing and
backwards-compatibility (and of course any other considerations that may
apply). Of course, if there's no particular benefit to either method then
we should use the one that's already in place.
#2 - Grouping
There have now been three proposed groupings of the special pages. Aaron's
(currently live on WMF sites), Mine (in the patch I attached to the bug) and
Simetrical's (in the initial bug description). Obviously, I think mine is
best, but I don't think any of them are quite right yet. It would be good
to get some discussion and settle on a decent order.
Also, in my view there should be no sections with just a single item (my
code avoids this by moving single-item sections into 'miscellaneous', which
would be an easy thing to add to Aaron's code) and also the default sections
should not be as big as (for example) 'Other special pages' currently is.
Thanks to Aaron for getting this long-awaited feature into core.
- Mark Clements (HappyDog)
[1] http://svn.wikimedia.org/viewvc/mediawiki?view=rev&revision=33197
[2] https://bugzilla.wikimedia.org/show_bug.cgi?id=10457
Why is there a $time parameter there? Doesn't seem to be used.
Also, $titles looses the ones that are matched. That probably should be
documented, since a caller wouldn't expect that most likely.
--
View this message in context: http://www.nabble.com/includes-filerepo-FileRepo.php--r1%3D35096-r2%3D35095…
Sent from the Wikipedia Developers mailing list archive at Nabble.com.