@Miloslanda - please make sure you're using the latest version of Page Forms, 6.0.4.

@Alex44019 - thank you for the analysis, and for the fixes/improvements to the documentation. I look forward to any patches you provide.

Thanks, @thcipriani and @Reedy! Let's see how this goes. Maybe this will be a good test case for removal of REL branches for many other extensions...

I assume this can be closed...

Sorry, that's really a question for @Techwizzie - it's his extension, I'm just a fan. :) From my perspective, though, I think this makes sense.

Well, I created (and merged in) a cherry pick to REL1_45 - but it looks like cherry picks to any previous branch will require some manual work.

Sure, that sounds good to me - let me know if you want me to do it.

@TechieNK - thank you for this fix!

That translation thing sounds interesting! Could/should a prompt be added for that, if the user's language is different from the content language?

I do wonder about that. Given that, right now, Wanda is just basically doing a text search rather than using a vector database, is it even possible for the LLM to read and answer questions in language A about content that's in language B?

Maybe there's no need for this setting, i.e. the additional LLM prompt "Please provide your answer in the language with code ..." should just always be added? I don't know if there would be a case where it's not a good idea to add this.

Okay, this looks good! Could you create a patch for it?

Sorry for the delay. I don't see any way for me to delete these branches, either.

Marking this as "Invalid" - feel free to re-open if escaping the curly brackets doesn't work.

I can't say for sure, but I don't think I have that option.

Okay, I think I see the issue: Page Forms only creates a "Data structure" section if one does not exist (see here), but in the SMW code, it creates one no matter what. Maybe I had assumed that the SMW code would always be called be first, if both were installed; I'm not sure. Anyway, one relatively easy solution would be to have the SMW code first check before adding a section, like the PF code does. Your code does what might be the better solution, - assuming that no one will ever want to have two sections with the same name, which I think is a reasonable assumption. It seems a little needlessly complicated, though: the lines from 44-63 seems like they could be handled with a single section of code, without the "if" statement.

Done! Thank you, @Samwilson.

I think it makes sense to remove the REL branches for every such extension that's also on Gerrit. It may seem drastic, but these branches currently cause a lot of confusion, without much of an obvious benefit. Sure, it's nice to get the right version of an extension for one's wiki running, say, MW 1.35, but for these extensions, there's a good chance that the REL1_35 branch is not the right version, and will still have MW 1.35 compatibility bugs.

Option #5! Also a good one.

Actually, there's a fourth option, as far as I can tell: delete the REL1_43 and REL1_44 branches, and recreate them as copies of master. (This unfortunately can't be done for REL1_39, since the latest Cargo code only supports MW 1.40 and higher.) I would think this is the best option, at least for those two branches, since it's the most painless overall. But I'm not against any of these.

Hi, I think you just need to escape the curly brackets - see here: https://www.mediawiki.org/wiki/Extension:Page_Forms/Defining_forms#Reusing_form_elements

Feature added! Thank you, @Jayanthvikashs .

Evidently some other fix needs to be backported to these branches before this change (or any other) can pass validation; I thought it was this one, but clearly not, since this cherry-picked version gets the same error:

Okay, thanks, very interesting. And I guess I understand the need for a bot, for a large site - there would be too many approval-requiring changes being done for humans to have to deal with them every time.

@Anderlaxe - sorry, I think I'm missing some basic information. Is there the possibility of Approved Revs being used on some Wikimedia site? Or another large site? And why would a bot be needed for approving changes?

Oh, yes! I forgot about this - sorry.

Thank you, @sanjaisid!

@SomeRandomDeveloper - thanks for pointing this out; I believe this is fixed now.

@Gorasuhl - thanks for pointing this out; I think this is fixed now.

I believe this issue was fixed by the change to Codex in T406737, so I'm closing this. I assume that the patch submitted can be "abandoned" now, since it's no longer relevant.

@Tepid_b: thank you for doing all this research! What a relief that this is not actually a Widgets bug.

