User Details
- User Since
- Nov 14 2014, 3:01 AM (510 w, 5 d)
- Availability
- Available
- LDAP User
- Yaron Koren
- MediaWiki User
- Unknown
Thu, Aug 22
That's good to hear!
Tue, Aug 20
Great!
Mon, Aug 19
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.
Fri, Aug 16
Sorry - by "JS-related issues", I meant issues where the fix needs to be in the JavaScript code, rather than in PHP.
Thu, Aug 15
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:
Tue, Aug 6
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.
Mon, Aug 5
@Samwilson - thank you for pointing out this problem. I believe it's fixed now...
Wed, Jul 31
Oh! That's quite surprising, given that (as you pointed out) the Postgres drilldown query checks for both blank and null.
Tue, Jul 30
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.
Mon, Jul 29
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.
Jul 25 2024
Jul 24 2024
Somehow, for you, this line:
Jul 23 2024
@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?
Jul 19 2024
@Jayanthvikashs - thank you for fixing this!
Jul 17 2024
Jul 16 2024
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.
Jul 15 2024
Yes, sounds good.
Jul 12 2024
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?
Jul 11 2024
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.
Jul 10 2024
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.
Jul 9 2024
@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.
Jul 8 2024
@DavidGdx - thanks for diagnosing the problem. I think it's now fixed, but please let me know if this fix works for you.
Jul 4 2024
Jul 2 2024
Jun 12 2024
@-style mentioning is now fully supported. Thank you, @Jayanthvikashs, for all your help with this!
Jun 6 2024
This was fixed for MW < 1.35 back in 2021, with e2452ff998d9 - support for those earlier versions is no longer necessary.
May 23 2024
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.
May 22 2024
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.
May 21 2024
@CyberSpecter - thank you for pointing out the problem; I believe it's fixed now.
May 20 2024
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.
May 17 2024
@Samwilson - thanks for pointing out the problem! (And for the suggested fix.)
May 16 2024
Fixed, finally, I think!
May 8 2024
I assume this is now resolved.
May 6 2024
May 2 2024
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.
Apr 29 2024
Finally fixed in a93e09443776, I believe.
Finally fixed in a93e09443776, I believe.
Thank you very much - it was worth the wait!
Apr 15 2024
@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.
Apr 10 2024
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.
Apr 8 2024
@Reedy (or anyone else) - can this be closed?
Apr 4 2024
Apr 3 2024
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.
Apr 2 2024
It looks like this works, post-upgrade!
Apr 1 2024
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?
Mar 26 2024
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.
Mar 22 2024
Yes, you can use the "default value=" parameter - see here:
Mar 19 2024
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.
Mar 18 2024
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.
Mar 15 2024
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.