Forum:Ongoing Requests for FANDOM from the HP wiki community

Forums: Index > The Wizengamot > Ongoing Requests for FANDOM from the HP wiki community

As our FANDOM rep Lady Lostris has stated an interest in helping out the HP wiki community and requested being informed of possible issues needing her and FANDOM's attention, I'm creating this Forum thread so everyone can offer up their items of concern. Please separate out any request into its own subsection so the conversation remains organized and the resolution can be tracked. Thanks --Ironyak1 (talk) 20:23, 4 September 2022 (UTC)

To keep track of the bugs and progress, a spreadsheet has been created. I'll try to keep this updated as we go along. Lady Lostris /  SOAP 13:03, 28 September 2022 (UTC)

Sockpuppets

The HP community is aware of multiple sockpuppets operating currently, but when FANDOM performs an IP check, the IP does not match the past user accounts, likely because of a change in ISP or use of a VPN. Should an admin ban the sockpuppet based on the obvious patterns of behavior, the user will just go to FANDOM and complain, and FANDOM will almost invariably take the user's side and question or attempt to overturn the ban. I've considered using a community voting process, following site Policies, so that action on a sockpuppet account is based on the recognition of the behavior and confirmation of the concern from several members in the community and not just the suspicion of any single user. Regardless, FANDOM either needs to up their technical game to better identify sockpuppets or sanction a method by which action can be taken and upheld by FANDOM as allowing these sockpuppet accounts to continue to operate undermines the healthy functioning of the community. Thanks --Ironyak1 (talk) 20:23, 4 September 2022 (UTC)

Would you mind linking to the instances where Fandom took the sockpuppet account's side?

Fandom's global wiki rules and blocking policy require wiki communities to have clear local rules that can be easily found, and admins can only block based on those rules. This community has a clear policy against having multiple accounts, especially when used disruptively, so blocking according is already allowed. Accounts created to circumvent global blocks are also already blocked. While Fandom tends to look more at links in IP and email for a global ban, there is nothing standing in the way of admins placing a local ban on a user they think is a sockpuppet given that they have ample proof of that conviction and the block was thus fair. Lady Lostris /  SOAP 15:10, 5 September 2022 (UTC)

I've asked for advice before on what I could do in regard to situations when users are obviously a sockpuppet to the community but the IP check didn't match. I hoped FANDOM could advise me on how to approach it. I was informed it is not something I can outright block for and it needs very intimate knowledge of the user. And that the unfortunate thing in these sockpuppet cases is that if an IP check fails or shared email address isn't found, then it is very tricky (particularly in the case of social problems like harassing) to prove. I put together a collection of links, but outside of the HPW, people don't have intimate knowledge or experience of these users, so they fail to really support or understand it. I find FANDOM don't provide adequate support or effective guidelines for these situations.

So if I go ahead and block these users, they could lodge a complaint or appeal to Fandom. I find it difficult to trust that Fandom would understand/support me, so I don't feel confident taking action. Unfortunately, there was a situation here where an admin was judged very unfairly and lacked support for rightfully challenging a user about their behaviour. I think if FANDOM were better at identifying these sockpuppets or provided and upheld better guidelines for which action can be taken when IP checks fail, it would be very helpful. - Kates39 (talk) 19:03, 5 September 2022 (UTC)

What you were told before isn't wrong either, as that's referring back to what I said about how Fandom tends to look at those elements due to indeed lacking -- understandably -- the intimate knowledge on every community to fall back merely on editing patterns. However, to therefor seemingly come to the conclusion that Fandom doesn't understand or care for the problem is just incorrect. Out of curiosity, what kind of effective guidelines are you hoping Fandom would provide more? I can always try to pitch it internally with the Trust and Safety team, but to be frank, asking Fandom to create a tool or whatnot that would bypass VPN (disabling it platform wise isn't viable as there are also solid uses for this, such as general privacy or circumventing country censorship, which outweigh the abuse of the tool) or otherwise link accounts together when IP and email checks result to nothing, is asking the company to fix the troll problem of the internet, which is just not a realistic ask or a fair and actionable complaint at the company's address. But again, saying that doesn't mean that we do not understand how annoying it is to deal with persistent sockpuppets or do not take it seriously.

I obviously can't say anything about the instance you're somewhat referring to due to lack of concrete details, but referring back to the blocking guidelines I linked above, everyone who's blocked can lodge a complaint against the admin who blocked them. It is also our duty as a company to investigate these instances to make sure the blocks were fair, which entails listening to both sides of the story and reviewing the evidence based on which action was taken. I take it your sockpuppet blocks have been overturned multiple times then with all the gathered evidence you had dismissed for being insufficient proof of pattern to have created that mistrust in Fandom's block review? Without concrete links to situations you're referring to though this all remains very vague and difficult to reply to with concrete answers. I'd be happy to look into certain cases for you to see if I can shed more light on support staff's reasoning for siding with a potential sock puppet against the evidence provided locally, but then I do require the links and concrete facts of those situations. Lady Lostris /  SOAP 23:27, 5 September 2022 (UTC)

Can you please provide a definition of "ample proof" of a sockpuppet expected by FANDOM to determine that "the block was thus fair"? It would be helpful to have clarity on these matters to avoid (yet another) many-hours long back and forth with FANDOM over an admin blocking a user or taking other actions to enforce the wiki's policies. Thanks --Ironyak1 (talk) 17:43, 6 September 2022 (UTC)

I think guidelines on what to do if an IP check/shared email check fails will be very helpful. Particularly if they could provide a definition for "ample proof" so I know how much to prove if they were to question my decision. I didn't say that FANDOM don't care, but rather that they don't always understand due to lack of intimate knowledge, which has and could lead to hours of confusing back and forth communication. Perhaps a more defined standard/process would be beneficial for both wiki communities and FANDOM. - Kates39 (talk) 11:21, 7 September 2022 (UTC)

As far as I've seen, these situations are handled on a case by case basis with taking the usual elements like IP, usernames, and editing patterns into account. The more specific a pattern is, the more likely it'll stand as proof. I did receive the answer from Fandom staff that "we try to keep our methods to ourselves, to prevent gaming," which is a fair reasoning as that's the same reason as why AbuseFilters are generally kept hidden from the general userbase.

If you want answers in regards to that specific instance you keep referring to, I'll reiterate that I am happy to look deeper into that situation to see if I can find more concrete answers for you, but then you will have to provide me with more concrete information than just a vague reference to something that happened some time to some admin. When I mentioned it now, I got the replies "It must have been a very clear result for us to overrule a local admin on a sock though. I don't know the case, but we don't often do that on the sock issue" and "circumstantial evidence is still evidence, I wouldn't overrule a block just because we don't have hard evidence."

I will also refer back to the above linked policies: while Fandom on itself doesn't block the use of multiple accounts unless used maliciously, communities can decide to uphold a "one account"-policy (excluding bot accounts) and block accordingly, which you are already doing and can thus block locally for already. Generally speaking and per the above staff statements, Fandom doesn't quickly overturn local block decision unless there was a clear indication of it having been an unfair block. Lady Lostris /  SOAP 15:03, 7 September 2022 (UTC)

UCP Source Editor Preview

The UCP Source Editor preview is still (reported May 2021) highly unreliable and fails to properly render text widths, references, etc. This leads to extra time wasted and frustration created by having to publish, check, and fix repeatedly. Are there any plans to fix this or is the 2010 editor workaround the only solution being offered? Thanks --Ironyak1 (talk) 20:23, 4 September 2022 (UTC)

I found a ticket filed by Ursuul about "Reference cite errors do not appear in 2017 editor preview", which seems to be what you're referring to. I flagged this internally, and the priority of this ticket has been raised. I will keep you updated on developments here.

In regards to the preview of the 2017, an engineer told me that for some reason the previews for the 2017 source editor use the parsing engine that the visual editor uses to render its contents, which does not have 100% parity with the parser that is used to render the page contents that users end up seeing. Issue is that it is not easy to address this without mucking around in code that is not Fandom's but rather from a third-party (the MediaWiki Foundation itself) -- which is exactly what initially caused the problem with Fandom's convoluted backend coding that required UCP to happen in the first place (i.e. too many custom changes to the base code of the Foundation).

That said, yes, the 2010 editor thus currently remains the generally suggested workaround. I will already say that there is a ticket about the preview here as well as the preview always renders at 100% width, thus is doesn't take the right rail into account. Awaiting a fix there, this issue can be remedied by putting the following css in your personal css (local or global):

/* Fix for editing preview in source mode */

#wikiPreview .mw-parser-output {

margin-right: 336px;

margin-left: 2px;

}

This should give you a preview on fixed and wide width as if there was a right rail (it just adds a white space instead). Lady Lostris /  SOAP 15:10, 5 September 2022 (UTC)

IDK if stuff on Forum:Call for bugs on Harry Potter Wiki to be fixed by Fandom were ever taken care of, but in case it wasn't, a reminder lol. I also don't know if this is a new bug, because I definitely hadn't noticed before, and IDK if it has to do with different device and different browser. On PC using Chrome, just now, when previewing, all the File namespace links would not get me to where it should get me, but the very same links worked fine after actual publication. It's inconvenient because I'd like to check things before publishing, and would not be able to do so when using the same tab. Not sure if this is a thing for Mac and Safari (which is what I usually use and I hadn't noticed this problem; then again, I'm on hiatus lol). --Sammm✦✧(talk) 02:17, 6 September 2022 (UTC)

There is a lot of stuff on there as well, undoubtedly things have have been fixed by now and others that haven't, so is there anything in particular you are still experiencing that's bugging you that I can look into?

Just as a general statement for transparency, I said it in a conversation with Ironyak before, but while we perfectly well understand how bugs are annoying and sometimes even a real hindrance (as an admin and editor myself, I really do feel this pain and irritation), as a company with lots of projects going on, priorities need to be set, and I hope that community members can also somewhat understand that, aggravating as it may be. So what happens is that we (now more referring to Wiki Reps, the CMs, and Fandom Support Staff) continue to gather these reports and complaints from communities and continue to pile up the reports on the existing tickets and create new ones where necessary and build a case to justify giving priority to a specific issue over working on something else. This is why it is so important for us that people just let us know what's broken or missing somewhere. While we may not be able to fix it in that instance, we do document it and build a case for having that site-wide fix. That said, it can also be that we know of a workaround in the meantime -- which is obviously not a substitute for an actual fix site-wide, but it's better than nothing.

As for the reported issue: what are your specific preview settings in your user preference? Cause I tried navigating to file likes using the 2010 editor with the setting that the preview appears in front of the page without reloading on Chrome on desktop, and I can navigate to any file I want to. Do you have a specific page in mind and can ideally even give instructions on how to reproduce the experience you're having? Thanks! Lady Lostris /  SOAP 08:42, 6 September 2022 (UTC)

When I'm on https://harrypotter.fandom.com/wiki/Forum:Proposal_to_change_the_background_picture?action=edit previewing, clicking File:Hogwarts Legacy.png for example, gets me to Hogwarts Legacy instead. Clicking file:wiki-background via preview at least gives https://harrypotter.fandom.com/wiki/Main_Page?file=Wiki-background but it's still not what it's supposed to do. Even as I preview what I'm writing here, it gives me the same thing. My preference is set to VisualEditor - source mode with the first and last box checked. --Sammm✦✧(talk) 08:58, 6 September 2022 (UTC)

Interesting. On first glance I get the feeling that the preview is mimicking the behavior for anonymous users. Either way, this doesn't seem to be the expected behavior for a logged in user. I'll see if this is a known issue and if not, file a ticket about it. If you wish to not having this experience in the meantime, the 2010 editor does not have this issue, as it does lead you to the actual file pages as you would expect it to do (though when you preview a page without having made any changes and if you then click an image link, you will immediately go to that image page rather than have it open in a separate tab like the 2017 editor does. You can remedy this by clicking with the scroll mouse or doing ctrl+click the link). Anyway, thank you for flagging this! Lady Lostris /  SOAP 09:18, 6 September 2022 (UTC)

Hey there, so it very may well be a PC/Chrome thing? At home Using Mac/Safari does not produce the same problem! Unless it got fixed somehow lol. The PC/Chrome I have access to will have to wait till tomorrow. It is odd though, I wonder if other Users who use this particular device and browser have encountered it. --Sammm✦✧(talk) 14:02, 6 September 2022 (UTC)

That's currently my working theory based on what you told me. I put out a request for someone with Mac/Safari to test it as well to compare results, so the ticket can be as precise as possible. Lady Lostris /  SOAP 15:27, 6 September 2022 (UTC)

I'm on Chrome, and curiously, left click leads to the behaviour for anonymous users, and so does right click and open in a new tab, but middle click works fine. MalchonC (talk) 16:25, 6 September 2022 (UTC)

I've added all this to the ticket, thank you for the additional details! Lady Lostris /  SOAP 16:30, 6 September 2022 (UTC)

I'm now on PC/Chrome and I tried out what MalchonC said, and got the same result! I never thought of using the middle(scrolling) click, but that one does work indeed! That said, I'm not sure all mouse have the middle one, so it's probably still a good idea to check what's going on for Chrome, or PC/Chrome. (I haven't tried Mac/Chrome so not sure if it's an issue.)

Would like to comment on the "anonymous-users-can't-view-file-namespace" thing, but this is probably not the place. Let me know if it can be raised elsewhere. In short, our {{See image}} would not be very ideal for anons, since they'd be first directed to a page where the image is hopefully used, and view it via the popup frame. Not so sure why the entire namespace had to be inaccessible to them, since it hadn't always been this way. --Sammm✦✧(talk) 05:49, 7 September 2022 (UTC)

In response to "so is there anything in particular you are still experiencing that's bugging you that I can look into?", before I forget, so the missing TOC during preview is still a thing, kind of really disappointed lol. Really hope someone is working on this.

Other stuff that's not editor issue but from the thread and originated due to UCP: Category namespace for files also did not seem to have improved. I thought at one point it was fixed, but it's still either no file name, or with file name but with tiny thumbnails that we basically had to click on each to really know what those images are, honestly not really efficient. --Sammm✦✧(talk) 08:44, 7 September 2022 (UTC)

@Sammm, my talk page is always open to anyone for anything, so general feedback about whatever may always just be posted there. The decision regarding the file pages for anonymous users was announced with more detail here, which may provide you with some of the info you're looking for.

