I have an open bug in CentralNotice [1] where I have a search function by
name for old content. Naively this happens as a LIKE query on the table's
name column. Though this works, it fails at being case insensitive because
the table, like most(all?) other tables on the WMF cluster, has by default
binary charset/collation.
Given that I want to support case insensitive searching; does anyone have
any thoughts or examples on how to go about doing it in a binary table?
The only solution I can think of would be to change the collation/charset
of the table in question to utf8. Would that be a bad idea? I'm led to
understand the binary default came about because older versions of MySQL
did not support the full multilingual plane. But this might no longer be an
issue with MariaDB 5.6?
[1] https://bugzilla.wikimedia.org/show_bug.cgi?id=53751
~Matt Walker
Wikimedia Foundation
Fundraising Technology Team
I worked on making a prototype for an extension supporting inline comments
on wiki artciles. This was implemented using the Open Knowledge Foundation
Annotator (OKFN) library. The project can be tested [1], switch to the view
annotations tab, select a particular text and leave an annotation. It also
supports the logged out users. But currently the update and destroy of
annotations is restricted only to the user of the annotation since we are
not having any history of annotations.
The prototype phase of the project is over, it was a fun working around
with the community and the mentors. The future implementation includes the
history of annotations, internationalization support, may be a change of
frontend, etc.
Overall it was nice working around with the community and the mentors!
Thanks for your support :)
Read my blog post[2] and project updates[3] if you are interested.
[1] http://annotator.wmflabs.org/
[2] http://richajain-annotator.blogspot.in/
[3] https://www.mediawiki.org/wiki/User:Rjain/Gsoc2013/Project_Updates
Hi all. I just wrapped up my three-month-long Summer of Code project,
"Improving support for book structures".[1][2] I worked to create an
extension, BookManagerv2, that will allow wikis to store metadata and
structural information about books. This information is entered using a
form, and stored in a JSON block. This block is then used to create
navigation bars for the section pages, and will ideally be used in the
future to allow things like one-click actions on entire books.
The extension is not complete, as it has a number of remaining bugs that
must be solved before it can go to security review.[3] That said, I hope to
close these up soon. My wrap-up blog post has some more information, if
you're interested.[4]
Thanks so much for all of the support—my mentors and the MediaWiki and
other Wikimedia communities have been instrumental in the work I've
accomplished.
[1] https://www.mediawiki.org/wiki/User:GorillaWarfare/Proposal
[2] https://meta.wikimedia.org/wiki/Book_management
[3] https://meta.wikimedia.org/wiki/Book_management/Bug_priority
[4] http://www.mollywhite.net/blog/?p=104
FYI,
---------- Forwarded message ----------
From: <core-ops(a)rt.wikimedia.org>
Date: Mon, Sep 30, 2013 at 2:12 PM
Subject: Fwd: [wikimedia #5841] etherpad.wikimedia.org downtime due to upgrade
etherpad-lite has been successfully update to version 1.2.11. The
upgrade procedure server-wise was uneventfull, however it will cause
some minor problems to existing users of the service. Specifically
CSS/JS elements of the page have changed and need to be re-downloaded
by the browser, however due to browser caching this does not happen
automatically. Users of the old version will have to FORCE REFRESH
their browser when accessing the service for the first time. Otherwise
they will get garbled versions of the user interface. Pad contents
will be intact, however a brief message suggesting the user does not
have permission to access a pad might show up. That message is
inaccurate and is a by-product of the garbled UI.
--
Alexandros Kosiaris <akosiaris(a)wikimedia.org>
[Re-posting, since my original post apparently never got through. Maybe I posted
from the wrong email account.]
Hi all!
As discussed at the MediaWiki Architecture session at Wikimania, I have created
an RFC for the TitleValue class, which could be used to replace the heavy-weight
Title class in many places. The idea is to show case the advantages (and
difficulties) of using true "value objects" as opposed to "active records". The
idea being that hair should not know how to cut itself.
You can find the proposal here:
<https://www.mediawiki.org/wiki/Requests_for_comment/TitleValue>
Any feedback would be greatly appreciated.
-- daniel
PS: I have included the some parts of the proposal below, to give a quick
impression.
------------------------------------------------------------------------------
== Motivation ==
The old Title class is huge and has many dependencies. It relies on global state
for things like namespace resolution and permission checks. It requires a
database connection for caching.
This makes it hard to use Title objects in a different context, such as unit
tests. Which in turn makes it quite difficult to write any clean unit tests (not
using any global state) for MediaWiki since Title objects are required as
parameters by many classes.
In a more fundamental sense, the fact that Title has so many dependencies, and
everything that uses a Title object inherits all of these dependencies, means
that the MediaWiki codebase as a whole has highly "tangled" dependencies, and it
is very hard to use individual classes separately.
Instead of trying to refactor and redefine the Title class, this proposal
suggest to introduce an alternative class that can be used instead of Title
object to represent the title of a wiki page. The implementation of the old
Title class should be changed to rely on the new code where possible, but its
interface and behavior should not change.
== Architecture ==
The proposed architecture consists of three parts, initially:
# The TitleValue class itself. As a value object, this has no knowledge about
namespaces, permissions, etc. It does not support normalization either, since
that would require knowledge about the local configuration.
# A TitleParser service that has configuration knowledge about namespaces and
normalization rules. Any class that needs to turn a string into a TitleValue
should require a TitleParser service as a constructor argument (dependency
injection). Should that not be possible, a TitleParser can be obtained from a
global registry.
# A TitleFormatter service that has configuration knowledge about namespaces and
normalization rules. Any class that needs to turn a TitleValue into a string
should require a TitleFormatter service as a constructor argument (dependency
injection). Should that not be possible, a TitleFormatter can be obtained from a
global registry.
Hello everyone,
During the Google Summer of Code 2013 program that concluded recently I
worked on implementing section handling in the Semantic Forms
extension[1][2] which also involved enabling the Page Schemas extension[3]
to handle sections as well. This means that now, not only templates but
sections too can be defined in forms. The work also included adding unit
tests to the Semantic Forms extension.
In SF a new {{{section}}} tag was introduced to the form definition syntax
to define sections in forms. The Special:CreateForm helper page allows you
to add sections to forms by specifying the section name and also modify its
properties. If you want to add sections manually the basic usage is -
{{{section|<section_name>|level=<header_level>}}}. The "level" parameter
here is optional.
PS now supports a <Section> XML element to be included in the schema to
define sections. The Special:EditSchema page can be used to add sections to
the schema and modify their attributes. As before "Generate pages" will
create the form with the templates and sections in the schema.
These changes can be tried out by pulling the latest code from Git. Section
handling for SF and PS will be available with their next released versions.
Any feedback or bug reports are welcome.
Many thanks to Yaron Koren who mentored this GSoC project and to everybody
who reviewed code and provided suggestions for improvement. It has been a
wonderful learning experience and I hope the newly added section handling
capabilities will be useful in defining a more complete structure for forms!
[1].
http://www.mediawiki.org/wiki/User:Himeshi/GSoC_2013/Project#Project_Descri…
[2].http://www.mediawiki.org/wiki/Extension:Semantic_Forms
[3]. http://www.mediawiki.org/wiki/Extension:Page_Schemas
-Himeshi-