I'm still not fully back, but found myself with some bandwidth and idle CPU time. I'll get around to reading all the new articles and participating in the forum soon enough. (At least with my usual verbosity, it's believable that answering takes some time.)

Have we ever explained people how to create new pages? I'm afraid without that newbies might just be confused then.

Probably make a whole new page that is just various instances of these modules for items, tales and other stuff. as they can be configured to have certain tags by default (*intensely stares at ScaledDatura*).

Otherwise, I like it

Anyone got feedback on the new layout? Anything important missing?

Also, what animosities? Did I miss something? I thought I was just slowing down for a time in something that started to stress me (which is not what a hobby should do).

EDIT: There seems to have been one message of you I flat out had not read, opened so that it was no longer a new PM, but never read. So, I guess do not leave open letters lying around before going on extended leave? Also, I do not crack ciphers.

Also you underestimate my power, I ate Coruscant Nihilus style before crashing a ship into Mustafar ending the clone wars. So Vader never lost his body, Padme and Sidius were eaten and the galaxy fractured because suddenly all major powers of the clone wars lost their heads at the same time.

Also, sorry for putting a hat on your cosmic horror. I see game pieces, not hopes and story beets.

I also plan to finally finish my Ozor's Uniform Translation, so we have two FR translations; then I'll copy Yorick's ES ones (or rather cross-include them) and add ES and FR to the Projects and Series hub too. (Same goes for Sectors and Steel, probably.)

@Meta: Do you take it personally if Moving Shadows falls under "alternative formats/canons"? If not, I think this might be an agreeable resolution to the recent animosities.

EDIT: Fixed. Doing it with flexbox as is "best practice" didn't work, at least not without restructuring the entire mainpage, so I used absolute positioning which is "not recommended". I think there is something to learn about IT after my birth here.

I believe it's something to do with the way different character sets are being handled. Somehow, somewhere, the individual octets of an UTF-8 encoded string are interpreted as indivudual characters (mind you, this was done after I switched to my Windooze machine, so likely any 125X-charset) somewhere between writing, reading, piping, convertign piping and writing. What happened to the good old days of treating strings as a sequence of byte-sized characters terminated by a null? Oh, yeah, people to stupid to do bounds checking demonized them as "inherently insecure" and act all haughty for generating inferior assembly at exponentially increased compile times…

Anyway, rating modules: so far, the simpelst solution would be just to strip out the rating HTML directly; if it's inside my modified widget, we can also extract the additional info text.

I'm not sure whether can nor whether we should (Hah, take that Jurassic Park!) transfer ratings from WD to MW; assume we get most of our users over to MW, then what? Check who has already voted and prevent them from voting again, unless they are there to check their votes? I think keeping something like a "Legacy Votes" badge is a better solution.

Do we even want to keep the upvote/downvote system the same? I think merely allowing people to "favourite" a page (i.e. give it a thumbs-up, a +1, a star, etc.) is sufficient; if people have problems with it, they should write into the Discussion/Talk page with a call for rewrite/deletion if it's that bad, and otherwise criticism. A sole downvote never helped anyone improve their writing. (Also stops downvote brigading; a phenomenon we never had to deal with but must expect nonetheless.)

When we move to new wiki, let that be the opportunity to overhaul some of our processes.

From what I saw here maybe you need to add

<meta http-equiv="content-type" content="text/html; charset=UTF-8">

Wikidot has the full string as the one suggested by Stackoverflow (sour wine : line 52), while mediawiki does not. Maybe we should just find/replace that in the product.
after f.close():

MetaRep = open(dest, "r+") tempHold = str(MetaRep.read()) tempHold.replace("<meta charset="UTF-8">", "<meta http-equiv="content-type" content="text/html;charset=UTF-8"/>") MetaRep.truncate(0) MetaRep.write(tempHold) MetaRep.close()

…fiiiiiiiiiiiiiiiiiiine. Look at the repo; it's merely 17 lines but it should work quite reasonably. Demonstration — note that much of the uglyness stems from the absence of our CSS, put these side-by-side in your browser's reading mode (F9), and there's no difference.

Stuff I need to do:

• fully filter out all the rating module shennenigans
• Investigate why some, but not all, Unicode characters get corrupted
• Disable auto-ToC
• Test on more complex stuff (tabs, collapsibles, images)

I think this is a promising venue; I tinkered that stuff together in, like, 20 minutes, half of which were related to cross-platform issues caused by MICROS~1, so yeah, that's probably a plan.

That's great. It means that instead of crawling and converting the source of every page (which has been a pain in the proverbial each time, especially since WD decided to have semantically significant whitespace, but only in some contexts and not always…), we can just take the already crawled versions of our backups and convert those straigth away.

There is some minor stuff to be done, i.e. we probably need to trim everythign but the #main-content div, and examine how this works with collapsibles and other hijinx, but all in all, this off-the-shelf solution is vastly superior to what I have procrastinated on for 8 months now.

Still, as it transpired, I seized the chance to try my hand at that side-bar redesign that has been planned since… probably even preceding the Vaults, gee. If you want to try it, go to "Appearance & Behaviour" and then "Navigation elements" in the admin panel and replace nav:side with nav:side2.

I believe this is incomplete without the top-bar redesign as well, where we plan to put the seldom used "power user" stuff like CSS links, the Tag Guide, Recent Edits, etc.

Question: where to put the "New Page" Button? I think it'd be probably cool to have it up in the top bar, but only appear to logged-in users (doable) which are part of the wiki (probably not doable?) but I'm not sure if this thing isn't simply to fat.

Also, we might even consider some smaller redesign of the sidebar - I don't like unnecessary changes, but having there bullet points for no discernible reason wastes valuable screen estate (note how some pages don't have their full name linked there to prevent line wraps). Additionally, having small symbols for the other linked wikis would be cute.