Re missing TOC in 2017 editor preview: I will dig for that ticket and see if I can get an update of any kind on it -- but as the response to editor issues tends to be: the 2010 editor does not have this preview issue in case you want to switch in the meantime.

Re category display for files: it was recently requested to restore the default MediaWiki behavior on classic category media view, which is more or less what you're referring to, so I added your note about it to the ticket. Lady Lostris /  SOAP 15:03, 7 September 2022 (UTC)

Lostris, I just noticed that the little SOAP logo in your signature also doesn't show up in previews, it just displays the url instead, even though the logo shows normally after publishing. Is this a bug? -  MrSiriusBlack  Talk  19:40, 7 September 2022 (UTC)

Yeah, seems to be an other 2017 editor preview fail. I added that to the general "issues with 2017 editor preview" ticket. As mentioned often by now, the 2010 editor doesn't have this issue. I'll say that Fandom is aware of these issues, and we're looking into whether it continues to make sense to have two separately maintained source editors or if we should be looking int retiring one of them. This is something about which no final decisions have been made whatsoever, it's just a call that lives internally and needs to be properly investigated. Lady Lostris /  SOAP 13:01, 8 September 2022 (UTC)

Just an FYI, the reference issue in the preview is set to be tackled somewhere between October 4 and 17. This is an estimate, as unforeseen situations may always cause priorities to shift and dates to change. Lady Lostris /  SOAP 16:57, 27 September 2022 (UTC)

So I have just noticed that if the file link in an infobox's 'image' parameter is coded as simply 'Filename.suffix' rather than '[[File:Filename.suffix|widthpx]]' AND there is an <!--editorial note--> present right after the file link (for instance on Draco Malfoy), the infobox image will not render on 2017 editor preview, despite displaying as normal on publish. An odd one. Yes, a simple fix is to just add the [[File:|widthpx]] to the file link, but as the file displays normally on publish with or without adding that, the preview should behave the same, no? -  MrSiriusBlack  Talk  00:19, 3 October 2022 (UTC)

Odd one indeed, but I am going to just chalk this up to being more "2017 editor preview shanannigans", as the issue isn't present on the 2010 editor preview, nor the 2017 when you indeed remove the editorial. I did update the relevant ticket with your finding. Lady Lostris /  SOAP 15:25, 4 October 2022 (UTC)

Templates not rendering correctly on Mobile/App

Multiple local templates (e.g. {{IMDb name}}, {{Wikilink}}) fail to render their text on the Mobile/App version of the articles (see 11 January for an example of both). This has been happening since at least Oct 2021 when it was reported. Is FANDOM supporting their mobile/app interfaces after the UCP upgrade? Thanks --Ironyak1 (talk) 20:23, 4 September 2022 (UTC)

