That's good to hear!

Great!

It never ends! Thank you for your continued patience. I think I've fixed everything now with d60319b19027 and 59af70a2ec87, but I'm looking forward to finding out...

Thanks for pointing out these problems. Clearly I was over-optimistic before! I believe I've now taken care of the remiaining issues in dfe25479c450 and 8ca19783349d - though of course I could be wrong.

Sorry - by "JS-related issues", I meant issues where the fix needs to be in the JavaScript code, rather than in PHP.

Here's another change, which I think fixes issues 14 and 15, and also some new long-overdue i18n messages: 62b150dca2bb

@BlankEclair - thank you for this very detailed analysis, and the video, and the patch! This is extremely helpful. (And I had no idea that there were this many unescaped messages and other strings!) Unfortunately, I didn't see the patch until now - by which time I had already written up fixes on my own for most of these issues. Although in many cases our fixes are (as maybe could be expected) very similar to one another's, and in some cases your fixes are a little more elegant. Anyway, I'm going through the issues piecemeal, and here is the first of my changes:

I'm amazed that this never came up before! I guess people don't enter negative numbers that often. Anyway, @KGello - thanks for pointing out the problem.

@Samwilson - thank you for pointing out this problem. I believe it's fixed now...

Oh! That's quite surprising, given that (as you pointed out) the Postgres drilldown query checks for both blank and null.

Why do you need to change the PostgreSQL query at all? I thought it was only the MySQL/MariaDB query that was the issue.

Actually, thinking more about it now - unlike with #cargo_store, with the Lua equivalent, you really can tell whether a value was intended to be blank or null. So perhaps the value should not be changed - and the Special:Drilldown SQL query should just be changed to match the Postgres version, as you suggested.

Okay, this is interesting. I had forgotten this, but #cargo_store, when it takes in a blank value, changes it to null before storing it to the DB. It appears that, now that storage can be called from Lua, this code should be duplicated, or moved, somewhere else - around here in storeAllData() might make the most sense, since there is a loop that already cycles through all the field values.

Somehow, for you, this line:

@Rishi2108 - sorry for the delay. That's great to hear! Are there specific extensions you know about and are interested in? Or are there specific technologies (PHP, JavaScript, Vue, SQL) that you want more experience with?

@Jayanthvikashs - thank you for fixing this!

That does seem to work, yes! I'm indeed quite surprised. If you create a patch to fix the JS bug you talked about, I would be happy to check it in.

Yes, sounds good.

What do you mean by the "backend code" - the PHP code that displays the forms? If so, I would be surprised if the current code can handle parsing pages that contain two or more levels of nesting - though I could be wrong. Do you know definitely that this works?

I agree - it would be great to have more tests for Page Forms.

Well, Page Forms doesn't support more than one layer of nesting, i.e. three-dimensional data or higher within a single page. So I would argue that the real bug is just that this display happens at all - maybe it should just show an error message.

@Skillson - thank you for reporting the bug, and @ashley - thank you for the fix.

I generally don't make changes to the "REL" branches - I always recommend that people just the "master" branch for my extensions. With that said, if anyone wanted to make such a patch for REL1_39, or any of the other branches, I would merge it in.

@Allanext2 - does this solution work for you? I really just wanted confirmation that it solves the problem.

This is finally done! @Jayanthvikashs - thank you for implementing this; and @Rockingpenny4 - thank you for the great suggestion.

@DavidGdx - thanks for diagnosing the problem. I think it's now fixed, but please let me know if this fix works for you.

@-style mentioning is now fully supported. Thank you, @Jayanthvikashs, for all your help with this!

This was fixed for MW < 1.35 back in 2021, with e2452ff998d9 - support for those earlier versions is no longer necessary.

It's not suprising that this fails for you, because the "datetimepicker" input actually does not support the "include timezone" parameter, unfortunately - only the "datetime" input does. That, in turn, is because the JavaScript widget that "datetimepicker" uses - DateTimeInputWidget from OOUI - doesn't support timezones, other than UTC. So, other than with a hack, I don't think can be done; you might be better off just setting that default value to UTC time, or of course using "datetime" instead.

I'm marking this as "Declined", since I think support for TinyMCE is on the way out - sorry about that.

@Bewfip - thanks for pointing this out! I think this is fixed now.

I'm closing this, because I think it's fixed... feel free to re-open if not.

@CyberSpecter - thank you for pointing out the problem; I believe it's fixed now.

I was able to reproduce this problem, but it turned out to be not due to the multiple-instance template but to "values from namespace=Main"! At least, that's how it appeared to me. I just checked in what I think is a fix - please let me know if this fixes the problem for you.

Thank you for your effort on this patch! I think it was worth the wait.

@Samwilson - thanks for pointing out the problem! (And for the suggested fix.)

Fixed, finally, I think!

I assume this is now resolved.

This proposal was not chosen - sorry.

This proposal was not chosen - sorry.

This proposal, although very good, was not chosen - sorry.

This proposal was not chosen - sorry.

This proposal was not chosen - sorry.

Finally fixed in a93e09443776, I believe.

Finally fixed in a93e09443776, I believe.

Thank you very much - it was worth the wait!

@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.