Okay, that was unexpected. Great!

Well, there have been some changes to "tokens" since version 5.6.2, so you never know. Plus, if you have local changes to the code, anything is possible. But if you are seeing this same problem with the latest Page Forms code, then I have no idea what is causing the different behavior. The presence of SMW is one option; so is the different MediaWiki version. I would consider both of those explanations unlikely, but then again I have no better idea.

@Sugarbravo - do you consider this issue resolved?

I've never heard of this error message - could it be due to some PHP setting?

Well, "Save and continue" uses the "autoedit" API action, and autoedit has had a number of big recent fixes, like 6616372ef665, so it was certainly possible that you were seeing some bug that had been fixed already. But since that is not the problem - I do wonder about the "Objekt" field value containing square brackets. Could you see if removing those brackets makes the problem go away?

I doubt it's SMW-related - though I can't be sure. But your wiki also uses an old (or maybe even custom) version of Page Forms. Maybe upgrading there would fix the issue?

Ooh, thanks for letting me know about that. I think I just fixed it; please try again.

Could you elaborate on what is going wrong, or at least what changed?

Okay, that's good to know. Yes, since you offered - could you replicate this problem on https://discoursedb.org?

Unless I hear otherwise, I'll assume that this problem is just due to the old code on the Sandbox site.

I can't reproduce this problem - the SMW Sandbox site is using a somewhat old version of Page Forms, so I'm guessing the problem has been fixed since then.

@Sugarbravo - are you saying that this call fails (or returns the wrong result) as well?

Oh... if t2 was not in "from", that would definitely explain the problem.

No - that sounds like a strictly SMW issue.

@Emwiemaikel - thanks for pointing out this problem as well. I made a slightly different change, but same idea.

@Emwiemaikel - sorry about the problem, and thanks for the patch! I checked it in myself. I believe this is now fixed.

@YOUR1 - there are about six different bugs in Phabricator relating to mapping in remote autocompletion for Page Forms; this is one of them. I and others have made various attempts to improve/fix mapping in remote autocompletion over the last year or so. (Mostly, by disabling it, i.e. making autocompletion local if there is mapping involved.) I'm not sure what the current issues are with mapping and autocompletion, if any - or whether any of these bugs can be closed. But if you can let me know whether this particular bug is still a problem, that would be helpful.

I assume this is fully done now... feel free to re-open if not.

I don't know anything about CVE IDs, so - no.

@Kamalinux - thanks for pointing that out; I think this is fixed now:

Sorry about this. I believe if you get the latest code, all the #autoedit problems have been fixed. If you try it out, please let me know if everything works for you.

Replace Text now has two PHPUnit tests! Thanks to @Umherirrender and @TechieNK.

I'm closing this; anyone can feel free to re-open it if there are still any issues.

Fixed, thanks to @TechieNK.

I just tried this, and the font sizes look fine now; I'm guessing this was fixed at some point.

Very interesting - thats good to know.

A search limit is now available as a global setting, a UI field, and a script parameter, so I would say this task can be closed!

@Samwilson - thank you, this is a big improvement!

@Bethoniel - thanks for pointing that out, and sorry about the problem. This bug was in place for just about a year! I believe it's fixed now.