Fandom is supporting their mobile interface very much (cfr the announcement about the incoming mobile editing fixes and theme designer. Work on this has started and user testing on selected wikis will happen toon, more to come in general soon, and I'll alert this community per usual when that happens).

The issue with these templates not properly showing up lies with the chosen template type though, as not every template type shows up on mobile -- this is by design, as not everything renders well on mobile or should render on mobile as to not cramp the limited space available. With the two examples you gave, if you were to change the template type from "infoicon" to like "design" for example, the template will show up. (For full transparency, there is a known bug that with new templates, the template type doesn't save on first instance despite being asked about this.) Lady Lostris /  SOAP 15:10, 5 September 2022 (UTC)

Yeah, I had seen that announcement back in June as well - the acknowledgement that "the community has asked for years" for some of these changes was refreshing. Guess we will wait to see what might be possibly accomplished in the future.

However, in the present, that change to the Template Type did allow those templates to fully render in the mobile interface, so thanks! Guessing these have been broken on mobile for several years, when the implications of the assigned Template Types wasn't fully detailed on Help:Template types. Probably others that are misclassified as well so something to look into. Thanks --Ironyak1 (talk) 17:59, 6 September 2022 (UTC)

Is there a way to view Templates by Template Types (list of all infoicons regardless of template Category for instance)? Or a way to see the history of Template Type changes on a Template to see who assigned these, when, and any possible edit summaries as to why? Thanks --Ironyak1 (talk) 05:04, 7 September 2022 (UTC)

Sadly, no to all of that. The "easiest", but still not easy due to the sheer amount of templates, would probably be to pull up a list of all the templates and start there if you want to go through them all. Lady Lostris /  SOAP 15:03, 7 September 2022 (UTC)

Actually, there is a way to see the history of Template Type changes - Special:Log?type=templateclassification. -  MrSiriusBlack  Talk  17:47, 7 September 2022 (UTC)

Thanks! At least this provides some context for whom to contact with possible questions. However, there seems to be some glitches or gaps as if you look at the log for {{IMDb}} here there is only Sammm鯊's original type assignment to Infoicon, and not the change I made yesterday to update its type to Data to fix the mobile display issue (which you can see it has now). Delay in log creation? Unlogged changes are possible? Who knows... no really, who knows? --Ironyak1 (talk) 18:25, 7 September 2022 (UTC)

Noticed another example of templates not rendering correctly on Mobile/App today, though this is specifically referring to when looking at a page via ?useskin=fandomdesktop on browser on mobile - when doing this, infobox themes don't show up at all, and also some templates' tweaks that allow them to be readable in dark mode also aren't working - see this image. -  MrSiriusBlack  Talk  19:40, 7 September 2022 (UTC)

@Sirius: Oh, it's a part of the general logs? Ha, things you learn, thanks for sharing that! I was thinking in that there used to be an actual proper way to do that, but that was something that did get lost in UCP, and no one seemed to realize that the general log is apparently an option for that.

Cfr that screenshot: I can't reproduce what you see though. As a general remark about mobile theming, and then I'm referring to the actual mobile theme, so using the mobile view rather than desktop view on mobile, there is no wiki specific mobile theming and css/js doesn't work on mobile (which is generally known already). I do specifically say "at this moment", cause we are literally ramping up to start a mobile theming test project next week where a handful of wikis will get early access to the feature to test it out and actively give feedback on it so it can be better developed before it goes live to all communities. Naturally when that happens, I'll announce this on this community as well for the admins to test it out and theme the mobile design of the HP wiki. So stay tuned for that!

@Ironyak, seems to be a delay in log then, as your change does show up now. Lady Lostris /  SOAP 13:01, 8 September 2022 (UTC)

Um, nope, my change to the template type for {{IMDb}} is still not in the logs for me, although my changes to some of the others such as {{IMDb name}} are. Seems to be a gap in the logging (for reasons unknown?) - can add it to the bug list should anyone be interested. --Ironyak1 (talk) 17:41, 8 September 2022 (UTC)

Apologies, I misread and thought you were talking about the IMDb name template. I just now tested it out for the IMDb template and my edits showed up immediately in the log, so yours now showing up may just have been a fluke or something then. Lady Lostris /  SOAP 11:55, 9 September 2022 (UTC)

Back to Templates not rendering correctly on Mobile. Happened to look at Holly Blackbird on mobile and the top {{Dialogue a-b}} template only renders the source and explanation text and none of the actual dialogue text. Template type is Quote so it shows up, but just missing all the actual dialogue.

This affects ~700 pages so probably worth sorting out. For those interested, adding or removing "?useskin=fandommobile" to the url, or alternating "?mobileaction=toggle_view_mobile" and "?mobileaction=toggle_view_desktop" (what the link at the VERY bottom of the page does), will allow you to see the page in mobile view, as this option is no longer in Preferences - Appearances - Layout, so you can quickly toggle back and forth between Desktop and Mobile. Cheers --Ironyak1 (talk) 18:17, 27 September 2022 (UTC)

This is something I've noticed for a long long time, and not just on this wiki. Take a look at this on ?useskin=fandommobile. The top- and bottom-most of the quotes under the infobox display the quote and attribution the wrong way round, despite displaying normally on desktop view. -  MrSiriusBlack  Talk  18:26, 27 September 2022 (UTC)

Thanks for the extra context! I very rarely use the mobile interface so don't have a good history on how well or poorly it has functioned compared to now, but figured it's worth trying to highlight these issues now as Mobile stuff is part of the FANDOM developer roadmap for the next few months. Hopefully there are some tweaks that can be applied. Cheers --Ironyak1 (talk) 18:34, 27 September 2022 (UTC)

This is sadly a very old and often reported thing. An earlier ticket about the same issue was closed due to not having found a solution that would allow us to fix the problem without further complicating our mobile quotes logic. There was a suggestion to run a test involving SEO and switching off the markup modifications for quotes on mobile, which would then potentially be an option if it didn't impact SEO in a negative way, though afaik, that test didn't take place -- I have raised that suggestion internally again though.

Until the test happened, the only way to avoid problems with these non-standard quotes will be to consider changing the modified quote templates back to the default one.

Just a general note, it's better to use ?useskin=fandommobile or &useskin=fandommobile (in case the url already contains a ?) if you want to see something on mobile on desktop, as using mobileaction= will change your setting in general, which can be annoying to get rid of as it requires a cookie cleanse. Lady Lostris /  SOAP 13:03, 28 September 2022 (UTC)

Unfortunately the single quote template doesn't fit the need of capturing a back and forth dialogue, which is why these other dialogue templates were created. It seems best to make a "Not safe for Mobile" template category that can be added to templates as they are identified and change their Template Type to make sure they don't display in Mobile until a fix is sorted out. Thanks --Ironyak1 (talk) 17:59, 28 September 2022 (UTC)

Oh I'm aware it's not, I had already put what you said in my commentary on the ticket as to why a fix other than "change to the regular template" is needed, as that just doesn't meet the needs of our communities. I've raised this again to see if this ticket can get more attention, but the options for now are indeed to change the template type, which will normally strip the template from its mobile theming and thus potentially make it less clear that said block of text is a quote; to make the effort to switch from using the dialogue template to using the single quote template and use html elements to preserve the dialogue; or to ignore and wait it out. To be continued. Lady Lostris /  SOAP 15:25, 4 October 2022 (UTC)

Template Type changes not always captured in Logs

So the logs missing template type changes are not a fluke, or at least not a one time fluke. Changed template type for {{Dialogue a-b-a-b-a-b-a-b-a-b-a-b-a}} to Quote and it appears in the logs. Change TemplateType for {{GrindelwaldRandomQuote}} from Unclassified to Quote, and the change is not logged. Something is amiss - should this be reported as a new bug or is it a known issue? Thanks --Ironyak1 (talk) 18:53, 26 September 2022 (UTC)

I filed a ticket for this in which I made note of the missing logs you found on September 6 and September 26. If you find more, I'll update the ticket accordingly. Lady Lostris /  SOAP 16:57, 27 September 2022 (UTC)

Link suggestion often not working correctly

Wanted to check with others how well the link suggestion is working for them (when you type "[[" or "{{" and a list of suggested articles or templates appears to choose from). For me, this list is often misplaced from where I am typing (appearing farther down the page and largely obscured) or if one starts a link, gets the list, but then deletes the link started, a grey bar is left over the text (see this). Other times the look ahead list just fails to appear for reasons unknown.

Are others still seeing similar or related issues to this key feature after the change to UCP? Thanks --Ironyak1 (talk) 18:11, 6 September 2022 (UTC)

Yes, I have the same problem. The list doesn't appear when I type a link, so I have to scroll up and down to get it to appear on my screen. It's never in the right place, it's always higher or lower than where I'm typing. Hopefully it can be fixed. - Kates39 (talk) 11:32, 7 September 2022 (UTC)

There are some recent open tickets about link suggest being unreliable. May I ask which browser and editor you're both using (as those are both relevant elements affecting the link suggest, since not everyone is seeing the issue or the same issue depending on that). Depending on your answers, I can add to the relevant ticket. And not that it makes a difference as the user experience is not how it should be, but this has nothing to do with UCP, but it was rather triggered by the latest MediaWiki update to 1.37. Lady Lostris /  SOAP 15:03, 7 September 2022 (UTC)

I use the source editor on Google Chrome. - Kates39 (talk) 15:48, 7 September 2022 (UTC)

I also tend to use Chrome, but for giggles tried it in Firefox v104 and instantly ran into same issues where the list is disconnected from where the cursor is and leaves an obscuring box if you backspace out of making the link (see these). This is when using the Source editor w/ 2010 workaround enabled, which seems to be the suggested option? To be clear, the UCP "upgrade" removed the suggested link feature entirely, and only after strong pushback returned it, but with all the links being truncated, or with it only sometimes working, and now with it being dislocated or a unremovable blank list obscuring the text. ~2 years on and UCP still hasn't recovered even the reliable baseline feature-set from the previous source editor. --Ironyak1 (talk) 18:10, 7 September 2022 (UTC)

I already added your notes to the open ticket, but I'll update it with the browser specifics and the screenshots, so thank you for providing these additional details.

Just to give some backstory tot UCP, which I'm sure Ursuul explained at the moment it occurred as well, UCP is called an upgrade cause it meant we made a giant coding update from MediaWiki 1.19 and all the custom hacks Fandom needed to make to keep things running to MediaWiki 1.33, even though for many the user experience seemed to have decreased, thus finding it to be a downgrade instead. In any case, since that code jump wasn't even possible to outright do that due to all the modifications, a new platform running on the MW 1.33 version needed to be built and then wikis were migrated to that. That's what UCP basically was/is. The link suggest was always considered to be a key feature from the start, so it's not something that just got added back because communities asked for it, it was flagged way before community testing even became a thing. One of the many issues from a wiki community point of view is that this massive project felt like it was pushed out too soon, given all the obvious (and less obvious) bugs it brought with it -- the link suggest still being wonky being part of it, as well as the breaking of several community's coding, as they were all styled for the MW 1.19 hack rather than the MW 1.33 version, where some features had been removed or renamed by the Foundation itself, and some of the old Fandom hacks simply couldn't or wouldn't be transferred. The reason why this migration was pushed out when it was, even when we knew some of the troubles it would cause, was simply because we had to due to a warning the company received from Google. To grossly oversimplify the situation, Google said that the structure was such a mess that if nothing would be done, all Fandom wikis would be penalized in the search results, which would basically mean that no wiki would show up in a proper ranking when anyone searched for something related to the topic. Considering that the vast majority of the traffic comes from Google searches, this needed to be dealt with, and this was basically the only way to do it. The company is very much aware that the transition wasn't smooth and without faults, but at the same time it also simply was inevitable as continuing with the old version was impossible. Lady Lostris /  SOAP 13:01, 8 September 2022 (UTC)

Well, we intentionally moved ourselves to the back of the UCP upgrade process and even then link suggestion was MIA and it was communicated to us that other communities had previously made it clear how essential it was, yet still there was nothing, and still now there are issues. I would have thought that a feature that was apparently flagged as key by FANDOM before the UCP change, and almost universally requested by communities would have some priority for development & support?

The note about Google pressuring for the Mediawiki upgrade is interesting - given its apparent motivating importance, it's strange that it wasn't mentioned in any of the UCP blogs (unless I missed something) even from the very beginning of the process in June 2019 (oh, look at all the sweet summer children - MisterWoodhouse: "Our motivation is providing a better editor experience. You're right that talk is cheap. Judge us on what we do.", "Feature Derelict" being highlighted by out former Wiki Rep Ursuul (wonder whatever happened to them...), even SuperSajuuk makes an appearance noting his multi-year break from his wiki commitments to "growing a community" apparently - such simpler times ;)

Anywho, causes and history aside, please let us know if there is an ETA for when the link suggestion is to be fixed and working properly again. Thanks --Ironyak1 (talk) 18:41, 8 September 2022 (UTC)

I don't control the general communication, so I don't know what to tell you for why it wasn't announced at large, though the absence of that bit of information doesn't invalidate the other reasons either, as you seem to imply by using the phrase "sweet summer children". I am here to be as open and transparent with you all as I can be, but I can't say that I appreciate such dismissive replies and word choices. As I've mentioned on our talk page conversation before, while it may not be your intention to come across a certain way, you very much are by using such deliberate word choices, and I don't think they're really productive for the further course and purpose of this forum.

I'll naturally keep you all posted on progress regarding the link suggest. Lady Lostris /  SOAP 11:55, 9 September 2022 (UTC)

And I just noticed that the priority of this ticket was raised upon my request, so hopefully it'll see a fix within the month. Lady Lostris /  SOAP 12:24, 9 September 2022 (UTC)

In case you're not familiar, "sweet summer child" is used to to describe "someone who is naive, or who has never experienced hardship." Given that 3+ years on, this thread is largely comprised of problems created from the stated "motivation" for UCP "is providing a better editor experience", as well as the fate for some of the individuals mentioned, the phrase is not dismissive at all, but seems entirely apropos. Sorry if you find it unproductive to highlight these ongoing issues or the disconnect between communication and outcomes, but this is where FANDOM has led us all. Hopefully documenting these problems might lead to them being fixed in the near term, or possibly even avoiding being created in the future, but only yet more time will tell. As FANDOM's former Global Communications Lead MisterWoodhouse put it, "talk is cheap", or to continue the GOT phrasing, "words are wind" - I'm sure we all look forward to these issues finally being resolved. Thanks --Ironyak1 (talk) 18:01, 12 September 2022 (UTC)

Correction, I find highlighting these ongoing issues very productive, as I've clearly indicated by my activity on this forum and efforts to give you all answers and get things fixed. As was quite clear from my previous comment, my comment about what I didn't find productive was entirely related to your general dismissive attitude and choice of words -- again, whether that's intended or accidental, I'll leave in the middle for argument's sake -- as regardless of whether you find the phrase appropriate to use here, it still remains a phrase that has a negative connotation of looking down on people, cause "they simply don't know any better". Ergo, not productive. Not sure why you felt the need to attempt to explain something to me that I clearly already understood, but thank you for the effort I guess. Also, while UCP has its own set of bugs and issues, seemingly presenting the entire endeavor as some dark place where "Fandom has led us all" is also incorrect and seemingly projecting your own negativity on the matter, as things had to change and it's not like no progress was made and nothing got fixed. The previous platform wasn't perfect either, and bugs will always exist everything with anything -- not just on Fandom. Perfection simply doesn't exist, so there really is no need to be constantly lament about the experience with this passive-aggressive jabs, as that's not productive (to be clear, this is again a remark about the wording used, not the bug reports and feedback, as that's very much welcomed). Fandom is still clearly also actively working on things as well as providing workarounds, again as evidenced by my own involvement and answers here. Lady Lostris /  SOAP 16:05, 13 September 2022 (UTC)

You feel my phrasing is overly dismissive, I think it is aptly descriptive - cool cool, everyone has an opinion. You also say I am "seemingly projecting your own negativity on the matter" - I would say 3+ years on, having donated hundreds of hours in beta testing, being left with an editor that can no longer reliably scroll text or preview an edit without various workarounds to be a step backward and a negative outcome, but maybe I am just missing something. What are the objectively positive improvements to the editor, which was a stated motivation for the UCP project? Thanks --Ironyak1 (talk) 17:56, 14 September 2022 (UTC)

It's not so much an opinion as a fact that using "sweet summer child(ren)" is dismissive, that's just the nature of the phrase. In case you didn't know, it's only really used in the context you used it in to be dismissive about someone else, writing them off as naive and thus devaluing their opinion, which is in general an unnecessary unproductive attitude to have in a forum like this where we're trying to work together productively. I want to say though that just using the site isn't really "having donated hundreds of hours in beta testing", that's just "being a regular editor" and something we're all doing.

The 2010 editor, which you continuously write off as a "workaround", is a solid editor -- I'm just referring to that one, since my experiences are largely limited to that one as I only use the 2017 to test bug reports. It's been widely said that that is the stable one and has long since been more than a workaround. So if you find the 2017 editor not to your liking, then just use the 2010 one. Yes, it has a minor scroll problem when at the bottom of the page, but clicking 1 easily accessible button to disable syntax highlighting while editing in that spot and then clicking it again to turn it back on when you're done is hardly the greatest inconvenience. The preview works stable as well with the understanding that you have a wide width preview -- which you can correct with coding if that's really a bother. So those are hardly elements to write it all off as a bad editor. The pre-UCP editor also had its bugs, let's not forget that either. Since you asked, some of the positive improvements: this editor offers a faster loading time, a very easy and helpful "find and replace" tool, is easy to bulk upload images by dragging them into the editor, and has those code lines in the front which come in handy when reading long source code.

In any case, you're welcome to have your own opinion on the editor indeed, but there is just no productive or actionable point in continuing to fixate on minor inconveniences and praise a previous editor that also had its own bugs. It's a feature on the internet with software that's constantly updating. Bugs are inevitable, that's just part of internet life. To be clear, I am not uncomfortable discussing this, there is just no productive point in doing so. I'm happy to continue to listen to actual bug reports and actionable feedback though, as that's something I and the company can do something with. Lady Lostris /  SOAP 07:45, 15 September 2022 (UTC)

@Lady Lostris - pretty bold to believe your, and your alone, textual interpretation is fact. Citing the proven disconnect between initial beliefs and ultimate outcomes as a sign of naïveté isn't dismissive of the original idealism or optimism, just that it wasn't born out in the results. No doubt as the ultimate arbiter and moderator of discourse you'll disagree, but what's new - you do you. :)

If having to go into preferences to switch to the 2010 editor, and then turn off Syntax highlighting for the basics of the editor to work correctly, aren't workarounds, I'm not sure what are, as these settings sure aren't the default. You said above that FANDOM was "providing workarounds", which seems to apply here, but perhaps you were referring to other workarounds needed? Is there a list of these necessary workarounds available somewhere? As an aside, I've done large-cap organization-wide software rollouts for my bread and butter so this isn't my first rodeo and I know how things can be done better if the focus is actually on at least maintaining, if not improving, the end-user experience.

It's that experience that motivated myself to help coordinate several others in volunteering our time in testing, reporting, and tracking UCP bugs before and after its deployment. Having all this donated effort, in edition to routine editing and community support, dismissed by a paid FANDOM rep as "just "being a regular editor and something we're all doing" is pretty crass but appears increasingly to be par for the course. I've asked repeatedly if there was any attempt at a hand-off or knowledge dump during the change in wiki reps, but have never gotten a clear response, although this discourse here seems evidence enough of its absence. Even when given multiple links to this context, it appears that there is no interest in understanding the actual history of events for this wiki, but rather just a narrative pushed that FANDOM has always had to make the changes unasked for by their communities, it's all been for the best, those things that aren't working may be fixed in the future if enough people complain, but there really is no reason to complain as bugs are always to be expected.

So cool cool, where's that leave us - if the lesson wasn't learned when many communities pushed back on Monoco v Oasis, or Forums v Discussions, or Featured Video, or UCP, or a dozen other unasked-for and yet-dictated changes, it's unlikely to be understood now; FANDOM is going to FANDOM. Carry on --Ironyak1 (talk) 18:55, 15 September 2022 (UTC)

I'm happy to report that the link suggestion is now working perfectly for me so it appears to have been fixed. Thank you Lostris, you've been great at helping and facilitating our reports. The upgrade to UCP has been a trial and error process but it is something I've gotten used to and it is always improving. I'm grateful to know that our reports are getting ticketed and a solution provided. I understand the frustrations people have with UCP, for which I've had my own concerns, but I feel that Fandom/you have been very responsive and active recently at fixing things. - Kates39 (talk) 12:51, 15 September 2022 (UTC)

@Kate: I'm happy to hear that! Full disclosure though, the ticket about this is still open, but the issue seems sporadic by nature. So it's very possible that you'll encounter it still at some point. And thank you, as said from the start, I'm very happy to try my best to help this community advance in any way possible, so I'm glad I was able to facilitate some of this haha. Lady Lostris /  SOAP 15:30, 15 September 2022 (UTC)

Okay thank you for letting me know. It's still working right now which is the first time since the upgrade so at least something is happening! Hopefully it will stay like this. - Kates39 (talk) 17:00, 15 September 2022 (UTC)

@Ironyak: And once again it seems like I cannot be giving the benefit of the doubt or even an assumption of good faith from you. Not that I should've done this or even need to tell you this, but after your strong counterreaction I actually asked for second opinions from native English speakers on the matter, cause here I went "you know, maybe I, a native Dutch speaker, am indeed missing the nuance of this idiom." I asked them how they interpret that idiom, how they perceive it when used against them, rather than asking "is this correct", as to not influence their answer, but they all told me, separate from each other, that it's used in a way to look down on people. But you really may use this idiom in however way you deem fit, just be aware then that it may not come across in they way you're intending it, and may thus cause friction in your conversation.

I will say this though, since my previous requests and even openings to give you the benefit of the doubt in how you meant things and chosen your words, I will now flat out say that using language as "ultimate arbiter and moderator of discourse" to clearly dismiss whatever I'm saying is just very unbecoming of anyone trying to have a productive and respectful conversation. Even if it still wasn't intended that way, then I have already clearly indicated that your way of communicating is not coming across in the way you're intending it to, and per common language rules, it's on the speaker to make sure that they're understood properly in the way that they want to be understood. I'm quite unclear why you think it's appropriate to have such an attitude with me, but as I've told you multiple times before, if you have some kind of issue with me and/or Fandom, you're free to then come talk to me on my wall or even Discord if you wish more privacy and air your grievances, but this passive-agressive towards me really needs to stop, especially on this forum where we're all trying to continue productively. Thank you.

In any case, to continue to giving you answers, I could ask how having to go into preferences to switch to the 2010 editor is any more a "workaround" than using the 2017 editor as the default editor for everyone is the VE editor. But at this point this has devolved into an unproductive conversation about semantics, "workaround vs alternative", so I'll move on from this. I'll also conclude "agree to disagree" on the severity of a bug that's only happening when at the bottom of a page, which can be prevented by clicking on button, and just reiterate that the feedback was heard, and the issue flagged for a priority fix.

There is no list of workarounds available, though I guess you can maybe count the js scripts and css sheets available on the Dev Wiki as such. If there is a specific workaround you're looking for for yourself though, as per the idea of this forum, please voice it and I'll be happy to see what I can do about it.

Ah, our miscommunication seems to stem from a disparity in what constitutes as "beta testing". While there is no standard for what a beta test should look like and how it's set up, the common denominator in definitions is that it's about having a sampling of the intended audience try out the product, which is thus not what the UCP rollout was and why I don't see using the site as an editor on UCP as "beta testing". In return, whatever your definition of beta testing is, does seem to have caused you to sadly interpret my words negatively, or as "crass" even, and not at all as how they were intended. I'll emphasize for clarity's sake then that considering that I work constantly with multiple communities in the manner you described to coordinate receiving feedback and bug reports and fixing things -- as a Wiki Rep, naturally, but that I also did that as a volunteer admin on my own home community -- I naturally welcome those actions, so I'm unclear how, even with the different definitions, you could come to your conclusion about my intentions. So for what it's worth, I'm happy and pleased to learn that you did that as well. It's a great help.

If you asked me those questions about the hand-off between Wiki Reps repeatedly, would you mind pointing me to where I made this oversight as I'd love to reread that conversation to get the full context and give you a proper answer then. But in short, I can already say that part of the job description is to note down relevant things about communities as well as keep your manager informed, which is then information that's passed on to the next person. I'm again unclear how you conclude that I'm not interested in understanding the actual history of events for this wiki, cause I've asked you during our first conversation on Discord, and you flat out refused to tell me, dismissing my question by saying that I just needed to look into what happened to the Wiki Rep before me, so that was hardly something helpful to me. You now say that I was "given multiple links to this context", which is new information to me, so please share those links again, as well as point out the first instance where these were shared and thus missed them, so I can see how this oversight happened and try to prevent it from occurring again. When I get the links again, I'll be happy to do my part to get up to speed with the history of this wiki.

Are there any particular changes you are referring to when saying "rather just a narrative pushed that FANDOM has always had to make the changes unasked for by their communities"? As evidenced by previous answers to this forum, whenever possible and appropriate, I will give you more insight on why a certain change was made. To already answer some of the things you noted already though:

• "Monoco v Oasis": The Oasis Wars were before both our time really, as I came to Fandom in 2011, and unless you had another account before, you started in 2015, when those "Oasis Wars" were in 2010. So I don't really see why this is something to bring up, but in any case, you'll be happy to know then that there are internal documents with feedback from the Oasis launch. In general, the feedback seemed to be around 1) a lack of real understanding why it was all needed (which we tried to remedy by the increased amount of blog posts, Wiki Rep outreach, and the availability of the general Discord where staff and the larger community is available for questions and support. While we did better this time, there is still room for improvement.) and 2) a lack of support to deal with these changes, feeling like it was all the responsibility of the volunteers to fix it (which was remedied by the Wiki Reps being there to assist communities directly, blogs highlighting new releases and changes, there again being the Discord where people could turn to with questions, the bug fixes weeks -- which I truly do hope will return --, and even the phased rollout). And lessons from UCP were taken with us to the rollout of UCX. So while there will always be room for improvement, cause nothing is ever perfect, lessons were learned. As for the general "nobody asked for this", that's also never true, cause there were also people who welcomed UCP and applauded its change in design. You'll always have both sides based on preferences. It's also just the way of the internet that you do need to evolve along with it, as you cannot get away with a 2010 design in a 2022 internet setting, but I'm sure you know that already per your above indicated experience with rollouts. Though if you have more concrete, constructive and actionable feedback to give that we can take with us to the next MW upgrade (cause I will already say that that is coming), then I'd love to hear it, so way may do better for you all next time!
• "Forums v Discussions": This is another double one, cause it all depends on whom you believe your target audience here is and what the forums were used for. To look at this story completely, you also need to remember that Special:Forum, the one that was deprecated, was actually the replacement for Wiki Style Forums, such as this one. While I definitely will not argue the loss of wiki text as a blow for those who used those forums as a true wiki feature rather than a social platform, those who used it for wiki features generally went back to using forums like this -- as was also advertised as being a valable alternative for which help was provided to set it up for anyone asking for it. The short party line for Discussions is that it offered a better accessibility through the app for those social mobile users, which it does and is something lots of people welcomed, though those more rooted in wiki text disliked. And then we have the obvious with the lack of moderation tools though, but with the beta testing of the discussion abusefilter going on, that's a first step to working on that, and more is to come this year.
• "Featured Videos": That was indeed a mistake that was also owned up to and clear lessons were drawn, as evidenced with the new Interactive Videos where the entire process is about community involvement in getting those made.
• "UCP": see my above answer about it, and the blogs about also it being an absolute code necessity to be able to remain up to date with MediaWiki updates (the latter is something that's frequently asked for though, as there are often requests to enable certain MediaWiki native features that we never could before due to the convoluted code that was the old platform).

As for "Fandom is going to Fandom" and sharing that offhanded link to some anonymous review, I don't know what it is you want to achieve here, as you seem to share it out of a belief that it were some nefarious and hidden statements on Fandom's part rather than things that were well advertised to anyone taking this job. Not that I have to comment on this, but in the spirit of continuing to be transparent, I'll give you my firsthand knowledge as a Wiki Rep, I'll give you my first-hand experience about this:

• It was clearly advertised from the start that this job is a contractor role -- if someone took it without properly knowing what that entails, i.e. the no benefits, no PTO, and not being an employee, then I feel like that's on them and not the company (working with contractors is also not uncommon in many industries).
• Same with the hourly rate, it was clearly said from the start what the hourly rate was an how many hours you'd be allowed to bill, so that was another clear "this is the offer, take it or leave it." If this Wiki Rep took the job with the idea "oh, I'll take it, but I want this to change", then I again feel this is not on Fandom, as that's just how business works, and they would've had that same issue literally anywhere else.
• It was and is also literally and repeatedly said that people shouldn't hold out for a fulltime job here (as in, not look elsewhere when they feel like they want more), as there are no guarantees -- it all depends on being in the right place, right time with job openings (as is the case everywhere as everyone looking for a job can tell you). It has happened before (I know off at least 4 contractors who became fulltime staff, and of at least 3 users who became hired as staff), and we're all always allowed to apply to open job positions, though that naturally comes without guarantees and is dependent on being the best candidate who applies.
• As for the raises, they happened, so.
• The being maxed on hours during that time is true, and the request for overtime was made multiple times. I have my personal opinions about that as well, but it also needs to be said that it was also said that when you reached your hours, that was that. We weren't forced to do overtime. There are those who did so voluntarily and those who didn't, but that was our choice.
• Fandom not encouraging open communication about the reasons of someone's departure is actually just Fandom complying with the law and not divulging someone's personal details. Don't know what this particular Wiki Rep wanted to know, but whatever it was, it never was anyone's business.

I hope this does satisfy some of your to this forum off-topic questions, I agree to indeed carry on, but hopefully again with only relevant and productive things. Lady Lostris /  SOAP 11:05, 16 September 2022 (UTC)

As this conversation has become more generally about FANDOM's broader practices, I've posted my reply here for those who may wish to provide feedback on their related experiences. Cheers --Ironyak1 (talk) 20:52, 18 September 2022 (UTC)

For transparency, I will already say that the focus for a fix for this ticket will in first instance be the 2010 editor. Lady Lostris /  SOAP 16:57, 27 September 2022 (UTC)

So this problem is back again. Seems to happen when starting to create a link and then moving off of the link to look at something, the small grey bar of an empty suggestion list is left floating over the text. Not sure if fixing it again is tied in with the upcoming Mediawiki upgrade but wanted to bring attention to it. Thanks --Ironyak1 (talk) 06:43, 15 March 2023 (UTC)

I've filed a new ticket for this, linking back to the old one. Thanks for flagging this again! Lady Lostris /  SOAP 10:14, 15 March 2023 (UTC)

Large white spaces before Table of Contents

While using Firefox for the Link suggestion test above, I noticed that some articles like Newton Scamander and Jacob Kowalski display large amounts of white text before their TOC, likely caused by its width running into the Infobox. I usually don't see this as I keep the right-rail collapsed, but anonymous users don't have that option so it affects them, and any logged-in users with the right-rail displayed. Happens on both Firefox and Chrome (see these) and likely affects hundreds of articles given the common combination of large TOCs and Infoboxes and that I simply spot-checked a few of the main characters prominently linked from the main page. Thanks --Ironyak1 (talk) 18:42, 7 September 2022 (UTC)

That isn't really something related to the right rail as much as it is about your screen width. You can easily reproduce this when you view any page that has a long infobox and a TOC that stands next to the infobox on the page and you start to reduce the width of your browser. There are always certain moments where the content starts to collapse into itself and restructures if you will. When you have the right rail open, there is such a moment where the TOC gets pushed to be underneath the infobox. If you then keep resizing the browser width, the content will jump and the TOC comes back up, causing the created white space to disappear again. If you continue reducing your browser width, the lede content will again push the TOC down, recreating that white space. At this point, it's generally less of an issue, as the content will be that narrowly stretched out that it'll more or less match the length of the infobox, but if you still continue resizing, there comes a point that the TOC jumps back up again, cause the right rail gets automatically collapsed, which then means that the content has more room to fan out horizontally.

This all just to say that the white space you see isn't always there and just depending on the width of your browser at the moment of looking at the page. That's not to say that it can't be looked at to see if there is maybe a possible way to streamline this reduction in size, the appearance of this white space, and the jumping around of the content, but for the sake of transparency and proper expectations, it's not something that'll be seen as high priority due to the limited moments that it actually occurs. Lady Lostris /  SOAP 13:01, 8 September 2022 (UTC)

To be clear, this issue is present when running the browser full width with a 1920x1080 resolution, which is still the most common desktop resolution by far. If it's happening at this resolution (and on every resolution smaller) for anyone with the right-rail displayed, then it's happening a vast majority of the time. If making the TOC properly size itself to sit next to the infobox and avoid this layout issue isn't a priority to FANDOM, then so be it. Can't care more about the common display issues than the host company that created them. --Ironyak1 (talk) 17:49, 8 September 2022 (UTC)

Could it potentially be that you're zoomed in? I was unable to reproduce your presented screenshots on a browser full width with a 1920x1080 resolution on FireFox or Chrome, nor were the 3 other people that I asked. It was only when zoomed in 120% or when I started to resize the browser as I explained above, that I could reproduce your experience. Are you perhaps using specific browser extensions that could potentially interfere with your experience?

Is there anyone else here who can reproduce Ironyak's experience?

Also to be clear, the host company does care, as evidenced by me being here checking and responding to this forum multiple times a day and helping to find solutions, give explanations, add to tickets, and even ask to raise certain ones in priority. Lady Lostris /  SOAP 11:55, 9 September 2022 (UTC)

Strange - not zoomed in and happening on fresh install of Firefox so no extensions involved (see this). Would still hope the TOC would just slide alongside the Infobox as needed, but if it is an uncommon problem and difficult for others to replicate, hopefully it isn't affecting too many readers. Thanks --Ironyak1 (talk) 17:35, 12 September 2022 (UTC)

Well, what I will do is file a ticket for the experience that I described above in that that still is annoying even if it isn’t what you're describing. It does sound like the two issues are related, so maybe fixing one will fix the other. Though if someone else can replicate Ironyak's experience, please do still add it here so I can add that to the ticket as well. Lady Lostris /  SOAP 17:49, 12 September 2022 (UTC)

Source Editor doesn't scroll as needed

The Source Editor (w/ 2010 workaround enabled, in Chrome or Firefox) doesn't scroll the contents as expected or needed.

• When typing at the bottom of the content, the cursor will move to a new line below the scrollbox display so you can no longer see what you are typing. This happens a lot when adding a new comment forcing one to stop and use the mouse to move the scrollbar down - various keys such as Page Down don't help bring the scrollbox to the active cursor location either.
• When highlighting text to copy with the mouse, you cannot start at the bottom and click-drag up to highlight all the text in a comment, unless you scroll the main window exactly to where you have both the bottom of the text and the "Drop Files" section visible. Alternatively you can to scroll to the top of the comment and then click-drag down instead into the "Summary" page area. Quite the pain when trying to archive items having to scroll and rescroll just to highlight an entire block of text.

It of course didn't use to be such a hassle to simply type or highlight text in the editor. Any known fixes? Thanks --Ironyak1 (talk) 18:58, 8 September 2022 (UTC)

That's a known and ticketed issue as well, so I added the report to the ticket. It's an unfortunate hassle, but you can either 1. disable the syntax highlighting, cause then the problem goes away, or 2. what I tend to do when I need to post a message or edit at the bottom of the text is to add several white lines first, scroll down so they're all in view, and then just continue working at the start of the white lines, so your view won't be constantly pushed below the scroll box. Lady Lostris /  SOAP 11:55, 9 September 2022 (UTC)

Turning-off syntax highlighting when copying large blocks of text seems to work, especially for archiving - will add it to the workaround list. Thanks --Ironyak1 (talk) 17:51, 12 September 2022 (UTC)

This ticket too has been raised in priority, so hopefully we'll see a fix within the month. Lady Lostris /  SOAP 16:08, 13 September 2022 (UTC)

Just an FYI, the ticket dealing with this issue is set to be tackled somewhere between October 4 and 17. This is an estimate though, as unforeseen situations may always cause priorities to shift and dates to change. Lady Lostris /  SOAP 16:57, 27 September 2022 (UTC)

This issue is fixed for the 2017 editor, though the ticket it still active for the 2010 editor. Lady Lostris /  SOAP 13:07, 19 October 2022 (UTC)

And as of today also properly fixed for the 2010 editor, whoop! Lady Lostris /  SOAP 16:15, 17 November 2022 (UTC)

Infobox preview not rendering correctly

Hi, the text in the infobox is squeezed together in preview (2017 source editor). MalchonC (talk) 02:47, 9 September 2022 (UTC)

There are multiple issues with the 2017 editor preview as highlighted above, this also being one of them. This particular issue was already ticketed, but I'll add to it. Lady Lostris /  SOAP 11:55, 9 September 2022 (UTC)

2017/Visual Source Editor Find & Replace feature does not scroll through matches correctly

In trying out this recommended feature as an editor improvement, I find that after doing a ctrl-f and entering a term, the source text scroll box does not properly scroll to go back through the matches, or forward through the matches once you have reached the bottom and are trying to wrap back to the first match. The match number changes but the scroll box does not update the view correctly. Also, the scroll box easily loses sync if you move it ahead the highlighted text and no longer jumps to the current match when using the forward or backward arrows. Note that the Chrome browser's Find tool does function correctly and the scroll box advances back & forth through the matches so overriding "ctrl-f" just gets in the way of a working solution. Are there some setting changes needed to make this editor feature work correctly? Thanks --Ironyak1 (talk) 19:56, 18 September 2022 (UTC)

ETA - Not sure if this is related to, or a continuation of, this similar issue reported back in May 2021, but there may be related bug tickets. Thanks --Ironyak1 (talk) 00:20, 19 September 2022 (UTC)

Yes, that is pretty much exactly the same as the issue I was talking about there. Ursuul did say that it was ticketed to be fixed, and iirc it did get fixed, as iirc I was able to use the find & replace feature as normal at one point, but it seems to have become unfixed/rebroken, with the only difference being that it didn't jump at all back then, whereas this time it jumps down until you get to the bottom, and then doesn't jump back up, as you say. -  MrSiriusBlack  Talk  19:32, 21 September 2022 (UTC)

I couldn't readily find that ticket Ursuul referred to, but I just filed a new one for this issue. Just for those interested, this feature does work as expected with the 2010 source mode editor. Lady Lostris /  SOAP 16:57, 27 September 2022 (UTC)

Is there a button I am not finding for the "Find & Replace" feature in the 2010 Source Editor? Ctrl-F just brings up Chrome's Find tool for me, which as noted above, does work, but doesn't have any of the regular expression, whole word, diacritic, replace/all, etc, options like the 2017 VE Source editor feature. Unless I am missing something, it appears that the 2010 source mode editor does not have a "Find / Replace" feature and just relies on using the browser's Find option? Thanks --Ironyak1 (talk) 17:59, 27 September 2022 (UTC)

With the 2010 editor, that tool comes up when you click "advanced" and then the magnifying glass to your right. Clicking that will trigger a pop-up that will allow you to search and replace (all) with the options to "Match case", "Match whole word", and "Treat search string as a regular expression". Lady Lostris /  SOAP 13:03, 28 September 2022 (UTC)

Thanks for the directions - totally missed that Advanced - "Search & Replace" button! Would quibble that using the same icon as Site Search at the top isn't very intuitive, but all the options (match case, regex, replace/all, etc) seem to work as expected so 2010 FTW again. Thanks --Ironyak1 (talk) 17:49, 28 September 2022 (UTC)

Any update on this? The find & replace tool still fails to scroll back up on 2017 editor. -  MrSiriusBlack  Talk  14:12, 11 January 2024 (UTC)

Sadly no. I put another comment on the ticket about this just now, highlighting that the issue is still ongoing and an annoyance, especially on longer pages. For now, using the 2010 for this or using your browser search through ctrl+f remains the workaround. Lady Lostris /  SOAP 14:55, 11 January 2024 (UTC)

Link suggestion list includes non-related items

The link suggestion list is back to incorrectly including items that are not an extension of what has been typed. For instance, if you start typing "[[Albus Du" the list includes Severus Snape, Hogwarts Pensieve, and other items that are not an extension of what has already been typed. This leads to the list having many unrelated choices and missing many that would be of use, like Albus Dumbledore's pocket watch. This was a noted bug back in Oct 2020 just after UCP deployment (see this Discord DM). Setting changes needed? Workarounds? Fixes? Thanks --Ironyak1 (talk) 21:02, 18 September 2022 (UTC) [[

It seems to take redirects into consideration as well, since Severus Snape has Albus Dumbledore's Killer, and Hogwarts Pensieve as Albus Dumbledore's Pensieve as redirects. I'm not sure if it's desired that the link suggestion prioritise non-redirects over redirects, but the inclusion of redirects does seem useful at times, such as when I'm not aware of a page move and type out the original page name. MalchonC (talk) 02:37, 19 September 2022 (UTC)

Ah, interesting catch about the redirects! I would agree then that it's a prioritization/ranking/sorting issue as when typing "[[Albus Dumbledore's" the most likely intended choices would first be Albus Dumbledore's portrait, Albus Dumbledore's wand, Albus Dumbledore's pocket watch, etc... and only be Severus Snape via Albus Dumbledore's Killer, Hogwarts Pensieve via Albus Dumbledore's Pensieve, or the very indirect Knockback Jinx via Albus Dumbledore's advanced Knockback Jinx, secondarily or if other more direct matches aren't available as the articles were moved for a reason. Cheers --Ironyak1 (talk) 17:14, 19 September 2022 (UTC)

Just for clarity, I'll ask if it was intended behavior or not. I did give the internal feedback anyway that in case it is intended, it would perhaps be nice to have the redirects be indicated as such somehow like they are when you search for them. Lady Lostris /  SOAP 16:57, 27 September 2022 (UTC)

Yeah, I'd love to see the functional spec on this feature as its behavior has shifted so much over the years, it seems to just be "suggest related stuff" without any way to make heads or tails of why it picked what it did and why its presenting the items in the given order. An explanation of the intended behavior would help and likely guide suggested improvements such as direct links before redirects, redirects indicated in list, etc. Thanks --Ironyak1 (talk) 17:54, 28 September 2022 (UTC)

Mmm, I don't know any details. I got the suggestion that it was assumed the order is based on page popularity of the destination, so it's not prioritizing redirects, but it's prioritizing destination pages. That said, I did leave the general feedback for a feature request to somehow make it clearer that you're dealing with redirects by listing the redirect name that's triggering the suggest in italics (since that's the accepted way to list redirects) rather than the destination name or the destination name in italics, or ideally even the redirect name in italics that renders as the destination name on the actual page when selecting that option. But we'll see what comes of it. Lady Lostris /  SOAP 15:25, 4 October 2022 (UTC)

