Please join our next Tech Talk via video streaming:
MediaWiki Upgrades and Extension Dependencies – Ideas for Improvement
Friday, December 13, 2013, 19:00 UTC
http://www.timeanddate.com/worldclock/fixedtime.html?iso=20131213T19&p1=1440
Facilitators: Mark Hershberger and Markus Glaser.
Watch https://www.mediawiki.org/wiki/Meetings/2013-12-13 or
#wikimedia-dev IRC for URL details.
Upgrading MediaWiki is easy, upgrading a MediaWiki site using extensions
is not. Versioning extensions and aligning them with MediaWiki versions
is not done consistently. And how would you know which extension version
works for your slightly older MediaWiki, e.g. because you are using a
LTS version? The talk explores the various possiblities of remedy for
this issue. It'll cover:
* the current situation
* the question of how we version extensions
* the question of how we manage dependencies
* an idea of using our users' power to know what's working
* of course, a discussion
Technically, we'll touch issues of LTS versions, git tagging and
branching, Composer support, WikiApiary, usage statistics and crowd
certification.
--
Quim Gil
Technical Contributor Coordinator @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil
Hi,
I'm almost asleep, so this might be terrible wrong, but who knows:
This is all based on the presumption that
$this->mMemc->get( $this->getOptionsKey( $article ) ); (in ParserCache)
returned false on Wikidata because the cache has been disable before or
whatever.
Then the problem is as follows:
One calls ParserCache::get() with $useOutdated=false (default value).
ParserCache::get calls out to ParserCache::getKey (with $useOutdated
still false).
That one then does: $this->mMemc->get( $this->getOptionsKey( $article )
).
If that returns false and $useOutdated is false also:
$usedOptions = ParserOptions::legacyOptions(); (line 152)
will be called which then nukes all our ParserOptions.
Cheers,
Marius
On Tue, 2013-12-10 at 21:45 +0100, Daniel Kinzler wrote:
> Hi.
>
> I (rather urgently) need some input from someone who understands how parser
> caching works. (Rob: please forward as appropriate).
>
> tl;dr:
>
> what is the intention behind the current implementation of
> ParserCache::getOptionsKey()? It's based on the page ID only, not taking into
> account any options. This seems to imply that all users share the same parser
> cache key, ignoring all options that may impact cached content. Is that
> correct/intended? If so, why all the trouble with ParserOutput::recordOption, etc?
>
>
> Background:
>
> We just tried to enable the use of the parser cache for wikidata, and it failed,
> resulting in page content being shown in random languages.
>
> I tried to split the parser cache by user language using
> ParserOutput:.recordOption to include userlang in the cache key. When tested
> locally, and also on our test system, that seemed to work fine (which seems
> strange now, looking at the code of getOptionsKey()).
>
> On the life site however, it failed.
>
> Judging by its name, getOptionsKey should generate a key that includes all
> options relevant to caching page content in the parser cache. But it seems it
> forces the same parser cache entry for all users. Is this intended?
>
>
> Possible fix:
>
> ParserCache::getOptionsKey could delegate to ContentHandler::getOptionsKey,
> which could then be used to override the default behavior. Would that be a
> sensible approach?
>
> And if so, would it be feasible to push out such a change before the holidays?
>
> Thanks,
> Daniel
>
Dear all,
just a short note from Wikimedia CH that we are currently preparing the
2014 Hackathon in Zürich.
Contracts are about to be signed and we want to let you know that you
can count on us to create you an unique experience in Switzerland.
Date: May 9th - 11th
Location: Youth Hostel Zürich
A preliminary page can be found on MediaWiki.org
More to come soon!
Feel free to contact us in case of questions!
Charles and Manuel
--
Manuel Schneider - Chief Information Officer
Wikimedia CH - Verein zur Förderung Freien Wissens
Lausanne, +41 (21) 340 66 22 - www.wikimedia.ch
Hi.
I filed <https://bugzilla.wikimedia.org/show_bug.cgi?id=58250> if you or
someone you know feels like writing a small script that can report new and
status changes to MediaWiki requests for comments on a weekly basis to
this mailing list. I think such a script would directly improve
participation in RFCs.
MZMcBride
For wider discussion
----
From: <bugzilla-daemon <at> wikimedia.org>
Subject: [Bug 58235] New: Remove skin selection from Wikipedia and
Wikimedia site Special:Preferences for new user
accounts<http://news.gmane.org/find-root.php?message_id=%3cbug%2d58235%2d3%40https.b…>
Newsgroups: gmane.org.wikimedia.mediawiki.bugs<http://news.gmane.org/gmane.org.wikimedia.mediawiki.bugs>
Date: 2013-12-09 20:27:15 GMT (35 minutes ago)
https://bugzilla.wikimedia.org/show_bug.cgi?id=58235
Web browser: ---
Bug ID: 58235
Summary: Remove skin selection from Wikipedia and Wikimedia
site Special:Preferences for new user accounts
Product: Wikimedia
Version: wmf-deployment
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: Unprioritized
Component: Site requests
Assignee: wikibugs-l <at> lists.wikimedia.org
Reporter: jared.zimmerman <at> wikimedia.org
CC: benapetr <at> gmail.com,
bugzilla+org.wikimedia <at> tuxmachine.com,
dereckson <at> espace-win.org, greg <at> wikimedia.org,
tomasz <at> twkozlowski.net, wikimedia.bugs <at> snowolf.eu
Classification: Unclassified
Mobile Platform: ---
To reduce the support burden on foundation developers and designers when
creating new features or improving existing ones, skin selection and related
preferences should be removed for newly created accounts and the default skin
(currently vector) used for all new accounts.
A new access point for custom css/js should be added if necessary.
--
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
_______________________________________________
Wikibugs-l mailing list
Wikibugs-l <at>
lists.wikimedia.orghttps://lists.wikimedia.org/mailman/listinfo/wikibugs-l
Ciao gvf,
Francesca ha cercato disperatamente di embeddare un video in Wikina,
non sapendo che però non si può fare.
Pensavo avessimo in passato installato qualche estensione per farlo,
ma ho ricontrollatto in Speciale:Versione[1] e non mi pare.
Ho visto che c'è questa estensione che potrebbe andare bene:
http://www.mediawiki.org/wiki/Extension:EmbedVideo
La potresti installare per favore?
Grazie,
Cristian
[1] http://wiki.wikimedia.it/wiki/Speciale:Versione
Dear MediaWiki Hackers ,
WikiMedia Israel is pleased to announce a second Hackathon in Tel Aviv.
If anyone is staying in Israel or Visiting for Xmas consider joining us at a
developer conference and will be held in the hackaton format - (less
lectures and more coding, adding features and fixing pesky bugs. )
On the hour, every hour we will host lightning talk in a subject related to
wiki technology or research. (lightning talks are about 5 minutes long) Some
of the slots are currently open - so let us know if you have some
interesting updates ?
Schedule:
10:00 - Start and Registration.
10:30 - Opening Words and Setting up teams.
>From this point on we will code in teams with short breaks for meals and
brief lightning talks (5 minutes)
12:00 - Lightning talk on MediaWiki Eco system.
13:00 - Lightning talk on Google summer of code.
14:00 - Lunch
15:00 - Lightning talk on translation, internationalization and
localization.
16:00 - Lightning talk on (Suggest a subject) .
17:00 - Lightning talk on (Suggest a subject).
At this point we suggest you prepare a demo on what you have developed or
learned.
18:00 - Lightning talk on (Suggest a subject).
19:00 - Dinner.
19:30 - Demos.
22:00 - Closing.
http://www.meetup.com/MediaWiki-TLV/ English registration
http://www.wikimedia.org.il/events/hackathon-2013/ Hebrew registration
Any questions can be directed to me at
OrenBochman(a)gmail.com
---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com
