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…
Hi everyone,
I recently set up a MediaWiki (http://server.bluewatersys.com/w90n740/)
and I need to extra the content from it and convert it into LaTeX
syntax for printed documentation. I have googled for a suitable OSS
solution but nothing was apparent.
I would prefer a script written in Python, but any recommendations
would be very welcome.
Do you know of anything suitable?
Kind Regards,
Hugo Vincent,
Bluewater Systems.
Hey,
I am wondering if we have IRC bots that can report changes to specific
extensions (both on gerrit, ie when a comment is made or stuff is merged,
and on bugzilla). This would be useful for the #wikimedia-wikidata and
#semantic-mediawiki channels, and possible others as well.
Cheers
--
Jeroen De Dauw
http://www.bn2vs.com
Don't panic. Don't be evil.
--
Hi everyone,
As we do more frequent deploys, it's going to become critical that we
get database schema changes correct, and that we do so in a way that
gives us time to prepare for said changes and roll back to old
versions of the software should a deploy go poorly. This applies both
to MediaWiki core and to WMF-deployed extensions.
I'd like to propose that we make the following standard practice:
1. All schema changes must go through a period of being optional.
For example, instead of changing the format of a column, create a new
column, make all writes happen to the old and new column (if it
exists) and deprecate use of the old column. Check if the new column
exists before blindly assuming that it does. Only eliminate support
for the old column after it's clear the schema migration has happened
and there's no chance that we'll need to roll back to the old version
of the software.
2. There might be cases where rule #1 will be prohibitive from a
performance perspective. However, schema changes like that should be
rare to begin with, and should have prominent discussion on this list.
In the case where it's impossible to follow rule #1, it is still
critical to write scripts to roll back to the pre-change state.
3. For anything that involves a schema change to the production dbs,
make sure Asher Feldman (afeldman(a)wikimedia.org) is on the reviewer
list. He's already keeping an eye on this stuff the best he can, but
it's going to be easy for him to miss changes in extensions should
they happen.
I don't have a strong opinion about whether we need to follow rule #1
above through an iteration of our six month tarball release cycle, but
we at least need to follow it through the two week deployment cycle.
Assuming this seems sensible to everyone, I can update this page with this:
http://www.mediawiki.org/wiki/Development_policy
(/me desperately tries to avoid yak shaving and updating the policy
above for Git)
Rob
We now have three mirror sites, yay! The full list is linked to from
http://dumps.wikimedia.org/ and is also available at
http://meta.wikimedia.org/wiki/Mirroring_Wikimedia_project_XML_dumps#Curren…
Summarizing, we have:
C3L (Brazil) with the last 5 good known dumps,
Masaryk University (Czech Republic) with the last 5 known good dumps,
Your.org (USA) with the complete archive of dumps, and
for the latest version of uploaded media, Your.org with http/ftp/rsync
access.
Thanks to Carlos, Kevin and Yenya respectively at the above sites for
volunteering space, time and effort to make this happen.
As people noticed earlier, a series of media tarballs per-project
(excluding commons) is being generated. As soon as the first run of
these is complete we'll announce its location and start generating them
on a semi-regular basis.
As we've been getting the bugs out of the mirroring setup, it is getting
easier to add new locations. Know anyone interested? Please let us
know; we would love to have them.
Ariel
Hi guys, i have created a simple map editor which works with the Maps
extension, i'm looking for some feedback on your impression of it.
please take a look @
http://ec2-46-137-28-172.eu-west-1.compute.amazonaws.com/static/google-draw…
let me know what you think.
and also, please note it's a work in progress. My idea is to implement this
as a special page in the Maps extension so that people can easily create
and edit maps.
Cheers
Kim
https://gerrit.wikimedia.org/r/#/c/3925/https://gerrit.wikimedia.org/r/#/q/project:mediawiki/extensions/RSS,n,z
Hi,
I don't know how to ask but I ask now:
if someone has time to review the full set of changes, so that I later
can resume with my work for this extension.
My patches were submitted to SVN before the move to git, and this
version works smoothly.
So from my point of view, the main open issue is code review.
An older - outdated and buggy version of - Extension:RSS is also used on
www.mediawiki.org. A request to upgrade is already filed
( https://bugzilla.wikimedia.org/show_bug.cgi?id=34655 )
Remarks:
I will be available during the Berlin Hackathon at the spot to answer
your questions - if there are any.
And from Antoine I know: if he had time, he would help me.
Tom
(Wikinaut)
Hello,
Under 20%, I have decided to give the wikibugs IRC bot some love.
That bot is a script processing bugzilla emails notification sent
publicly to the wikibugs-l mailing list. It crafts colorful IRC messages
which are then relayed by ircecho to #mediawiki.
I have made wikibugs to recognize the Bugzilla product and, based on
that, to split the IRC messages in different files. Thus, ircecho can be
made to relay different products in different channels resulting in less
spam in #mediawiki and more in #wikimedia-mobile .
The script is written in perl, my changes are listed in the good old
CodeReview tool and needs someone to have a look at them and eventually
tests them using various bugs notifications:
https://www.mediawiki.org/wiki/Special:Code/MediaWiki?path=/trunk/tools/wik…
I also described wikibugs in puppet to ease its installation. The
related gerrit change is https://gerrit.wikimedia.org/r/8339/
It lacks the exim configuration which makes mchenry to send the mail to
the wikibugs perl script for processing. Maybe a local hack?
cheers,
--
Antoine "hashar" Musso
`git review' says that "a new version of git-review is availble on PyPI".
The last update created some unwanted surprises, so I decided to avoid
updating it for now. What do our Git experts suggest?
Thank you,
--
Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
http://aharoni.wordpress.com
“We're living in pieces,
I want to live in peace.” – T. Moore