Link suggestion triggering the list on links with completed brackets

As there seems to be active tinkering happening on production with the link suggestion, it appears that the list of suggested links is (now?) triggered when arrowing through the text of a closed link with completed brackets. As an example if there is a completed link such as Albus Dumbledore, when I arrow it and land on the last letter the list suggestion triggers. While arrowing backwards and forwards this isn't a big deal as the cursor just keeps advancing as expected, but when arrowing up and down the cursor is now stuck in the suggestion list and you have take steps to break out of the suggestion list to continue. Not sure why a new suggestion list would be expected behavior here as the link is closed and complete, although this prompt makes sense for links left open without the end brackets.

While this may seem like an unlikely occurrence, when you have a paragraph with many links (like in the bug report above) it happens repeatedly in just moving about the text. In short, I didn't go looking this bug, just ran across in the ordinary course of typing a reply. Thanks --Ironyak1 (talk) 18:17, 19 September 2022 (UTC)

Ha, that's a curious one, good (accidental) find. I haven't heard of it before, but it's worth a ticket anyway. Lady Lostris /  SOAP 16:57, 27 September 2022 (UTC)

Notifications list is inaccurate

Something is awry with the FANDOM notifications where the user & timestamps don't actually match the user who left a message see this. In this case the notification says it was from MalchonC 24h ago, but the most recent message was from Kates39 about 24 hours back and MalchonC's message was 5 days back as seen on the page history. Not sure where the wires are crossed but somehow they appear to be. Anyone else having problems with Notifications being inaccurate? Thanks --Ironyak1 (talk) 05:49, 21 September 2022 (UTC)

