All posts by Revriley

1. Oh yes, you're right, I'm blind, "DPLForum for technical wiki support." Somehow I failed to process this. It's a combo I'm somewhat surprised they're going for, though I'm not necessarily complaining given the aforementioned -well- technical concerns. Guess we'll see how they handle the logistics of it in two days' time.

2. Ah yes, I was being euphemistic; I had heard that one has to now contact Staff with a request for DPLForum now. However, I'd forgotten that Staff might not be willing to switch off Discussions anymore... Damn. I remember when those wikis' Forums were initially switched to Discussions--I remember thinking "I should probably disable this now, while I have the chance."

Since nobody was using Forums on those three wikis, though, it admittedly wasn't high priority. I suppose, with that reasoning, it still isn't actually a 'concern' since nobody uses Discussions either (on those wikis). Granted, I've never tried to develop Discussions, so I could begrudgingly have done/do more on that front.

Certainly the wiki's actual content remains top priority before social features at all times, and I'd say that even if people were actually using the social features.

In any case, cheers for the clarifications. Evidently I simply cannot read today....

I said this elsewhere, but:

Well, it's finally going to happen. I've been dreading this day, but at the same time, it always seemed so far off. Yet, somehow, here we are. It's hard to picture myself using/participating in CC Forums-as-formatted-in-Discussions; certainly, that is, hard to picture myself enjoying doing so.

Offering aid in Technical Support will definitely be more cumbersome without wikitext, for one thing. Quoting replies is also extremely quotidian practice on CC forums, but that's still not something Discussions does (again, wikitext mourns). ...Why haven't I switched a few wikis I admin from Discussions to DPLForum yet? I should do that.

I can only hope that this...most anticipated migration (rather, its consequences) will...highlight the need for wikitext / richer editing ability on Discussions, because, while the lack of wikitext is far from my only gripe with Discussions, it currently detracts from the experience.

Well, as a reminder to anyone reading this, they updated Discussions to offer an alternate 'condensed' view to the default 'card' view. I highly recommend 'condensed' if you want any semblance of a traditional Forum format. While I continue to dislike Discussions, the infrequent times I use it, my dislike was even more pronounced when Card was the only option. Condensed makes it more bearable.

