Setting to "Resolved" - feel free to re-open if this is still an issue.
I'm guessing that this has been fixed with Approved Revs 1.2... feel free to re-open if not.
Sorry about the problem, and thanks for the fix! I'm assuming all of this works now.
Mon, Oct 14
Fixed now, I guess? Thanks for the patch, and sorry for the delay!
Thu, Oct 10
Tue, Oct 8
Mon, Oct 7
Thu, Oct 3
Wed, Oct 2
@KatkovYury - sorry for the long delay. This was actually a Page Forms bug. I believe it's fixed now, though I can't test it because it only happens when SMW is installed. I'm setting the bug to "Resolved" - please re-open it if the fix didn't actually work.
Mon, Sep 30
I forgot to say - thank you, @Legoktm, for your help with improving the security of all three extensions.
Okay, I believe all three patches are now merged in. In the case of Approved Revs, the code checked in was simpler than the original patch because support for MW < 1.28 was removed, soon after the original patches were created.
Sun, Sep 29
That's a good idea - I added in this code in 0069ae1265dc.
Fri, Sep 27
@Aklapper - sorry for not responding here before. I believe I took care of the Cargo patch with the commits 9b8d3a0a2d10 and 3407fb767040. I still need to take care of the Approved Revs and Admin Links patches.
Sep 11 2019
Sep 9 2019
Sep 6 2019
Sorry about that! This was a bug from January. I just checked in a fix for it; hopefully it will get to you soon.
Wow! It looks like that bug has been in place for a long time. Sorry about that. I just checked in a fix - hopefully it will get to you soon.
Sep 5 2019
That seems like the right approach, yes. I think someone else made that request too recently, but I can't remember where. Hopefully this is easy to do.
Sep 4 2019
I should probably know this, but how do you restrict an entire form?
Yes, that's not ideal... what do you think the behavior should be, if there are mandatory-but-not-visible fields that are left blank?
Is it your view that people will never create a field tag on purpose that has "mandatory" and "restricted", but no "default"? If so, I don't know... I haven't heard of someone doing that, but I can imagine that it could theoretically be useful, if only as a way to restrict creation of pages to a specific subset of users.
The end product ended up being somewhat different from this task description, though just as useful - the original task was to add calendars to Special:MultiPageEdit, and instead calendars were added to single-page forms. So this particular task wasn't done per se - I'm still closing it, though, because it's strongly tied in with the 2019 GSoC project.
Aug 30 2019
I plan to do this as soon as support for MediaWiki 1.26 and earlier is dropped - which is also overdue. It might happen soon.
Is this something *I* should do? I've never dealt with branches.
Aug 29 2019
Sorry, what does this patch do?
Aug 28 2019
Aug 27 2019
Aug 21 2019
Good point - I didn't think about that. I just checked in what I think is a fix for this.
Aug 20 2019
Oh! That's good to know in general, outside of this bug. And @Darenwelsh - thanks for translating between the two bug reports. :) I'm back to having no idea - I think someone will have to go into the code and see exactly what's happening.
Thinking about this again, I still think that this is somehow due to $smwgEnabledCompatibilityMode, if only because I haven't heard of this problem outside of that variable. Maybe this variable is not being handled correctly in recent versions of SMW?
Aug 19 2019
Okay, I just checked in a modified version of this patch, at 8c75f7b5aad5 . Sorry, @Rcdeboer - I forgot to credit you when I checked in the code. But I definitely thank you. This code is working a lot better for me - if there are still any issues, with SMW data or anything else, maybe it should go into a separate bug/task.
Oh. I don't know, then.
It's not a bug, it's a "feature". A very strange feature - SMW shuts itself off if Cargo is installed on the wiki, unless the following is added to LocalSettings.php:
Aug 16 2019
There's no difference in terms of pull/push between DPL and the rest - the only difference is that Cargo and SMW are querying their own database tables, while DPL queries core MediaWiki database tables.
Aug 15 2019
Aug 13 2019
Oh, I didn't realize (or forgot) that you work together, and that "we" thus included him. I guess I'll have to look into this, then...
Aug 12 2019
@Rcdeboer - what's the status of the patch? Are you still working on it?
I believe this is an Approved Revs issue - and the one already covered in T227801. That one is waiting for a patch from someone else - I need to see what the status is of it.
Aug 7 2019
I'm still waiting for @Rcdeboer's full patch. Or is there something I can do already?
Aug 6 2019
Sorry for the delay in responding. I believe the "placeholder" parameter has been supported for section tags for a long time, but it just wasn't listed in the documentation. I just added it to the documentation - sorry about that.
Aug 5 2019
Sorry for the delay. I don't understand this request - what is that you want to do, that can't be done already?
Aug 2 2019
What's the page, and how are you associating it with a form?
Jul 26 2019
@dlo - thanks for the patch! I added it to the code; hopefully Cargo works well with SQLite now...
Jul 24 2019
Jul 16 2019
Oh, okay. That's too bad.
Oh, okay - I knew about that "compatibility policy" parameter, but never went through all of my extensions' pages to make sure it's there. I just added "compatibility policy=master" to the Page Forms extension's main page. (The compatibility policy is "master" for all of my extensions.)
Unfortunately, phan will complain about undefined classes if SMW is not installed in the test environment,
@Daimona - thanks for putting this together, and of course for your work on the actual patch, which looks like it will make a lot of improvements to the code. Just to clarify one thing: Page Forms doesn't require Semantic MediaWiki, and is often used without SMW, so SMW doesn't need to be loaded for any testing.
@Nikerabbit - thanks for that explanation. Some of these tasks, there are already plans to implement, like adding in more tests. I'd say more, but I don't know if a closed bug report is the best place to have this kind of discussion. :)
Hi - I don't know if this is a good title for this task either, since, whatever you think of Page Forms' current compatibility policy, it is clearly stated on the extension's main wiki page, where it says that "MW 1.23+" is supported:
Jul 15 2019
Would it make sense, then, to rename this to something like "Add phan to Page Forms"?
Sorry about the problem! I fixed this in 59c1d49f8d43.
@Nikerabbit - what do you mean by that?
Is this a task, or what?
Jul 12 2019
Great. I didn't know about the SecondaryDataUpdates hook! I'm reading about it now - it looks like it was deprecated in March 2018, in favor of the RevisionDataUpdates hook:
That's great to hear!
Jul 9 2019
Jul 8 2019
I just checked in a patch based on this one (at 82039d9d661c), though first making some changes to the autocompletion code, to eliminate the code duplication that your patch reminded me about. Thanks!
Jul 5 2019
I don't know the right way to mark a bug as a duplicate, but anyway, this is a duplicate of T225685.
Jul 1 2019
@Kghbln - thanks for including me; no, I didn't see this before. I just checked in what I think is a fix for this.
Jun 30 2019
I was hoping to get confirmation that the fix actually works, but sure - no need to draw out this discussion any more. Feel free to re-open if this still an issue, of course.
Jun 27 2019
Thank you for debugging the problem and finding the fix! I just checked in your suggested change.
Okay, I just checked in a fix for this. It's different from what you have, but hopefully it works!