What version of Page Forms are you running? I assume it's not 0.5.2.
Do you mean, when saving a page that happens to contain a call to #formlink?
Tue, Feb 25
Patch was merged in a while ago.
Sorry about that. I fixed this, and the other calls to useCan and isAllowed(), in 47c680f124e8.
Mon, Feb 24
Thank you, @TheSandDoctor !
@Nocodes - yes, definitely!
Fri, Feb 21
That's good to know! Well, this needs to be fixed within the Cargo code. So either the class should be removed, or, if that's not possible, there should be local CSS added within Cargo to override the CSS being set for that class.
Thu, Feb 20
Wed, Feb 19
Ooh, sorry about that! You found a bug that got into the code a few weeks ago. I checked in a fix for it earlier today. If you get the latest code, this will hopefully work.
Do all of your CSV files have thousands of rows? If so, it sounds like you have a bigger problem than comments in the files.
Tue, Feb 18
Okay, I get it. I don't know what the best approach is here - it would be easy to have the code just ignore lines that start with a "#", but on the other hand, commented lines like this are not part of the standard CSV specification, and there's always the small chance that a row is actually supposed to start with a "#".
Not any immediate plans, but I do still want to get this done, yes.
Mon, Feb 17
@ahmad - how do you include comments in a CSV file?
Thu, Feb 13
Great! Now you need to create a form that includes an input with type "checkboxes". Look at the Page Forms documentation for how to do that:
Wed, Feb 12
@Rexsteroxy - you need to set up MediaWiki and install Page Forms on it, if I understand the question correctly...
Mon, Feb 10
@Rexsteroxy - great! Please pick a microtask and try to do it. Let me know if you have any questions.
There's a lot of documentation here: https://www.mediawiki.org/wiki/Extension:Page_Forms
The type specified might need to "String".
Right, those are Cargo field types, which are different from Page Forms input types. You can't directly specify an input type in Special:CreateClass, unfortunately. But actually, if in Special:CreateClass you click on the "List of values?" checkbox and add a set of values to the "Allowed values" input for any one field, I think checkboxes will show up for that field in the resulting form.
No problem, I should have said that beforehand.
Sun, Feb 9
@Prondubuisi - are you trying to become a Google Summer of Code student? In either case, please just pick one microtask and stick to that, instead of trying to do all of them.
Yes, this is still an issue. You need to specify "input type=checkboxes" for at least one field in the form.
You need to create at least one Cargo table in order to see the autocompletion in effect.
Yes, this is still an issue. This refers to checkboxes in user-defined forms, defined with "input type=checkboxes".
Wed, Feb 5
Tue, Feb 4
Great! You can start by going to Special:CreateClass and filling in the form. Although it might be helpful to install the Cargo extension first, so you can see the full working of the overall system. As to beginner-friendly issues: check out the list of microtasks above.
Sun, Feb 2
Thu, Jan 30
I don't think a field holding a list of Boolean values makes sense; maybe Cargo should simply prohibit users from declaring this.
Jan 27 2020
@BamLifa - okay, thanks for offering to help You should know that I'd prefer to have a co-mentor who has significant MediaWiki development experience - and ideally, someone with Page Forms development experience. But I'll let you know.
Jan 26 2020
Jan 24 2020
@BamLifa - no, I don't have co-mentors yet. Who are you?
Jan 23 2020
Thanks for letting me know - I don't think I saw that other patch before.
Jan 21 2020
Jan 20 2020
Jan 17 2020
Jan 16 2020
This thing is coming up fast! I added a few microtasks to my project.
I'm guessing this is no longer an issue...
Jan 15 2020
Jan 13 2020
Jan 7 2020
Yes, sure. I don't think this bug report was ever valid - at least, the way it was described - so there's no harm in making it public.
I'm marking this again as "Invalid", for the reasons stated above.
Jan 6 2020
Dec 31 2019
@DannyS712 - thank you for the patch!
For the 2020 Google Summer of Code, I would like to mentor a project to remove some or all of the usage of jQuery UI from the Page Forms extension - this is detailed at T241632.
Dec 30 2019
Dec 27 2019
This was indeed implemented in the Cargo code, using hooks, a few weeks ago in ce51277d7ed2. I'm marking this bug as "resolved", though feel free to re-open if there are any issues.
Dec 19 2019
Dec 18 2019
Sorry for the long delay. I understand the problem, but I don't think this specific patch will work, because fields of type "Text" and "Wikitext" don't get truncated at all in the database - or if they do, it's after many more characters than the value of $wgCargoDefaultStringBytes. The same goes for fields of type "String", "Page", etc., if they have a "size" value that's set to more than 1000 - they get stored in the database as just a "Text" field. So I think it makes sense to do the truncation in doesRowAlreadyExist() instead - compare a substring of the new value with a substring of the database value, I guess by using both mb_substr() and SUBSTR().
@alex-mashin - sorry about the delay. I've reviewed, and the code looks fine. I'm just not sure yet that the ed_url_cache table should get created automatically. I just need to decide on this one way or the other. But that SQL should indeed be improved either way.
Dec 17 2019
@Samwilson - that sounds good; a JS timepicker is generally a lot less useful than a datepicker anyway. Yes, masked inputs get used a lot in Page Forms already, if I understand what you're asking...
Dec 16 2019
Dec 13 2019
Okay, got it. Well, I hope you do look again into it - and, as I noted a while ago, if you do update the patch, I think the "datepicker" and "datetimepicker" inputs should just be replaced completely, instead of adding separate input types or some "ooui" parameter.
Sorry, I must be missing something obvious. Are these two separate issues? They seem to be two conflicting descriptions of the same issue. This one says that you can't ever track a single namespace or category, the other one says that you can't track a single namespace or category, but only when the NewUserNotif extension is installed.
I thought this bug report is saying that the namespace restriction is not respected even without NewUserNotif.
So is T240391 incorrect? What's the impact that the NewUserNotif extension has, if any?
Dec 12 2019
Okay, that makes sense, and I agree.
Sorry about that! I did an incomplete code check-in before. If you get the latest code now, you should see the "x"s.