This is a troubleshooting guide for when your Wikidot page simply isn't working and you don't know why. Because there are a massive number of different ways in which Wikidot pages can break, many of the steps below are highly situational. As a result, this document is divided into several sections, each of which are particular to certain use cases.
这是一份故障排除指南，用于解决您的Wikidot页面无法正常工作且您不知道原因的情况。由于Wikidot页面可能以多种方式出现故障，因此以下许多步骤都是高度情境化的。因此，本文档分为几个部分，每个部分都针对特定的使用场景。
Note that this is a living document, intended to be contributed to by members of the community as new issues arise.
请注意，这是一份动态文档，旨在随着新问题的出现，由社区成员进行贡献。
一般问题
Complex formatting appears broken? Do NOT use the "Preview" Button
复杂格式显示异常？请勿使用“预览”按钮
Wikidot's "Preview" button does not properly display complex formatting. Never use it for anything technically complex.
Wikidot的“预览”按钮无法正确显示复杂的格式。切勿用它来处理任何复杂的技术内容。
Instead, use the "Save" and "Edit" buttons; or, to save yourself some time, use the Ctrl+S and Ctrl+E keyboard shortcuts.
相反，请使用“保存”和“编辑”按钮；也可以使用键盘快捷键Ctrl+S和Ctrl+E来节省时间。
Not sure how (X thing) works? Check the Documentation!!! (Find it HERE)
不确定（某个事物）如何工作？查看相关说明！！！（在这里找）
If you're at a loss as to how to do something, always always always consult the documentation. It will, in all likelihood, contain the answer you need.
如果你不知道该怎么做某事，请务必、务必、务必查阅相关说明。它很可能包含你所需要的答案。
Bold/Italic/Underline/etc not working? Wikidot has its own custom syntax. Do not use Discord, Markdown, HTML, etc. syntax
粗体/斜体/底线等无法工作？Wikidot有自己的自定义语法。不要使用Discord、Markdown、HTML等语法
Don't use *this* for italics — Wikidot uses //this//, which renders as this. See here for how to style text in more ways.
不要使用*这个*来表示斜体——Wikidot使用//这个//，它显示成这样。请查看此处以查找更多文本样式。
Formatting broken on mobile?
在移动设备上格式显示错误？
Does your entire page appear to just be completely broken, similar to this image?
你的整个页面是否看起来完全损坏，类似于这张图片？
This is actually an iOS specific Wikidot issue involving your browser cache, and can only be fixed by clearing the cache on your mobile browser. Instructions to fix this can be found below:
这实际上是iOS特有的Wikidot问题，涉及浏览器缓存，只有清除手机浏览器缓存才能解决。修复说明如下：
On your Apple iPhone:
在你的Apple iPhone上：
- Go to Settings > Apps > Safari.
- Scroll down and tap Clear History and Website Data.
- Confirm the timeframe you want to clear, then tap Clear History.
- 前往设置 > 应用 > Safari。
- 向下滑动并点击清除历史记录和网站数据。
- 确认你要清除的时间范围，然后点击清除历史记录。
More information on this can be found on Apple support.
更多信息，请参阅Apple支持。
我从外部编辑器复制了文本，但无法正常工作！（例如Google Docs、Microsoft Word、LibreOffice等）
Check for "Smart Quotes", if Copying and Pasting from an External Editor (e.g. Google Docs, MS Word)
如果是从外部编辑器（例如Google Docs、MS Word）复制粘贴，请检查“智能引号”
This is a quotation mark. These will work in Wikidot elements such as [[div]] blocks and the like.
这是一个引号。这些可以在Wikidot元素（如[[div]]块等）中使用。
These, on the other hand, are so-called "smart quotes". These will not work in said aforementioned Wikidot elements.
而这些则被称为“智能引号”。这些在上述Wikidot元素中无法使用。
External editors like Google Docs and Microsoft Word are often configured to automatically convert quotation marks into smart quotes, leading to them breaking your article in unpredictable ways.
像Google Docs和Microsoft Word这样的外部编辑器通常会自动将引号转换为智能引号，这会导致它们以不可预测的方式破坏你的文章。
我的页面含有}}[[div]]，而且无法正常工作！
Ensure every [[div]] has exactly one (and only one) corresponding [[/div]], alongside other such Wikidot elements.
确保每个[[div]]都恰好有一个（并且只有一个）对应的[[/div]] ，其他类似的Wikidot元素亦然。
When writing advanced Wikidot syntax you will very frequently encounter [[div]] blocks. One common thing people often don't realize about these [[div]] blocks is that every [[div]] must have exactly one (and only one!) corresponding [[/div]]; not following this rule will lead to your article breaking in extremely unpredictable ways.
在编写高级Wikidot语法时，你将非常频繁地遇到[[div]]块。关于这些[[div]]块，人们常常没有意识到的一点是，每个[[div]]必须恰好有一个（且仅有一个！）对应的[[/div]]；不遵循这个规则会导致你的文章以极其不可预测的方式崩溃。
If you're wondering why this is the case, think of [[div]]s like opening parentheses, and [[/div]]s like closing parentheses, as if you were writing a complicated math equation. Each [[div]]-[[/div]] pair "contains" a section of code, which can include other divs!
如果你想知道为什么会出现这种情况，可以将[[div]]想象成左括号，将[[/div]]想象成右括号，就像你在写一个复杂的数学方程式一样。每个[[div]] - [[/div]]对“包含”一段代码，其中可以包括其他div！
You can easily verify that you're matching [[div]]s to [[/div]]s by using Ctrl+F — search for [[div and [[/div, and see if the number of each of them in the Page Source is equal. (make sure to subtract instances of [[div and [[/div outside of Page Source, since these can sometimes erroneously show up if your formatting is broken!)
你可以通过使用Ctrl+F来轻松验证你是否正确匹配了[[div]]和[[/div]]——搜索[[div和[[/div，并查看页面源代码中它们的数量是否相等。（确保减去页面源代码外[[div和[[/div的实例，因为如果你的格式有问题，这些有时会错误地显示出来！）
Note that this also applies to most other similarly-notated elements — for example, every [[collapsible]] needs exactly one corresponding [[/collapsible]], every [[span]] needs a corresponding [[/span]], et cetera.
请注意，这也适用于大多数其他类似标记的元素——例如，每个[[collapsible]]都需要一个对应的[[/collapsible]]，每个[[span]]都需要一个对应的[[/span]]，等等。
However, also note that this does not apply to other elements, such as [[image]] and [[module Rate]]. This is because these elements do not "contain" other user-specified textual content — you aren't ever going to put a paragraph of text in an image or a rating module.
然而，请注意这并不适用于其他元素，例如[[image]]和[[module Rate]]。这是因为这些元素不“含有”其他由用户指定的文本内容——你永远不会把一段文本放在图像或评分模块中。
Ensure that every [[div]] and every [[/div]] is the only thing on their respective lines. This includes spaces after the [[div]] or [[/div]] on the same line.
确保每个[[div]]和每个[[/div]]是它们各自那行上的唯一内容。这包括同一行上[[div]]或[[/div]]后面的空格。
If you're a programmer succumbing to your urge to neatly inline everything, this will unfortunately not work:
如果你是程序员，习惯于把所有东西都排在行内，这种方法很遗憾是行不通的：
Instead, you'd want to notate it like this:
相反，你应该这样标记：
Another much more insidious footgun with [[div]] happens when you mistakenly include spaces after it on the same line, as seen in the example here.
另一个与[[div]]相关的更加隐蔽的陷阱发生在你错误地在同一行中在其后添加空格时，如本例所示。
The problem here is that there are invisible trailing spaces after the opening [[div]]; I've highlighted the entire line in red to make this clear. Remove these invisible trailing spaces, and it will work. If you want to see if these spaces exist at a glance, try selecting the chunk of text you suspect has the problem, and look for invisible selected text at the end.
这里的问题在于[[div]]开头后存在不可见的尾部空格；我将整行用红色突出显示以使其更加清晰。删除这些不可见的尾部空格，它就能正常工作。如果你想一眼看出这些空格是否存在，可以尝试选中你怀疑有问题的文本块，并查看末尾是否存在不可见的选中文本。
All of the same counterintuitive behavior applies to many other elements Wikidot gives you access to, such as [[collapsible]] and [[include]]. However, bizarrely, there are a few it doesn't apply to — notably, [[span]] and [[a]].
Wikidot提供的许多其他元素都存在相同的反直觉表现，例如[[collapsible]]和[[include]]。然而，奇怪的是，有几个元素不受此影响——特别是[[span]]和[[a]]。
我无法保存我的作品！
Wikidot stuck on "Saving…" and you can't copy and paste your work elsewhere? Paste the following code into your browser console (open the collapsible below)
Wikidot卡在“保存中……”并且你无法将你的作品复制粘贴到其他地方？将以下代码粘贴到您的浏览器控制台（打开下方的折叠）
Press Ctrl+Shift+I, click on the "Console" tab, paste in the following code, and hit ENTER:
按下Ctrl+Shift+I，点击“控制台”选项卡，粘贴以下代码，然后按回车：
var btn = document.createElement("button");
btn.style = `position: fixed; top: 50%; left: 50%; translate: -50% -50%; font-size: 400%; z-index: 100000000; color: black; background-color: white;`;
btn.innerText = "Click to Copy Article";
btn.onclick = async () => {
await navigator.clipboard.writeText(document.getElementById("edit-page-textarea").value)
.then(e => btn.innerText = "Copied!")
.catch(e => btn.innerText = "Failed to Copy :(")
.finally(e => setTimeout(() => btn.parentElement?.removeChild(btn), 2000));
}
document.body.appendChild(btn);
Once you paste in the code, a button should appear. When clicked, the current contents of the editor should be pasted into your clipboard, allowing you to paste it into an external editor (e.g. Google Docs, Notepad, etc.) for safekeeping.
粘贴代码后，应该会出现一个按钮。点击该按钮后，编辑器中的当前内容将被复制到剪贴板，允许你将其粘贴到外部编辑器（例如Google Docs、记事本等）进行保存。
Obligatory Warning: Don't paste code from a source you don't trust into the browser console. The code above is harmless, but it is possible for someone to create code that is not harmless.
强制性警告：不要将来自你不可信来源的代码粘贴到浏览器控制台。上述代码是无害的，但有人可能会创建并非无害的代码。
Non-code solution:
非代码解决方案：
Press Ctrl+Shift+I or F12. Then, click on the "Elements" tab (if on Chrome, Edge, Brave, or another Chromium browser) or the "Inspector" tab (if on Firefox).
按下Ctrl+Shift+I或F12。然后，点击“元素”选项卡（如果在Chrome、Edge、Brave或其他Chromium浏览器上）或“检查器”选项卡（如果在Firefox上）。
Find the following three elements in the list, they should be at the bottom:
在列表中找到以下三个元素，它们应该在底部：
Right click each of these three elements, and click "Delete element".
右键点击这三个元素中的每一个，然后点击“删除元素”。
You should now be able to drag select everything in your edit box and copy it (CTRL+C). You can now paste this into an external editor (e.g. Google Docs, Notepad, etc.) and refresh the page, moving it back into your sandbox when ready.
现在，你应该能够拖动选择编辑框中的所有内容并复制它（CTRL+C）。你可以将内容粘贴到外部编辑器（例如Google Docs、记事本等）中，刷新页面，并在准备好时将其移回你的沙盒。
我的图片无法显示！
SVGs not loading properly? See here.
Again, see here.
Why is this happening? Long story short, Wikidot does not always use the file extension (in this case .svg) to determine what kind of file it thinks you've uploaded — in the case of SVGs, it checks for a bunch of specific text at the beginning of the file. And many SVG generator tools do not add that text to the beginning of the file. So, as a result, Wikidot doesn't think you have an SVG file, and, as such, neither it nor browsers treat it as if it were an actual image.
Images displaying as low-resolution, low-quality, opaque JPEGs? Use the full image link instead of just the image name.
If you only use an image's file name in an [[image ...]], [[component:image-block ... ]], et cetera, it will automatically convert the image into a low-resolution version.
If you don't want Wikidot mangling your images, include the full URL to the image in your [[image ...]], [[component:image-block ... ]], et cetera, instead of just the image's file name. So, for example, if I were to try to include an image on this page with the name example.png like in the previous example, then I would do this:
[[image https://scp-wiki.wikidot.com/local--files/wikidot-troubleshooting-cheatsheet/example.png]]
You can find the image's URL by:
- Navigating to the "Files" option you used to upload the image.
- Finding the file you want to grab the URL of under the "File Name" column.
- Right-clicking the link, and clicking "Copy Link" or "Copy Link Address"
So, why is this happening? Long story short, Wikidot tries to be "smart" when you include images, and will convert them into the JPEG format at a lower resolution and lower quality so that they can be loaded over the network faster, so that your page loads faster. In most cases this is an acceptable trade-off. However there are several circumstances in which this will cause noticeable loss in quality:
- Transparent images. Because JPEG does not support transparency, any transparent portions of the image will instead display as white.
- Large, detailed images, which Wikidot will often compress too much, to the point where artifacts are visible.
- Clip art, SVGs, and other images with sharp, precise lines, which JPEG cannot compress easily.
Can't fit images into the mandatory 800kB size limit? Use Image Resize Widget or another tool to switch to .webp and reduce the resolution.
The SCP Wiki Technical Content Policy mandates that all uploaded images be less than 800kB in size. While shrinking them might appear to be an insurmountable task for some images, there is usually a clear reason why the image is so big. The Image Resize Widget provides a good baseline for images in most articles, and is likely sufficient for your use case. However, if it isn't sufficient, here are some more actionable guidelines you can follow to decrease file sizes:
Do not use .png. .png files use what is called "lossless" compression, in which every single bit of detail of the image is encoded such that it can be recovered later without losing any information. This makes .png the obvious choice if you want to preserve 100% of the detail of an image — for example, if you are still editing the image, or are uploading detailed art; however, this also makes .png file sizes very large in comparison to .jpgs and especially .webps, making them unsuitable for uploading on websites. As a rule of thumb, switch to .webp.
Decrease the image's resolution. Many image-creating tools generate images with resolutions far higher than what is necessary for use on a website, resulting in images that might contain dozens of times as many pixels as they actually realistically need. For a frame of reference, SCP-682's image is only 945 pixels wide and 630 pixels tall. By contrast, modern cameras and document scanners often generate images in excess of 5000 pixels wide and 5000 pixels tall. This is $\frac{5000\cdot5000}{945\cdot630} = ~42$ times as many pixels as necessary!
All of this said, however, it is often better to make an image a few times bigger than its actual on-screen dimensions. This is because a single "pixel" in the browser often corresponds to multiple "pixels" in the actual physical screen's hardware, especially on mobile phones. For example, a "200px"-wide image might actually be 600 physical pixels wide. As such, a 200-pixel-wide image will appear blurry or pixelated, because it isn't taking advantage of the full 600 pixels of horizontal resolution the device actually offers.
Decrease the image's quality. If switching to .webp and reducing resolution didn't get your image down to a suitable size, try decreasing the "quality" value on your .webp exporter, if it is provided. The lower the quality, the smaller the file size will be, at the expense of some visual quality.
Be wary of .svg files. SVGs are stored fundamentally differently from other common image types like .png, .jpg, and .webp. Rather than representing the image as a two-dimensional grid of pixels, an SVG will represent the image as a combination of lines and shapes. This makes SVGs extraordinarily effective for images with fairly simple layouts (e.g. clip art, logos, and icons) because the lines and shapes can be scaled to an arbitrarily large size while still retaining crisp edges.
However, because of this "lines and shapes" system, it is much harder to conclusively predict how large any given SVG will be when compared to other formats — for instance, an SVG that appears to consist of a single circle, which you'd expect to only be a few hundred bytes in size, might actually contain the code for 10000 additional circles stacked underneath it. I've genuinely seen SVGs on the wiki where 90% of their file size is taken up by invisible content.
Image escaping its container? Add ~~~~ to the bottom of the container on its own line.
Say you have a setup like this:
[[div class="blockquote"]]
[[include :scp-wiki:component:image-block name=header-logo.png | width=150px]]
Example text here.
[[/div]]
Then it will display like this, which is not what you want — as you can see, the image is overflowing the blockquote:
To fix this, add ~~~~ to the bottom of, but still inside of, the blockquote:
[[div class="blockquote"]]
[[include :scp-wiki:component:image-block name=https://scp-wiki-cdn.nyc3.cdn.digitaloceanspaces.com/theme/en/sigma/images/header-logo.svg | width=150px]]
Example text here.
~~~~
[[/div]]
You will get this result:
Note that some themes, such as Basalt, have an alternative fix for this already implemented.
I can't find, view, or edit my page!
Page broken? Append /norender/true to the page's URL, and refresh.
If you really messed up with CSS and made your article unviewable, you can always regain access to the editor by adding /norender/true to the end of the URL, and refreshing. This will load a version of the page where all the page content, including the offending CSS, has been removed, allowing you to revert or edit the broken code. See SCP-173's page with /norender/true enabled!
Forgot the URL? Click your profile picture in the top right corner of the screen to view your Recent Contributions under your wikidot.com/user:info/USERNAME page.
If you forgot the URL to your page altogether and want to remember where it is, don't worry! Simply click the image of your profile picture in the top right corner of the page. This will take you to your your "User Info" page, which should have the URL wikidot.com/user:info/USERNAME, where USERNAME is your username.
Then, click on "Recent Contributions", and you should see a full list of every edit you've made to any Wikidot page. You can then filter this list by the type of edit (e.g. only showing newly-created pages).
My Fonts are Broken!
Use @import for fonts in a CSS module, not <link>.
When importing fonts from a font provider — most notably Google Fonts — do not use the <link> option, which is selected by default. Instead, select @import, and copy and paste the @import statement into the top of a CSS module.
Make sure the @import(s) are the first things in the CSS module.
The CSS @import specification requires that all imports are at the start of every CSS stylesheet. As such, if the @import is not at the start of the CSS module, it will not work.
Each font should get its own @import; do not combine multiple fonts into one @import, even if the provider claims to support it.
Font provider services — notably Google Fonts — often allow you to @import multiple fonts using a single URL to speed up website load times. However, this will not work properly in Wikidot CSS modules. Only select one font at a time in Google Fonts, and use multiple @import statements instead of just one.
Why does this happen? Well, you probably don't need to know this, as it's rather technical, but if you're curious nonetheless, here's why:
This happens because all CSS modules in Wikidot have their CSS inlined, meaning that, rather than separating the content of the CSS modules into their own file(s), Wikidot CSS is bundled into the same file as the webpage. And because this webpage is written in HTML, a text-based format where certain characters have special meaning, the CSS has to be "escaped" so that if it contains any of these special characters, they're converted to a version that won't interfere with the HTML. For example, every & is replaced with &
Unfortunately, this & character is the same character that Google Fonts uses in its URLs to separate a list of multiple fonts. And, unfortunately, after it's converted to &, Google Fonts will have no idea what it's looking at.
My .ttf, .woff, .otf etc. won't work when I upload it to Wikidot!
First of all, if at all possible, switch to a reliable external font provider like Bunny Fonts.
If that's not possible, there is an alternative fix — albeit, a rather janky one: Rather than attaching the font file directly, you'll need to embed all of the font's data into what's known as a "Data URL," and copy and paste that Data URL into an attached CSS file, which you can then @import. A Data URL is essentially just a URL which contains all of the data in the font file.
Here is a tool that, given a font file, will generate a .css file you can @import to use that font. The name you should use for the font's font-family, in this case, is just the name of the file you uploaded to the tool, without the file extension.
So… why is all of this actually happening? For this, we have to understand a bit about web security. Long story short, every piece of content loaded over the web is associated with what's called an "origin" — this is generally the domain name, plus subdomain, from which it is loaded. For example, this page has an origin of scp-wiki.wikidot.com. Conversely, every file you attach to an SCP Wiki page has an origin of scp-wiki.wdfiles.com (emphasis mine). Even though these files can technically be accessed via an scp-wiki.wikidot.com URL, this URL just redirects to an scp-wiki.wdfiles.com URL, so it doesn't count as having an scp-wiki.wikidot.com orign.
Fonts (alongside most other web resources) abide by what is known as the "Same-Origin Policy" — essentially, because the origin of your uploaded font files, scp-wiki.wdfiles.com, is different from the origin of the main page, scp-wiki.wikidot.com, your browser will, by default, refuse to load the font files when they're loaded on the main page.
This is an intentional design choice on the part of browser developers. Why? Well, imagine you create a website. You host a few custom fonts on the website to make it look nicer. If fonts did not abide by the Same-Origin Policy, then in theory, someone else could create a website and, instead of hosting fonts themselves, they could link to the fonts hosted on your website. And because services for hosting websites often charge money based on the amount of data transferred, by serving fonts from your site, they are costing you money.
Wait so, if this is the case, how does Google Fonts load fonts? Well, whenever your browser requests a font file (or, really, any other file), the server it's requesting from can optionally specify what origins are "allowed" to load those files, effectively overriding the Same-Origin Policy. scp-wiki.wdfiles.com, for whatever reason, doesn't specify any allowed origins for font files. Google Fonts, on the other hand, allows every origin, alongside every other font provider specifically designed to link to other sites.
As an aside, if you're wondering why attached images can load despite being hosted on a different origin, images do not have to abide by the Same-Origin Policy by default.
My Tables Aren't Working!
All line breaks in "standard" tables must be denoted with an underscore _ character.
Say you want to generate this table:
If you try to do it like this:
|| Hello || Line
Break ||
You'll get something like this, which is not what you want:
Instead, you'll want to put a space followed by an underscore character _ immediately before the line break, like so:
|| Hello || Line _
Break ||
Note that there are several ways to mess this up.
DO NOT omit the space before the underscore. This won't work:
|| Hello || Line_
Break ||
DO NOT put a space after the underscore. This won't work either (space highlighted in red):
|| Hello || Line _
Break ||
Can't put X, Y, or Z in your table? Can't change the color of individual cells? Use the "Advanced" Table Syntax
Wikidot tables can be a hassle (or even completely impossible) to get working with various complex formatting elements; use Wikidot's "advanced" table syntax instead for these cases.
Do note that "advanced" tables will not look the same as regular tables by default. This is because a regular table's underlying [[table]] element has the wiki-content-table class, while an "advanced" table's underlying [[table]] element does not. This is a deliberate design choice to allow web developers to apply their own styles to the table without interference from built-in styles associated with wiki-content-table.
If you want to retain the default styles, replace [[table]] with [[table class="wiki-content-table"]] in your advanced table.
My CSS Isn't Working!
IMPORTANT NOTE: A lot of what's referred to as "CSS" colloquially in the SCP community is not CSS. When editing Wikidot pages, you will only be directly editing CSS when editing a CSS module (i.e. the content between [[module CSS]] and [[/module]]) or in the style attribute of a [[div]], [[span]], or other such element. As such, this section will only cover these narrow definitions.
Is something earlier in the CSS file breaking it? Check for typos early-on in the CSS module.
Some seemingly trivial typos can "trick" the CSS engine into parsing the entire remaining portion of the CSS module incorrectly. Pay particular attention to the following:
- Mismatched curly braces — for example, a { with no corresponding }.
- Mismatched parentheses — for example, a ( with no corresponding )
- Mismatched quotes — this applies to both single ' and double " quotes. Ensure you are not using "Smart Quotes" which are denoted as “ and ”.
- Missing semicolons, especially in the same CSS rule.
- @import statements anywhere except the beginning of the file (@import should only be at the beginning!)
If you really aren't sure what's breaking your CSS, paste it into an external CSS editor with proper error checking.
Is your CSS selector actually matching anything?
Make sure the CSS selector you wrote is actually matching something that exists. For example, if you meant to type .blockquote, but instead typed .blcokquote, it won't appear to do anything.
There are several things you can do to rule this out as a cause. The simplest is just to put an extremely obvious, noticeable style on the element — e.g. background-color: red !important; — and then save the page to see if anything happens.
Do your CSS rules have enough specificity?
Multiple CSS rules can set the same property on the same element. If one of your CSS rules is doing this to a property on an element that's already been set by another stylesheet (e.g. Sigma Theme's stylesheet), then your CSS rule might not appear to work, because it's getting overridden by that stylesheet.
While this is by no means guaranteed to work, you should be able to resolve most specificity issues by either:
- Prepending :root one or more times before your CSS selectors. For example, if you have a rule with the selector .blockquote which is getting overridden, you might be able to fix it by changing it to :root .blockquote, :root:root .blockquote, :root:root:root .blockquote, et cetera.
- Appending each declaration (not selector) you want to individually use to override all others with !important, before the semicolon. So, for example, color: red; would become color: red !important;. Note that !important is not recommended, especially for any reusable theme or component, as using it makes it difficult for others to override your styles, if such a thing is ever necessary.
Under the hood, CSS engines use a variety of complicated rules to determine which style actually applies. This system is known as CSS Specificity. The specific details of how this system works are out-of-scope for this document — if you want to learn more, you can do so here. That said, in broad strokes, the more "specific" a CSS rule's selector is, the more "power" it will have to override other rules (hence the name "specificity"). This makes sense, because, you often have a generic rule you want to apply to all elements of a certain type (e.g. "all links should be red"), with specific exceptions carved out for a subset of those elements (e.g. "out of all links, all visited ones should be purple").
Do be warned that, in general, if you are increasing the specificity of a CSS rule purely to override another rule, you should increase the specificity as little as possible (e.g. if :root .blockquote suffices, do not use :root:root .blockquote). This is because these high-specificity selectors can get annoying and unwieldy the more people contribute to them — imagine someone has to override your code, and tack on another :root?
Check Developer Tools! (AKA DevTools)
While I hesitate to recommend DevTools to nontechnical users, they are really the tool for debugging weird CSS issues, but only if you know what to look for.
DevTools can be opened in one of two ways:
- By right-clicking on something on the page, and hitting "Inspect" or "Inspect Element", you will open DevTools pre-focused onto the thing you clicked. This is useful if you know a specific thing on the page isn't how you expect it to look.
- By using the shortcut Ctrl+Shift+I, Cmd+Shift+I, or F12.
Once you've opened DevTools, you should see a new window appear. Several options for tabs will appear at the top:
- If you're on Firefox, you'll want to click on "Inspector", if you aren't already there.
- If you're on Chrome or Edge, you'll want to click on "Elements", if you aren't already there.
Once you've done that, you should see the following screen, or something similar:
So uh. What the heck are we even looking at?
This section over here with all the weird angle brackets contains what's called "HTML" — it essentially describes all the content on the page, formatted as a series of nested lists:
Now, if you click on one of the individual parts of the HTML window, you should see this section appear — well, if it hasn't appeared already:
This section describes all the CSS rules that are getting applied to the element you just clicked, along with crossed-out rules that would be applied if it weren't for errors or specificity issues.
You should also see this row of tabs in the CSS section:
Try clicking on the "Computed" tab, and you'll see this section:
As the name suggest, this contains a list of the actual computed values of every single CSS property set on the element. Every element of this list is expandable; try expanding one, and you can see every single rule that modifies that CSS property on that element:
This is a wealth of useful information for debugging CSS, because, if your CSS rule isn't working, you can see, at a glance, if it's listed here. If it isn't, then you know that the rule itself is broken; if it is, then you know it's a specificity issue, or some other issue, such as a child element overriding the property.
My ListPages aren't working!
Note: If you haven't set up ListPages/Offsets yet and aren't sure where to begin, check out
NICO'S GUIDE TO OFFSETS (EZ MODE).
Have you set the parent on each on the fragment pages?
Assuming you have set everything up correctly, you should have:
- The parent page (On Sandbox this will be collab:your-slug-here)
- Your fragment pages (fragment:your-slug-here-0, fragment:your-slug-here-1, etc etc)
On each of the fragment pages, make sure you have set the parent page as the parent of those pages.
…I understand that might be a confusing sentence, so here is a step by step:
First of all, a quick way to check if a page has a parent is the breadcrumbs, which will be present at the top of the screen if a parent has been set:
If absent, you probably haven't set the parent, scroll to the bottom of the page and click +Options
And then Parent
And in the textbox, paste the exact slug of your parent page
Make sure you have done this for all of your fragment pages, it is easily missed!
Is your parent page and, by extension, your ListPages module set up correctly?
Your parent page should only have the following content:
- Rating module
- Any includes you'd like to apply to all pages (such as a theme)
- ListPages module and commented fragments
- License box
Below is an example:
Your module should be exactly as seen below:
[[module ListPages category="fragment" parent="." order="created_at" limit="1" offset="@URL|0"]]
%%content%%
[[/module]]
A common mistake I see people do is change @URL to their actual page URL, don't do this, again keep it exactly as typed above.
Are you linking to the offsets correctly?
Offsets, or "your other pages", should be linked to exactly as below:
[[[/your-slug-here/offset/1 | Link to next page here]]]
Or on the sandbox:
[[[/collab:your-slug-here/offset/1 | Link to next page here]]]
- offset/1 will link to fragment 1 (Your second page of content)
- offset/2 will link to fragment 2 (Your third page of content)
So on and so forth.
Do not link to your other pages with the URL of the fragment:
BAD: https://scp-sandbox-3.wikidot.com/fragment:your-slug-here-0
This bypasses the listpage module entirely and just links to your fragment page, which isn't how this works.
If all else fails — refreshing the cache
The ListPage module uses its own cache, but all you really need to know is it updates at a slower pace than the actual page.
If everything seems to be right, and one of your fragments still just refuses to work, the module simply may not have updated yet.
In this case, it is worth manually updating the cache, which is a lot easier than it sounds. Simply edit your parent page, and update the ListPage module as seen below:
BEFORE:
[[module ListPages category="fragment" parent="." order="created_at" limit="1" offset="@URL|0"]]
%%content%%
[[/module]]
AFTER:
[[module ListPages category="fragment" parent="." order="created_at" limit="1" offset="@URL|0"]]
%%content%%
>
[[/module]]
This very simple addition of a ">" forces the module to update, and should now account for any stray pages that weren't in the cache.
Once updated, you can remove the ">", or you can leave it, as it doesn't really do anything.
If you want to learn more about how ListPages works under-the-hood, check out ListPages Magic and You for a full explanation.
My ACS isn't working!
Are your options lowercase?
All the options on your ACS include should be lowercase.
The below won't work, as all the options are capitalised:
BAD:
[[include :scp-wiki:component:anomaly-class-bar-source
|item-number= XXXX
|clearance= #
|container-class= Euclid
|secondary-class= None
|disruption-class= Vlam
|risk-class= Warning
]]
Change them all back to lowercase:
GOOD:
[[include :scp-wiki:component:anomaly-class-bar-source
|item-number= XXXX
|clearance= #
|container-class= euclid
|secondary-class= none
|disruption-class= vlam
|risk-class= warning
]]
Are your options valid? Only a few pre-set containment/disruption/risk classes are supported out-of-the-box!
A common mistake is inputting custom classes into ACS, standard ACS only accepts the pre-set options.
The available options and their icons are listed on the component page, though I will also list them below:
Containment Class:
- safe
- euclid
- keter
- neutralized
- pending
- explained
- esoteric
Disruption Class:
- dark
- vlam
- keneq
- ekhi
- amida
Risk Class:
- notice
- caution
- warning
- danger
- critical
Secondary Class:
- apollyon
- archon
- cernunnos
- decommissioned
- hiemal
- tiamat
- ticonderoga
- thaumiel
- uncontained
If you wish to use custom classes, you will need to incorporate Customizable ACS.
Customizable ACS: Is it positioned correctly?
Your Customizable ACS needs to be above your standard ACS.
BAD:
GOOD:
Want to contribute to this guide?
This guide is open for contributions from anyone who's experienced a problem with editing Wikidot pages and has reason to believe to believe they're not the only one. That said, there are a few guidelines to follow when contributing:
Put more common issues first. Wikidot is a complicated platform with hundreds of failure modes; in principle, we could document all of them here. However, with guides like these, the larger they become, the less useful they become, because the specific information a user is looking for will become buried amongst information they aren't looking for. To mitigate this, put issues you believe are most common near the beginning, and issues you believe are rare near the end.
Focus on solutions to specific problems, not on "tips and tricks". Contextless series of tips and tricks are hard to remember unless the user actually has to immediately apply them toward an actual problem they have. By focusing on actual problems users face, they immediately get to apply what they learn.
Organize your issues by section. Many Wikidot issues are highly situational; as such, this page begins with a prominent table of contents to allow users to select the problem they are dealing with, so they can jump straight to the relevant section instead of sifting through irrelevant info.
Problem, then Solution, then Explanation. Users tend to naturally tunnel-vision into finding the solution for their specific problem, at the exclusion of all others. Consequently, they might skim over important sections of this document that might be useful to them if you are not cutthroat in prioritizing what information comes first. As such, every section you add should start with a brief description of the problem and its solution so an experienced user realizes what they can do at a glance; meanwhile, if a less experienced user need more help, they can expand the collapsible for a more detailed explanation. Even within the collapsible, prioritize putting actionable solutions first, before explaining how those solutions work. We're trying to fix bugs, not make people web developers.
Shoot 
radian628 or 
wackdog a DM if you have any questions or requests. While we're happy to answer any questions, also feel free to DM radian628 if you need any files uploaded to this page, since only I as the original page creator can do this.
