Hello,
I have been a WP editor since 2006. I hope you can help me. For some reason
I no longer have Section Heading titles showing in the Articles. This is
true of all Headings including the one that carries the Article subject's
name. When there is a Table of Contents, it appears fine and, when I click
on a particular Section, it goes to that Section, but all that is there is a
straight line separating the Sections. There is also no button to edit a
Section. If I edit the page and remove the "…
[View More]== ==" markers from the Section
Titles, the Title then shows up, but not as a Section Heading. Also, I don't
have any Date separators on my Want List. This started 2 days ago. Any
thoughts?
Thanks,
Marc Riddell
[[User:Michael David]]
[View Less]
I'm happy to announce the availability of the second beta release of the
new MediaWiki 1.19 release series.
Please try it out and let us know what you think. Don't run it on any
wikis that you really care about, unless you are both very brave and
very confident in your MediaWiki administration skills.
MediaWiki 1.19 is a large release that contains many new features and
bug fixes. This is a summary of the major changes of interest to users.
You can consult the RELEASE-NOTES-1.19 file for the …
[View More]full list of changes
in this version.
Five security issues were discovered.
It was discovered that the api had a cross-site request forgery (CSRF)
vulnerability in the block/unblock modules. It was possible for a user
account with the block privileges to block or unblock another user without
providing a token.
For more details, see https://bugzilla.wikimedia.org/show_bug.cgi?id=34212
It was discovered that the resource loader can leak certain kinds of private
data across domain origin boundaries, by providing the data as an executable
JavaScript file. In MediaWiki 1.18 and later, this includes the leaking of
CSRF
protection tokens. This allows compromise of the wiki's user accounts, say
by
changing the user's email address and then requesting a password reset.
For more details, see https://bugzilla.wikimedia.org/show_bug.cgi?id=34907
Jan Schejbal of Hatforce.com discovered a cross-site request forgery (CSRF)
vulnerability in Special:Upload. Modern browsers (since at least as early as
December 2010) are able to post file uploads without user interaction,
violating previous security assumptions within MediaWiki.
Depending on the wiki's configuration, this vulnerability could lead to
further
compromise, especially on private wikis where the set of allowed file types
is
broader than on public wikis. Note that CSRF allows compromise of a wiki
from
an external website even if the wiki is behind a firewall.
For more details, see https://bugzilla.wikimedia.org/show_bug.cgi?id=35317
George Argyros and Aggelos Kiayias reported that the method used to generate
password reset tokens is not sufficiently secure. Instead we use various
more
secure random number generators, depending on what is available on the
platform. Windows users are strongly advised to install either the openssl
extension or the mcrypt extension for PHP so that MediaWiki can take
advantage
of the cryptographic random number facility provided by Windows.
Any extension developers using mt_rand() to generate random numbers in
contexts
where security is required are encouraged to instead make use of the
MWCryptRand class introduced with this release.
For more details, see https://bugzilla.wikimedia.org/show_bug.cgi?id=35078
A long-standing bug in the wikitext parser (bug 22555) was discovered to
have
security implications. In the presence of the popular CharInsert extension,
it
leads to cross-site scripting (XSS). XSS may be possible with other
extensions
or perhaps even the MediaWiki core alone, although this is not confirmed at
this time. A denial-of-service attack (infinite loop) is also possible
regardless of configuration.
For more details, see https://bugzilla.wikimedia.org/show_bug.cgi?id=35315
*********************************************************************
What's new?
*********************************************************************
MediaWiki 1.19 brings the usual host of various bugfixes and new features.
Comprehensive list of what's new is in the release notes.
* Bumped MySQL version requirement to 5.0.2.
* Disable the partial HTML and MathML rendering options for Math,
and render as PNG by default.
* MathML mode was so incomplete most people thought it simply didn't work.
* New skins/common/*.css files usable by skins instead of having to copy
piles of
generic styles from MonoBook or Vector's css.
* The default user signature now contains a talk link in addition to the
user link.
* Searching blocked usernames in block log is now clearer.
* Better timezone recognition in user preferences.
* Extensions can now participate in the extraction of titles from URL paths.
* The command-line installer supports various RDBMSes better.
* The interwiki links table can now be accessed also when the interwiki
cache
is used (used in the API and the Interwiki extension).
Internationalization
- --------------------
* More gender support (for instance in user lists).
* Add languages: Canadian English.
* Language converter improved, e.g. it now works depending on the page
content language.
* Time and number-formatting magic words also now depend on the page
content language.
* Bidirectional support further improved after 1.18.
Release notes
- -------------
Full release notes:
https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/core.git;a=blob_plain;f=RE
LEASE-NOTES-1.19;hb=1.19.0beta2
https://www.mediawiki.org/wiki/Release_notes/1.19
Co-inciding with these security releases, the MediaWiki source code
repository has
moved from SVN (at https://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3)
to Git (https://gerrit.wikimedia.org/gitweb/mediawiki/core.git). So the
relevant
commits for these releases will not be appearing in our SVN repository. If
you use
SVN checkouts of MediaWiki for version control, you need to migrate these to
Git.
If you up are using tarballs, there should be no change in the process for
you.
Please note that any WMF-deployed extensions have also been migrated to Git
also, along with some other non WMF-maintained ones.
Please bear with us, some of the Git related links for this release may not
work instantly,
but should later on.
To do a simple Git clone, the command is:
git clone https://gerrit.wikimedia.org/r/p/mediawiki/core.git
More information is available at https://www.mediawiki.org/wiki/Git
For more help, please visit the #mediawiki IRC channel on freenode.netirc://irc.freenode.net/mediawiki or email The MediaWiki-l mailing list
at mediawiki-l(a)lists.wikimedia.org.
**********************************************************************
Download:
http://download.wikimedia.org/mediawiki/1.19/mediawiki-1.19.0beta2.tar.gz
Patch to previous version (1.19.0beta1), without interface text:
http://download.wikimedia.org/mediawiki/1.19/mediawiki-1.19.0beta2.patch.gz
Interface text changes:
http://download.wikimedia.org/mediawiki/1.19/mediawiki-i18n-1.19.0beta2.patc
h.gz
GPG signatures:
http://download.wikimedia.org/mediawiki/1.19/mediawiki-1.19.0beta2.tar.gz.si
g
http://download.wikimedia.org/mediawiki/1.19/mediawiki-1.19.0beta2.patch.gz.
sig
http://download.wikimedia.org/mediawiki/1.19/mediawiki-i18n-1.19.0beta2.patc
h.gz.sig
Public keys:
https://secure.wikimedia.org/keys.html
[View Less]
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 …
[View More]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…
[View Less]
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.
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 …
[View More]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
[View Less]
Hi everyone,
I'm happy to announce that we have promoted Sumana Harihareswara as
manager of Engineering Community group. Sumana started with us as a
contractor back in February 2011, initially in a targeted engagement
to help out with Google Summer of Code and with the Berlin Hackathon
last year. Later that year, as we interviewed people to bring in as
Volunteer Development Coordinator, not only did Sumana put in a strong
application herself, but recruited very worthy competition …
[View More]for the
role. After winning the role, she worked tirelessly to straighten out
many kinks in our processes around volunteer development and
systematically ensured that new volunteer developers get the
recognition and (if needed) help they deserve. She has also applied
focus and organization in many areas outside of her immediate purview,
for example, recently stepping in as project manager for Git, and
occasionally filling in for me when I've been unavailable for the
larger Platform Engineering organization.
The promotion to Engineering Community Manager isn't so much a change
in the way things are done here so much as an official recognition of
a vital role that she has already played for the past year. Sumana
has been working with Guillaume Paumier and Mark Hershberger under the
somewhat ad hoc group title of "Technical Liaison; Developer Relations
(tl;dr)", serving as lead of that group since last year. Under the
new "Engineering Community" name, this group will continue to serve
many roles: facilitating collaboration and communication between
Wikimedia Foundation and its employees and the larger Wikimedia
developer community, as well as facilitating collaboration and
communication between the Wikimedia developer community and other
Wikimedia communities.
Thank you, Sumana, for your hard work over the past year. I'm looking
forward to seeing what you and the group accomplish moving forward.
Congratulations!
Rob
[View Less]