In the interest of keeping things manageable, I'm closing this, since neither I nor others have been able to duplicate the problem; but please re-open this if you still see this happening.

@Taylan - thank you for the research, and the detailed explanation! Hopefully this fixes the problem.

Closing this now; this probably could have been closed a long time ago!

@SomeRandomDeveloper - thank you for these patches. The one for master is not going through because of the recent removal of the cl_to field from the categorylinks table - which presumably is also preventing commits in something like 50 other extensions that use cl_to (including some of my own). I need to modify my extensions to not query cl_to - although if you want to try your hand at fixing WatchAnalytics, feel free. (The use of cl_to in WatchAnalytics seems more involved than in most of the others.)

@SomeRandomDeveloper - yes, I'm the closest thing this extension has to a maintainer. This looks like a great improvement! If you want correct attribution, etc. for this patch, feel free to create a Gerrit patch for it, and I will check it in; otherwise I will create it myself. Either way is fine with me.

Okay, interesting. I still can't reproduce the problem, though. It might be because of the old Approved Revs version, although I don't think there have been any changes to "blank if unapproved" handling during that time. Could it be that you placed this line in LocalSettings.php before the inclusion of AR?

Great to hear! Thanks for reporting the problem.

Thank you, @TechieNK!

By the way, if anyone's curious, "CTE" = "common table expression".

Thank you, @Jayanthvikashs!

Yes, I see the problem. The loading of Sortable.js was changed about a month ago, in 4c7cd83cdce - I assume that was what broke this. @Samwilson - any thoughts on this? It seems like the require( 'ext.pageforms.sortable' ); call that was added is not working.

@SomeRandomDeveloper - this looks great! Could you submit it in Gerrit?

Fixed now, I think!

Thank you for the fix!

@Orfur - thank you for looking into this. I agree that switching to variables is the way to go - it's what I've been doing with my other extensions also. I will try to get this done soon.

There are no other subtasks for this task, if I understand your question.

Fixed, I think, thanks to @TechieNK's patch!

I just wanted to mention that this looks like a subset of T377307.

I assume this can be closed.

We just tried this bug out, and couldn't reproduce it - so my guess is that it got fixed at some point through some change to delimiter handling. I'm closing this now; feel free to re-open if you are still seeing the problem.

Oops, meant "Declined".

I think I have to close this. A Cargo- or SMW-based remote mapping solution can work, because you are just matching to another existing DB table column or that sort of thing. But with something generic like "mapping template", I don't think this can be done - in order for the Page Forms autocomplete API to find all matches to what the user just typed, it would need to apply that mapping template on to every possible value, on every key stroke. Which is extremely inefficient. The only real solution is to get the full mapped set of values exactly once - which is what local autocompletion already does.

Thank you, @Collins!

I'm closing this long-ago bug as a duplicate. This exact bug is no longer fully relevant, since it has to do with the "remote autocompletion" parameter, which no longer exists.

@SomeRandomDeveloper - thank you for the patch! This was a pretty serious bug.

Oh, just saw this now.

@MichaelLyle - thanks for the code fix! I decided to go with deleting the old temporary table each time - it seems "safer", if any of the data changed in the meantime.

I assume this can be closed.

@Collins - thank you for creating these additional tests! It's unfortunate that it took so long to get this patch in, but that's alright. Getting this patch through validation led to some bug fixes/improvements in the Page Forms code, so it has already been helpful.

I'm closing this as "Invalid"... feel free to re-open it if you think it's still an issue.

@Samwilson - can this be closed now?

@Collins - thank you for creating this patch! This looks like a big improvement to Page Forms.

@SomeRandomDeveloper - thank you for the bug report. I believe this is fixed now.

@matmarex - thank you for re-subscribing me!

Well, if you can upload it yourself to Gerrit, that would be great!

@SomeRandomDeveloper - thank you for the diagnosis, and the patch. I checked in your patch here: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/FlexDiagrams/+/1179692

@Anysite - thank you for this addition!

@Collins, @Samwilson - please see my comment on the patch; I think I know why it's failing.