EDIT: Also thanks for archiving the old stuff. I was not sure when I went looking for the page and could not find it.

For "wirtschaftlicher Geschäftsbetrieb", I found this page:

Unter dem wirtschaftlichen Geschäftsbetrieb einer gemeinnützigen Organisation versteht man jede selbstständige nachhaltige Tätigkeit, durch die Einnahmen oder andere wirtschaftliche Vorteile erzielt werden, die kein Zweckbetrieb sind und die über den Rahmen einer Vermögensverwaltung hinausgeht.

I don't think we'll have any income (besides "membership fees", which probably don't count?) until we actually start selling stuff (probably merch, since I think neither of us wants banner ads). If you check the (shockingly long) list of examples there, I don't think any applies to us.

Notaries are insultingly expensive and as far as I can tell not required? We can do that, but in this case it'll be your money (the same way I'll be paying for a sensible domain).

Usefull Links:

• Leitfaden Vereinsrecht by the Ministry of Justice
• various Muster forms by the Ministry of Justice.
• turns out the abbrevation is n. e. V.
• Some explanation on the liability of a n. e. V. by the Vereinswiki.info (no idea how reliable they are)

1. What is "wirtschaftlicher Geschäftsbetrieb" in practice (§14 just left me with the question of what is "nachhaltige Tätigkeit" and "wirtschaftliche Vorteile") and how do we avoid it?
2. We need to put down an upper liability limit into the Satzung

My comments about Gemeinnützigkeit also came from the article:
strg+f "Kann ein nicht eingetragener Verein gemeinnützig sein?"
It reads as if we just need to modify the Satzung a bit (I assume we get a proven Muster and just adjust it and then sent it to a Notar to get us on the right side of the law, before it goes as a mail to the responsible Finanzamt, which sends us back our certificate and than we need to send something every 3 years to keep it). If I read it correctly it would get us out of taxes (Freigrenze).

We're very certainly covered by §7 DDG, but I believe we still need to copy a suitable preprint disclaimer somewhere (think the standard privacy policies to comply with GDPR).

However, I'm afraid the n.V. can't be in the Imprint, due to having no juristic personhood. Alternatives would be checking in other EU countries, perhaps? Risky.

My main concern is my money and stable operations.

I don't think that taking care of our own physical server through a most likely non-commercial IP connections ("97% uptime guarantee" trololololol) is wise, nor cheap. Using literally the first search result, Ionos rents you a server for 7 USD a month — and as a wiki is basically just a database serving mostly static webpages, even their smallest option is going to be dreadfully bored (= opportunity to run other stuff).