Can anyone here verify whether this patch fixes the problem? (Assuming it's still a problem.)

In theory that's true, yes... in practice, I'd say there's just as much chance that a REL branch will be broken as that master will, for this extension. That said, I'd be happy to accept any fix patches to any previous branches.

I believe this is now fixed, thanks to @TechieNK's patch! If anyone can confirm that it works correctly now - or still doesn't, for that matter - that would be great.

Anyone could do it... but is it really important? Why not just use the master branch?

@KloudZ - thanks for pointing that out; I think this is now fixed too.

It sounds like you are using the REL1_35 branch of Page Forms. You should switch to the most recent version of Page Forms, which thankfully still supports MW 1.35 - I think this particular bug, or set of bugs, was fixed a long time ago.

I think this is fixed now. Sorry about that problem! And thanks for reporting it. I wonder how long it's been there... it definitely was not always a problem.

This is a bug that I think was fixed a few months ago - unfortunately I think there has not been a version release since then, so you would just have to switch to the latest code for Page Forms. Which is a probably a good idea anyway, because you are using a rather old version right now.

Oh, I wasn't thinking about using Echo directly for the notifcation - but that's an interesting idea. Anyway, it sounds like this particular task can be closed.

It would have been nice to hear back from the user who reported the error, but I think it's safe for now to assume that this problem was indeed fixed.

Okay, having looked now at the code, I think I understand what's going on: if the earliest pending review is more than $egPendingReviewsEmphasizeDays days old, that link gets displayed with font size "16px", which, depending on the skin, can really stand out. I guess maybe this isn't so bad, since that's the intent - and the admin can make this go away by taking care of those long-pending reviews. On the other hand, it's unconventional: the Echo extension, for example, takes care of signalling to the user that action needs to be taken by using the color red, not changing the font size. But maybe it's fine.

Okay, I think it "works" now... I still think the use of CSS to change the display of the link is quite weird, especially with the Vector skin - in your screenshot, which looks like it uses the Chameleon skin or something, it looks more normal, although still a little odd. But maybe that's a separate discussion.

For what it's worth, with two dropdowns you can use "show on select" instead. It's kind of annoying, because then you have to define a different 2nd dropdown (with a different field name) for each value in the 1st dropdown, but it works.

Sorry it took me so long to respond to this. You could get around this by blanking the page MediaWiki:adminlinks_pagenotfound - which maybe is enough of a solution. Anyway, it looks like Admin Links is no longer even installed on translatewiki.net, so maybe this doesn't even count as a bug any more. Is it okay to close this?

I'm marking this as "Declined" - I'm not sure I fully understand this task, but from having looked at the code in the (abandoned) patch, it seems to me that this change is only relevant for FlaggedRevs, where every revision gets its own approval/disapproval, and not for Approved Revs.

Yes, looking now at the code, the handling of the SkinTemplateNavigation::Universal hook is clearly not correct. On the other hand, the "expected" behavior also seems strange. The fact that the "Watchlist" link is meant to be replaced is strange - what if the user just wants to check their own watchlist? As is the fact that this one link has its own display class, meaning that the text is supposed to look different from all the other links around it (bigger, I guess). Can you explain the thinking behind these changes?

To clarify - are you saying that the value of the second input should always be cleared, or only cleared if (as in your case) "existing values only" is set?

Thanks for these patches, then! I think I have fixed all six of these issues - in some cases with your exact change, in some cases with a null check. Anyway, I think it's resolved - but feel free to re-open if you still see any PHP 8 warnings.

Good idea - I think this is done now.

What makes you think that there's a problem at all?

Wow - I don't think I had seen this one before. It does seem to be related to Page Forms, but I'm not aware of any current issues with Page Forms and ConfirmEdit, so I'm guessing that whatever problem the person was seeing has been fixed since then.

Thanks for putting these together. Are some/all of these real bugs, as in, you have seen a warning message from PHP 8 coming from these lines? Or did you simply look for instances where str_replace(), etc. were being called without a "null" check?

This is done, I assume...

@Dinoguy1000 and @SnorlaxMonster - thank you for the suggestions. Hopefully this is better late than never!

Okay, great. It would be nice if the page explained this better, although I'm not sure how best to do that. Anyway, it looks like this particular issue can be closed now.

Okay, that's interesting - I had assumed that your wiki (and those of the other two people who had reported this issue) simply lacked forms, and maybe even templates. But yes, Special:MultiPageEdit can ignore existing forms - that is meant to happen when a certain template is handled by more than one form, in which case there is ambiguity about which form should be used to edit the pages that contain it. Could it be that more one form on your wiki includes the "Instrument" template?

@Meowcatx - thank you, that was very helpful. I had just assumed that this was a database problem, but your reporting caused me to actually look at the code, where I realized that this error output occurs when the page has nothing to display. I just checked in a fix, so that at least the big "stack trace" goes away. Perhaps the displayed message could still be clearer, though. Anyway, please let me know if that fixes the problem.

@Platinops - sorry for the very long delay on this. I finally tested this, and could not reproduce the issue. Perhaps it has somehow been fixed between then and now? Or perhaps user "Bob Smith" had administrative privilege?

Is this still an issue? Change a8f0de6382f5, from May 2023, might have fixed it.

Fixed, I think...

I don't know how this got fixed, since I don't think that was dependency was added, but I just tried it and the combination of SyntaxHighlight, VEForAll and Page Forms seems to work fine for me - and no JavaScript errors appear. I assume this can be closed.

I hadn't heard of the (now-archived) Bullet Feed extension - I just looked at it. Very interesting; yes, it has a more informal approach to linking and all that. Okay, I'm glad you can modify your setup to handle this more structured approach. I'm "declining" this task; hopefully that's alright.

I still don't really see the point of a "link from description" parameter. If you use the "url" field, then you don't even need the "see ..." text, because the link is already there - no? And of course, with "url", you don't need to worry that every editor remembers the required format for the description.

That's true, "link from description" would solve the problem of unexpected behavior. But is this even that useful? Is it common for the canonical link of a news/etc. item to be contained within the description, and then for it be guaranteed as the first link? This might be specific to your particular description format.

Yes, this sounds like a "too-clever" solution, which indeed could lead to unexpected behavior - I don't think it's a good idea.

I just changed the value in External Data to include Composer v. 1 as well, here: https://gerrit.wikimedia.org/r/942479

I believe you can now use External Data with Composer version 1 again - sorry this took a while to fix.