@ssaluja16 - yes, there are lots other ways to contribute. But you should know that I already selected another student as the one to do the GSoC Page Forms project (assuming the project gets selected). Sorry about that. So if you're looking to do a GSoC project, I suggest you find another one.
Fri, Mar 16
@ssaluja16 - thank you for looking into this. I am marking this issue as "Resolved", based on your findings.
Thu, Mar 15
I moved Nischay from this project to the Page Forms one.
Moved Nischay over from the Cargo project to this one.
(This shouldn't have been modified.)
Wed, Mar 14
Tue, Mar 13
Mon, Mar 12
Done! Thanks to a patch by @Nikhil-nk .
Sun, Mar 11
The FancyBox upgrade has now been done, thanks to a patch from @yashdeep97, and there's also a patch in place for the Dynatree/Fancytree upgrade (https://gerrit.wikimedia.org/r/#/c/416920/), though it needs a little work. So the only upgrade really left to do is the Select2 one, and, as noted before, that's the hardest one. Still, this has been great progress.
Fri, Mar 9
Oh, very good to know - I didn't know there were any JSONPath libraries for PHP (it's been a long time since I looked).
Thu, Mar 8
I think this is fixed now!
@yashdeep97 - well, someone's already working on the Dynatree one, and jsGrid probably isn't worth doing, so that just leaves Select2 and FancyBox. I looked into Select2 at some point and I think it might be quite challenging. But the FancyBox upgrade may be doable. Sure, feel free to take it if you're interested.
Wed, Mar 7
This particular line is fixed now, as have most of the calls to SpecialPage::getTitle(), though a few stray calls remain.
Fixed - thank you!
Tue, Mar 6
Fri, Mar 2
I'm marking this as "Resolved", then - feel free to re-open.
@sahil505 - great! Although it should only display an error message, not any (bad) data.
Thu, Mar 1
@Bawolff - thanks for the help; I just checked in what I hope is a fix for this security problem, based on your recommendation.
Hi - to any potential Google Summer of Code students: there are already around eight students who have contacted me about this project, and I plan to select from that group; so if you haven't yet contacted me about this project, either on Phabricator or via email, please find another project to do. Sorry.
@Gopavasanth - yes, that's it.
Wed, Feb 28
@EllipticMW - I think they both use the same code to do the actual saves, which is contained at /includes/PF_AutoeditAPI.php (which means that the file is somewhat misleadingly named). The issue is that the code to set the new wikitext for the page is totally different. With regular forms, it's just based on what's contained in the form - the code doesn't care what's currently on the page, and just overwrites it completely. With #autoedit, the code takes what's on the page and modifies it. (Assuming it's not a new page.) Anyway, it's different logic.
@Bawolff - yikes! That's pretty bad. Judging by that blog post, I assume by "brick" you mean just crashing the database, as opposed to harming its contents in some way?
Tue, Feb 27
I just got Special:RunQuery embedding working again, but unfortunately this parsing problem is still there... five-year bug.
@Nikerabbit - sorry about the problem. I just checked in some changes, and I think this is finally fixed now.
@priyanshu_varshney - thank you for your interest. I just added another micro-task, T188414, that hopefully you can work on. I don't know how hard it is; if it ends up taking you more than a few hours, please just stop and let me know what your progress has been.
Mon, Feb 26
@Aklapper - actually the question was directed to redrooster (but he figured that out).
I should note that Page Forms still supports MW 1.28 (and even older versions than that). Still, it would indeed be good to know if this problem still exists with newer MW versions.
@rosalieper - please don't take this task; I'm trying to limit the number of micro-tasks that any one person takes, and I think you've already done two.