Renting a server has multiple advantages:

• Reliable internet and power connectivity already included in the price -> Better Uptime than doing it privately
• Most providers offer automatic updates
• Most providers allow you to make backups much more thoroughly than we can: some external hard drive vs. RAID with incremental backups physically distanced by kilometers from the main server. And as we can still make local mirrors/wiki dumps, we're not losing on anything

Since we'd be simply using some FLOSS wiki software, there's not really a risk of vendor lock-in. Worst case scenario, we dump the database and go somewhere else. I believe that all other perceived disadvantages are of the "raving paranoiac detached from reality" flavour if we stick to a privacy friendly hosting provider. (Reminder: we are currently putting out faith into WikiDot.)

I'm the swabian here and even I don't get why you're so insistent on getting some foreign ccTLD instead of going for something reasonable like .org, .net or perhaps even .wiki (but please no cypriot domain hacks). If you really think a couple of euros are really worth using some non-standard TLD (which is probably going to cause reputation issues and/or make us seem illegitimate to users), I once again offer you to fully pay the difference out of my own pockets. Like, what if we one day get a dutch translation wiki?

Doesn't your sandbox with the vault boldly claim to use images incompatible with our license?

We pretty much are an art collective so we could qualify under §52 ab5. With the money going through this construct being:

• URL (.nl 12€/year)
• Internet Connection (do we run it over a privat connection? If not 30€/month)
• Hardware (150€ initial and ~20 € yearly maintenance)
• Power (?)
• Personnel (?)

The additional accounting might not be so bad. We can whittle it down further by renting a VM, but I think we can get our finances in order even with "Gemeinnütigkeit".

As long as we keep an eye on the sandbox (I do) and remove violating content (which we would do anyway, because of WikiDot's TOS), it's realistically not that different from how we're acting right now, and given that we'd operate from Germany, we'd probably have higher standards towards privacy and fReEdOm Of SpEeCh than from WD.

Gemeinnützigkeit is as far as I can tell a big hurdle with tight criteria to meet - a hobbyist association certainly won't meet it without offering plenty of other services (I'm thinking of Git hosting, privacy frontends, Tor relays, etc. which require attention and money) and I believe that by the time it's the fiscally responsible thing to do, we can and should already become an e.V. instead.

If we can subtract CI expenses from taxes we might not even be paying extra.

Through, oddly enough, the old Glitch City Laboratories, I discovered SMF, which apparently integrates well with MediaWiki.

Legal Entity

@Meta: I checked the options, and it appears that you can form a "nicht-eingetragenen Verein" which seem to be mostly what we need — minimum of 2 members, no need for in-person meetings or any fancy roles and reporting, merely an entry at the Finanzamt (which should be private, afaik). Liability wise, that entity is not rechtsfähig, though, i.e. all contracts/other stuff must be through one of us members. (I wonder how this interacts with the Impressumspflicht.)

For now this is not a problem since it has been only triggered by one person, most likely on accident, but yet another reason why we can't leave this godawful shithole soon enough for something that actually works.

Yes, I don't even bother the use euphemisms anymore.

Hold back the "servers with HDDs" thought for a moment.

I think your estimation of wiki size is fundamentally flawed: WD only calculates attached files. Stuff like page source, it's complete revision history and the forum do not count towards the limit. And if you take the main page, at ~4k characters and ~300 revisions, that's already about 1.2 MB for a single page. However, most of our available space isn't (meaningfully) used anyway.¹ My current Backup of this wiki is roughly 300 MB, and this includes an abhorrent amount of different wiki thumbnails (I was to lazy to exclude those) and duplicates of all the necessary (and unnecessary) JS for many pages.

Now, the interesting thing about that is that we could probably run the entire thing as a RAM server, using persistent storage only for backups.

