All posts by Oot42

"You'd have to give the specific infobox you want widened a theme"

That's certainly a good idea if you only want certain infoboxes to be wider, which we don't know whether it's tha case here or not, but anyway, it's not a solution to the problem addressed here.

@OP:

I haven't really found a css-only solution for this so far (you're not the first one to ask this). I tried all kind of variations with min- and max-width, and min-, max-, and fit-content but haven't found a way to make this work only if the image is large enough.

However, a solution would be to add an extra parameter to the infobox, which, if defined, adds a CSS class to some field.

Like this:

{{#if:{{{nostretch|}}}|<span class="nostretch"></span>}}

For example, you could add this to a header that is always displayed, e.g.

<header>General Information{{#if:{{{nostretch|}}}|<span class="nostretch"></span>}}</header>

This adds an empty <span> with the class .nostretch if parameter "nostretch" has any value.

On the page that uses a small image in its infobox, you would add it to the template call like this:

{{infobox_name
|image     = Small image.png
|nostretch = 1
 ...
}}

And the CSS would be:

.portable-infobox:not(:has(.nostretch)) .pi-image-thumbnail {
  width:100%;
  height:auto:
}

That way, images in the infobox would use 100% width (= fill the 300px) unless the "nostretch" parameter is defined.

"I didn't know that linking categories required the ":" at the beginning"

Without the colon it adds the page to that category but displays nothing.

It's the same when you want to link to a file, instead to display it, you need to add a colon, e.g. [[:File:filename.png|Filename]]

Some other things:

• You have the caption text color set to black on a black background. That makes no sense. The only reason the captions are still visible is because they are links.

• "accent" is not a valid border color.

• hideaddbutton is a deprecated parameter for what I know and does nothing.

See also Help: Galleries

It's TheKorraFanatic, a global discussion moderator.

Also, please read and follow the Discussion Guidelines.

Point 1:

"Please make the title as specific as possible."

"er" is not a specific, nor is it an appropriate or somehow descriptive title.

You just added those by editing their pages about one hour ago. It's a cache thing. It will work in a few hours.

"though only one of those categories shows the pages (season 1)"

The other categories are empty. There is nothing to show.

"its possible for the top navigation things to link to an actual page instead of a category"

*Seasons
**#Category:Season 1#|Season 1
** ...
** ...
*Characters
**#Category:Main Characters#|Main Characters
** ...

To be honest, I think it's the opposite. Too many maintenance boxes on too many pages makes a wiki look unprofessional. If such boxes are displayed everywhere, it also tends to be just overlooked. I personally also don't like cluttering pages with notice boxes generally. It breaks layout and aesthetics in most cases, imho.

On my home wiki, we use the stub template very sparingly. Only if the article has almost no information yet (but there's still a good reason to even create it already), we put this in top. As soon as an article has its basic structure, which in our case is an infobox with at least the basic infos in it, a lead of at least one sentence, and the most basic sections (History, Gallery, See also, and References in our case), it's not considered a stub anymore, even if those sections are still partly missing content.

Instead (most often for the History section), we use a template "section-stub", which just puts a text notice on top of that section, saying "This section is currently incomplete".

At the end, this is something every wiki has to decide for themselves though.

But wikis and pages are never finished or fully done in general. Putting a stub notice on pages that are not really stubs, i.e. almost have no content yet, does not make them look better, imho.

Some admin would have to request it as already said.

There is some more background on the help page's talk page, last entry.

Still a little confusing, but if I understand it correctly, then if it is activated on a wiki, it marks all edits, but if not, it still marks but only page creations. Which seems to be the case on your and all wikis I've been admin.

So as IAmNobodyIntresting said, the default has probably changed at some point.

I think the help page should explain this better. It's kinda confusing that a deactivated feature still does part of the feature's thing. Also, it cannot be that long ago that the default changed, since my home wiki is only little over 5 years old.

In case you or your admin get some more insight from Fandom support, it would be nice to post an update here so we can try to clarify the help page.

You need to be more specific about what exactly you want to "duplicate", and you should also always include a link to it.

"I want to duplicate table" is way too generic for us to understand what you actually want.

If you want to reuse a certain table layout, a template could do that.

If you want to display a certain table, including its content, one several pages, there are ways to do this.

So without more information we cannot really help you.

Both on my home wiki and on another one where I have admin rights, I have never seen a patrol sign/option for edits, but only ever for new pages (in any namespace).

Are you sure you see a sign to patrol edits (not new page creations) in other namespaces than main?

This makes me assume that this feature is not activated by default. The Fandom help page is kinda unclear about this, however, according to the MediaWiki help page, "some wikis only use new pages patrolling", so this is clearly a separate setting in the wiki's configuration. Therefore, I assume that's what's default on Fandom wikis.

Another thing that kinda points in this direction is that in my preferences, I only have the option "Hide patrolled pages from new page list", but not the one for "Hide patrolled edits from recent changes" (which is mentioned on Fandom's help page).

Also, I vaguely remember a similar question about patrolling edits here some time ago and I think that's what we had figured out, iirc.

Somehow the simplest option is missing here:

If it's just one upvote, like in the examples you showed above:

you can simply hover your mouse over the avatar in the upvote notice and it will show you the username. No need for the kinda complicated API call.

However, this only works if:

• The user has an avatar (not the default icon).

• It's not a notification for more than one upvote (n users upvoted...) in which case it only shows the name of one of them.

You were close with this edit, but used it the wrong way around.

Styles and other attributes for table cells come first, divided by a pipe from the table cell's content.

! style="width:13%" |
! style="width:29%" | League
! style="width:29%" | Nature
! style="width:29%" | Horde

You have to create a line break after the resultheader, or the wikicode table syntax will fail because {| is not on a new line.

You used <br>, but this is a html line break. It is written to the html source, but it doesn't put {| to a new line before it is processed. You have to use \n instead:

|resultsheader=There are '''%PAGES%''' Zois found in [[Dowon]].\n

It didn't work initially because as I said, the variable you first used does not exist.

The code I provided does work. I tested it.

"all of a sudden ... it had fixed itself ... i didn't actually change anything"

You changed the wrong variable to the one I provided. That's why it worked.

But you probably didn't clear your browser chache. That's why you didn't see the changes. You always need to do that after editing Common.css, as it is mentioned on top of it, or it will take until whenever your browser does it by itself for you to see it.

@ Fried Shrimp Lomein:

The autoblock feature prevents them from editing with a new account from the same IP address for 24h. If they use a VPN, they could just change their IP and immediately edit again. If the block keeps them away for a day, like OP said, it would indicate they don't use a VPN.

Also, OP said:

they apparently have multiple accounts from 2020-2021

so these are apparently not new accounts.

This code seems to be for a countdown using this dev script: dev:Countdown

Do you have this installed?

For any further help, as always, please include a link to your page.

If they stay away for 24h (until the autoblock expires) after each block, that would actually indicate that they do not use a VPN.

"Maybe stop IP blocking them for 24 hours and just ban them permanently."

They do block them permanently for what they say:

"I indefinitely block them every time"

The 24h autoblock feature is something diffferent.

Please always include a link to the page/template in question as advised in the Discussion Guidelines.

Posting a huge wall of raw code, even more without using the code preformatting option, is not really helpful. It's much easier to look at the code directly on its page, hence the need for a link. A link also allows us to see and understand its usage more quickly.

Please always include a link to your site as advised in the Discussion Guidelines.

The font seems not to exist (anymore?) under that URL:

https://db.onlinewebfonts.com/c/77e2c172ad2201a53a7462c14893bb10?family=Conthrax

Generally, the use of onlinewebfonts.com is not recommended. It is considered unreliable and very often causes loading issues and lags due to unavailability.

You could try this source instead:

https://www.cdnfonts.com/conthrax.font

@import url('https://fonts.cdnfonts.com/css/conthrax');

Alternatively, download the font somewhere, convert it to .woff2 if you don't find it in that format, then upload it locally on your wiki. You may have to ask to activate font upload with Fandom support first. Hosting the font locally is the best solution as it doesn't depend on external services.

No, the limit is 100 expensive parser functions per page. Transcluded pages (templates) count the same as functions used directly on the page. You cannot circumvent this by using templates or subtemplates.

There are other expensive parser functions (like {{PAGESINCAT}} ), but not too many, and the limit is 100 for all together.

Alternatively, you could make a DPL gallery. If you can make sure that all uploaded "Horse" images (or whatever images that should appear in the gallery) are always added to a specific category, you can make a gallery that updates itself automatically when new images are added to that category. However, you wouldn't have placeholders than.

For this, the DPL3 extension would have to be activated on the wiki, which has to be requested with Fandom support.