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

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