However, having an own server and a domain would allow us to do some fancy other things. Like hosting our own matrix space, our own booru (you wanted that, if my memory doesn't fail me), our own git or even stuff like an own Invidious instance (which costs money, but then again, if the artemislena girls can afford it…)

Does anybody outside of Germany actually use Moodle?

I'm also in no position to host a stable server. And this also includes physical stability — if some of you could see some of my setup, you'd be accutely aware I live in an earthquake zone. (Thank goodness my dog is afraid of walking stairs too…)

You can run servers from hard drives just fine. It just depends on what load times you are willing to stomach.

I know people run servers of Raspberry Pis. A wiki that is not payed for is 300mb (like the Insurgency, 900 if we take the sandbox and image database into account). With our user numbers we might just run the whole thing on a 2GB Pi. I actually never tested how far these little buggers can go. I correct my stance. A server as you propose would be 5 100 Watt bulbs not one.

I am not currently in a position to just build a DMZ into my current network and just set up a Moodle on a Pi. Moodle was just the platform I worked on during my education and the one I know somewhat how to set it up.

As you said, in the end it is the problem of whom ever takes up the migration and I just can not be that person at the moment.

We have no search whatsoever (whenever I need to search something, I grep my local backup), no API access even for paying customers, and no customer support — last time there was a problem the only guy in charge of WikiDot had to be contacted over a microblogging service that's incredibly unstable itself.

As I mentioned, I could trivially bankroll the Wiki myself without prior notice; the problem is that I am in no position to actually host stuff myself. My ISP only gurantees me 97% uptime without even the chance of upgrading to a business plan, and there is no viable way to anonymously buy a domain name for me.

Plus, somebody would have to do all the boring behind-the-scenes managment (setting up the database on which the whole shebang runs, maintain the actual (sub)domain, get us fail2ban or something to prevent the background noise of script kiddie attacks, etc. And from my vantage point, you don't seem terribly suited in that regard (who just wanted to run a server with a Hard Drive?). Since Cad never shows up anyway, it would all just end up being my problem anyway. And I'm not planning to end up burned out after three weeks doing something I'm only moderately qualified to do.

You again make unfounded claims about computer science. A processor is basically equivalent to an electric heater of the same wattage. So it is an incandescent lightbulb, just not driven to the degree of incandescence (which is mostly a function of thermal mass here). A two-socket x86 servers with up to eight core chips will run at rest somewhere between 150 to 200 watts. At full utilization, this energy usage can double to as much as 400 watts. Clearly, we are discounting cooling here (as this setup would probably operate in somebody's basement, not a big server farm).

If you have a better alternative to Miraheze, come forwards with it. ShoutWiki is still a thing. But simply in order to not keep all our eggs in one worn and battered basket.

Wikis without financial backings are limited to 300mb and 1TB hard-drive sits at 40 euros new.
The large beasts like the foundation have paying membership everything else might just as well be pocket change.

Wikidot is probably 1, maybe 2 old servers that are probably not even rack-mounted. It is basically as close as you can get to passive income. A domain, internet and power is pretty much all you need and a server that is trimmed for storage and just basic applications might just run on less power than it would take to run an incandescence light bulb.

And, y'know, I'd actually enjoy having a platform I can financially support instead of an economic zombie like WikiDot that relies on long outdated ad platforms.

Not really a sign of worry, except … this would entail a move to the United States. What would that mean in regards to migration perspectives? I mean, the infrastructure would probably stay the same, but the jurisdiction changes. I don't believe there is any concern regarding our user's privacy (The UK is a 5EYES nation anyway, and unless you're really dumb your Wiki account won't contain anything besides a disposable addy and your public interaction on the public wiki.)

However, whilst the british web legislation has been continually slowly getting worse, moving to the US is much more explosive: depending on the individual states and depending on whether the US population will vote for an orange man child, we have the very real potential of suddenly ending up in a legal hellscape with laws that we simply could not comply with even if we would. So it's up to chance whether we'll end with better-than-british legislation or having to bow to some carrier who wants to track our periods.

Sadly, when it comes to free wikifarms, I couldn't find any on EU soil. A paid provider would still be possible, as is self-hosting, but I thought I better bring this up here and now.

It'd be advisable to set a couple of "colour groups" or whatever which our theme (and future themese, both an WD and MW) could simply alter, to support, for example, dark modes. Somethign like --insu-bg-colour and --insu-text-colour is obvious, but I wonder how much we need, and with how many we can get away from. E.g. we need a special colour for our quote blocks, but is it the same used for many buttons? There is definitely going to be a colour for links/interactables, but is it the same colour as we use for eye-catchers (h1) and accents (like in the rating module)?

Just something simple to mull over whilst I procrastinate.

These challenge levels are (hidden) tags I'll use to determine how easily a given page's source is parseable to wikitext. We'll ignore rating modules for now.

Challenge Level 0: Migration is trivial

For stuff (mostly tales) that only employ the most basic markup: bold, italics, headings, horizontal rules, [[[Internal links]]]]] or [*https://example.com hyperlinks]]]. (No underlining though.)

Challenge Level 1: Migration is doable

Stuff that includes everything from CL0 plus tables, blockquotes, footnotes and normal images.

Challenge Level 2: Migration may require check-up

CL1 and collapsibles, tabviews and coloured text. Also probably most stuff with basic [[div]]-based styling.

Challenge Level 3: Manual migration required

Everything that uses weird stuff that is easier transferred manually than considered in the python script

Challenge Level X: No migration planned/other

To indicate we saw a page even though we don't actually need to assign a CL.

I'll go ahead and apply some of these already, everybody else is invited to help according tot he rules above.

EDIT: Ugh, PoI files are gonna be fun…

• Have a nice day

And I remember uploading the latter image. It turns sinister suprisingly easy once you edit out the 5 in the maximum occupancy sign. What about the photographer? Why are there more chairs than 3? Y'know what? Why do you get to have all the fun with the dumb challanges? I'll try to cook something up until my birthday, that's it.

Ideas for a "more CI picture"?

I'm actually hyped for MW's template magic. I already found plenty of useful ones, like Template:Dialogue and it should be possible to do stuff like the Infoboxes and a couple of other frequently used formats (video transcripts, PoI Sheets, etc.) templated too. Not to mention simple in-line ones for stuff like showing the Rank symbols from the Personnel Designations page. Or Dynamically creating a set length of redacted text (see the failed, JS-dependent experiment in the Kernel).

Just, like, don't make me write an extension in PHP. I know I claimed I could easily work myself into the language, but that was before I learned that PHP is a programming language made by people who can't code for people who don't want too. Seriously, the fact that in PHP 0x0+ 2 is 2, but 0x0 +2 or 0x0+2 equal 4 should make you drop everything an run away very fast immediatly. Not just do I revoke my previous offer, I will also deny under oath to have ever made it.

Also, the Vault's lilac-apricot theme will be inevitable.

I still think that a simple find and replace could get us there, but I do not know the miraheze format, so I do not know how "ci-wiki scrape html" translates to it.

I will make a more recent backup once I stop getting DB200 errors every ~20 read-attempts. Usually they are fixed after a reload, but I do not think it would bother the scraper so a few pages might just get lost.

Well, hiding them with CSS is no problem, I'm afraid the massive spam of them in the CoR stems from me having used Headings for formatting, which tell MW that this is a new section. I'll go and ask their support, mayhaps we can do something about that. (Also note that WikiDot has an "Edit Section" thingy under +Options; it's just nobody used that.)

For now, the themes are just random default ones I tend to swap in whilst we have none. Take a look around Miraheze to find other wikis with designs we can base ours off of. Besdies the Gay Ravens there is the Land of Liberos Project which uses agreeable colouring. There is also the Cadence which is apprciate for their techy, yet clear design, the When They Cry Wiki which is well-laid out. Formerly, I've been already suggesting Halopedia, but honestly, outside of their main page, it's kind of attrocious?

Mind you, all these themes can, if properly implemented, be override through either a logged-in user's settings, or through an URL agrument (?useskin=) meaning everybody can run what they prefer; like a dark mode.

We could start with a stole theme and work from there, or we simply hire somebody to do it. I'm not opposed to spilling a few bucks to be some fledgling web designer's first portfolio entry, if we get a professional, maintainable and accessible theme in exchange.

A terribly hacky python script to transfer most things to MW syntax is probably possible, but will require manual post-processing on more extravagant articles (like EK); but tales and simpler Items should be fine.

However, said script would require a large chunk of WD-syntaxed Page sources to churn through… since WD offers no API access even to paying accounts anymore (is that even legal?) this means: time to web scrape. I'll probably run Selenium for that, but perhaps you too want to make a full backup of all the wiki's sources?

For something like the Unisnger, it's actually a mostly straightforward process (but we definitiely need a script for tables; doing this manually is maddening!) with the correct layout of images for both desktop and mobile being the main problem.

However, I am currently working on Elisabeth Kaitlyn, who relies much more on additional styling, which requires significantly more manual adjustment than my find+replace approach). Still, I believe to have shown once and for all that migration, at least in a read-only state, is totally possible.

Also check out Unsi in Minerva and Timeless (note that the former automatically un-collapses collapsibles).

I believe you are using a Samsung product then. Checking with Ctrl+Shift+M only those devices where generating three lines, all other had an ugly two (mayhaps I should use text-align: center; for both cases).

I asked the CSS gurus of SCP-INT if they have any ideas, so let's wait and see. The easiest way to make this thing tiling would be just using a transparent background image set to repeat vertically. But people who use images of text instead of text deserve to be court martialed, so…

I might consider adapting this for the CoR as well to check it for a longer passage of text.

Anyhow, if you don't want to wait for me, you can just go ahead, though I wouldn't run the whole wiki through the process before we got some basic acceptance testing done.

But if we were to do this, everything had to change, else there is no point in doing it.

Also, I hope that you can get some better connection soon. The tchibo way might be a radical new approach but it can not be sustainable. I wanted to make a "Get better (internet) soon" joke here, but it came out more demanding than a "get well/better soon". So now you get an explanation to a joke that did not work (as intended), instead of the joke itself.

Should I edit the older stuff with the div blocks? Should this only be a "from now on" thing?

(Yeah, I forgot I changed 'em to collapsibles. Lots of my old stuff contains sins I try to get away from, like using footnotes and those dumb login-interface thingies.) I see you already found a way to just use it for divs. (Yet I believe the collapsibles with a default display are actually functional without JS, except that you can't close them.)

I'll take a look at getting a working watermarked div running for the fly boy as a proof-of-concept. Probably doable today or tomorow, but right now I can even less stand to my word than usually (still relying on tchibo where Telekom failed me).

Sporal Contagion in particular was what made me think about this in the first place.

Everything that isn't a published article, be it something in the sandbox, a forum post or an administrative page is fair game imho. In the end, a properly-indexed page with table of contents might be the way to go for most of those (except my rather extensive replies, of course), but those probably aren't what people are coming for here.

Found this:

[[div style="background-color: #F7F7F7; margin:1em; border: 2px solid #5C5C5C; padding:1em;"]]
[div]

Might be usefull.

Collapsible and tabs are also used to differentiate between different clearance levels.

CI-Cases that use Collapsible and Tabs (more then others):
Sporal Contagion
Elisabeth Kaitlyn
Creative Cat
Shanalick
Sekhmet
Analiana Matos
He's Got The Whole World In His Hands
We Are Slaves Of Creatures We Cant See
Eternal Selach
Sadistic Statistics: The Infobox's Guide

Namely, that the main, fiction part of the wiki could probably do without them.

First of, let's consider their intended use: make a document easier to read and visually appealing by hiding extraneous information — only show the radiation pattern of the antenne I use, only show the economic details of the province I care for, etc. and neatly hide the rest.

I'd argue fiction does not need this — if information is superfluous, why are you putting it into the article in the first place? There are no "situational" passages here, simply bloat.

Besides this honestly abstract point, there are a couple of more practical ones:

• They require user interaction, making reading a much less passive experience
• They break many things, from accessibility software (Screen Readers Ali Express Hatsune Miku) to web crawlers
• They also require JavaScript — sure, WikiDot needs that in general, but once we're on MediaWiki, this would be the only thing which strictly needs it.
• It is easy to masquerade about anything that does JS javascript:void(); as a collapsible.
• They make it hard to gauge the overall length of an article.
• They change the feeling of "reading leaked secret documents" to "perusing the corporate intranet"

I have looked out our Arsenal so far (are there any tales with either?) and found that we could universally replace them with minimal changes. See for example the "individual sheet of paper"-styling I've been experimenting with. Give that a snazzy heading and perhaps a "water mark" (easily doable with CSS) and you acheive the same narrative effect as collapsibles are currently being used for, perhaps even more appealing.

So, to ask the question again: can we bring the wiki in a state in which people could easily print articles without having to worry about collapsible content?

It requires JS though, but unlike WD's approach, is actually fairly useable without (as in: I've used a wiki with it for quite some time before I realized it was technically broken due to uBlock origin) and thusly preferable.

Apparently they have taken a look at DokuWiki for wiki software and Flarum for a detached forum so far. I consider DW's Markdown-based syntax insufficient, but it is apparently easy to set-up, use and administrate. Flarum is a hard no-go due to being a non-integrated service (compared to MW extensions) and requiring JavaScript to do anything (sure, WD does too, but you get my gist).

Also, it appears that their domain ci-wiki.cn/ is under attack by malicious traffic — so far CloudFlare is keeping them safe (I guess it's just a sweeping assay for vulnerabilities and no targeted attack). Should we consider to self-host (compared to using wikifarms with their own anti-spam/Denial-of-Service measures) keeping that stuff in check should also be a thing to keep in mind. I'm by far no fan of CloudFlare, but they do deliver results. (Also, claiming live and on stage that "You underestimate how much money we have in the bank" gets them bonus badass points.)

I'll continue testing with my own local install — I believe I just broke its database due to being somewhat … zealous when clearing up "unused" memory. Another reason you shouldn't have me adminstrate anything on my own, else we'll end up like yugipedia.

My verdict: our wiki is small enough and without weird edge cases that we can afford migration. Attempting this with stuff like SCP-EN would be something not even a masochist would enjoy.

Now a breakdown:

Setup

Uargh. Setting this up was not fun, mostly because of PHP; the database was a breeze. I used the TinyPHP server for a local instance, and promptly ran into an issue with the International Components for Unicode which… didn't function, except they should have been included. Took my like an hour of fiddling with versions, downloading random binaries, etc. until I decided to screw it an compile them myself, which finally worked.

I refuse to ever be the sole person in charge of hosting the wiki should we decided to get a private server. But honestly, Miraheze (or in a pinch ShoutWiki) probably offers more than we could ever wish for, at less cost and effort.

Hypothetical Migration

I've taken a look at the Python Script to translate WD source into MW source and honestly… even I could do better

However, we need to do the whole thing mostly manually anyway, because WD isn't giving anyone API access anymore, meaning we have to manually copy'n'paste the page source and throw it into the script. Then we can also take the opportunity to check the input/output if there are any weird things that require special attention. As we don't have pages that rely on on dark magic (e.g. ListPages, heavy JS for interactivity, CSS animations, other things that really have no place in creative writing) that shouldn't be too much, and leaves the script to be relatively simple (formatting is almost primitive token replacement, most complex is probably parsing and re-assembling tables).

At less than 200 pages, this is something that can be done manually, especially when multiple people help. Get some 6+ hour supercut of some recorded lecture, sigh, and get working.

Collapsibles and and Tab Views

There are, however, two features of WikiDot which I believe can not be (directly) transferred over to MediaWiki: Collapsibles and and Tab Views, which MW doesn't feature
As these rely on JavaScript, and MediaWiki doesn't require JS to display correctly (huzzah!) they also can't be easily re-created using transclusion or something else. Sure, some extremely contrived CSS gizmo might also get the job done without JS, but at this point, I dare to ask the question: do articles really need these features? Like, these are meant to be documents that can be printed. And the way articles are structured, you're supposed to read all of them anyway, so the argument of "hiding away option content that might not interest everybody" falls away. I consider these an anti-pattern, and even though I used Collapsibles myself in the past (only twice) though, notice that they are mostly absent from our fiction anyway, barring outliers like Elizabeth Kaitlyn or Sporal Contagion which could be rewritten trivially whilst still preserving the author's vision. (Note that they both are rather old articles.)

Voting and Forum

MW does not have a voting functionality by default, nor does it have a forum (talk pages are such an affront we're just going to ignore them). However, there exist a multitude of extensions both for Voting and Forums which we can use. I haven't tried and compared them yet, but there are plenty to choose from. Jot this down as a TODO. I believe all the extensions for rating use a 3 to 5 star rating scale rather than the primitive Up-/Downvotes of yonder. I have basically no experience with PHP, but can probably adapt the number of stars to 2 and design the widget accordingly. (Just like CLU, I can only alter or delete.) The same thing technically also applies to bread crumb navigation, but we don't use that anyway.

Theme

Being made by reasonable people, there is not much opportunity for WD-like in-page styling with CSS. Instead, the whole wiki is styled by a theme. These are default, but can be changed either via URL arguments or for logged-in users in their user settings. (I.e. ?useskin=vector for Wikipedia if you want to revert the horrible change that was pressed against overwhelming contra votes on the world.) There currently exists no theme that suits our needs, but that can be changed; I consider halopedia's Nimbus theme as a good foundation so we don't have to start from scratch.

Features

• MW is perfectly useable without JavaScript
• MW is stable
• MW lacks the many many undocumented "surprise features" of WD
• MW can be hosted on independent servers that don't make us rely on some dubious polish company that won't let us use HTTPS
• MW syntax is widely known
• MW lets use pick from many useful extensions
• Letting users pick their own themes instead of hard-coded atrocities as became common here strikes a balance between individuality and accessibility

Conclusion

Eh, honestly forgot where I was going with this post, but, uh… MediaWiki is cool, and I think we should use it. But I'm above getting blinded by the shiny new functional thing and just rush for it like brain dead.

I'd recommend looking more into the extensions and what else is needed to copy our current wiki structure over (and perhaps identify flaws in the current one and try to make it better in the new wiki), and then start with a private wiki limited to the future admins who keep copying stuff over until it is up-to-date with the main wiki, where we will open it as read-only to the public and try to slowly phase it in (and the main wiki out) before opening it for contributions and, upon seeing that it works, beginning to sunset the WD site.

I'm not even trying to sugarcoat this; the whole process is probably going to take until somewhen in 2025. Better than jump-starting and then running out of steam whilst also getting caught up in technological debt and pitiful planning.

Second:
Is that what is going on? Author self-deletion was not a problem in the past, or was it and we just did not notice?

Yes, pages going missing is an issue, so if you want to start fresh, just tell staff before you pull the trigger. I do like to make backups of forum threads for later reference.

My deletion method worked in the past and I believe with us both here and Baronjoe also being rather active lately we have enough staff to make decisions.

I am OK with the changes in file-policy as I was also not aware that non-members had that right until recently.

1. Wikidot takes permanently dropping a page's records really badly, and a minor "exploit" is know to happen since quite a while when you repeatedly create and delete a page with the same name.
2. Staff would very much like to know what happens to stuff before it disappears for good.
3. You can no longer rm -rf your stuff on accident. More than half a century of usability testing was pretty clear that giving the power to irreversibly make stuff blink out of existence to randos isn't a good idea.

Authors who still wish to remove their works from the wiki just have to move the page to the deleted: category (Under "+ Options" in the toolbar below every page) and confirm in the page's associated thread that they intend for their work to be removed. We may enact a proper policy on how to handle deletions once there is enough staff around to former a proper consensus.

Plus, you now have to be a wiki member to upload files to categories outside of the default one. Why was that even enabled? At the other hand, non-staff may now rename attached files - everyone already had the rights to upload and delete so I really don't know what the U in CRUD had to be it's own checkbox, WikiDot.

EnderDragon101

So I'll file this one under "yet another reason to leave WikiDot ASAP".

EDIT: Began affecting our sandbox literally minutes after me posting this. The SCP branches are serving their CSS (mostly) through GitHub; I'll look into non-M$ options for us.

There have been no changes on our end (nor on INTL's end) that could have caused this, and the issue was global (as checked through VPNs and Tor nodes) and cross-browser (I used LibreWolf, Ungoogled Chromium and Tor Browser). The servings failed about 80% of the time, and the periods when it worked were time-correlated (i.e. there were brief windows when it would work everywhere, just to fall back to borked soon after).

I have diff checked the HTML servings from tabs where it worked vs those when it didn't and saw no relevant changes except a reordering of the <script> tags in the <head> element, though no changes in content. I tried resolving all the included URLs from the <style> tags end could load each of them manually.

I have absolutely no idea what caused this, but if I had to guess, it would be some problem with cloudfront (yet Amazon lists no problems in the relevant time frame).

If this returns, we might be able to work around it by simple including an [[moudle CSS]] with a copy of our theme in the nav elements, so it is loaded individually to each page. Not pretty, but it should work.