Fri, Dec 15
@Foxtrott - can you look into this? Or do you at least have an idea where the fix should be made?
Thu, Dec 14
I don't think it makes sense as a general feature request - if there's no other "id" field, it seems odd to display "mods.id" as (say) a column header, instead of just "id".
@Stefahn - I looked through the change again, and my guess is that the problem is somehow due to the parser function that was added in that change. If you're on a version of Contributors that has that error, could you try removing the line from either Contributors.php or extension.json - depending on what version you're using - that adds 'ContributorsHooks::setupParserFunction' to the 'ParserFirstCallInit' hook, and seeing if that makes the error go away?
I wouldn't exactly say it's a bug - rather, it's behavior that's probably not properly documented.
Tue, Dec 12
Marking as "resolved" - feel free to re-open if it's still an issue.
Resolved a few months ago!
I don't know why this is still open... it's time to resolve it!
Wed, Dec 6
Mon, Dec 4
This just got more specific! It requires the presence of three extensions, plus a specific syntax in the template, and a newline in the free text.
That is very specific! Are you sure that this was not happening before the upgrade? And if indeed it was the upgrade that caused it, do you remember what versions you were running before?
Thu, Nov 30
I think a new bug report is the way to go, yes. Hopefully there you can clarify exactly how to reproduce this issue.
Wed, Nov 29
Is it only the 3rd issue that requires the presence of Page Forms to happen, or all of them?
Mon, Nov 27
I can certainly see the value of dropping the namespace (maybe that should actually be a separate setting/parameter). But what's an example where the basic syntax of "...your text here... : page name" is not ideal?
It works for me now - when I type in "g", it shows an autocompletion value.
I think this is two issues in one: first, the category you're autocompleting on, "Tsilari", redirects to "Tsilarin artikkelit", and I don't think Page Forms picks up on the redirect. But there was also a separate bug in Page Forms: autocompletion on a category that had only a small number of pages didn't work if the page with the #forminput call on it was cached. (For a somewhat obscure reason.) I just checked in a fix for the 2nd issue, but you'll probably still have to change the category name in the #forminput call.
Fri, Nov 17
Ah, I never thought to test with a field name that's an SQL keyword. Sorry about the problem! Thankfully, it looks like the issues are only in Special:Drilldown. I just checked in some fixes, so hopefully everything works now.
Nov 15 2017
@Alexia - sorry about the problem, and it's great that you were able to find a fix. I checked in a fix pretty similar to yours, so hopefully this has been resolved.
Nov 14 2017
Nov 13 2017
Nov 9 2017
Nov 6 2017
Right, I should have clarified - I didn't just mean adding those <div> or <span> tags, and seeing if it worked; I meant modifying the CSS or JS to also look for "span.form-control input" instead of just "input.form-control", and that kind of thing. Or is that not possible? (I don't really know what Bootstrap does.)
Nov 3 2017
Can't you just wrap the forminput in a div or span with its own class, and set the CSS/JS through that?
Oct 26 2017
Oct 23 2017
@cscott - thanks for letting me know about this. I just checked in a fix to Page Forms to remove all the calls to insertStripItem(). It looks like two more of my extensions, Cargo and Header Tabs, include the same hack and need to be modified also.
Oct 18 2017
Oct 17 2017
Could you add a line like:
Oct 16 2017
Oct 6 2017
Oct 5 2017
Sep 27 2017
Semantic Drilldown uses the Semantic MediaWiki messages "smw_true_words" and "smw_false_words" for these:
Sep 26 2017
Alright - I'm glad you see the same thing I do! I wonder when that new control was added... it looks like some other controls have been added too. Anyway, I see your point about having control over it, but for the moment the default behavior, and no one has complained about too many controls on the map, so I'm marking this as "Declined" - though there's always the option to bring it back.
Sep 17 2017
@Jonathan3 - sorry for the long delay on this. I just finally looked into adding this capability - probably via a "controls" parameter, instead of a "fullscreen" parameter, but no matter - when I realized that the Google maps are all already showing a "fullscreen" control! I don't know if the default changed at some point between then and now, or what, but the problem seems to have been solved on its own. Would you agree?
Sep 13 2017
Sep 11 2017
Sep 7 2017
Aug 30 2017
@Reception123 thank you!
Oh. That's even worse!
Thanks for asking. Dropping support for PHP 5.3 means dropping support for MediaWiki versions below 1.27. I would rather not drop support for these quite yet, especially MW 1.26, which was in use until about a year ago. So I would say no, for now.