I'm seeing the House Guest infobox in the wiki's sitenotice (lower left window thing). It's not in the sitenotice's code at all so that's not it, and there aren't any recent edits to Mediawiki pages of any type that would explain it that I can see. Weird glitch on my end? Is this happening to other people.
2,519
pages
ALL POSTS
All posts by Citrusellaeditswikis
Here to make another post to this thread as it's happening again. If it goes away after I post this, I will wait for a third time of it happening and then approach Wikia's staff since I'm not sure this is a local issue.
...Oh, I see. Apparently as soon as I talk about it, it stops happening. XP
I feel I must note in addition to what's been said: Grace Rolek's mom is Japanese and black and her dad is white, so she's mixed (though she's certainly white-passing). Source: https://twitter.com/grace_rolek/status/895100098174042112
(And her racial identity is important to her... which is one reason I brought this up instead of starting to clean my living room. XP)
(Edited by Citrusellaeditswikis)
The colors WERE less harsh but unfortunately I can't say what they definitely were like by default on legacy as I had copied over a Wikipedia gadget that changed a lot of aspects of the way they displayed (I half-noted that back on the post where I included a screenshot, when saying some of the CSS might still be working but other parts (the relevant parts) were definitely busted). I remember it being less intense on legacy by default if I really think back but unfortunately I had used the custom CSS so long that my memory of what it appeared like without the customization isn't exactly sharp as a tack.
(For clarity, if I remember right the reason I even copied over the WP gadget in the first place was a personal preference thing back then, which is why I'm pretty sure my vague memory of the default is that it wasn't harsh.)
(Edited by Citrusellaeditswikis)
@ShadowRose9508 Anywhere in specific?
That's actually exactly what I tried to do, regarding pulling WP's gadget. There's something different about Wikia's setup here that I haven't had time or cared TOO hard about pinpointing quickly yet that means 100% of the gadget fails to work (unlike HotCat, whose relevant-to-1.33 version half-works and I sort of know why but haven't had the time to play with that one either). I unfortunately don't yet know enough JS to build my own version, though I'm working on learning JS--modifying existing code could be in my wheelhouse if I make time to sit down to actually do it, though.
I think I remember the chief complaints for 2017 being "I don't like VisualEditor", "there are things in the 2010 editor that are more useful to advanced users", and "I think [feature x] is not in the 2017 editor at all" in about equal doses? 🤔 (My chief complaint, especially on my old computer, is that I was experiencing a marked slowdown (especially on longer pages) using a modal-based editor like VE is. I think that complaint of slowness was a distant fourth? (Well, that was my complaint outside not liking it (which I didn't personally voice).))
Well, huh. That's a change of heart from their previous stance that there was a lot of demand for the 2010 editor and that's why they made it available. (And I don't remember the post linked saying that, exactly, either. Maybe I read the tone differently?)
The 2017 editor is fully working AFAIK (it's the same as the one in beta on Wikipedia, IIRC, as opposed to a wildly different product as it was before the migrations)--it just offers different things than the 2010 editor and some people have severe lag with it because it's a modal, which may be difficult to mitigate.
Heck, I don't even have the actual editor turned on with the non-VE source preference--I edit in a blank text box until I can try to figure out how to port Wikipedia's 2006 editor gadget over here to Wikia. XD
Double posting to keep this long block of text on a different issue as separate as possible:
As for the "just in case" of edit/edit source for non-VE editors... I'm sure some people out there do the thing interchangeably, perhaps (I don't know if there's analytics on how often people use VE when they've got 2010 source selected)... though I know in my case I have never had a reason to switch from 2010 source to any form of VisualEditor, outside of some times I was playing with the preference itself before 99% of wikis were migrated. I've never needed to switch for editing reasons, personally. (And in the other direction... I don't think people with a VisualEditor preference of either kind selected as their default editor can even get to the 2010 editor if they want to. I only tested logged out, but even using action=edit forces a VE load, into VE/2017 source editor).
The original issue was that the diffs' added/removed text (highlighted) was harsh and difficult to read, though technically compliant with the most widely adopted accessibility guidelines on the internet. (WCAG: AA contrast ("minimum"), AAA contrast ("enhanced"))
It's a little easier/less harsh now that the text is white, but I think what's messing with my eyes/brain is the color of the highlighting (the red/green) more than the color of the text.
The change to white text resulted in a lower contrast ratio that made the green noncompliant with the minimum WCAG contrast guideline and the red just barely compliant with the minimum.
Disregard comments on the coloring of SU Wiki's green specifically (though its contrast is, at the least, worse against the white text than the default green highlight (it's AAA compliant against the black)), because it's defined locally and I only realized that when Sophiedp noted it.
(Separate note I just thought of now and had not considered in my prior comments (hence its non-bulleting here as it's separate from that report but related to it) but I know it's why the default MediaWiki color scheme for added/removed highlights is now, like, blue and orange, which happened a long time ago: Red and green also isn't great for differentiation in certain types of colorblindness? But that's more of a "hey, be aware" comment, as I think there are other things that make clear whether parts of an edit are a removal or addition? Maybe?)
(Edited by Citrusellaeditswikis)
See, I thought that your issue was that you *did* have notifications you just couldn't see, in which case you WOULDN'T want to mark them read, if you did in fact want to read them (I was going to suggest that myself the other day before OP showed back up but held off when I took the other meaning out of it). (But I've never had that issue. Sometimes I've had the number stick around after reading something, though. Mark read is perfect for that.)
Your earlier screenshot with a notification number has the mark read button though... even though it's still blank for you as far as listing notifications. @ClassyHeadbanger
Oh, weird. I couldn't find an edit to MediaWiki space that would have explained the change, as I thought it had occurred in the past day. 🤔 But that makes more sense, yeah, as I couldn't figure out how anything not-local would have applied to SU wiki specifically and not another wiki as well.
Also, I don't know if this counts as a feature request or a bug, but is it possible for users who have the non-VE source editor selected as their editor to have section edit links that would open VE either suppressed or open their preferred editor instead? (For instance, Wikipedia's permutation of this kind of preference suppresses "edit source" links on sections and just has the "edit" button open the user's preferred, non-visual editor.)
I have personal CSS loaded globally (from UCP wiki) that does "display: none" on the edit links in section headers as well as the VisualEditor option in the page edit button so I have no chance of ending up in VE... but for some reason it doesn't load on the wiki I admin which I use most frequently... not sure why (and that part does feel like a bug but maybe a specific-to-me one)... But it would be infinitely easier if it was just something the software did for me.
Went to look for an example from a light wiki and a dark wiki (this one). This wiki's text in the green/red highlight is now white which is slightly easier for me to read but is ironically actually lower contrast and fails WCAG (green is 2.23 and red passes AA just barely at 4.51).
(The light example is from a wiki where I have user CSS modifying some of its look, I think--I'm pretty sure something changed post-UCP that broke the part that was modifying red and green highlighting (and most other parts), though, as the CSS I was using was similar to Wikipedia's old red/green shade and nothing like what I'm seeing here. The red and green are slightly different shades than the dark example, though--they result in the contrast being 4.37 for the green (still a WCAG failure) and the red is the same shade (so 4.51).)
See these examples live:
https://wreckitralph.fandom.com/wiki/Minty_Zaki?curid=2375&diff=106189&oldid=106178 (light)
https://steven-universe.fandom.com/wiki/Rainbow_Quartz_2.0?curid=932997&diff=1985934&oldid=1984004 (dark)
It looks like by default these are "theme-success-color" (#018c30) and "theme-alert-color" (#e81a3f), though SU wiki's became "#16c916" (with an !important) in the past day somehow (not through a local change, at least not to common.css). (EDIT: That last part is wrong--clarification in later posts but short of it is that it's local and I just didn't realize it was.) The text was black yesterday (higher contrast against the highlighting in all of these cases, though also more harsh than white), but is white in all cases I can find now. I can try to mimic the black text to get a different screenshot that shows the behavior I reported, but not right now as I need to go do something offline.
Note to be totally clear, that I've been referring to the interaction between the red/green highlight and the text it's highlighting, and not the highlight and the surrounding background of the wiki or the text near the highlight.
(Also note that I put a screenshot in this post and it's not appearing--if it doesn't show up I'll upload it elsewhere and link it.)
(Edited by Citrusellaeditswikis)
@Josephlint101 Out of curiosity, what do you mean by this? I'm trying to follow what you're saying but I'm not sure I'm understanding. Something in the header to get to categories? Does Special:Categories work? Or Special:CategoryTree, if you're wanting to see a hierarchy from a specific cat you know the name of? SU Wiki has 255 categories.
https://steven-universe.fandom.com/wiki/Special:Categories
https://steven-universe.fandom.com/wiki/Special:CategoryTree
@Sophiedp Ooh, I reported that edit issue when I came across it on a wiki I admin--it may also interest you to know that your own user page's edit dropdown, when you are an admin, will not include move or delete options (even though, like editing, they're directly accessible via URL). (I also wonder if the AbuseFilter issue could be solved with custom CSS but it's probably better if it's a tad automatic...)
Another for the possible-bug pile but may just be a feature request, but I'm putting it in this extra post because I noticed it while playing with the mention dropdown:
Sometimes TOS-violating username suggestions show up in the suggestion dropdown (just recently I saw ableist (which I would classify as "offensive") as well as violent, alongside with direct user harrassment (i.e. for a fake example, let's say it said something like "Citrusellaeditswikis sucks" but like... worse). This is a thing that I'm sure happens from time-to-time (more likely to admins who have made a lot of "enemies" by... doing their job) and isn't always easily caught.
But when it is caught and user accounts disabled (which is true of the single one I checked): Is it possible to anonymous-ize or otherwise rename users in this way, and then globally (somehow) prevent recreation of accounts under names like those with something like TitleBlacklist (name-dropping that one as it's standard issue for all wikis here and I know it has that functionality, though I worry it could require or expose local copies of a blacklist? IDK), or would that not be enough to remove them from suggestion dropdowns, i.e. for mentions here, or for, like, Special:Log?
I think it's incredibly... hmm... "oof" at best that account names like that are able to continue the harm they were created to inflict even after they've been globally disabled.
I've noticed in diffs that the shading of red/green and the text it's on (which is always black no matter the wiki's CSS or theme) is somewhat hard to read, even though AFAICT the combination meets WCAG AA standards at the least (red background is AA at that text size (more than 4.5--specifically it's 4.65) and green is AAA at all text sizes (more than 7--specifically it's 9.4)).
Oh, wow. Wonder what could have even caused that? It almost looks like that gallery format they were testing out but decided not to bring to UCP but I can't actually ascertain if SU Wiki ever had that enabled or if it was ever used on that article.
Does it look better now? If so, a null edit (opening the page in the source editor, doing nothing in the text box, and just hitting save) may fix it when you come across it. (Putting "?action=purge" at the end of the problem page's URL might also work since it does a similar but not identical thing, but I haven't actually tried it so don't quote me on it.)
EDIT: Some other galleries that use Tabbers may have a different issue I'm not sure how to fix...
(Edited by Citrusellaeditswikis)
...Which Designs gallery?
Like, I'm looking at random galleries and not noticing anything amiss, but I don't wanna assume this is a "they changed it now it sucks" because I've heard of (but not witnessed) gallery issues being posted about from other people who frequent different wikis that have also upgraded.
Just took a peek at a gallery and nothing appears to be wrong with it? Am I missing something?