Why do you have #forminput in a table?
Sorry about that! I think this is fixed now.
Wed, Dec 2
I don't know if it matters, but I just want to add that I, too, think this group of developers are very well qualified and deserve to have their own Gerrit group.
It's actually worse than we thought - I'm pretty sure it's unrelated to "show on select", and just happens whenever a datepicker input is made mandatory.
Tue, Dec 1
Well, because I think it unnecessarily complicates the code, for the sake of backward compatibility that I think is minor.
Well, right - "ghost restrictions" (or really, "ghost permissions") is what I was talking about when I said that it's easy for an admin to go through, find "users" params, and delete them. Don't you think that's a good enough solution? Especially since I don't think an unauthorized approver can do much damage.
I think you may have misunderstood what I'm saying. Here's the basic idea: disallowing the "users" param seems reasonable, but that can be done by just modifying the code that handles #approvable_by - which seems quite a bit simpler than how the current patch does it. Wouldn't you agree?
That's fair about refactoring - so let's talk about this change first. I understand that this patch will work better for wikis that already have #approvable_by with the "users" param. The question is, is that superior handling worth the extra complexity? It doesn't seem that way - after all, it's easy to just get rid of any "users" params that already exist on the wiki.
Okay, now I get it. It would be easier to just disable the "users" parameter when handling #approvable_by... I suppose the downside there is that you can't do anything about #approvable_by calls that already exist and already include a "users" param, but that doesn't seem like a big deal. Or is it?
@MarkAHershberger - could you explain this in more detail? I don't really understand the requested feature, or the patch.
Mon, Nov 30
I think this is fixed... feel free to re-open if not.
Sun, Nov 29
@Aklapper - Cargo is still meant to support MW 1.33, so that part is fine.
Fri, Nov 27
Thu, Nov 26
That makes sense - thanks.
I... still don't understand. Please, just someone tell me what the message should look like. :)
@abi_ - I speak Hebrew, and I'm still not sure I understand. :) What should the message look like instead?
Wed, Nov 25
Oh, that's very interesting. The JS problem seems unrelated to the blank form problem, which I think that this bug report covers four separate bugs. :)
Oh, that makes sense.
@abi_ - thank you for looking into this. I should have specified this before, but the "translatewiki" account does in fact have push access to the GitHub repository, as requested.
Sorry, I should have been clearer - please add "?debug=true" to the URL of the actual form, where the error happens, not the form definition page beforehand.
Mon, Nov 23
@Letofred - for #2, could you add "?debug=true" to the URL? That will hopefully provide a more useful error message.
Fri, Nov 20
Oh, okay. Well, I'm pretty sure that just setting a "table" value in the query string for Special:CargoExport won't work with any PHP version - although the error message is probably different, depending on the version.
Is this really related to the PHP version? I mean, the code is trying to access an array index that doesn't exist - I would think that would cause problems in any version.
Thu, Nov 19
For the blank pages, please see this:
Wed, Nov 18
Tue, Nov 17
Mon, Nov 16
Fri, Nov 13
Thu, Nov 12
@Tgr - thanks for taking care of this. I didn't realize a Vagrant role for Page Forms would be quite this simple! My only comment is that the description sort of makes it sound like Page Forms requires the presence of either SMW or Cargo, while in reality it can work without either one. But it probably doesn't really matter.
Wed, Nov 11
@Platinops - if you could create an actual Approved Revs patch for this (even just as a file), it would really be helpful...
@Nikerabbit - what does this mean? If you get that change into WikiEditor, can I switch Page Forms to using the simpler code, at least for MW 1.34+?
Tue, Nov 10
I think this is fixed now.
Mon, Nov 9
Unfortunately, I have to mark this as "Invalid", because Page Forms no longer uses jsGrid for spreadsheets - it now uses jExcel.
Thu, Nov 5
Wed, Nov 4
Nov 3 2020
Nov 2 2020
Oct 30 2020
Oct 29 2020
I thought about having this kind of column (maybe "_lastEditor" is a little better name for it). But how useful is this information?
Oct 28 2020
Oct 27 2020
Oct 26 2020
Oct 23 2020
Sorry for not responding before. I can't replicate this issue. Is this happening with only a specific input type?
Oct 22 2020
I finally removed the last references to jQuery UI in the code. This is now done!
Yes, all of the listed items are done now.