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.

Well, I updated the version in composer.json - hopefully everything works now. @MarB-96 - thanks for the suggestion.

Actually, maybe 1 - 2 is the easiest-to-understand value, and it seems to be equivalent, according to this. What do you think?

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

Sorry it took this long to fix!

Thanks again - all that information is helpful. (I sort of knew that composer.json was also used for CI, but wasn't sure about it.)

Thanks for the information - that's very interesting. I had wondered about how Composer could get the code into the extensions/ directory.

@Osnard - I know it's strange to follow up on a patch so much later, but: is the "composer/installers" line really necessary in composer.json? It looks like most extensions' composer.json file lacks such a line - even Semantic Drilldown, which I assume is meant to be installed via Composer: https://github.com/SemanticMediaWiki/SemanticDrilldown/blob/master/composer.json

Okay, thanks - I figured that line wasn't essential to the whole thing.

@MarB-96 - sorry for the delay. I looked into this, and it looks like most extensions don't even have a line for a "composer/installers" requirement in their composer.json file (see VisualEditor's, for example). Would simply removing that line fix this problem for Page Forms?

@Aklapper - thank you!

It would be interesting to know if you see this same problem in other skins, like Vector.

Okay, I'm marking this as "Invalid", since I'm guessing that the lack of those extensions is the issue. (Though these extensions should probably be mentioned in the documentation.) As for your other questions - this is of course not a general support forum. Though again, I don't know the answer, in any case.

I don't know what the issue is with upgrading Page Forms, since as far as I know the latest version of Page Forms works with both MW 1.35 and PHP8 (certainly, it works better with PHP8 better than version 4.9 of Page Forms did). Anyway, I hope you're able to upgrade Page Forms at some point. For now, I'm closing this issue again, since as far as I know it's been fixed. As before, feel free to re-open it.

This is done now! Thanks to everyone for your help.

I don't know, but for the actual issue here, it sounds like you might just need to install the Math and Cite extensions, no?

Do these buttons show up for you in the standard VisualEditor interface? If not, the issue may be lacking the necessary extensions - Math and Cite, I think, though I'm not sure.

It sure does. I had no idea about that "nonwmf-skins" repository.

Oh, okay - I guess I didn't need to go into that whole long analysis. :)

Sorry for the very long delay in responding. I just tried this out, and couldn't reproduce the problem, so I'm guessing that it was fixed sometime in the last five years.

@vbrooks (or anyone else) - do you happen to know if this is still a problem? Four years later, I still haven't heard of this problem from anyone other than NASA.

What version of VEForAll are you using?

I don't understand this issue - do you have some special styling in the form, or the wiki, that overrides the CSS defined by VEForAll?

@DAlangi_WMF - thanks for your help with this. I think is fixed now.