The October 16 Technical Update announced Link Suggest (assuming you're talking about Link Suggest) would return on Tuesday, aka the 20th. To be clear, Link Suggest is the feature that autocompletes/autosuggests article names when you're adding an interwiki link in Source Editor.

If this features is what you're talking about, then it should be functional now on your wiki. I can confirm that Link Suggest has returned (thank goodness) on the UCP-migrated wiki I admin (note: I use the 2010 editor). You may have to wait a couple seconds for a suggested link/article title to pop up--I think there's a smidgen of a delay compared to the instantaneous autocomplete on legacy wikis.

(Also, make sure you're not scrolled up too high; Link Suggest may have appeared off-screen if your cursor is too close to the bottom of the window.)

I did end up adopting 452's custom "File pages are inaccessible without an account" (paraphrase) PSA/notice that they tacked on to lightboxes. For those interested, 

.LightboxModal .LightboxHeader:after

--still works for UCP wikis (the wiki I trialled the notice on was migrated to UCP; 452's main wiki is pending migration).

However, it looks like the .user specific classes no longer work on UCP wikis, i.e. .user-anon (class for anonymous users) and .user-logged (class for logged in users) classes, last I experienced, have stopped working for UCP wikis (but do work for 'legacy' wikis). So:

.user-anon .LightboxModal .LightboxHeader:after

This won't work on UCP wikis; you'll have to remove the .user-anon class. I know because I tried the above first and had to trial and error before I realized .user-anon was interfering. Yes, using.LightboxModal .LightboxHeader:after on their own will mean the notice is visible to all users, and, yes, it will be moot for logged in users, but I doubt logged in users will mind seeing the message.

(I do, as a side note, mind somewhat about the myriad class changes and removals UCP is seeing. They did break a few things for migrating wikis. If UCP is going to have equivalent classes to .user-anon and .user-logged, it would sure be nice to know what those are--as you say, be given a "heads up." I guess the class selectors are maybe still subject to change, but hey--the migrated wikis have no choice but to be suddenly subejcted to change, and so far all the class selector changes/removals have been detected by users on an encounter basis.

(e.g. when a wiki I admin was migrated, the background image for the article content 'broke' due to class selector changes. I also had to figure out the correct class selectors for User Page elements on my own. The .user-anon/.user-logged removals I discovered on my own. Still haven't figured out if they have replacements or not.)

I don't mean to digress on a UCP tangent; I realize what thread I'm in. To reiterate, if you are an admin who wants to append a PSA/notice regarding this restriction to your ligthboxes for anons' sake, then appending a PSA to lightboxes via CSS--in lieu of FANDOM doing so--is the most efficient way. It's been months since this technical update rolled out--dear God, has it really been 3/4s of a year?--and I still don't understand why lightboxes don't natively explain this to anons in the first place.

Just to confirm, if no posts have been reported on a wiki (especially a wiki that does not have Comments or Discussions enabled), are the error messages "Loading reported posts failed" and "REPORTED POSTS LOAD ERROR" expected responses? I assume they are, since the migrated wiki I admin has neither feature enabled, I just want to confirm these are the expected messages when 'Reported Queue' is clicked.

(Note: to be absolutely clear, I'm not saying I expected anything when I clicked on Reported Queue, given the migrated wiki does not have Comments / Discussions enabled! I suppose I'm just curious if these messages were written with these circumstances in mind.)

Ah, but the actual audio file player is still defunct, yes? To quote the user-compiled list of issues, "OGG-Vorbis audio files do not show audio player UI and just give a link" is similar to what is now occurring on the migrated wiki I admin (previously was just a link, now displaying a blank bar). I look forward to the actual player UI being functional again, since there is little good in uploading files to UCP wikis that cannot play them.

Hm, can you confirm if this change is meant to affect UCP and 'legacy' wikis or just, er, 'legacy' wikis? I've tested this on a 'legacy' wiki with a semi-transparent background and can confirm the source editor is solidly backed there, but on the one migrated wiki I admin, the source editor does not display a solid background; its background remains the custom 'parchment image' background set via CSS.

---

I must say the mobile editor updates/fixes are a tad bemusing in the wake of 'mobile preview' being removed from UCP Wikis. As someone who rarely operates a smartphone, I mostly relied on the mobile preview editor to attend to the mobile homepage et al. Admittedly I did not do this as often as I could, but the fact remains it was my primary means of attending to the mobile experience at all. I suppose if I am to maintain the mobile experience at all, I am expected to have regular access to a smartphone? That's unfortunate.

In the wake of UCP migrations being paused, MisterWoodhouse, I do want to say I'll be keeping an even closer eye on Technical Updates in the upcoming months, given that the most popular wiki I admin (504 articles and counting) was among those migrated last month. As I said on your blog post, I think pausing was the right move, and I look forward to seeing the current UCP experience stabilized and improved. The editing experience is extremely slow, which is why I hope the 2010 editor will provide a comparatively faster experience for the time being (and am glad to hear its development is coming along).

Thanks for the updates in these trying times.

(Recommending rock bands, are we? Then I'll nominate The Cranberries, if you please, and throw in some Alice in Chains and a pinch of R.E.M.)

Mm. Although the Forum here generally operates on a "Please don't revive old threads" basis, surely Technical Updates at minimum are exceptions to that practice. These are official changes (major, minor, the gamut) that impact all users across the board; major changes continue to impact users weeks, months, years down the line, and so it would be disingenuous to say all Technical Updates become 'irrelevant' or that the debate or discussions they spawn have an expiration date.

Why, the other day I brought up this Technical Update (and linked the thread) to a recently-active again bureaucrat--only for a fellow admin to exclaim, "OH I had noticed that but didn't know why it was happening / I had assumed it was a mobile thing but now it makes sense."

Clearly people are still being directly impacted by this update, even if they aren't aware the cause is this update in particular. (As a side note, the fact the admin assumed this was another issue with mobile is fairly telling in its own right. That she thought it was a technical issue in and of itself, and that her instinct was to fault the mobile experience...) And this thread continues to be discovered by anons who have bothered to locate and look behind the wizard's curtain for the sake of an explanation.

And, upon realizing it is the wizard's doing, for the sake of lodging a complaint.

The reaction here shouldn't be, "It's been months, fellas...necro much?"

The reaction should be, "It's been months and we still have people assuming this is a bug, not a feature; we still have people post-epiphany voicing their disbelief and discontent. Mayhaps this hasn't blown over like we hoped for a good reason."

The majority of feedback in this thread remains relevant. Snapper2's about gallery neutering, practically everything 452 has said, Jak Himself & Vicarage's comments re: image descriptions, et cetera - alongside, of course, the valuable opinions of anons + former anons who have taken the time to chime in. My own feedback I suppose was 'technically' late, but I don't believe the points I made were trivial.

Honestly, I'm considering emulating 452's custom notice on lightboxes informing anons how to access file pages. If FANDOM does want anons to create accounts (as has been previously brought up), the absence of an explanatory notice re: inaccessibility is as puzzling as it is disheartening.

I believe I have found the issue. When you were re-adding the non-breaking space to the three templates, you forgot to re-add these:

<noinclude></noinclude>

You'd experimented with moving (them to the wrong places, e.g. after the br) the non-breaking space and removing one or both tags prior to removing the hard break, and when you re-added the nbsp you forgot to move and/or re-add them back. I re-inserted them for you (apologies for doing so without a heads-up); please check your Sandbox for Tabs' updated appearance. On my end the height appears to have been reduced.

While I'm here, I want to comment quickly on a few items of concern 452 has highlighted:

I experienced an event like this by anonymously visiting the main articles for Saints Row and Saints Row 2; in both articles' cases, clicking the cover art in the infobox simply refreshed the article. Where I can see how examples citing image galleries might fail to rouse alarm (since the use, misuse, and usefulness of image galleries continues to be debated), surely the infobox example holds some sway? An infobox inherently draws attention to an image editors have consciously chosen to pedestal, and it's reasonable to think anonymous users might want to access 'featured' images.

I couldn't even click to view 'full size image' of the Saints Row covers as an anon because I wasn't given that option. These are not tabbed images, mind you (|image = Saints Row box.jpg). I imagine many anonymous users might give up trying to access the image at this point.

Also, I'm in accord with 452's full statement that the above excerpt is from. Preventing anonymous users from accessing file history / previous versions is particularly rankling in my eyes--should we view file history as lesser to article history, which anons can (oh boy) 'still access'? To what extent is this to the detriment of transparency as it is use and practicality?

Then there are image categories, which others have already invoked. If the file history inaccessibility rankles me, the implications which arise from the perspective of category navigation trouble me and would appear to undermine FANDOM's own navigational philosophies.

You've essentially removed a straightforward method for anons to access image categories (i.e. by using the category row at the head/food of a file's page)--one of the easier methods at that. Yes, I recognize that the state of file categorization widely varies between wikis. So what? Even wikis with a robust image categorization system (in which the majority of its files are included) may not link to Category:Images anywhere obvious / indicate that's where anons should look.

(I guarantee the 'convenient links' scattered across the Harry Potter Wiki as brought up by Snapper2 in #18 are not majority practice. This isn't to say Snapper2's point isn't valid or relevant, for it is; where Snapper2 has underscored the problem of neutering image categories in and of themselves, I'm underscoring the problem of inaccessibility to image categories via files.)

FANDOM has indicated it values cross-wiki uniformity with the standardized local top nav design introduced in '15 or '16 and other customization restrictions. Moreover, you showed us you considered the visible display of categories useful when you duplicated the footer category row at the top of articles; you clearly believe they are valuable as navigational tools.

But now you've effectively removed the very navigational tool you highlighted for anons with respect to files. I'm having trouble reconciling this with both the prominence you've given displayed article/file categories and the import you've attached to standardized global experiences--the latter referring to your philosophy that users need some semblance of familiarity across wikis otherwise they'll be at a loss as to how to navigate (c.f. the local top nav design decision).

All wikis must display categories at the head and foot of articles/files; surely this falls in line with your navigation standardization philosophy? After all, as I acknowledged before, many wikis will not necessarily link to Category:Images anywhere obvious (homepage, top nav, community portal). Many do not have a file policy. (Special:Images in the top nav is useful, but not a substitute for Category:Images for obvious reasons). But anons who might not think to add Category:Images to the URL might think to access an image's categories from its file page, because this is the standardized experience you've offered and highlighted until now.

There are many reasons why anon users might have cause or desire to access an image's categories. Perhaps they want a quick way to view all the book covers in a book series. Scenario: they click on a cover in Volume One's infobox; they access the file; they discover it is categorized in Category:Book Cover Images and thus proceed; they are satisfied with their FANDOM experience. You have now rendered this method inaccessible for the anon user. Now what? If this user does think to manually load Category:Images, good for them... Unless that wiki hasn't filed the book covers category as a sub-category of Images, alas.

This user could spend time guessing the book cover category's name (optimistically hoping the Wiki actually has such a category), could look up how to access all categories, or, you know, the user could write FANDOM off and leave having learned to avoid FANDOM for future image-related queries.

(Before one dismisses the above scenario as something constructed just for "argument's sake," let me be clear: the above method to access Image categories is one I myself use often. I've used it on wikis when I'm logged in, on wikis I admin and know full well what the image categories are, and on wikis when incognito (anon) because it is convenient. It is useful. Count me among those who will be inconvenienced, even if only in small part.)

To summarize the Image Categories point, this move seems to directly oppose if not sabotage your previously espoused stance on the usefulness of displayed categories as navigational tools on articles and files. How do we reconcile this update with FANDOM's stances on displayed categories and standardized navigational experiences? I can't see how.

Glad to help. I hope you'll forgive my impulsiveness, but I went ahead and removed style=" from the second table so that I can use it as an explanation of what went wrong. You've probably now noticed that the extra style wasn't just negating text-align:center, it was also affecting the second table's width:700px and auto margins. 

Your problem was you were viewing style="color:white;" as one whole, when really it's composed of two things: an attribute (style) and a property (color). Technically three including the value (color:value). The code you provided in your original thread question already had 'style', right? So once you've noticed that, your next question would be, "Where do I put color:white;" within the style attribute.

It's great that you've been experimenting w/wikitext-editing in the first place. Help:Tables/Wikitext exists on FANDOM, but for more in-depth Table editing such as what we've just figured out here (e.g. HTML attributes), check out https://www.mediawiki.org/wiki/Help:Tables, which the preceding page links to for good reason. Jump down to the "HTML Attributes" section, and you'll find the section's first example changes the table's text color.

On that note, I still stand by my advice to avoid white text on light backgrounds; the text is hard to read.

Edit: Scratch that last remark; that is, never mind! I see you're way ahead of me on that one. Have fun!

Next time, please link to the page you're testing/using the table on for faster assistance. I assume User:AtoneTheMage/Armors this is the relevant page, yes? I see that you've been experimenting with code in the second table, so I've taken the liberty of updating the first table's look; please feel free to change it back or change it from there.

This is the wikitext customization I'm seeing for the first table prior to editing it:

{| class="wikitable" style="border: 1px solid white; text-align: center;"
|- style="background: #181c18;"

Here is my change:

{| class="wikitable" style="border: 1px solid white; color: white; text-align: center;"
|- style="background: #181c18;"

Is that what you want? I personally advise against white text on light background (referring to body of table). Go ahead and check the page to see what it looks like post-my edit.

By the way, regarding your experimental code for the second table...

class="wikitable" style="width:700px;margin-left:auto;margin-right:auto;text-align: center; style="color:white;"
|- style="background: #181c18;"

The reason this "overrides the center-align" is because the wikitext is incorrect. You've added one too many styles with style="color:white;". If you remove style=" to make it:

class="wikitable" style="width:700px; margin-left:auto; margin-right:auto; text-align: center; color:white;"
|- style="background: #181c18;"

--the results will be closer to what you want, I should think.

Edit: If the look of this table (i.e. background and text colors used, etc) is something you want to apply to all tables, then you could consider customizing the table class .wikitable. If you plan to use this design for only some tables (e.g. tables intended to be used on Armor/Armor-related pages or the like), then you could still consider creating a custom armortable class for convenience's sake.

Edit x2: Whoops, sorry Upn; when I started writing my response, no one else had replied yet. I always take too long.

I believe I've figured it out. I've made the necessary change on your wiki myself--I hope you don't mind--as shown below:

The quote template design you're using is one I use myself--as in, the basic design--so after I compared your template to mine and ruled out any mistakes in the code itself, I had a lightbulb moment and investigated your Template:!, aka the | in your template code. If you look at that template's history, you'll notice that it has been--likely unintentionally--'converted' to a portable infobox twice before. The first time you noticed and reverted it, but the second time seems to have slipped your notice.

Obviously Template:! is very much not supposed to be an infobox, so I went ahead and manually changed it back to its default state. This seems to have done the trick. To confirm, I'll point to the quote as used on Gary Jansen's page as an example.

Prior to my edit, the quote template indeed displayed colspan... as you said. It also put the speaker and source above the main quote. Now, the speaker/source row is properly displayed under the quote and no wikitext is visible. If you cannot see this change, I suggest purging your cache/hard reloading/etc.

That Template:! was 'migrated' to register as a portable infobox may be of some concern; I suggest double-checking your other non-infobox templates to make sure no other erroneous migrations occurred circa Feb 2020.

Edit: Informal observation regarding the quote template on Gary Jansen's page: I notice you tagged the quote source as a ref(erence), but this is a little clumsy given the quote template set-up. Notice the space between the comma and the [1] superscript; the design has a named source in mind, not a citation. Either use the source title instead, or change the template design if you'd prefer sources look like citations.

Here is an example of a quote template naming the source of the quote (i.e. example of what I mean by 'source title'); in this instance, the source is a book, so the book's title is written out.

I noticed after I posted my previous reply that you went and changed the font for the entire wiki at MediaWiki:Wikia.css. You should know this goes against FANDOM's Customization policy; I suggest replacing 'body' with #WikiaArticle, #WikiaRail just like this Staff member did when the Tensura Wiki violated the Customization policy the exact same way back in 2018. It's fine to change the font of the article body, but FANDOM decided a few years back that changing the font of article headers, top nav, and the wiki title is no longer hip.

Edit: Oh, curious; looks like a user decided to replace #WikiaArticle, #WikiaRail with #WikiaPage on Tensura Wiki in 2019...meaning article headers are using their custom font anyway. The user via their edit summary seems to think they must be "whitelisted for customization," but as far as I can tell the Customization policy hasn't changed re: article headers? Aren't they now technically violating the Customization policy again?

Not that I agree with Fandom's stringent Customization policies, mind you, but it is what it is for the time being.

(Side note, whoops; took me far too long to realize/notice I initially posted this reply in a different thread.)

Edit x2: Oh, how's this for feedback: I think you've credited the wrong author on your homepage. You've written "Amy Alward's Jinxed," but--per the book cover in your wiki's background, and after a quick DuckDuckGo search--isn't the author of the Jinxed duology Amy McCulloch? I suggest correcting this as soon as possible; although mix-ups and typos are understandable, a mistake this fundamental is to be avoided.

Ah. Well, if by "editing" you mean you'd like more people contributing content to the wiki, such as adding proper articles with robust content, this isn't the best place to attract potential long-term contributors or editors. I suggest reading Sannse's blog post How to Grow Your Wiki for ideas there. Some people like to promote their wikis on Community Central by writing a blog post (ought to then be categorized under Category:Wiki_Promotions), which is preferable to a Forum post in this case.

If you need help with editing on a technical level, for something specific, then that's another story. You posted in the Design Support forum category, so if you have an editing question regarding design, this is the place to ask. The Help Pages are useful for getting acquainted with editing in general; UpnCbs06 linked you to a few to get started.

As for feedback, you didn't specify what kind. If you want general feedback on the wiki, I'll echo Dralkyrie's advice that you develop your home page and add articles. I see you've started uploading various image files to that wiki, but actual articles with written content need to be prioritized over images. If you haven't read Sannse's blog yet, check out the paragraph where she explains why FANDOM recommends you write at least 50 articles; articles with text are good for SEO and therefore better at attracting readers/editors.

Dralkyrie's advice to categorize those articles is also good. I'll suggest you remember to update your wiki's top navigation (see Help:Navigation) as you start adding more articles, since I personally place high value on useful, well-developed top navigation. I loathe using wikis that doesn't make use of it.

Do you want to place a slider on a 'legacy' wiki or a UCP Wiki? Please link to the wiki page you want a slider on.

If your wiki is pre-UCP ('legacy'), then see Help:Galleries, Slideshows, and Sliders for starters. You can open Classic Editor and select 'Slider' from the Features section in the right sidebar, or add a slider via Wikitext in Source Editor. The Help page shows you how to do it in Classic Editor.

If you're on a UCP Wiki, you can add a slider using the same source code as you'd use when adding a slider via wikitext in pre-UCP wikis. For example:

<gallery type="slider" orientation="bottom">
Image Alpha.png|Title|link|linktext
Image Beta.png|Title|link|linktext
</gallery>

Edit: I tested adding a slider on my Sandbox page at Woodhouse's UCP-testing ground wiki; you can check the source code there. For examples of Sliders on pre-UCP Wikis... well, you're a Warriors fan, so check out this slider on the Warriors Wiki (see source code), or the wikitext for the slider on the Narnia Wiki home page. Ignore that they use hyperlinks when linking to articles on their own wiki.

Right... Are you asking if it's possible to claim 'Jinxed' as your Wiki's name, or are you looking for some other kind of help? I'll suggest you read Help:Sitename if your query is indeed sitename related (based on you mentioning your first choice being taken). It's still not entirely clear what you need help with specifically.

It's best to be specific when you ask a question on the Forum. Rather than ask, "Can I have some help," just go ahead and state outright what you need help with in particular; that way, people can more immediately offer assistance.

Don't forget to link to the Wiki in question as well; while it'd be especially great if you could link to the page or file in question that you need help with (or multiple pages, if relevant), but no one can offer 'help' to a 'Wiki' if they don't know what the Wiki is or what you want help with.

("Can someone help"--of course! That's what people are here for! Don't worry about pleasantries--just get straight to business.)

Hey,

I just want to say disregard what I previously said regarding Special:Community typically displaying Wiki Managers. The Wiki Manager module on Special:Community has been so normalized on manifold wikis I visit that I had come to assume it was an integrated feature accompanying a manager's assignment to a wiki. It turns out that Wiki Managers (usually WMs) upon joining a wiki have been manually importing a JS script from Dev Wiki that adds the module.

Needless to say, I've been a tad embarrassed now that Kirkburn's done that for B! Wiki. I checked and Durarara!! Wiki's manager indeed manually imported the JS script upon joining; it should have occurred to me sooner that the 'norm' might not be a native feature after all.

Sorry to revive the thread just for this, but definitely turn to Special:ListAllUsers instead of Special:Community for such things. Hoo boy.

What matters most to search engines isn't how long a Wiki has existed (though it's not irrelevant), it's what content exists on that Wiki. Search engines crawl web pages for keywords, titles, image names, etc. If your Wiki doesn't have much in the way of written content (which, at a glance Prison Planet is rather in want of), there's "not much in the way of content" for search engines to scan.

I recommend reading the Help Page on Search Engine Optimization [SEO] which provides a better explanation of how, when, and why sites are indexed in search engines. You may also want to read User_blog:Sannse/How_to_Grow_Your_Wiki. The short of it is you need to write more robust content for your wiki.

As for the images... well, that's unusual. Unusual indeed... I might have considered copyright infringement takedown for a moment, but there's no trace of any takedown notices and the files themselves simply can't be properly linked to in the first place, so...I'll need a minute.

Correct, that's why I said, "If a Wiki has the Special page Special:Community," though perhaps I should have been more overt with my phrasing there. 'Twas also why I went more in-depth with Special:ListUsers.

As for "It has to be requested," I was about to reply, "Huh, I seem to recall it was enabled on Baccano! and Durarara!! Wiki by default once it made its debut, I don't recall requesting it..."

...but then I remembered it was only enabled "across the top 5000 communities on Wikia!" Silly. It's not as if I'm not aware less popular wikis don't have them by default (I have founded three unpopular wikis so I am acutely aware, hah; I still haven't developed their Community Portals), hence my opening "if a wiki..." line, but I do admit that submitting a request for Special:Community to be enabled on a less-trafficked wiki hadn't occurred to me as a course of action.

It really should have, though, considering Kirkburn explicitly suggests a user wanting it enabled to send in a request in the comments of that staff blog post. Ah, memory, sweet unreliable mess you shall remain.

Ooh, oh my, I see what you mean. I've linked to a poor example for Wiki Manager demonstration since Wreckit-Woodhouse certainly lacks one, but still--so that's what Special:ListUsers looks like UCP-side. (This is a reminder I really should check out more Special Pages on that UCP Wiki; most of my UCP experimentation has been editor-side so far).

Worth noting that "Show only users with edits" isn't checked by default, so I suppose that's something. The lack of specification for that filter--i.e. no way to filter by edit count a la 'legacy' "five edits or less" style--however, is...the opposite of something. It's a glaring lacuna, now that I've noticed it. Actually, I take back what I've just wrote about the "show only users with edits" filter being something. Strike that. Reverse it.

Edit: Ha. My remark about Baccano! Wiki's Special:Community 'Wiki Manager' module (or lack thereof) being potentially bugged becomes more amusing in light of my comment on the Technical Update for June 29, 2016; back then, I was submitting bug reports for the 'Top Contributors' module being bugged on B! Wiki's Special:Community page. Nearly four years later and whaddaya know, some things don't change...

If a Wiki has the Special page Special:Community, its Wiki Manager (if it has one) is supposed to be listed as such in the right column for higher-level users and contributors. For an example, here's Special:Community on Durarara!! Wiki; notice how User:Neffyarious is listed as its Wiki Manager.

That said, not all wikis have Special:Community, nor does Special:Community always display Wiki Managers. At least, Special:Community isn't doing so on Baccano! Wiki, despite the wiki being assigned a Wiki Manager in March 2020. I thought it was just a matter of time (it took a little while for the Wiki Manager to show up on Drrr!! Wiki's Special:Community page), but after three months I'm thinking this might be a bug.

For general reference, you can see whether any wiki has a Wiki Manager by visiting Special:ListUsers. Here is Special:ListUsers on Baccano! Wiki as an example. Observe that Wiki Managers is last in the list of Filters.

1. Deselect All
2. Check 'Wiki Managers'
3. Remember to change the Contributed input to "all users" (from the default "5 times or more") since chances are the Wiki Manager has made less than five edits. This is the case on Baccano! Wiki.
4. Click 'show' for results.

On the Baccano! Wiki, after following these steps, you should see 'Unai01' listed in the 'wiki-manager' user rights group. You can make use of Special:ListUsers on all wikis.

Edit: I see you have editing history on the RoTG Wiki. By visiting the RoTG Wiki's Special:ListUsers page and following the above steps, I can see that User:Spongebob456 is its Wiki Manager. (That user is also listed as such on RoTG Wiki's Special:Community page). Obviously I don't know whether RoTG Wiki was the one you had in mind, but it serves to demonstrate how one can filter users by user rights groups on any wiki.