I've also had a problem with Notifications. If two or more people send me a message in one day, the notifications list tells me only one person sent a message (the latest one in my case) and doesn't tell me about the others. So now I'm in the habit of checking nobody else sent me one through RecentChanges or page history because I can't rely on Notifications. - Kates39 (talk) 09:34, 21 September 2022 (UTC)

Thanks for the confirmation. I've generally relied on RecentChanges / Talk page history to track messages, but wanted to try out some of the (literal in this case) bells & whistles of the FandomDesktop with fresh eyes. Do you know if these inaccuracies in the Notifications list is a more recent occurrence or a long-standing issue? Cheers --Ironyak1 (talk) 16:41, 21 September 2022 (UTC)

Yes this is a long-standing issue which I've been meaning to bring up for a while. I always check RecentChanges anyway but it would be nice if I could depend on the Notifications list to do what its supposed to do so I don't necessarily have to. - Kates39 (talk) 18:22, 21 September 2022 (UTC)

This seems to be a notification issue specifically related to talk pages as I can't recall ever having the problem with message wall notifications. So to get the fact straight for testing purposes and filing a ticket for this once I can reproduce: @Kate, it's only an issue when you get multiple messages on the same day on your talk page? @Ironyak, your screenshot doesn't make note of a notification for Malcom's message in general. Do you recall whether or not you got one? Kate's notification is either indeed missing or the issue is as you reported that it's being misattributed. Just trying to pinpoint the issue here, but I'll try to do some testing later anyway to see if I can reproduce any of this behavior. Lady Lostris /  SOAP 16:57, 27 September 2022 (UTC)

In my instance, the time of the notice was correct for the last message (24h ago) but it was misattributed to the sender of the previous message (the notice said MalchonC was the sender but it was actually from Kates39) even though MalchonC's message was days earlier. So not related to multiple messages in the same day in this instance, but a mashup of the correct message time but previous message sender. Hope that helps explain the screenshots. Thanks --Ironyak1 (talk) 18:05, 27 September 2022 (UTC)

Yes, I've only noticed it so far when I get more than one message in a single day on my talk page. I would have to test out whether it does it over multiple days. - Kates39 (talk) 18:59, 27 September 2022 (UTC)

Well damn, that doesn't narrow things down for test lmao, but I'll see if I can reproduce either behavior. Kate's issue should in theory be the easiest to reproduce on short term. Should this occur again, please let me know indeed as the more details we have, the better. Lady Lostris /  SOAP 13:03, 28 September 2022 (UTC)

Mobile interfaces lacks undo option?

Is there a way via the Mobile interface to perform an undo? Was reviewing Recent Changes on mobile device, and there is no undo option there now, so clicked diff which led to Special:MobileDiff/1628214, which also doesn't have an undo? Not wanting to misuse Rollback, tried choosing Desktop Version in Chrome on this mobile device, which changed the text sizing, but didn't move into Night mode which is my default, and diff still lead to MobileDiff, so logged-out and back-in, same problem remained, so cleared cookies/cache & logged out/in, and then the Desktop version loaded with full links allowing an undo, but by then I was back at a computer and just handled the undo there. Please tell me I am blind and missing a link to Undo when logged in on Mobile. Thanks --Ironyak1 (talk) 17:48, 22 September 2022 (UTC)

After poking some more, the (hist) link e.g. Special:History/Grey Rat also has no undo option so the mobile interface appears to lack a method for a simple undo from RecentChanges? Guess it's a feature request for the upcoming Mobile Editing improvements and would seem like a commonly needed feature so maybe low-hanging fruit? Thanks --Ironyak1 (talk) 17:39, 26 September 2022 (UTC)

Currently the mobile interface is very moderator unfriendly, with basic functions as a simple undo button and easy accessible history indeed missing. The only way you currently have to access them is to scroll down to access the "view full site" button to call on the desktop view on mobile. We're very aware of the less than ideal experience this offers our editors and especially admins, which is why this is on the roadmap to be tackled later this year. Mobile theming is already being beta tested, as is the Discussions AbuseFilter, but I can say that "Page history and vital admin functions like undo/revert are accessible on mobile" is part of the "we are done when" criteria. So tbc, but normally it should be expected this year still. Lady Lostris /  SOAP 16:57, 27 September 2022 (UTC)

Template Type not saving

In, trying to change the Template Type for the dialogue templates that don't render on Mobile, I click the type, choose Unknown, hit Save, receive confirmation notice of the change, change is logged, but Template:Dialogue a-b still says Quote for its Type and shows up on the Mobile interface. Tried a couple times, used different browsers, purged the template, but no luck and not sure what is happening, but will try again later. Suggested fixes welcome & thanks --Ironyak1 (talk) 19:28, 28 September 2022 (UTC)

So, Template Type doesn't stay after being reassigned to "Unknown", and reverts to "Quote", but did stay after being assigned to "Non-article" (which isn't great as the template should in fact be used on articles). Strangely enough however, this change, with a page purge, actually allows all the dialogue text to appear in Mobile, just without the usual leading large quote mark - see Holly Blackbird on Mobile. So happy accident? However, is there a preferred Template Type that hides the template text completely on Mobile if such is needed going forward? Thanks --Ironyak1 (talk) 02:52, 29 September 2022 (UTC)

The "quote" type is the one that indicates those templates as quotes and thus triggers the mobile quote format. Changing the template type to one that would show up on mobile like you did indeed can fix that -- though may cause the confusion that it may not be instantly clear that the block of text is a quote. If I recall correctly, "notice" should normally hide the template on mobile. Anyway, I did list the above on the ticket about type not saving. Lady Lostris /  SOAP 15:25, 4 October 2022 (UTC)

Image masking for unreadable signature images on Dark Theme

We have many images for character signatures in the infoboxes that are unreadable on the Dark Theme (e.g. see Queenie Goldstein, Porpentina Goldstein, etc). At one point there was some masking code that would help make such images legible. Is this listed somewhere and is there a way to automatically apply it to a list of images? Thanks --Ironyak1 (talk) 18:45, 29 September 2022 (UTC)

You can make those images readable again by wrapping them in div tags that invoke a css class. For example, wrapping the image in <div class="invertimage">[[File;image.png]]</div> and then adding

/* Making black image visible on dark theme */

.theme-fandomdesktop-dark .invertimage img {

filter: invert(1);

}

to the wiki's css, makes a dark image white on dark theme. Lady Lostris /  SOAP 15:25, 4 October 2022 (UTC)

Thanks! This looks to be working correctly as part of the format tag on {{Individual infobox}} so should handle most of the problematic cases all at once, but can also be added to other templates as needed if anyone runs across them. Cheers --Ironyak1 (talk) 18:56, 5 October 2022 (UTC)

