Sun, Dec 4
Done, finally! Thanks to both of you for the idea, and the patch.
Fri, Dec 2
Ah, the famous "paradox of tolerance" - I figured that would show up here at some point. How does that work with MediaWiki code, I wonder? Do hateful people produce hateful MediaWiki code that drives out the good MediaWiki code?
Wed, Nov 30
Okay - so you're allowed to kick people's code off of codesearch for political violations. And then the next group of people to run codesearch could turn around and ban feminists, if they wanted to, with the same justification. I just don't think it's a good idea.
Sorry, I don't buy it. What you linked to is not even policy on Wikipedia (it's just an essay), let alone in Wikimedia technical spaces. We have a whole code of conduct (maybe even two) that was/were hashed out, discussed and voted on by a lot of people. As far as I know, WikiMANNia hasn't violated any of it. Are you now saying there's a whole extra category of unacceptable behavior, having to do with political views, that was never discussed or voted on but simply determined by the handful of you? It doesn't make sense.
Tue, Nov 29
I don't think this whole process is a good idea. I know nothing about WikiMANNia, but I don't see how being anti-feminist, or holding any other specific political views, is "antithetical to the Wikimedia mission and values", unless those views include removing people's access to knowledge, which I don't think is the case here. If anything, I would say the idea of limiting people's access to support (or code) based on their political views is what's antithetical to the the Wikimedia mission.
Sun, Nov 27
@Samwilson - not to pass the ball back, but I'm not sure that this is a bug in Cargo. Granted, I'm sure this problem could be fixed in either extension, but the basic problem seems to be (if I understand it correctly) that Cargo sometimes includes "null" in its returned values. I think that's correct behavior - again, if I understand it correctly. Jeroen said the problem should be fixed in the CargoOutputBuilder class, which is part of the Maps extension - why not do that?
Tue, Nov 15
Fine from my perspective.
Mon, Nov 14
formatFieldValue() is already only called for non-null, non-blank values - no? Are you actually seeing a problem somewhere?
Wed, Nov 9
Nov 2 2022
Oct 26 2022
Okay, great news: thanks to some enterprising work from @WolfgangFahl, Tim was successfully contacted, and he just made his first mediawiki.org edit in nine years:
Oct 6 2022
Oh! Sorry, I must have forgotten. :) I'll have to look into this, then.
This is sort of on purpose - there are indeed no "class" or "style" parameters for "standard input", or any of the other form definition tags. My thought was that, if you want to do any custom formatting, you can put a <div> or <span> tag around any part of the form definition (like the "free text" tag), and then apply CSS to that, either inline or somewhere like MediaWiki:Common.css.
Sep 28 2022
I should have added this Phabricator task ID to the patch - oh well. Anyway, I believe it's resolved now.
That's great! Thanks for trying it, and letting me know.
Sep 27 2022
I rewrote the patch a little, to make it more comprehensive - what do you think about the current code?
Sep 25 2022
There are two main issues listed here: "YYYY/MM" values not being parsed correctly, and Page Forms not outputting month/year values as "YYYY/MM". The first one seems to have been solved at some point, and the second one I don't think is a real issue - "Month YYYY" is a good output format, I think - so I'm marking this as "Resolved".
Sep 21 2022
Sep 19 2022
That sounds good - it would be great to be able to drop in a new class and just have it work, in modular style, instead of requiring duplicate information. My only concern is that going through all the classes might be a little slow - but if that is not a real problem, then this sounds fine.
Sep 16 2022
What version of Cargo are you running? Also, were those rows in LocalSettings.php added below the inclusion of Cargo?
Sep 7 2022
Sorry for the (extremely) long delay on this... this no longer seems to be a problem, so I'm guessing it was solved sometime in the last six years.
Aug 29 2022
Aug 23 2022
Aug 19 2022
I totally agree, and I talked about this in a talk I gave at EMWCon earlier this year, whose slides are here (see slides 13-17). Basically, I think this can be done by adding three new parameters to the #get_*_data functions: "display template", "additional values" and "display format". This would then allow us to get rid of the #external_value and all the "...external_table" parser functions.
Aug 18 2022
@alex-mashin - okay, that makes sense. For some reason, I was thinking that all the get_..._data functions let you use an ID in place of the source, but actually I think only get_db_data does that. So this seems reasonable - there's no reason for regular users to even know what type of source is being accessed.
Sorry about missing this problem before! I had no idea that it was this severe. (I'm guessing that it only happens on page save, not on page viewing, but still.) I just checked in this change, which may or may not fix the problem - I hope you can add in this change to your local version of Cargo, in one way or another, and that it fixes the problem.
Aug 17 2022
What would be the benefit of this?
Aug 4 2022
Jul 28 2022
Thanks for letting me know about that problem - I believe it's fixed now.
Sorry for the long delay on this. I don't know if the OpenLayers display actually works, but at least the PHP error will no longer be there.
@Oeyvindg - sorry for the long delay, and thanks for the suggested code. I believe this is fixed now.
Jul 26 2022
@Anysite - thank you for the patch, and sorry for the extremely long delay on it! Hopefully this merge is better late than never.
Jul 25 2022
Marking this as "Declined" - it's unclear what this means. @Kasyap - if you want to work on any of these ideas, it would be better if you could create more specific (and clearer) tasks.
Okay, great. Hopefully the problem no longer exists!
@Bawolff - sorry for the very long delay in responding! Do you know if this is still an issue? If so, how can it be fixed?
@Tenbergen - sorry for the three-year delay in responding. :( I can't reproduce this problem - do you know if it still happens for you?
Alright, I'm closing this on the assumption that this was just a strange, one-time occurrence... hopefully it won't happen for anyone else!
Patch was never sent, but that's alright. :)
I'm marking this as "Declined" - I don't think anything can be done about this problem, within Page Forms.
Marking as "Invalid" - "Creates page with form" no longer exists, and the equivalent current feature doesn't seem to have this problem.
@Vitalisator - does this problem still happen for you, do you know? Is that workaround still needed?
I assume this patch fixed the problem.
Marking as "Invalid" - I believe this bug was already fixed when this bug report was made.
Marking as "Declined" - this was actually an issue with SemanticFormsHTML5, a long-abandoned extension, not with Page Forms (then Semantic Forms).
I'm marking this as "Declined", because I can't understand it - I think it relates to Special:MultiPageEdit, but I'm not even sure about that.
Jul 14 2022
@Megajoule - is this still a problem with the latest code?
Jul 13 2022
Sorry about this problem, and the long delay on fixing it.
Jul 12 2022
Jul 11 2022
I missed this until now! Although it turns out that a patch essentially identical to this one was added to Approved Revs right around when this patch was created:
Jul 8 2022
@Schtom - we just checked in a fix so that the extra cargo_backlinks code is only called if that cargo_backlinks DB table exists - and, since I'm pretty sure your system doesn't have this DB table, I think you no longer need that patch. Perhaps this counts as a full solution to the problem; I'm not sure.
This was done in 876d2faf76b2, with $wgCargoStoreUseTemplateArgsFallback.
Jul 7 2022
@Edtechdev - sorry that I missed this for so long (more than a year now!). Is this still a problem, do you know? If so, does it happen for you only with specific mobile devices/browsers, or all of them?
Thanks for adding the note to the documentation.
Thank you for this patch!
Jul 6 2022
@SuperHamster - FYI.
I believe this is now fixed, thanks to your patch.
What if you add "&_run" to the end of the "query string" value?
Jul 5 2022
The template exists! And it's now pretty well distributed across mediawiki.org. Thanks to everyone who helped with this.
Jul 4 2022
They were never there in the PHP demo. Only the JS demo has this feature.
That's a bit too flippant of a response, I think... the lack of the "Show code" arrows in the PHP version greatly decreases the usabilty. How are people even supposed to know about that source file?
Jun 29 2022
Marking this as "resolved", unless I hear otherwise.
I'm marking this as "invalid", until I hear otherwise.
Jun 28 2022
@rook - thank you!
Jun 23 2022
That's strange - I've never heard of that happening. Yes, I'm guessing that it's because you are using PHP 8, which is not yet officially supported by MediaWiki. I'm glad to hear that MediaWiki (and Page Forms) work at all with PHP 8, though!
Jun 21 2022
Thanks for this fix. But I assume you mean "tokens", not "combobox".
I don't think it makes sense to have a setting for this group of characters. Given that, I think having it in two places is maybe not ideal, but fine.
Jun 20 2022
Jun 17 2022
Sorry for the delay. Yes, the summaries are great now. I tried this out, and it works, but I do see one problem: it only checks for some of the word-break characters, but not all of them. You can see here the set of seven word-break characters that Page Forms autocompletion supports:
Jun 16 2022
Okay, thank you. If you have time - could you fix both the commit message and this bug report's name, to clarify that this fixes autocompletion specifically for Unicode strings? (If I understand the problem correctly.)
Also, I think you never answered my questions, above.
I don't know - I'm not sure what to do here. I believe there are now three patches associated with this bug: