@Paladox - oh! How strange. I had tried clearing the browser cache several times before, but now when I tried it again, it did seem to solve the problem. Given that it works for everyone, it seems safe to close this. I guess I'll mark it as "Invalid". Thanks to everyone for your help.

I guess that's good enough evidence for me... I'm closing this as "Resolved". @Krinkle and everyone else - thank you for looking into this! Of course, if this is still an issue, feel free to re-open it.

@Reedy (or anyone else) - can this be closed?

I'm pretty sure this is no longer a bug, 9 years later, though feel free to re-open if anyone is still seeing this problem.

I'm closing this, based on the above reasoning - I don't think this change is a good idea.

It looks like this works, post-upgrade!

That's great to hear! Thanks for reporting the problem also. I'm closing this now.

@Nikerabbit - could you see if this patch fixes the problem for you?

Well, that fits into T355948.

You could create a separate task for this patch, or just have no task for the patch - not every patch needs an associated task.

@Rockingpenny4 - this seems like a useful change, but is it related to the original bug/task?

I think using a 3rd party autocompletion library is the better option, if it's possible - using VisualEditor would be somewhat of a hack.

Yes, you can use the "default value=" parameter - see here:

That's great to hear!

Could it be that that's just a file permissions problem? I don't see how any of the recent changes to External Data would cause that error. The fact that the Data Transfer extension gives the same error also seems very suspicious.

That's great to hear! Closing this now.

@Nischayn22 - could it be that the fix for T341904 fixed this as well?

That's great to hear! @Lkvrsfld - thanks again. I assume this can be closed now.

I think this can be closed. @Rockingpenny4 - thank you for your help with this!

@Schtom - I implemented the fix in a slightly different way; please let me know if this fix works for you.

I'm closing this, assuming there's nothing more to discuss about it...

@TK-999 - thank you for finding, and diagnosing, the problem! It was a pretty big bug. I assume this can be closed now.

@Rockingpenny4 - sorry for the delay. Your proposal looks good! Impressive previous experience. You can of course add a few more completed patches to the "Contributions to Wikimedia" section now.

@GladwinJ - thank you!

@GladwinJ - thank you!

No, there's no way to do that.

Great!

Closing again - though feel free to re-open it.

@Nikerabbit - could you let me know if the additional line in this patch fixes the problem?

I just read through your proposal. It looks good!

Right, yes - Cargo has something similar too, where you can query values in the order in which they appear on the page, but it's already unreliable, even with linear parsing.

There isn't really the concept of an order of operations for either extension, as far as I can think.

Just to chime in, I don't believe Cargo or Semantic MediaWiki will have any issues with the non-linear aspect of Parsoid. (SMW does have an issue with the "::" syntax, but that's a separate thing.)

Well... that's an okay solution. I still think it's possible, somehow, to create a <noinclude> substitute that works directly in the template. But if you got this working, then I guess there is no longer a Page Forms issue.

@Solaris22 - thank you for your work on this!

@Nikerabbit - please let me know if the new code works for you.

@Rockingpenny4 - wow, this looks great! Yes, a patch would be great to see.

@Lkvrsfld - thanks for this fix, and please see the corresponding patch I created. Does this look correct - is it just this one line?

Your proposal looks good, including your past experience and set of programming skills - I can't think of anything that needs to be added.

@KloudZ - thanks for diagnosing this problem. I think the patch I checked in fixed the problem; feel free to re-open this if not.

@Jatinder190124 - thank you for the proposal; we will carefully evaluate every proposal we receive, including yours.

@XiaofeiTM233 - thank you for this patch.

I hope it can be done with a single file, yes.

Hi - one unfortunate aspect of the Google Summer of Code is that, most of the time, by the time you find out whether you have been accepted or not to a particular project, it's too late to apply for a different one. I have always tried to avoid that happening to applicants, so my plan was always to pick someone as soon as possible. Brian and I have now done that, and we have chosen @Jayanthvikashs as the student for this project. That means the other five of you who completed microtasks will have to find another project, if you are still interested in doing the Google Summer of Code this year. It is too bad, because many of you seemed to have both the technical skills and the enthusiasm to be able to do a good job on this project; but unfortunately we can only select one student. Hopefully your effort will not have been wasted, and you can point to the task(s) you did (or are currently doing) when applying for a different project, whether it's for the Wikimedia Foundation (ideally) or elsewhere. (Certainly your effort was not wasted in terms of your code contributions to MediaWiki extensions!) Sorry, and good luck.

Okay - it seems to me that the ideal situation would be that the category call goes into the template - but does not apply to the template itself, but does apply to any page that calls that template, but does not apply to any page that transcludes one of those pages. :)

I think this is done now! @Jayanthvikashs - thank you for your help with this.

I assume by "balise", you mean "tag". But why not put this category tag into the template, rather than on each page?

Impressive! Thanks. (And I hope they get merged in!)

I assume this is fixed now. Thanks for reporting it!

Sure, it would be great to see your other contributions. Where can we see them?

Hi everyone - there are six people who have completed, or are currently working on, a microtask for this project. We plan to select someone from among these six applicants. If you are not one of these six, it is unfortunately too late for you to take this project; please find a different GSoC project to apply for.

@Rockingpenny4 - interesting ideas. I just looked again at how Google Docs does it. As far as I can tell, InlineComments does let you delete comments in basically the same way Google Docs does - in Google Docs, you can either mark a whole thread as resolved, or delete a whole thread - the effect of both is the same, and I don't know what the difference is. In InlineComments, you can click the "Mark resolved" button, which also does the same thing - maybe the name of that button should change, but the functionality is the same, I think.

The key to this bug is "pages where they're not used".

No.

I discovered that three of these six global JS variables are no longer actually getting used anywhere, so I removed them in fdbbb72c559c. That still leaves three variables, though, that should be subject to this new logic.

@Akaibu1 - I just looked into this; the problem seems to be the "&" in there, not the CSS stuff. I'm guessing that this was a bug in the Mermaid version used in Flex Diagrams (10.2.1) which has since been fixed.

Well, as far as tasks for GSoC applicants to show their coding skills, we trying to limit people to just one each, to make things fair. And that task you linked to is indeed bigger than a microtask. With that said, you (and anyone else) are of course free to work on whatever you want to, this being open source.

@TK-999 - thank you for this patch! I didn't know about that pingLimiter() method. This looks like a great improvement!

Okay, this code is now merged in! @Rockingpenny4 - thank you for all your hard work on this patch!

What specific errors are you seeing? I didn't see anything about using spaces instead of tabs.

That sounds fine with me - let's go with "data-row-name", then.

Excellent! Thank you for this patch.

No, the value of the attribute is $this->name. Anyway, leaving aside what was said before, what do you think a good name would be for this attribute? Ideally it should be simple but also non-ambiguous.

Right, we talked about "data-row-name", but now it's just "data-row". It's not a big change, and it's not necessarily bad - I was just wondering why you made the change.

This generally looks good! But there's something wrong with the tabs and spaces, as you can see in the diff.

Great! The code looks very simple now. But I think there's a way to make CargoTemplateFormat.php even simpler! (Let me know if you want a hint.)

@Jayanthvikashs - this looks great! And it will definitely work. But to make this a little more of a challenge: I think it would be slightly better if the code in CargoTemplateFormat.php and CargoStore.php did not modify the original array in each case. Could you change the code so that these arrays don't get modified? (For CargoTemplateFormat.php, this could have the nice effect of simplifying the code in general.)

It looks better! I added my comments there. Also, please "abandon" the two other patches - the MediaWiki core patch, and 1008409.

That sounds logical.

I'm marking this as invalid, based on what I currently know. If you think there's a Cargo bug there, feel free to re-open this.

@Schtom - thank you for this work! These are some great improvements.

I just added T358843 as another microtask.

@Destiny - that sounds good. I think there are still two available microtasks: T353094 and T324173 (the latter had a patch submitted for it, but it wasn't quite correct). Feel free to take one of them. (If we run out of microtasks, I can add a few more.)