I saw your testing edits to the Queenie page, may I perhaps suggest (in case you don't have these already) to use the following dev scripts?

• https://dev.fandom.com/wiki/ThemeToggler

This will add 2 buttons to the left of the page underneath the wide/fixed with button and the TOC button that will allow you to change the theme temporarily, i.e. without changing your preferences each time. I find this to be super handy to test out how template designs and other page elements will look on both themes. The real kicker here is also that it can be used within both source editors while previewing an edit, thus omitting the need to publish edits when testing out a design.

• https://dev.fandom.com/wiki/PortableCSSPad

This adds a css pad to your QuickBar. Using that will allow you to test out css changes without having added them to the css of this wiki. This can be used during the page preview as well, so for Queenie for example, you could've added the coding to the page, preview it, access the PortableCSSPad, and add the css code to see how it'll affect the page. Again super handy to test out css changes to templates etc.

Note that with the 2017 editor, you need to access these scripts before you preview though, as the preview there works as a pop-up. The mentioned "instructions" are with my experience of the 2010 editor with the preview settings set on "Show preview before edit box" and "Show previews without reloading the page". Lady Lostris /  SOAP 08:51, 6 October 2022 (UTC)

Thanks for the pointers to the extra tools. Hopefully we won't have to add and test a bunch of custom css to fix things, but if so, we can keep these custom scripts in mind. Cheers --Ironyak1 (talk) 19:51, 8 October 2022 (UTC)

It's more as a good general test for when you're redesigning (which doesn't have anything to do with having to fix anything, but just with keeping the wiki fresh) and making sure in an easy way that it works on both themes. But yes, it's also useful to see when you need to fix something. Lady Lostris /  SOAP 10:07, 11 October 2022 (UTC)

Pressing the search button goes to Special:Search if page not loaded completely

I don't know if this is by design or not, but I'll guess that it's not because it just doesn't make sense to have a button do different things based on whether the page is loaded completely or not. I really don't like going to Special:Search since it means my current page is gone, which is undesired for like 99% of the circumstances since most of the time I search just because I'm in the middle of a page and encounter something unfamiliar, and want to go to another page, but then continue reading in the first page. Also searching in Special:Search doesn't give me autocomplete results. MalchonC (talk) 11:30, 6 October 2022 (UTC)

I've tried to reproduce this behavior, but I still always get the pop-up. What I did was that I clicked on a random page, and as soon as the search icon was available, I clicked it, but then the pop-up just opened. Is there a page where you have encountered this redirect to Special:Search consistently? Lady Lostris /  SOAP 13:15, 6 October 2022 (UTC)

In my case it is not specific to any page. I guess you have to have not a very good connection to reproduce. MalchonC (talk) 02:11, 7 October 2022 (UTC)

I'll note this as feedback for pages not having loaded completely, but I can say that it is expected behavior that when you ctrl+click or click with your mouse scroll wheel on the search button, you also open up a new tab on Special:Search. Based on that, I do feel like it could be intended behavior. Lady Lostris /  SOAP 07:29, 7 October 2022 (UTC)

Can you perhaps also elaborate on what you see when you use special:search, as that should normally give you suggestions in a dropdown -- it does for me. Is that not the behavior you're experiencing? Lady Lostris /  SOAP 08:02, 7 October 2022 (UTC)

Maybe it is intended behaviour to have Special:Search opened when ctrl+clicking the button, but it shouldn't be the reason why it is also done simply because the page is not completely loaded. I mean, what kind of UX design would that be?

About what happens when I use Special:Search - when I click into the input box, a sort-of dropdown appears that shows what I've searched in the past, but if I start to type, it is gone, and the suggestion dropdown never appears like it does in the pop-up. MalchonC (talk) 08:10, 7 October 2022 (UTC)

So you don't see this for example when you start typing anything in the search field? That's when I see on Google Chrome (incognito). Lady Lostris /  SOAP 10:07, 11 October 2022 (UTC)

I'm afraid not. I don't see it on either my phone (desktop mode) or actual desktop. MalchonC (talk) 11:21, 11 October 2022 (UTC)

I don't see any dropdown after I start typing either, as in that screenshot. I don't see that. I only see the slightly different dropdown of past searches that Malchon describes, which indeed disappears when I start typing (unless what I start typing happens to start with the same letters as something in the dropdown of past searches, but again it's a slightly different dropdown menu that doesn't look like the one in that screenshot; Google Chrome seems to have gathered the past searches from all random searches I've done on any website, as the things in that dropdown have nothing to do with harry potter lmao). -  MrSiriusBlack  Talk  11:31, 11 October 2022 (UTC)

Derp, I'm an idiot. I forgot I have SearchSuggest installed. So good news bad news situation: bad news, the feature is thus not native to Fandom, which I will note down as feedback. "Good" news: if you want it, you can install that script to your global js to have it everywhere, and it is allowed to use that script sitewide, so an admin can also add it to MediaWiki:ImportJS if desired. Lady Lostris /  SOAP 11:47, 11 October 2022 (UTC)

This also doesn't work for me. If other users are interested, I would be willing to add this to our MediaWiki:ImportJS so it works sitewide. - Kates39 (talk) 11:53, 11 October 2022 (UTC)

Repositioning the cursor jumps to the start of the text in mobile editor

In the mobile source editor, most of the time when I reposition the cursor, it repositions fine but the view jumps to the start of the whole text. I have to drag all the way down to the cursor to see the place where I want to edit. Super annoying and inconvenient. MalchonC (talk) 04:45, 12 November 2022 (UTC)

I can reproduce this partially: whenever I tap to put my cursor the first time in the body of the text, everything is normal. When I tap again, the view jumps to the top of the screen for a split second and then jumps back down to where I placed the cursor. This is what I see on an Android device, Samsung internet with the source mode. I could not reproduce at all on an Android on Google Chrome. Could you perhaps provide me with a video of your experience? Lady Lostris /  SOAP 10:21, 14 November 2022 (UTC)

"There is no section new in revision xxxxxxx"

When I press the "ADD TOPIC" button of talk pages, a popup is triggered saying "There is no section new in revision xxxxxxx", with two options "CANCEL" and "TRY AGAIN". The latter doesn't work and triggers the popup again, and the former leads me to the 2010 source editor (from the 2017 source editor that I normally use). Writing in there and publishing then work fine, so it's not a major issue, but the popup is still an unnecessary complication. MalchonC (talk) 09:53, 14 November 2022 (UTC)

I'll add to the ticket which I filed for the Stranger Things Wiki about this. Lady Lostris /  SOAP 10:21, 14 November 2022 (UTC)

Font in editor preview

I use the 2017 editor, and at the moment, when I click preview, it shows a preview of the page written in a serif font that is completely different from the sans serif font that the wiki normally uses (which obviously becomes visible as normal after I publish my edit). I have no idea why this serif font has started appearing in the previews, I wonder if it might be related to the recent theme redesign, as it only happens on this wiki and I have only noticed it since Cavalier One's redesign went live, though I cannot say for certain that it started happening immediately after the redesign went live because the redesign went live while I was away on break. Obviously it makes no functional difference to anything as it is only a visual bug, but yeah. Figured it was worth a mention here. -  MrSiriusBlack  Talk  14:02, 7 January 2023 (UTC)

Also, interestingly, in the preview, redlinks are a sort of murky goldish yellow colour instead of the normal red. ¯\_(ツ)_/¯ -  MrSiriusBlack  Talk  14:31, 7 January 2023 (UTC)

Apologies for the late reply! It seems like there's indeed a bit of coding that has some unforseen consequences, namely these two bits:

.WikiaMainContent {
    font-family:Crimson Text;
}
.WikiaMainContent a.new,
.WikiaMainContent a.new:visited {
    color:#856F38!important;
}

Why they're only affecting the preview ... that I can't tell you, but I'll hit up Mike so we can look into tweaking the code so it'll go back to normal! Lady Lostris /  SOAP 16:38, 19 January 2023 (UTC)

Any update on this? It hasn't been fixed yet. -  MrSiriusBlack  Talk  14:12, 11 January 2024 (UTC)

I brought it up with Cavalier One again, and he just removed that piece of coding. Should be okay now. Lady Lostris /  SOAP 14:55, 11 January 2024 (UTC)

It is! Thanks -  MrSiriusBlack  Talk  15:31, 11 January 2024 (UTC)

Additional Top Navigation Menus

With the increasing interest in Hogwarts Legacy, Kates39 raised the idea of pulling it out from our "Games" top navigation menu into its own menu item. Unfortunately, when she did that, it erased the "Community" menu item which has essential links, such as to this Forum and the site Policies in particular. I vaguely remember reading about FANDOM being able to allow for extra top level menu items in certain cases, so I was hoping that might be at least temporarily available here in support for FANDOM's efforts focused on Hogwarts Legacy, but still allowing us to have the "Books", "Films", "Games", and "Community" menus as well. Thanks --Ironyak1 (talk) 18:50, 18 January 2023 (UTC)

In the beginning of UCP, with the transition of Gamepedia Wikis to the Fandom design, it was made possible that they had more links in their local navigation bar as they had more of those links on Gamepedia. That to give them time to adjust their local navigation to the new theming. Perhaps it can be discussed to switch out the gaming tab for HL specific links for a while before switching back to how it is now (or to update the few links you're currently already showing for HL)? Lady Lostris /  SOAP 16:38, 19 January 2023 (UTC)

Unfortunately (or maybe fortunately), both Harry Potter: Hogwarts Mystery and Harry Potter: Magic Awakened are receiving new content as well currently so our "Games" cup over runneth and I couldn't see sacrificing the entire menu to just focus on one of its submenus. If 4 top menu items is the hard limit then we'll just have to make due - it's not like Hogwarts Legacy isn't getting enough attention across the site. Cheers --Ironyak1 (talk) 17:41, 19 January 2023 (UTC)

I agree with Ironyak. I thought it could be nice to promote it and have more HL links for readers to navigate. However, if an extra header isn't possible, then it's absolutely fine! It was just an idea that I thought I would try. - Kates39 (talk) 17:53, 19 January 2023 (UTC)

I would just add that the idea is a good one and having a "spotlight" item allowed for in the top-navigation menu design wouldn't hurt so users could be more quickly directed to whatever content is new and of interest for any given wiki. Just throwing that out there for future FANDOM consideration. Cheers --Ironyak1 (talk) 18:06, 19 January 2023 (UTC)

I think it could be great if Fandom considered letting wikis have an extra header, at least for temporary promotional purposes! There is space available on the top navigation to put another header. Right now, a lot of readers are checking HPW for HL content so it would be a good short-cut for those interested. - Kates39 (talk) 23:13, 19 January 2023 (UTC)

I'll relay this as general feedback. As a general note about the "space available at the top", that may be deceiving, as the available space depends on how large your browser is, so I would guess that also has something to do with it. As noted below, since those games are the hot topics right now, it can perhaps always be considered to temp change the gaming category to reflect that. For what it's worth though, internal search and click behavior research has shown though (from the little I've heard about it) that the impact of the local nav isn't as significant as one may always believe and that it is generally better to ensure that you have a good Main Page reflective of what's current and a good category and on-page linking system. Lady Lostris /  SOAP 14:40, 23 January 2023 (UTC)

Content Mods need ability to move category pages

MalchonC contacted me about the inability for content mods to move category pages, which in looking at Special:ListGroupRights, content-moderator does in fact not have the move-categorypages permission for some reason. I am pretty certain content mods used to have this permission as I've seen other content mods complete the entire category rename process. Can this permission be (re)given to content mods on this wiki so they can better perform their role? Thanks --Ironyak1 (talk) 22:28, 22 January 2023 (UTC)

Hmm, I will have to ask around when this change happened, as I was under the impression that people can still do that. I have restored this behavior in the meantime. Lady Lostris /  SOAP 14:09, 23 January 2023 (UTC)

Many thanks! -  MrSiriusBlack  Talk  14:22, 23 January 2023 (UTC)

It seems the right was initially giving to every autoconfirmed user with MW 1.33 but it was revoked on this wiki from those users, but the oversight seems to have been to not deliberately attributing it to content mods. Since users with additional rights already had the ability to move categories, that specific ability was thus never explicitly given to Content Mods. A feature request has now also been made to assign this right to all content mods across the platform by default, so that it needs to be deliberately taken from them rather than assigned when it would be removed from other users. Lady Lostris /  SOAP 14:40, 23 January 2023 (UTC)

As I've seen some related hub-bub on this topic, my request at the time of the UCP rollout was to maintain the same permissions scheme as before so that we weren't dealing with extra issues there in addition the many remaining technical problems. That would have meant preserving the ability of content-mods to rename category pages as usual in addition to not granting new permissions without a community discussion.

Thanks for fixing this now - hopefully we're almost back to full pre-UCP functionality :) --Ironyak1 (talk) 17:40, 23 January 2023 (UTC)

Happy to have helped here. If there are more permissions slip up, or anything else of course, let me know! For what it's worth, those right changes were something related to the MW upgrade rather than a conscious decision to change on Fandom's part, but that doesn't deter from the fact that in the end, a change was noticeable to communities. Some indeed preferred to stick to the old behavior like HPW (and others, like Memory Alpha, Star Wars, and the Avatar Wiki being at the top of my mind) while others welcomed the opening of the user preferences. The takeaway really just is: this can be adapted on a per community basis, as it the core working of this community! Lady Lostris /  SOAP 13:45, 24 January 2023 (UTC)

NewPages needs color adjustments

In trying to review all the new content recently created, I ran across the fact that Special:NewPages has some serious color adjstments needed to make the text legible. Not sure when this changed, but if someone could figure out what broke and how to fix it, that would be most helpful. Thanks --Ironyak1 (talk) 22:33, 22 January 2023 (UTC)

This has been ticketed before (I've updated the bug spreadsheet accordingly). I fixed it locally with css for now and we'll review whether or not the code is still necessary once the migration to MW 1.39 has happened, as realistically speaking, this won't be tackled at the moment on a site-wide basis due to that incoming upgrade (which hopefully fixes it). Lady Lostris /  SOAP 14:09, 23 January 2023 (UTC)

Can no longer merge files properly

Presumably a result of the recent mediawiki upgrade, one can no longer keep the file history when merging files, only the page history. Before, it would let you merge everything, with all versions of the file remaining viewable in the 'File history' section (see example), whereas now, it only lets you merge the page history, as when I try to restore the files, this happens, leading to only the latest version of the file remaining viewable. :/ -  MrSiriusBlack  Talk  10:28, 20 April 2023 (UTC)

Just so I understand it properly (as I don't think I've ever tried merging files before), how exactly did you do this? What was the process to achieve the file upload merger? Lady Lostris /  SOAP 10:33, 20 April 2023 (UTC)

You rename file 1 to the filename of file 2, which deletes file 2 in the process, but normally you can go to the delete log and hit 'restore' (now 'undelete') and the original file 2 will be viewable in the 'file history' section as described above, but now hitting 'undelete' causes the above-linked error message unless I specifically select the page history to merge and not the files. -  MrSiriusBlack  Talk  11:03, 20 April 2023 (UTC)

Ooh, interesting. Never did that last part, but it's indeed easily reproducible. I'll file a ticket about this. Thanks for letting me know! Lady Lostris /  SOAP 11:52, 20 April 2023 (UTC)

No worries, thanks for the quick reponse! -  MrSiriusBlack  Talk  12:06, 20 April 2023 (UTC)

Minor hiccup in my previous statement that I'd be filing a ticket: while I could reproduce the behavior on MW 1.37 and thus assumed the error, I can't reproduce the error you reported as I was able to restore the deleted upload histories just fine when I just tested it out here. Is the reported behavior something you've encountered every time or was it once? I tried to reproduce here and on the Avatar Wiki, but on both wikis did I manage to restore the file upload histories like you described. Lady Lostris /  SOAP 12:17, 20 April 2023 (UTC)

Just to be clear, I just clicked the "view/undelete" option from the deletion log and then the big "undelete" button at the top of that page to restore everything about the deleted file page, and I managed to do that without the described issues. Lady Lostris /  SOAP 12:21, 20 April 2023 (UTC)

It happens every time I try on File:David Decio as Chief Snatcher.jpg. I haven't attempted it on any other files since it started happening on that one. -  MrSiriusBlack  Talk  13:50, 20 April 2023 (UTC)

Hmm, I wonder if it's perhaps an issue for "migrated files", so files that already existed before on MW 1.37. Is there perhaps another file that you'd like to merge like that, one that already existed before? I want to see if I can reproduce the issue there. In the meantime, would you mind perhaps testing out if you can reproduce the issue with newly uploaded files? Cause that's what I tried to do and it worked for me. Lady Lostris /  SOAP 13:55, 20 April 2023 (UTC)

Tested and was able to merge two newly-uploaded files normally with no issue. As for older files to test on, this and this are tagged for merging, so you could try those; both are old files from 2017 and 2018.

It might be worth noting that in the case of File:David Decio as Chief Snatcher.jpg, I attempted to merge a new file uploaded today on MW 1.39 with an old file uploaded in 2012. ¯\_(ツ)_/¯ -  MrSiriusBlack  Talk  14:40, 20 April 2023 (UTC)

Which file needs to be the one that's kept? Do I move File:WingardiumLeviosa SeamusFinnigan.jpg to File:WingardiumLeviosa SeamusFinniganBurntFeather.jpg or the other way around? (I assume that the practice is to leave a redirect?)

And that's good to know about the files when you tried it. Seems to support my theory a bit more already. Lady Lostris /  SOAP 14:43, 20 April 2023 (UTC)

File:WingardiumLeviosa SeamusFinnigan.jpg is the higher quality one to yes I'd say rename that over BurntFeather. I'd leave a redirect in case of links on old versions of pages. Thanks -  MrSiriusBlack  Talk  14:47, 20 April 2023 (UTC)

Okay, so that also worked without issue. Since it seems like potentially only an older and a new image have trouble merging (though we'd ideally test this again with other files), I could file a ticket, but to be honest, I doubt it'll ever get any traction. With the limit resources and the niche use case this would have, I imagine that this ticket won't be handled, cause why go through the trouble of merging those images (and thus having to fix the potential issue there) when the more logical and straightforward course of action would just be to delete the later upload due to it being a duplicate and/or reuploading the newer file over the older file directly without going through the trouble of merging. Lady Lostris /  SOAP 14:56, 20 April 2023 (UTC)

It's common practice on this wiki to merge rather than delete where we can, so as to preserve file histories and to save having to go through fixing resulting redlinks afterwards. I understand that this is a rather specific and perhaps rare issue to need a ticket for. Thanks for your help anyway. -  MrSiriusBlack  Talk  15:45, 20 April 2023 (UTC)

Before any definite statements, let's first test out our theory when there is another case of an older file in need of merging with a newer file. I understand the reasoning for merging file upload histories, but in this specific case, it seems to be broken for a merger between an old file and a new file, so I'm just figuring that there would be little use to merge, as I'm assuming the new file will in general be so new that they wouldn't be used anywhere or if they are, not on many pages, so it would be less work to replace the use of the new file than it would be merging. Lady Lostris /  SOAP 16:23, 20 April 2023 (UTC)

Now having the same problem here. All the files are pre-MW 1.39. -  MrSiriusBlack  Talk  18:46, 18 May 2023 (UTC)

Issue with mobile editing

Myself and others have reported issues with mobile editing. When I try to edit a particular sub-heading, it instead loads a section several sections above it instead. I edit using an IPhone, Safari. RedWizard98 (talk) 06:55, 15 May 2023 (UTC)

Yes, I've been encountering the very same problem. There's also that whenever I click into a different place, it jumps to the very top and then quickly scrolls back to the desired location. It used to just jump to the start without scrolling back, but now it also scrolls, which makes the problem less annoying but still uncomfortable to deal with. It still does not scroll, however, when I press and hold at a place in order to paste something, it just jumps to the top and the option to paste doesn't show up (or rather, it does show up for an instant but then disappears because of the jump). I'm on HarmonyOS and Huawei browser, Chrome doesn't seem to have the problem when I test it now. MalchonC (talk) 16:42, 19 May 2023 (UTC)

Apologies for the late reply. @RedWizard, when you say "particular sub-heading" do you mean that the described behavior doesn't always happen? Would you perhaps be able to make a video of the bug? (or @Malchon)

@Malchon: the scroll ticket has been reopened a while ago, but for transparency, HarmonyOS isn't a supported browser. However, that issue was also reproduced on Edge and someone was able to also get it on Chrome, which are supported. Can't say it's a high priority ticket atm though, sorry. Lady Lostris /  SOAP 10:26, 31 May 2023 (UTC)

2010 editor freeze for a while after loading

Is it just me, or does the 2010 (desktop) editor freeze for quite some time after loading? Like, it doesn't respond to clicking, and after a while the browser (Chrome) notifies me that the page hasn't responded for a while and asks if I want to close it, and a few seconds after that it stops freezing. MalchonC (talk) 16:42, 19 May 2023 (UTC)

Apologies for the late reply. Just want to confirm, is this still a thing? If so, would you be able to make a video of it? Lady Lostris /  SOAP 10:26, 31 May 2023 (UTC)

A couple of issues with the 2017 VE source editor

So for some time now I've experienced two bugs with the editor:

Bug 1 - The autofill menu when one starts typing a link flickers and resets when I try to page down the list using the arrow keys, unless I page down and hit enter on the right thing in the list very very quickly. I attempted to record a clip of this bug but it is oddly not showing all of the flickering in the clip, it flickered more in reality - basically, I start typing a link, the link suggestion menu appears, and I try to page down it with the arrow keys and, if I page down too slowly, the menu flickers and I'm back at the top and have to start paging down all over again. The obvious quick fix is of course to select the desired link with the mouse instead of the arrow keys, as I do at the end of the clip, but it is still an annoying bug.

Bug 2 - If I click out of the editor box, e.g. by clicking the 'preview' button, and then close the preview, the flashing line that indicates where I am typing moves upwards very slightly and becomes solid instead of flashing, and when this happens I am unable to type until I click next to it to return the flashing line to the correct place - see clip. This is quite annoying, especially for me because I'm quite stupid and I always forget and attempt to type straight away after leaving the preview screen, before realising I have to click first. :P

(Note that these issues are not exclusive to editing file pages, they happen when trying to edit anything, I just used a random non-existent file as an example editor screen.) -  MrSiriusBlack  Talk  13:27, 15 June 2023 (UTC)

The clips were super helpful, thanks! I could easily reproduce these. I'll take a look to see if there are existing tickets for this and otherwise file one. Thanks for letting me know! Lady Lostris /  SOAP 13:43, 15 June 2023 (UTC)

Small followup on the second one though: was this possible on MW 1.37? I'm asking as the same behavior can be reproduced with the 2010 editor where the preview loads before the editing window and does not as a pop-up, leaving me to believe this may be just standard preview behavior -- although I can see why the expectation would be different when the preview was a pop-up. Lady Lostris /  SOAP 14:46, 15 June 2023 (UTC)

I can't remember how long I've had the issue for, sorry. -  MrSiriusBlack  Talk  15:11, 15 June 2023 (UTC)

No worries. I asked for additional opinions on the second, but the first bug has been filed. Lady Lostris /  SOAP 15:24, 15 June 2023 (UTC)

Any update on this? Both still happen. -  MrSiriusBlack  Talk  14:12, 11 January 2024 (UTC)

Asked for an update on both issues. Lady Lostris /  SOAP 14:55, 11 January 2024 (UTC)

Feedback on the new 'thank' button

So today (or very recently if not today) a new 'thank' button was added to revision histories and recent changes next to edits, alongside the undo button, akin to what Wikipedia has had for quite some time.

I'm sorry to be negative, I do understand the concept and it is clearly well-meaning, but in my honest opinion this is a completely pointless and unnecessary addition that will only serve to cause a metric ton of annoying notifications that risk drowning potentially important notifications. It would have been nice if the Harry Potter Wiki had been consulted before this change was unilaterally forced upon us by Fandom. -  MrSiriusBlack  Talk 

At the moment, this is just a test, but yes, the feature will be enabled platform wise eventually. There was no large-scale outreach done beforehand as to not skew with the usability data of this. We're aware that this feature isn't really designed for power users, which is why you can disable receiving notifications for this via Special:Preferences, tab notifications -- you'll both get an email and a bell notification unless you disable those. You'll still see the thank feature and be able to thank others, but you just won't receive any notifications anymore if someone thanked you. If you wish to not see it at all, you can hide it with personal css. Lady Lostris /  SOAP 13:38, 15 June 2023 (UTC)

Thank you. -  MrSiriusBlack  Talk  15:11, 15 June 2023 (UTC)

To bring this section back in the direction of the main theme of this forum, I have noticed a bug in relation to this - on the RecentChanges page, the parentheses around the thank button disappear when the page updates with a new edit e.g. on live updates mode. Also, there's no space between the opening parenthesis of the thank button and the closing parenthesis of the 'tags' bit, and oddly there are spaces between the parentheses and the thank button itself. -  MrSiriusBlack  Talk  12:50, 17 June 2023 (UTC)

Thanks for reporting! I created a bug ticket for the disappearing parentheses. There already was a ticket for the spaces, so I just added the report to that. Lady Lostris /  SOAP 09:23, 19 June 2023 (UTC)

There is a bug now that has 10 parenthesis surrounding the thanks button, 5 on each side. thats a bug. Also, I suggest the ability for one to hide it from being seen. SeichanGrey (talk) 20:13, 16 September 2023 (UTC)

Apologies for the late reply, I had missed this. Do you still see that behavior? If so, can you link me to where it's happening and/or provide a screenshot?

This feature will become optional eventually, so admins will have the ability to disable the feature in general via the Admin Dashboard. If you just want to hide it for yourself, you can always use some personal css to do so. Lady Lostris /  SOAP 16:17, 21 September 2023 (UTC)

It lasted a few hours, if I remember correctly, but now, it has fixed itself, so no need anymore. SeichanGrey (talk) 16:41, 21 September 2023 (UTC)

JavaScript

A few days ago, I noticed that the scripts I have in my global.js have stopped appearing in My Tools. One did briefly reappear, then when I refreshed my page, it disappeared. Is there a problem / a reason why? - Kates39 (talk) 11:59, 25 June 2023 (UTC)

Is this still an ongoing this? I haven't heard of any js issue reports on my end. Lady Lostris /  SOAP 13:41, 26 June 2023 (UTC)

Yes, they still keep reappearing/disappearing in My Tools. - Kates39 (talk) 10:30, 28 June 2023 (UTC)

Stupid suggestion perhaps, but out of those scrips, WikiActivity is the only one marked as "beta". Does the problem still occur when you move that script to be at the bottom of your list (or even removed at all)? JS stops working when it encounters a script that has an issue. Maybe that's throwing the other scripts which you only added recently off? Lady Lostris /  SOAP 10:43, 28 June 2023 (UTC)

It wasn't a stupid suggestion! It appears to have worked so good thinking lol. Thank you for your help. - Kates39 (talk) 12:00, 28 June 2023 (UTC)

Eyyy, simple suggestions/solutions ftw! Glad it worked out :-D Lady Lostris /  SOAP 12:01, 28 June 2023 (UTC)

Unable to view pages in the 'File' namespace while logged out

So when logged out, if you click on a file link, instead of taking you to the file page, it will either A: take you to the wiki's main page, where the image will pop up as if you clicked on an image rather than a link (which is fine), or B: take you to a page that the image appears somewhere on, without popping the image up or showing where it is on the page. I have a feeling that you will say that this is not a bug and works as intended, however this, especially B, is a bit of a problem on a wiki where there are countless image references across 2,600+ pages that are rendered useless to logged-out readers, which one would presume would naturally be the vast majority of this wiki's readers. -  MrSiriusBlack  Talk  11:15, 27 October 2023 (UTC)

You predicted the answer correctly: this is indeed not a bug but a deliberate change made like over a year ago if not longer before to improve on SEO. In the case of those image references, the logged out user will be directed to the main page where then the image file will pop up instead. Lady Lostris /  SOAP 11:36, 27 October 2023 (UTC)

No, again, some of them will take the clicker to a page that the image appears somewhere on, without popping the image up or showing where it is on the page, which is the main problem I am trying to make clear here. A good example is reference number 19 on the Hermione Granger page, which is for File:Deanthomasoriginal.PNG. Clicking that particular 'see image' while logged out just takes the viewer to the top of the Dean Thomas article. An average viewer unfamiliar with the Dean Thomas page would have no idea that they are supposed to scroll down, or what they are supposed to scroll down to. The image in question is right at the bottom of that page. Thus this particular reference is completely useless for logged-out folks. -  MrSiriusBlack  Talk  12:33, 27 October 2023 (UTC)

If the image is used on a page, the logged out user will indeed be guided to that page when clicking on an image link. When the image isn't used, the lightbox will open on the main page on the specific image. Lady Lostris /  SOAP 12:50, 27 October 2023 (UTC)

Yes, but...can you not see how what I explained makes the reference useless? -  MrSiriusBlack  Talk  15:41, 27 October 2023 (UTC)

No I can, I was just explaining what the intended behavior from this function is from Fandom's pov, so it's not something I can file as a bug. If this is something that the community as a whole wants gone, I can try to request and fight for that, but I can't make any promises. Lady Lostris /  SOAP 16:37, 27 October 2023 (UTC)

Well, I for one would certainly like to see the images directly shown, since we do use this kind of image references very often. MalchonC (talk) 17:09, 27 October 2023 (UTC)

I'm curious as to the reasoning why there isn't a lightbox popup on the pages like the Dean Thomas example, like there is when directed to the main page? -  MrSiriusBlack  Talk  17:41, 27 October 2023 (UTC)

(edit conflict) I would agree with MSB & MalchonC here - why doesn't the image open in a lightbox when it is used on a page? Or at least jump to the image on the page where it is used (have the File: elements insert an anchor element for the filename so when clicked the page can jump to https://harrypotter.fandom.com/wiki/Dean_Thomas#Deanthomasoriginal.PNG) ? Linking to a image that doesn't actually show the image is a substantial downgrade from previous behavior and would require us to create several thousand duplicate reference versions of the images that cannot be placed on a page, but then would actually be displayed when linked to. Or does FANDOM have a standard work-around to make these links function correctly again for the majority of users that aren't logged in? Thanks --Ironyak1 (talk) 17:52, 27 October 2023 (UTC)

Looking deeper into it to find proper answers, seems like I was mistaken and the lightbox not opening on the page itself is a bug, for which a ticket has been filed a while ago. I added your report to that now to hopefully give it some traction again. Lady Lostris /  SOAP 15:33, 30 October 2023 (UTC)

Any updates on this? How long ago was the bug filed and is there an ETA on a fix? Thanks --Ironyak1 (talk) 13:53, 3 November 2023 (UTC)

This issue was part of a larger epic ticket dealing with multiple things that was filed last year in August. After these reports though, we split this specific issue off from that one to be worked on as we speak, and it's currently in code review. If I understood the notes on the ticket correctly, it should be fixed in this sprint, which I think is set to end next week. Lady Lostris /  SOAP 14:04, 3 November 2023 (UTC)

Thanks for the update - sounds like we can check to see if this is resolved next Saturday (11 Nov) and go from there. Cheers --Ironyak1 (talk) 18:59, 3 November 2023 (UTC)

Actually checked in with the engineers now about this, and they indeed confirmed that they're going to test it today/tomorrow, and if it works correctly, we can expect the fix to be merged and released sometime this week. Lady Lostris /  SOAP 13:04, 6 November 2023 (UTC)

I was just told that the fix was merged, so it'd normally be released tomorrow, barring any unforeseen consequences. Lady Lostris /  SOAP 12:35, 7 November 2023 (UTC)

Thanks - hopefully everyone can give it a test in the next couple days. Cheers --Ironyak1 (talk) 14:53, 7 November 2023 (UTC)

I can confirm this has been fixed, the lightbox opens now on all pages the logged-out user is taken to. Thanks Lostris -  MrSiriusBlack  Talk  13:14, 15 November 2023 (UTC)

Glad I could help, thank you though for helping us by flagging this again so we could get it fast tracked. Hooray for teamwork :-D Lady Lostris /  SOAP 13:25, 15 November 2023 (UTC)

Reviewing FANDOM network-wide blocks

Given some of the confusion surrounding the reactivation of this account, is there a way to check the history/duration of FANDOM network-wide blocks as we can do locally in the Block log? The Block log shows that Chase Scott Bechtel was temporarily blocked locally, and RedWizard98 said that they were also blocked FANDOM wide, which prompted him to add these templates to the User's page. {{Banned}} wasn't accurate as the User was not permanenly banned locally. The likely explanation is that {{BlockedAcrossFandom}} was accurate at the time but that the block expired or was lifted recently which is how the account could return to editing? Anyhow, just checking if there is a way to get details on the reason, duration, & history of FANDOM-wide bans for an account. Thanks --Ironyak1 (talk) 15:05, 7 November 2023 (UTC)

I can't go into details for privacy concerns, but I can confirm they've been temporarily globally blocked before, which ended last month. Lady Lostris /  SOAP 15:54, 7 November 2023 (UTC)

Reverted tag on rename action

I wanted to bring attention to the following rename action. It was done by a rename but actually not reverted. It was a merge where two were merged, one was deleted, and another moved over it, and the deleted-file was restored. then the "older" file was restored as the current file. he rename was not reveted, but the tag was added because the file was reverted/an older "edit" was restored. I think that a bug should be fixed. SeichanGrey (talk) 14:05, 11 December 2023 (UTC)

So the issue is that a page that got restored was tagged as "reverted"? Lady Lostris /  SOAP 14:17, 11 December 2023 (UTC)

So Malchon merged File A and File B together at File B's filename, and it is not the rename itself that was reverted, it was the "edit" that automatically changed the file page content of File B to the file page content of File A upon the rename happening, which Malchon 'reverted' when he changed it back to the original file page content of File B after completing the merge. I suppose I agree that the "(Tag: Reverted)" serves no purpose on Special:Log and probably shouldn't appear there, as it does misleadingly make it look like it was the rename itself that was reverted, which is not the case. -  MrSiriusBlack  Talk  15:15, 11 December 2023 (UTC)

To be honest, this doesn't entirely sound like it's a bug as there seems to have been some action that was reverted (I assume this is happening on all the logs of these types of actions?), but I agree that the tag being there does make it a bit confusing. Lady Lostris /  SOAP 15:45, 11 December 2023 (UTC)

Error notice

Hi, every time I refresh a page or open a new page, I get this error notice telling me an "error has occurred while fetching user social activity". It appears in the top right corner. I'm unsure why it keeps happening but it is a bug of some sort. Are Fandom aware of this? - Kates39 (talk) 20:55, 13 December 2023 (UTC)

Good news and bad news there: this is related to the AutoCreateUserPages dev script that was installed here to automatically create user profiles and talk pages upon their first edit. The issue was already flagged and a ticket for this was made, but it remains to be seen if it can be tackled, as the problem is caused by a user-created script (being used in a way it was not intended to be used) rather than it being a feature maintained by Fandom. So right now the options are to ride it out and wait to see what'll happen, or you can decide to disable the working of the script in the meantime. I will see if I can get some clarity from Fandom's side on whether or not this ticket will be picked up or not. I also left a message on the script's talk page on the dev wiki to see if they can look at it as well. Lady Lostris /  SOAP 12:47, 14 December 2023 (UTC)

This issue should be fixed now, but if you do still see it, lmk! Lady Lostris /  SOAP 13:34, 18 December 2023 (UTC)

Page renames appear in the individual page log of the old title but not the new title

What I mean by this is the log found when you click "View logs for this page" at the very top of the page's revision history. After a page has been moved, the log of the move is only viewable by clicking that "View logs for this page" at the revision history of the old title, and not the new title. Is there a reason for this? Anyone not realising this could easily be misled into believing that the page they are checking the logs of has never been renamed before. -  MrSiriusBlack  Talk  14:12, 11 January 2024 (UTC)

I can't think of a reason why it's not working beyond it perhaps being standard MediaWiki behavior. I can ask about it and file a ticket, though I doubt it'll be picked up soon. Lady Lostris /  SOAP 14:55, 11 January 2024 (UTC)

So apparently this is standard MediaWiki behavior as expected. You can see the same happening on Wikipedia: eg. old and new. The more technical reasoning is that the only stable identifier for a page in MediaWiki is a unique combination of namespace + database key, i.e. the title. So the move log in this case shows whether this particular namespace + database key combination has ever been renamed, which will not be the case if it was only a move target, i.e. the new page title. Lady Lostris /  SOAP 15:16, 11 January 2024 (UTC)

Okay then. Fair enough I guess. :/ -  MrSiriusBlack  Talk  15:31, 11 January 2024 (UTC)

Editor screen prohibitively small on user pages

This has been addressed before, but it has been a few months and it is still not fixed, so I'm flagging it up properly here. The editor screen on user and user talk pages is too small, especially when the user has a bio, and especially when one is editing from a widescreen computer. See this image for what I mean. It is caused by the user profile header thing still being visible on the editor screen, and to be honest I'm not entirely sure what purpose is served by said header being visible on the editor screen anyway? -  MrSiriusBlack  Talk  14:12, 11 January 2024 (UTC)

The issue you linked to got fixed, though the editor screen is still relatively small in comparison, for which a new ticket was filed. Per the last Tech Updates:

Our fix to extend the min-height of the VisualEditor’s text area in User Talk Pages caused other minor problems. The code was reverted, and we will continue the work to fix it as soon as possible.

The ticket it currently in the testing fase. Lady Lostris /  SOAP 14:55, 11 January 2024 (UTC)

The fix for this should be live. Lady Lostris /  SOAP 12:30, 16 January 2024 (UTC)

My editor seems to have become the "simplified editor for first-time editors" for no apparent reason

Ya...as the heading says. I use the 2017 Visual Editor - Source, and I don't know when exactly this happened but some time recentlyish it randomly changed to become like this which seems to be the "simplified editor for first-time editors" trialled some time back. Given the fact that my fandom account has existed for over eleven years, this definitely doesn't seem right. How do I fix this?? -  MrSiriusBlack  Talk  11:47, 26 February 2024 (UTC)

That's not a bug but a deliberate change. I went into some more detail about it a few weeks ago. In short, since the VisualEditor has 2 components -- visual and source -- the source mode also received some changes to keep some consistency with the toolbar of the visual mode. Lady Lostris /  SOAP 12:41, 26 February 2024 (UTC)

Then why was this originally stated as being for first-time editors only? Not a great change, this. Seemingly a total loss of the WhatLinksHere button, and also there used to be a vertical three dots button in the top right that gave a drop down menu for 'view history' and 'move' and such, as there is on normal page view. Perhaps I'm being overly pedantic, but to me the loss of those buttons feels a little restricting. -  MrSiriusBlack  Talk  14:21, 26 February 2024 (UTC)

That part is explained in the "decision" section on the more elaborate blog post about it. The only functionality removed is indeed the following that was reported:

"The original menu icon contained links to Special:WhatLinksHere, Special:RecentChangesLinked, Special:Upload, and Special:SpecialPages, which were deemed largely unnecessary to be accessible from within the editor. As such, they were removed. If you do miss any of those links being available within the editor, know that you can read those by customizing your toolbar."

The lack of the vertical three dot (kebab -- don't ask me why, idk) menu was also an intended change. When I asked about it prior to release, I was told the removal was because:

"That's because it's just a repetition of the kebab menu on the article outside edit mode, and some of the options on here (like source editor when you're in visual mode) don't even make sense to show here. Why would you need this option in the dropdown when the editor switcher dropdown is literally right next to it? Or why would you need an option to watch the page when it's also in the bottom bar? You could argue some of the other options are more relevant, like view history. But you can also access that via the quickbar (depending on how you've got it customized)"

I'm not going to contest this being weird at first, as I can definitely understand muscle memory and being used to a certain editing flow, but I could also understand the Product Manager's reasoning for removing the duplicate entry points to declutter the editor, which has been a proven issue to users from survey data.

As the notes said -- while I acknowledge it's not the same -- you can readd a lot of those functions in your quickbar. Out of personal curiosity though, why would you ever want to use the "move" option from within the editor? Cause wouldn't that cause you to lose your unpublished edits? Lady Lostris /  SOAP 14:36, 26 February 2024 (UTC)

Oh I didn't say I wanted to use the move button, I was just using it as an example of what I was talking about. I occasionally found the page history button useful though (opening it in new tab to not lose edits) to check I wasn't about to hit an edit conflict or suchlike. -  MrSiriusBlack  Talk  14:47, 26 February 2024 (UTC)

Oh lol, fair enough! That's why I asked, cause I can understand the "whatlinkshere" and "view history" for reasons you mentioned -- which is why I inquired about its removal prior to release as well -- but the "move" button was one of those "yah, don't care" for me and then you mentioned it lmao. If you use it to check for edit conflicts, may I sugges installing the EditConflictAlert dev script instead? It'll give you a pop-up in the bottom left corner of your screen in case you are conflicted while editing. Lady Lostris /  SOAP 15:17, 26 February 2024 (UTC)

The above script will give you a warning when an edit conflict happens, but without it, the 2017 source mode editor will give you a warning when you try to publish your edits and the option to "resolve conflict". If you click that one, the page will reload, showing the differences made by the conflict and then your text will be saved in a window below so you can easily copy/paste your own changes back into the page. This just as an fyi. Lady Lostris /  SOAP 15:22, 26 February 2024 (UTC)

End of the Wiki Representative program

So it has been announced that the Fandom Wiki Representative program is ending, and that a small number of Wiki Reps are instead becoming Community Managers. What does this mean for the Harry Potter Wiki? Will Lady Lostris continue to work with us, or will another staff member be touching base with us on this forum? -  MrSiriusBlack  Talk  23:56, 25 March 2024 (UTC)

The details of the transition are still being ironed out to make anything as smooth as possible. Eventually yes, either Chris or Davon will take over from me here, but whenever that will be, we will communicate about it to make it ad smooth for everyone. Lady Lostris /  SOAP 00:18, 26 March 2024 (UTC)

'Edit section' button on tabbered pages do not let you edit the right sections

Using List of spells as an example, when you click the lil pencil icon next to the section headers to edit just that section, it does not open the editor screen on the desired section, it only lets you edit the sections outside of the tabber (See also, Appearances, Notes and references and External links in this case), unless you try to edit a section more than 4 lil pencils from the top of the page, in which case it returns an error box saying "There is no section <number> in revision <revision>". (Google Chrome web browser on desktop.) (And ik that the big normal 'edit' button at the top of the page lets you edit all the sections and is thus the easiest fix, but still.) -  MrSiriusBlack  Talk  17:44, 13 April 2024 (UTC)

I'm afraid I'm back to "this is a known issue and I've added this example to the ticket." Lady Lostris /  SOAP 14:53, 15 April 2024 (UTC)

That's alright, that's a lot better than nothing. Thanks -  MrSiriusBlack  Talk  15:12, 15 April 2024 (UTC)

Source editor

When a formerly deleted page is re-created, there was always a notification that appeared showing the deletion log of this page, recommending that users consider this before re-creating it. This helps show page history and is informative to users. How is removing this an "improvement" Fandom? RedWizard98 (talk) 23:36, 9 May 2024 (UTC)

I also have another question, is there an "undo" button that allows you to reverse errors while source editing? I have noticed it does not appear to exist anymore. RedWizard98 (talk) 23:37, 9 May 2024 (UTC)

Ctrl+Z works for me. -  MrSiriusBlack  Talk  02:39, 10 May 2024 (UTC)

I'm not entirely sure what you're referring to with removing the deletion history on the page, as when I just went to the "Eternelle" page, both logged in and out, I got the box indicating the deletion reasons.

There are no undo buttons within the 2010 source editor, there never were to my knowledge. The 2017 VisualEditor - source mode does have those if you like to use them. Otherwise, it is like Sirius said and we talked about before, you can use the keyboard command ctrl+z to go back and ctrl+y to go forward. Lady Lostris /  SOAP 13:07, 10 May 2024 (UTC)

For clarity, we're not talking about the deletion log that appears on the page itself, but the one that used to appear as a closable warning notice on the editor screen. I no longer see that. -  MrSiriusBlack  Talk  13:45, 10 May 2024 (UTC)

Ah, now I see. Or well, better understand, as this seems to be a discrepancy between the 2010 source editor who still has that vs the 2017 VE source mode that doesn't. Lady Lostris /  SOAP 14:18, 10 May 2024 (UTC)

Oh I see. What's the reason for that? -  MrSiriusBlack  Talk  14:41, 10 May 2024 (UTC)

Is this a recent thing about the notices being missing? As I know there have been reports about the pre-loaded page layout templates also no longer working in the 2017 editor, which now makes me think that you just don't get notices at all anymore in the 2017 editor. I don't use that editor myself, but could you confirm that you still get or don't get notices? Lady Lostris /  SOAP 15:14, 10 May 2024 (UTC)

I'm not sure what you mean by 'pre-loaded page layout templates', I don't think I've ever seen those, but the notices about the page being protected or previously deleted stopped appearing at the same time as the changes I previously reported about in this section above. -  MrSiriusBlack  Talk  15:53, 10 May 2024 (UTC)

Sorry, that's not really important. It's just something that some wikis have set up to help create pages in a uniform way (e.g. when you create a page on Grey's Anatomy or the LGBTQIA Wiki while using the 2010 editor). On the 2017 editor, those buttons appeared in the same location as the notices, which is why I had to think about it. I'll ask around about this. Lady Lostris /  SOAP 18:13, 13 May 2024 (UTC)

I created a ticket for the missing notices -- warning and otherwise -- inside the 2017 editor. Lady Lostris /  SOAP 21:47, 13 May 2024 (UTC)