Hi all
Phpunit tests that use the database should use @group Database. But that makes
them extremely slow. I'd like to elevate this problem. Here's the situation:
@group Database does two things, as far as I understand:
* MediaWikiTestCase will notice this group and use temporary tables instead of
the wiki database's actual tables. The temporary tables are re-created for every
test. This protected the wiki from modifications through test cases, and
isolates test. So far, so good.
* Jenkins will do one run for tests with @group Database, and a separate run for
tests *without* @group Database - the latter test is actually run without any
database connection. Any test using the database in any way, and be it only
indirectly and for reading, will fail if it doesn't declare @group Database. Or
so it seems.
There are a number of test cases (and there could and should be many many more)
that use the database for reading only. It would be good to have a @group
DatabaseRead, that does not enforce the slow and expensive creation of temporary
tables, but allows the tests to be run with a database connection in place. This
run could use a connection with a database user that has read-only rights to the
database.
If we decide to do this, there should be some way to define and re-create the
initial contents of the read-only database. Perhaps a maintenance script that
other parts of the code (and extensions) can register with could do the trick.
What do you think? Is this feasible?
-- daniel
Hi all,
We have a longstanding request to enable HTML5 on all sites:
https://bugzilla.wikimedia.org/show_bug.cgi?id=27478
We've had it enabled on mediawiki.org for ages, with minimal death and
mayhem. There are two issues listed as blockers:
Bug 30525: Search bar icon/button slightly lower when html5 mode is enabled
https://bugzilla.wikimedia.org/show_bug.cgi?id=30525
Bug 36495: Sanitizer incorrectly converts align="right" for elements
that are not table-cells
https://bugzilla.wikimedia.org/show_bug.cgi?id=36495
Bug 30525 doesn't seem like a blocker to me (but patches definitely
welcome). Bug 36495 seems more likely to cause problems, though I'd
like to nudge Krinkle to explain Comment 9.
Assuming we can either get these fixed, or agree they aren't blockers,
I say we set a date and go. Should we plan on sometime in July (say a
week or two after Wikimania)?
Rob
Hi all,
we are trying to let users switch their language - whether they are
logged in or not - through a language selector. This can be either the
ULS, which is progressing impressively, or just a list of languages in
the sidebar, or anything else. After selecting it, the page is
rerendered using the uselang parameter.
Now the problem: the uselang parameter is not sticky. When I move to
another page, it is lost.
We tried to change the linker in order to add the uselang parameter
every time -- but it only works in the content, not in the sidebar and
actionlinks.
We could put the language into a cookie, as the ULS currently does,
but this means that the squid caches won't work, afaik.
We could take the output just before it is send to the browser and
regex-substitute all the links in order to add the uselang parameter
every... OK, half joking. Only half.
Another solution could be to put the language into the path, i.e. the
pretty URL /wiki/San_Franicisco does get rewritten to
/w/index.php?title=San_Francisco as of now, but change that to
/hr/San_Francisco rewritten to /w/index.php/San_Francisco?uselang=hr
(or /w/index.php/Special:UseLang/hr/San:Franciso with an Alias if this
is more pleasing)
I think this is based on an idea of Brion during the Hackathon.
So switching the user language amounts to change the URL.
Any comments on this?
Cheers,
Denny
--
Project director Wikidata
Wikimedia Deutschland e.V. | Obentrautstr. 72 | 10963 Berlin
Tel. +49-30-219 158 26-0 | http://wikimedia.de
Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg
unter der Nummer 23855 B. Als gemeinnützig anerkannt durch das
Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985.
Hello!
I thought I'd reach out to the wider wikitech community to discuss a
problem we are having in the MobileFrontend extension and see if
anyone can come up with a good solution.
The MobileFrontend extension is increasingly getting [1] bugs [2]
raised [3] which are due to inline css styles present in certain wiki
articles that are written with the desktop site in mind. (Slightly off
topic there is also certain content that just doesn't work on mobile
[4])
To get an idea of some of the bugs that are present please see this bug [5].
Currently we are resorting to various !important hacks in a separate
css file [6] but this is not sustainable and does not cover everything
and ideally I would prefer that this file was not needed at all.
Solutions I have thought about so far involve the following. I am yet
to conclude on which is the best way to do this so would really
appreciate discussion...
1) scrubbing all inline styles
#########################
* in php - my worry is this would be a quite expensive operation?
* in javascript (but this doesn't help people with javascript disabled)
* would mean any nice mobile safe styling disappears :(
2) scrubbing certain inline styles
#########################
* I could imagine us scrubbing any inline styles which have not been
marked as mobile safe (e.g. anything with a class 'mobilesafe' keeps
its inline style) - this at least allows editors to use pretty styles
and encourages checking their styles on mobile
3) disallowing inline styles in wikitext output
##################################
* this is controversial as it would restrict us to defining css rules
in MediaWiki:Common.css which only admins can edit
** one could imagine pages/templates being able to maintain their own
stylesheets for desktop and mobile to allow customisations
** ResourceLoader could serve the desktop or mobile stylesheet
depending on the context
4) educating editors better about ensuring their styles work on mobile
#############################################
I'm not sure how effective/sustainable this would be and how we'd go
about doing this... but would be keen to hear your thoughts around it.
[1] https://bugzilla.wikimedia.org/show_bug.cgi?id=30887
[2] https://bugzilla.wikimedia.org/show_bug.cgi?id=36030
[3] https://bugzilla.wikimedia.org/show_bug.cgi?id=36076
[4] https://bugzilla.wikimedia.org/show_bug.cgi?id=20030
[5] https://bugzilla.wikimedia.org/show_bug.cgi?id=35704
[6] https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/extensions/MobileFrontend…
> How can I prevent this conversion so ampersands (and presumably other special characters) are preserved?
Followup up my own question: StripState is not relevant here. It's the fact that it's a parser tag extension. Simply returning "&" in the callback will produce "&". Is there a way to suppress this conversion when returning "&" from a parser tag extension?
DanB
In a parser tag callback, if I change this:
function myCallback($input, $argv, $parser) {
return '&';
}
to this:
function myCallback($input, $argv, $parser) {
return array('&', 'markerType' => 'nowiki');
}
shouldn't the second one cause a plain ampersand to be rendered, rather than & ?
Reference: http://www.mediawiki.org/wiki/Manual:Tag_extensions#How_can_I_avoid_modific….
This is MediaWiki 1.18.1.
Thanks,
DanB
_____________________________________________
From: Daniel Barrett
Sent: Friday, June 29, 2012 3:42 PM
To: 'Wikimedia developers'
Subject: RE: StripState and ampersands?
> How can I prevent this conversion so ampersands (and presumably other special characters) are preserved?
Followup up my own question: StripState is not relevant here. It's the fact that it's a parser tag extension. Simply returning "&" in the callback will produce "&". Is there a way to suppress this conversion when returning "&" from a parser tag extension?
DanB
Would anyone be interested in a program that generates Skeletons for new
extensions? I've noticed that when I make extensions I generally go through
the exact same process (with minor variations) each time.
The idea in my head right now is for a program that does the following:
* Asks for the Extension name and other Credit information
* Asks whether or not the extension is going to need to change the
database schema
* Asks whether or not the extension is going to make use of ResourceLoader
* Asks whether or not the extension is going to include a Special Page
* Depending on the answers to the above it may do some of the remaining
items on this list
* Creates a folder hierarchy with the following folders:
ExtensionName
|- includes
|- js
|- images
|- styles
|- sql
* Create skeleton files for ExtensionName.php, ExtensionName.i18n.php,
ExtensionName.alias.php, and SpecialExtensionName.php
* Create a skeleton file for sql\ExtensionName.sql
* Creates table, adds ID column UNIQUE PRIMARY
* Includes basic configuration for Schema Updates in ExtensionName.php
* Includes basic configuration for Special Page in ExtensionName.php
* Includes basic configuration for Resource Loader in ExtensionName.php
If anyone is interested in getting a copy when it is done, or can think of
any other useful things it might be able to make use of, let me know. I
feel like having something like this will help eliminate a lot of
development time for simple extensions, especially those created by people
new to extension development.
Thank you,
Derric Atzrott
Computer Specialist
Alizee Pathology
Hello everyone,
It’s with great pleasure that I’m announcing that Matt Walker has joined the Wikimedia Foundation as a Fundraising Engineer.
Before joining us, Matt was a software engineer at Rockwell Collins Control Technologies developing “a DO-178B level A qualified Real-Time Operating System in C and PowerPC assembly.” (Ask him about it.) He got his dual B.S. in EE and CS from the University of Tulsa with a minor in Mathematics.
On the side, Matt enjoys tech theatre, glass blowing, SCUBA diving, hiking, and bicycling so I’m not sure how he’ll fit in with his move to the Bay Area. During the reference check, the department chair of Electrical Engineering at his uni regaled me with stories about a time lapse video project he self-started and having to sign a permission slip for a high school prom.
His first official day will be on July 9th assuming he survives his cross-country trip through Wyoming and the Dakotas. (I’ve seen the trailers for Longmire <http://en.wikipedia.org/wiki/Longmire_(TV_series)> so it’s not a given — Wyoming sounds like a very dangerous place.) He will be working with the FR-Tech team trying to establish the lower bounds for the Ballmer Peak <http://xkcd.com/323/> during their late night programming sessions; Katie and Peter will be establishing the Long Tail.
He’s also great friends with Peter Gehres, but we won’t hold that against him. :-) Please join me in welcoming Matt to the Wikimedia Foundation.
Take care,
Terry
terry chay 최태리
Director of Features Engineering
Wikimedia Foundation
“Imagine a world in which every single human being can freely share in the sum of all knowledge. That's our commitment.”
p: +1 (415) 839-6885 x6832
m: +1 (408) 480-8902
e: tchay(a)wikimedia.org
i: http://terrychay.com/
w: http://meta.wikimedia.org/wiki/User:Tychay
aim: terrychay
How do you format dates according to user preference in Mediawiki? I
presume it has something to do with DateFormatter
(http://svn.wikimedia.org/doc/classDateFormatter.html), but I'm not 100%
sure how to make use of this class.
The extension I am working on displays, among other things, a last update
time for its data. I want this time to display consistent with user
preferences. Right now I am running (time() - (60*60*4)) through date(),
but I feel this is a very inelegant solution.
Thank you,
Derric Atzrott
Computer Specialist
Alizee Pathology