I have some query API module in which some SQL error is occurring. Now
MediaWiki is very helpful in truncating the lines in such a way I can't
actually make sense of the error message.
Well, what column is unknown?
How can I turn of this truncating, or otherwise see the error (preferably
w/o having to dig though some log file somewhere)? I have this already:
$wgShowExceptionDetails = true;
$wgShowSQLErrors = true;
$wgDebugComments = true;
$wgLogQueries = true;
$wgDebugDumpSql = true;
$wgDevelopmentWarnings = true;
Jeroen De Dauw
Don't panic. Don't be evil.
On Sat, Sep 3, 2011 at 5:30 AM, Andrea Zanni <zanni.andrea84(a)gmail.com> wrote:
> Well, it seems that every year we choose locations that for one reason or
> the other are likely not to be accessible to some groups or nationality (I
> hear complaints every year about these issues)(no judgements, just a fact).
> So I agree that this uploading issue should be faced once for all,
> setting up a workflow with WMF technicians that would allow videos and
> slides to be online in reasonable time.
Yes! if we can set up a system for media upload *before* the next
conference to try and address this issue, which does come up every
year, that would be fantastic.
Copying wikitech :) The problem: how and where should we annually
upload video and slides from ~100 conference presentations, keeping
them freely & easily accessible and the metadata (such as links to
papers, submission pages, wikipages of notes, etc) intact?
Added a few new committers this week:
Vitaliy - vitalif - Various extensions such DeleteBatch
Tobias - fptc - New extension, FrequestPatternTagCloud
Oren Bochman - oren - Lucene
Chris Ogden - cogden - New extension, WikiCitation
Hi! I am one of this year's GSoC students, mentored by Max Semenik and
Brion Vibber. I worked on the project of making gadgets customizable;
by that I mean:
- allowing gadgets to easily declare the list of configuration
variables they have
- allowing users to easily change those settings, with an easy to use
UI integrated to the Special:Preferences page.
Up to date notes on the project, a real world example and installation
instructions are being kept in this page:
The code is being kept in a branch, and is based on the current
version of the Gadgets extensions; it will need to be ported to the
new version of Gadgets on which Roan Kattouw and Krinkle are working
on. I have documented the changes I made to ease integration.
The syntax for specifying gadget preferences is quite flexible; it may
be useful to still add new features, but since I won't be able to do
heavy work on it in the following month, I would like to use this time
to collect feedback from developers and from gadget writers: what are
the features you think are missing? Would you change some of the
existing features (before it's too late...)? If you want to suggest
changes/new features, or for any other comment, please start a thread
on the discussion page of the project notes:
In the second half of the project I also started to work on a WYSIWYG
preferences editor (this was not explicitly part of the project plan,
but was an addition suggested by Max). This is far from being a
finished product, but yet it supports all of the implemented types of
preferences. Instructions on how to try it are here:
Those are the things I plan to do in the future (I expect to work on
them after mid-October):
- factor out the code for the editor from the jquery.formbuilder.js
file into a separate module;
- maybe, refactor the jquery.formbuilder module to completely isolate
it from Gadgets: it may be useful on its own;
- generalize the system so that any ResourceLoader module willing to
have some user-exposed settings can use it (e.g.: toolbar
- try to rethink the client side components to allow unit testing;
- improve unit testing on the PHP side (as of now, there is good code
coverage, but still not 100%);
- improve UI appearance
- any other thing that rises up from feedback
Thanks for your attention,
Roan sent out a new set of HTTPS fixes today, which made us confident
enough to enable protocol-relative URLs and HTTPS on commonswiki and
foundationwiki. We haven't purged the cache yet for these wikis, so
it's very likely some pages will point you back to HTTP. We'll be
purging caches some time soon, but please don't hesitate to try it
now. Please file bug reports or let Roan or I know of any issues you
Note: there is likely a bunch of site CSS, JS, and templates that will
need to be changed to use protocol relative URLs everywhere. HTTPS has
a massive long tail :). If you feel like helping out with that, please
Another *important* note: "Log me in globally" is still actually
insecure, even when using HTTPS. It loads the images from each wiki
using HTTP, which is what sets your cookies (which are also, then sent
over HTTP). If you use this option, people can still steal your
cookies; they cannot, however steal your password.
For MediaWiki below 17.0, replacing of variables does not work,
Can someone tell me, whether "replaceVariables($query, $frame)" and
"recursiveTagParse( $query )" are actually the right functions to use, e.g.,
in MediaWiki 15.4.
AIFB, Karlsruhe Institute of Technology (KIT)
Phone: +49 721 608-47946
From: Benedikt Kämpgen
Sent: Friday, September 02, 2011 9:54 AM
To: 'rdf-spark(a)googlegroups.com'; 'Jeroen De Dauw'
Subject: SPARK extension for MW < 17.0
I have changed the SPARK extension so that it also works for MW versions
below 17.0. I basically made the extension work without Resource Loader,
but I do not see another way at the moment; may I commit?
AIFB, Karlsruhe Institute of Technology (KIT)
Phone: +49 721 608-47946
Thank you everyone involved for getting the review queue down as low
as it is. As it stands, we have 82 new revisions to review, and 57
Back on August 18, we had 171 new revisions to review and 59 fixmes.
If you start there an plot linearly to release, that means reviewing
7-8 new revisions per day, and fixing an average of 2 fixmes per day
to just barely be done on September 16. Needless to say, we're doing
great on the new revisions, but the fixmes are a bit of a problem.
Even accounting for the fact that fixmes are being added as a result
of the rapid rate of new revision fixing, we're still not fixing the
fixmes fast enough. Between August 18 and now, we've netted 2
revisions, by fixing 9 fixmes, and adding 7 more. That's only fixing
the fixmes at a rate of 1.5 a day, which won't get us there even if we
don't add any more fixmes. Given the fact that reviewing 89 revisions
yielded 7 new fixmes, it's reasonable to expect that 5-10% of the
remaining new revisions will become new fixmes, which will add 4-8 new
fixmes before we're done.
So, please take a look at the fixme list (especially if you are one of
the committers involved) and do what you can to reduce our load.
I'm shopping Tampa colos; could someone remind me -- off list if you prefer --
what the one is that we're in, in Tampa? I know it moved across the street,
but I forget which street. :-)
Jay R. Ashworth Baylink jra(a)baylink.com
Designer The Things I Think RFC 2100
Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII
St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274