Forum:Technical problems on the new website

Forums: Index > Village Dump > Technical problems on the new website

Note: This topic has been unedited for 1741 days. It is considered archived - the discussion is over.

• These discussions began at Forum:Uncyclopedia's new home
• A subset of technical problems is discussed at Forum:Broken links/pages

---

Broken redirects (red-links)

In the News redirect

The link from the front page to the UnNews page has been fixed, although update method remain broken. Turned out to be an older form of the redirect command that doesn't work here. -- (talk) 07:04, 11 May 2019 (UTC)

There's nothing wrong with not having a colon -- User:Hymie le robot works. It was probably because something hadn't yet gotten the message about the UnNews namespace existing. Making an edit to a page like this would fix it due to flushing the old information. ❦ Llwy-ar-lawr • talk • contribs • 07:40 11 May 2019

Broken redirects list

There are about 400 entries now on the list which I believe to be historic. Checking a few of the links, they are properly redirected to pages other than that listed here. There is an error message after the last entry. Can the current list be safely purged? -- (talk) 07:04, 11 May 2019 (UTC)

Those are either just out of date or from before I configured the namespaces (so the "Babel:" redirects are supposedly pointing to nonexistent mainspace pages beginning with "Babel:" rather than pages in the Babel namespace). I think the list can be updated with mw:Manual:updateSpecialPages.php. I see the 'Fatal exception of type "Wikimedia\Assert\ParameterAssertionException"' error but have no idea what it's about. ❦ Llwy-ar-lawr • talk • contribs • 07:34 11 May 2019

I'm running mw:Manual:refreshLinks.php to fix the redirects. This seems to be slowing the site down. ❦ Llwy-ar-lawr • talk • contribs • 02:32 13 May 2019

As in the site notice, this got stopped because I accidentally closed the terminal window it was running in. However, Special:BrokenRedirects is mostly empty now, and unnews now redirects to UnNews:Main Page, so I think refreshLinks did its job. I've discovered there's an option to just do redirects, which I should have used. ❦ Llwy-ar-lawr • talk • contribs • 02:37 14 May 2019

Broken animated GIF thumbnails

I noticed there is a broken thumbnail for the bouncy Wikipedia gif we use to misdirect readers. Romartus/sig2

mw:Manual:Grabbers recommends running refreshImageMetadata.php to fix "display issues" with gif images. I tried running it but stopped it early when I realized it was actually deleting metadata. This affected about 205 files. The metadata must have been stripped out by Wikia, or this wouldn't have happened. I could retrieve the original database entries from the backup at home, but that wouldn't address the underlying problem.

Then I decided to try it on just one image, File:Bouncywikilogo.gif, to see if it was really the solution:

Processing next 1 row(s) starting with Bouncywikilogo.gif.

Finished refreshing file metadata for 1 files. 0 were refreshed, 1 were already up to date, and 0 refreshes were suspicious.

So supposedly it didn't do anything. Looking at the image confirmed this. What to do, then? I don't know. ❦ Llwy-ar-lawr • talk • contribs • 01:17 13 May 2019

Still no progress on this. It seems to be impossible to make thumbnails of any animated gif, as demonstrated when I uploaded a new version of Bouncywikilogo.gif at File:Bouncywikilogo 2.gif and an entirely new (Wikimedia Commons) image at File:Newtons cradle animation book 2.gif. No amount of refreshing the metadata will help. I've discovered that I can "fix" this by disallowing animation in the thumbnails (setting $wgMaxAnimatedGifArea to 0), but that's really not what we want. Bouncywikilogo.gif works properly on the backup wiki, so something must be wrong with the setup we have here. It's the same version of MediaWiki but different underlying software. The backup is on Ubuntu 18, PHP 7.2 and MySQL 5.7, while this is CentOS 7, PHP 7.3 and MariaDB 10.3. I know PHP 7.3 and MW 1.31 don't quite go together, as I get PHP complaining about undefined indexes and "continue" when I run maintenance scripts. It's possible a newer version would fix it, but that might not be enough. Probably better to downgrade PHP if it comes to that. I'd rather stay on LTS versions. ❦ Llwy-ar-lawr • talk • contribs • 22:42 16 May 2019

The problem was the wrong version of ImageMagick. Should be fixed now. Any remaining broken thumbnails are probably cached or out of date and will go away on their own. ❦ Llwy-ar-lawr • talk • contribs • 06:27 18 May 2019

Weird red links in Recent Changes (which point to existing articles)

Pay them no mind; they'll go away. (Eventually. (Probably. (Or so I'm told.))) They seem to have resulted from some funky namespace shuffling that took place during the last (and final) massive database import which was done in order to merge recent on-site changes with recent off-site changes. -- Snarglefoop (talk) 02:54, 13 May 2019 (UTC)

I saw this but do not anymore. Querying the recentchanges table shows that the namespaces and titles are correct, so I think we have to just wait. It's just a cosmetic issue in any case, since the links go to the right place. ❦ Llwy-ar-lawr • talk • contribs • 02:05 14 May 2019

Incompatible code and software

CreateBox

This is a feature which no longer works, because of the MediaWiki version dislocation. It needs to be replaced with InputBox everywhere. It affects random pages throughout the Wiki. (Work is proceeding on this.) -- Snarglefoop (talk) 21:50, 12 May 2019 (UTC)

The VFH page needs inputbox fixing. It seems to be in the page footer, and I can't get to that to change it. I've gone through all the projects and corrected; similarly for Pee Review and VFP. -- (talk) 21:22, 14 May 2019 (UTC)

What's this doing under DPL? They're unrelated. ❦ Llwy-ar-lawr • talk • contribs • 22:07 21 May 2019

If you have a better reorganization than mine, just do it. My only goal was to remove arcane technical issues from the Forum that would be the first one found by people wanting to understand how we wound up here. Spıke 🎙️01:32 22-May-19

I downloaded AutoWikiBrowser to my Windows laptop and started it up to replace any remaining createboxes. For some reason it's not adding "using AWB" to the edit summary, but if you see summaries with "removing createbox tag", that's what's going on. ❦ Llwy-ar-lawr • talk • contribs • 20:10 22 May 2019

I did the Uncyclopedia and Forum namespaces. It bogged the site down, ate over 1/4 of the laptop's CPU, and made its fan run loudly and continuously. Sounded like the wind. I think I won't be doing any more of that -- we're probably done anyway. Unfortunately I'll have to do another AWB job to fix the Wikia images, and that one will be a lot more intense. Hang on while I figure out how to write the regex. With luck we won't end up having 100 problems. ❦ Llwy-ar-lawr • talk • contribs • 22:56 22 May 2019

Dynamic page lists (DPL)

This is enough of a pain that it deserves its own section, if not its own page (or even its own wiki).

DPL is a MediaWiki extension which we depend on for a ton of stuff. There are three slightly incompatible versions of it, and they each work to different degrees with various versions of Mediawiki, and they all share a tendency to have remarkably incomplete documentation. Migrating off of Wikia necessarily entailed a rather massive jump in the versions of MediaWiki and (of course) DPL, which brought incompatibilities with existing code. DPL issues are currently causing trouble on the main page and, I suspect, on a number of other pages as well. Ongoing work to clean up issues with DPL should improve a number of things as issues are tracked down and fixed. (But DPL seems to be one of those recurring-nightmare sorts of things, so I'm sure it'll break again eventually, maybe with the next major release -- it's what you might call job security code for anyone maintaining a wiki.) -- Snarglefoop (talk) 21:09, 12 May 2019 (UTC)

Problems on VFP and VFH

I might know how to fix featured images related templates ({{FI}}, {{FI/class}}, and {{Votevfp}}) and VFP related pages, as I did that on the fork and apparently the issue here seems to be very similar (if not exactly the same). I could work on it myself if FI and other related pages are semi-protected until I'm done. If not, maybe my contributions to such pages on .co will be a good suggestion for the solution still.--The Pioneer (talk) 14:45, 18 May 2019 (UTC)

That is a complaint that needs to be resolved, and that I think is not high on anyone's list. A separate problem is that these templates were written to assume a daily rotation of features, which is far beyond our productivity at present. I recommend you either notify Llwy-ar-lawr of your suggested approach, or copy the source code into userspace and prove your solution. Spıke 🎙️14:57 18-May-19

I think some of what we've been seeing with the featured images can be blamed on DPL issues. (But then, I tend to blame everything on DPL issues.) -- Snarglefoop (talk) 16:04, 18 May 2019 (UTC)

IMO broken main page is an issue that should be fixed ASAP, because main page is the entrance page of the whole website; nobody would prefer a website with a broken main page, especially when the other one had it fixed.

So here's my solution to {{FI}} and {{FI/class}}.

1. User:The Pioneer/Template:FI
2. User:The Pioneer/Template:FI/class
3. User:The Pioneer/Main Page Preview - A preview of the main page using User:The Pioneer/Template:FI instead of the original Template:FI.

Generally speaking, includepage={Votevfp}.include or any other inclusion of a template of the target page using DPL will break the page when the classical signature with two hyphens (--~~~~) is included in the template part, and mode=userformat listseparators=,{{%PAGE%}},, should be used instead.--The Pioneer (talk) 17:05, 18 May 2019 (UTC)

Oh wow it works! Good to see someone who actually has a clue about DPL. I could have spent all day on this and gotten nowhere. What about Uncyclopedia:VFH and Uncyclopedia:VFH/summary, with the same problem? ❦ Llwy-ar-lawr • talk • contribs • 18:17 18 May 2019

I think the problem is essentially similar with that of VFP. I'll have a closer look (tomorrow, as it's 3:30 am JST) however, as I was never asked to fix dpl of VFH on the other wiki...--The Pioneer (talk) 18:28, 18 May 2019 (UTC)

I added your fix to {{FI/class}}. For some reason that makes it work even without modifying {{FI}}. We use a different DPL from the fork (DynamicPageList (third-party) vs. DynamicPageList3), so the right solution for them may not be for us. The page on DPL3 claims it's a drop-in replacement, but I have my doubts, as it doesn't seem to recognize suppresserrors while the other does. ❦ Llwy-ar-lawr • talk • contribs • 02:17 19 May 2019

I too grappled with the multiple versions of DPL and the poor documentation on TheMirror.miraheze.org and got something to work, which you can peruse if it would be any help. Spıke 🎙️02:28 19-May-19

{{FI}} may look like it works without modification because it transcludes {{FI/class}} at the rate of 80% (because of those <choose><option></option></choose> tags), meaning there's still 20% chance of failure if you continue purging it.

I had a quick look on VFH and it looks like you will also need to fix {{votevfh}} (to remove duplicated headers as I did on {{votevfp}}) and Uncyclopedia:VFP/Featured.--The Pioneer (talk) 05:25, 19 May 2019 (UTC)

Turns out the solution to Uncyclopedia:VFH/Featured was to use the values for the fornumber and againstnumber parameters directly instead of... whatever it was trying to do before. The other VFH problems seem to have solved themselves. I don't think any of my messing around with templates helped the issue. Unfortunately we may not be able to make use of code from The Mirror because it has yet another version of DPL, DynamicPageList (Wikimedia). ❦ Llwy-ar-lawr • talk • contribs • 22:34 1 June 2019

All that said, Uncyclopedia:VFP is still a mess. ❦ Llwy-ar-lawr • talk • contribs • 22:53 1 June 2019

I was going to say it's presentable on the front page, so that's a big step; much appreciated. Back to a mess today. One image, Tide Pods, has graduated from VFP in the last couple of years. Virtually no one does original shops here anymore and there are no voters besides. Run the archive images, but you can burn up VFP for all I care or for what anyone else seems to care.

As for the vote numbers, all the programming did before was calculate the net vote total. Voters had to manually advance the count in their vote category (for/against) as they do now.

Until the current mess of a page, FYI the image was cycling with every page refresh, like all of Did You Know. This happened sometime after moving to .ca. Both did not do this before, perhaps running on the same "timer" as Anniversaries; the main page header for the featured picture does read "Today's featured picture". Nonetheless, I do like both features changing with every refresh, and there is enough material to support that, so I would prefer that method. -- (talk) 00:21, 2 June 2019 (UTC)

I meant the Uncyclopedia:VFP page itself and its subpages, not what you see on the main page. The main page VFP section had already been fixed. I did a bunch of stuff to make the former work, which resulted in the latter displaying incorrectly again. I've now fixed this.

I believe "today's featured picture" was already randomly selected rather than static. {{FI}} and {{FI/class}} both use content inside <choose> tags to display the image and text. I didn't put that in. If the content were fully static and DPL-free, the main page would probably load faster. ❦ Llwy-ar-lawr • talk • contribs • 00:51 2 June 2019

Hall of Shame

It seems as though the entries in Uncyclopedia:Hall of Shame are sorted according to number of wins, but in string rather than numeric order, so that "9" is greater than "80.5". Don't know the fix, according to the extension/version we have adopted. Spıke 🎙️01:29 22-May-19

I noticed this too, and me neither. I got as far as finding out that there's an "ordercollation" parameter and the documentation doesn't list the possible values. Maybe the key is the SQL it translates to. ❦ Llwy-ar-lawr • talk • contribs • 01:51 22 May 2019

I think "ordercollation" was just to select the character set (ie: utf8mb-general, latin1-swedish-bork.bork.bork, whatever...) for sorting non-ASCII text at the database level; it didn't do anything useful beyond that, and looked to be buggy enough that it should be omitted. I don't think it could give a sort-numeric vs. sort-alphabetic option? carlb (talk) 05:09, 22 May 2019 (UTC)

That stinks. Any way to get it sorted correctly, short of ditching DPL and storing the entries directly on that page? ❦ Llwy-ar-lawr • talk • contribs • 00:24 26 May 2019

In the DPL manual at tablesortcol, I read: "Also note that the whole column contents is taken; this may include hidden contents or markup sequences if you used column formatting commands. For the same reason you cannot expect numeric contents to be sorted 'numerically' - sorting will always be alphabetical." So ditching DPL (or rethinking the format of the Hall of Shame) is indicated. Spıke 🎙️00:41 26-May-19

Well, jeez. I don't understand why this is the case, since it's allegedly the same version of DPL as Wikia -- "third-party" 2.3.0. Maybe it's actually different and the version number wasn't bumped. I think all we can do is change how Hall of Shame works. Transcluding the subpages might be best. ❦ Llwy-ar-lawr • talk • contribs • 02:04 2 June 2019

At Special:Permalink/6056510#Hall of Shame, you can see the result of a manual list of transcluded subpages. I've modified {{HoSuser}} so it can display as table cells when necessary. Is this a satisfactory solution? Doing it this way means that every new subpage created has to also be added to the main HoS page and every change in the number of features that would change the order has to come with a manual swapping of transclusions. It would also be good to reduce the protection level of that page. ❦ Llwy-ar-lawr • talk • contribs • 05:45 3 July 2019

Apparently this fixed itself. I don't know why it stopped working or why it started working again, but I went ahead and changed it to the non-DPL system anyway because it could break again with the next major software upheaval. This is also better for performance because the DPL had the parameter allowcachedresults=false. We should probably have instructions about transcluding new subpages. ❦ Llwy-ar-lawr • talk • contribs • 20:25 14 July 2019

Template:Featuredarticle/queue not showing revision numbers

It's supposed to have the code to put on the featured article, but it's showing %REVISION% instead of the revision ID. %STUFF% is meant to be interpreted by DPL and translated into various values, but it's not recognizing this one. ❦ Llwy-ar-lawr • talk • contribs • 00:24 26 May 2019

Also %DATE% on UnNews:Main Page. ❦ Llwy-ar-lawr • talk • contribs • 02:04 2 June 2019

I've fixed the latter by adding addeditdate=true to {{main historical}} and the former by using the magic word REVISIONID in {{lastrevision}} instead of DPL. This can take a specified page title as of 1.23. ❦ Llwy-ar-lawr • talk • contribs • 09:00 5 June 2019

Maintenance pages

The four maintenance tags organized by Uncyclopedia:Maintenance include some ancient pages. I think this is because the DPL is now pulling in pages from userspace. The point of Uncyclopedia:Maintenance is to help Admins enforce the time limit on slowly developing, short, and awful new pages, and if they're in userspace, this isn't a problem. Spıke 🎙️03:34 3-Jul-19

Uncyclopedia:VFH/summary

Did this just break? Spıke 🎙️11:54 3-Jul-19

External images don't work

I think this just needs to be enabled, but whatever, it currently isn't, and any direct links to images show up as text. -- Snarglefoop (talk) 21:33, 12 May 2019 (UTC)

External image links to Wikia are doomed

Even if the external image feature is enabled the images are still going to come crashing down when Wikia finally dumps their copy of the site (assuming they eventually do that). So, a bunch of images need to be dragged local or something to avoid that fate. -- Snarglefoop (talk) 21:33, 12 May 2019 (UTC)

The external-image MediaWiki extension I know defaults filenames in the File: or Image: space to pick up files in Wikimedia Commons. It would be damned peculiar if they homed to Wikia instead. But if they do, I concur that Wikia aren't going to maintain our photographs so we can pick at them from outside. Spike sockpuppet (talk) 23:28, 12 May 2019 (UTC)

This may also mean avatars, in many cases. Is there a list I can access to bring over whatever I can? -- (talk) 07:33, 13 May 2019 (UTC)

Not yet, AFAIK, but we clearly need one. We're still pulling a lot of important stuff, like the "Forum_torches3" image at the top of this page, from Wikia. Furthermore, something's configured to feed us webp images instead of pngs, which seems to be why the page logos (like the aforementioned forum torches image) are the wrong size -- the webp service is apparently ignoring scaling requests. -- Snarglefoop (talk) 15:23, 13 May 2019 (UTC)

That would be InstantCommons. Including images with direct external links is done with $wgAllowExternalImages, which is unrelated. Allowing external images is a tradeoff; not having them is less convenient and can break wiki pages with such images already there, but having them introduces various potential problems (described on that page). The "link rot" issue is one I've encountered on Illogicopedia. I've now enabled that setting, but that doesn't address the Wikia problem. It did fix VFP on the main page, probably because somebody's signature with a nonfunctional Wikia image was messing with the DPL code. The custom namespace logos have been replaced with relative paths, so they now point to the local images and display correctly. Someone will need to fix everything else. I might be able to do this with some sort of bot, if people are ok with me having a bot account (I'd flood recent changes otherwise). If we change hosts again, any new image URLs may also have to change because it's popular to put images on a different domain from the wiki. File links are preferable if possible.

Avatars are yet another issue. I know of no way to automatically import them, and there's not even any avatar functionality here, though there's an extension for it. This is not information we're about to lose, however, because Wikia avatars are Wikia-wide. ❦ Llwy-ar-lawr • talk • contribs • 03:05 14 May 2019

I can live without an avatar. A user page can still be decorated. -- (talk) 04:26, 14 May 2019 (UTC)

Main page breakage

Lot of little things.

The site notice showing up broken all over the place

This hit the main page as well as a number of other pages. The Fandoom Towers and Wikia staff meeting were invading article space, presumably because there wasn't enough text in the notice to extend below them. I threw a <br clear="all"> into it which fixed the immediate problem, but seems to have added a little too much vertical whitespace -- some other fix might look better. -- Snarglefoop (talk) 21:33, 12 May 2019 (UTC)

Warning: No results

This is DPL breakage. See that section of the Ongoing Rant, up above. -- Snarglefoop (talk) 21:33, 12 May 2019 (UTC)

I've been seeing a lot of that in places like fr: - if DPL is using a category as input, the output is "no results" until a maintenance script is used to rebuild categories and refresh links? carlb (talk) 22:37, 15 May 2019 (UTC)

{{featuredarticle}} calls for transclusions of {{FA}}. There is now a featured article showing on the main page, so if an empty table was the problem, it must have filled up. Running refreshLinks.php on the 13th could have done that. When fixing MediaWiki:Anonnotice I found out that the empty featured article section was still present for anonymous users because the main page's entry in the file cache was out of date. I fixed it by deleting the file. It might be better to turn off the file cache. ❦ Llwy-ar-lawr • talk • contribs • 18:15 19 May 2019

Math stuff in Did You Know

The math extension works in general (or so I'm told) but we're still seeing raw tex code blatting out in the Did You Know list from time to time. Maybe some issue with DPL? (Blame everything on DPL, it deserves it.) -- Snarglefoop (talk) 21:33, 12 May 2019 (UTC)

There are three choices in My preferences, including having MediaWiki prepare an image file with the math symbols, for browsers that support no other ways to create them. So my first guess is that you have your My preferences set to something incompatible with your browser. Math and DPL are separate extensions that attack different parts of a page, and both parts use tags that invoke that extension. So, while anything's possible, I don't suspect DPL. Spike sockpuppet (talk) 23:32, 12 May 2019 (UTC)

This might be a good place to mention that, in Special:RecentChanges, as well as the introduction appearing twice, there is a bit of HTML (the link that states the starting time of the report) that (studing the page HTML) is set to display as HTML and to not take effect as HTML. Spike sockpuppet (talk) 23:34, 12 May 2019 (UTC)

Two MediaWiki version incompatibilities. Now fixed. ❦ Llwy-ar-lawr • talk • contribs • 01:32 13 May 2019

More specifically, the first is because MediaWiki:Recentchangestext became MediaWiki:Recentchanges-summary at some point. I wish they wouldn't change message names like this; it makes it a lot harder to maintain customizations. This is also why I moved MediaWiki:Unblocklogentry to MediaWiki:Logentry-block-unblock, and it's why we lost "huffed" and "hacked up" for deletion logs many years ago. (The messages for deletion and restoration are now at MediaWiki:Logentry-delete-delete and MediaWiki:Logentry-delete-restore, if anyone's curious.) ❦ Llwy-ar-lawr • talk • contribs • 05:06 13 May 2019

And there may be problems with imported Wikia preferences. After the aforementioned fixes, I alone was still seeing broken Math output. My prefs looked fine, but my math mode problems only (finally) vanished when I changed my math display preference, saved it, changed it back, and saved it again. Seems like somewhere, under the covers, a field in my profile was set wrong, and it wasn't visible on the preferences page. -- Snarglefoop (talk) 03:14, 13 May 2019 (UTC)

The default math output mode for Wikia is MathJax, which is no longer supported as of MediaWiki 1.26. The only mode I've enabled here is MathML. For some reason you can select other ones, but they probably won't work. This might be it, but it doesn't explain why you had the problem and I never did, since our preferences came from the same place. ❦ Llwy-ar-lawr • talk • contribs • 05:06 13 May 2019

I was seeing this problem early on, but the math entries have come up several times in DYK in the last few days and were rendered correctly (for me, at least). -- (talk) 01:42, 26 May 2019 (UTC)

Featured articles are broken

This is a whizzy automatic gadget which fetches the featured article and puts it on the main page.

Unfortunately it doesn't seem to be working, and the result looks pretty dumb.

Given the slow rate of FA turnover, one possible fix would be to switch to posting the FA manually. It might result in it getting broken sometimes when the human who was supposed to do it forgot or fat-fingered it, but that would still be an improvement on it being broken all the time because the stupid template which is supposed to keep it up to date doesn't work. -- Snarglefoop (talk) 21:33, 12 May 2019 (UTC)

That is a reasonable outcome, as the whizzy gadget implemented automatic rollover of FA each midnight, which assumed a rate of FAs that nowdays is laughable. Spike sockpuppet (talk) 00:42, 13 May 2019 (UTC)

Yes, I've thought we should do this for some time for that reason. OTOH the main page is showing "Yesterday's Featured Article" now. I didn't touch any of that stuff, so something must have just left the cache. "Featured today, a long long time ago" remains stubbornly empty. ❦ Llwy-ar-lawr • talk • contribs • 02:06 13 May 2019

Probably because, these days, there is usually no article written exactly {Random|1..3} years ago. There is a similar feature on the UnNews Front Page. Spike sockpuppet (talk) 02:33, 13 May 2019 (UTC)

Dismissable site notice

We have it now. I guess you'll have to start incrementing MediaWiki:Sitenotice id again. ❦ Llwy-ar-lawr • talk • contribs • 22:45 13 May 2019

Not a problem, but I see no "[Dismiss]" link, and have gone back a couple years in the history and don't see how we used to make the site notice dismissable. I presume the template triggers something in Common.js Spıke 🎙️22:58 13-May-19

I see the dismiss button. Probably have to refresh browser or sign out and back in. However, the addition has squeezed horizontally the site notice. You'll have to decide which to alter, the site notice template or the header. -- (talk) 23:05, 13 May 2019 (UTC)

I see the squeezing, don't know why it's happening, as it isn't squeezed when you call up Sitenotice to look at it, and didn't used to be squeezed until you changed a photo to another photo of the same width. Regarding the dismiss button, this PC makes several websites believe JavaScript is off, and cookies are off, when they are on. Spıke 🎙️23:20 13-May-19

OK, Mozilla Object Inspector says load.php is calling for 20% off the right side of the banner (presumably for the dismiss button), also 5 em spaces off the left, which is about what I'm seeing. Spıke 🎙️23:31 13-May-19

By the way this is being used now (by everyone except me, apparently), this is immensely useful. However, if a user dismisses the notice, is there something/ some way to display a new notice for them? I see a fair number of regular users staying signed in forever; dismiss and the notice is gone forever(?). I see where there is a toggle of sorts with a "restore" button, but that's a little too easy to ignore. -- (talk) 04:36, 14 May 2019 (UTC)

If you have a new site notice, edit MediaWiki:Sitenotice_id (just increment the number), then the next time a page is rendered, they'll see the new notice. Spıke 🎙️09:46 14-May-19

Got it, thanks. Finally rejiggered the formatting of the site notice to get something decent. Lost the bullet in the process. If you play with your screen width, this now adjusts itself properly better. Wordwrap still works so text will flow differently around different height images. -- (talk) 11:01, 14 May 2019 (UTC)

EDIT:WTF. The link remains live for a time and changes itself into a (plain) line in bold. Think I got it fixed by advancing the ID number. -- (talk) 11:39, 14 May 2019 (UTC)

Site notice appears differently for me above Special:RecentChanges (the link is gone) than elsewhere. Spıke 🎙️12:29 14-May-19

So, I advanced the ID counter and the link returned for a time. Now the link is gone again. -- (talk) 21:16, 14 May 2019 (UTC)

And I think I now see how this works. We have to advance the ID counter after a new notice. Then the link is somehow timed to change to text, in about half an hour perhaps. Refresh a page left open for that long and the link returns. -- (talk) 23:17, 14 May 2019 (UTC)

That is a damn sight more complicated than how I imagined it, and less preferable: A Sitenotice should be armed by increment of the Sitenotice_id, and each Uncyclopedian should then see it, forever, until they dismiss it. If you are talking about the link to this Forum, as I was originally, that is part of the contents of Sitenotice, determined by its editor, and there is no excuse for software to modify it, ever. Spıke 🎙️23:47 14-May-19

(edit conflict) I've been seeing the non-link pop up on different pages seemingly at random. Vivaldi's developer tools show that it has the "selflink" class for links to a page on that same page, so something thinks the site notice is being viewed on "Forum:Uncyclopedia's new home" when it isn't. Maybe a cache problem. I don't know why the [dismiss] link needs so much space or why there's space being taken from the left as well. Could probably be changed with CSS if wanted. ❦ Llwy-ar-lawr • talk • contribs • 23:48 14 May 2019

I too have seen it rendered in bold, as though it were a selflink, and this is baffling too. The {{Sitenotice}} template writes HTML in which the elements have classes; removeSitenoticeDismiss() in MediaWiki:Common.js dismisses it, but it must be built into MediaWiki that it doesn't render in the first place if your Sitenotice_id already matches the current one. Spıke 🎙️00:00 15-May-19

Another annoying thing is that the site notice seems to rely on JavaScript to display, so if you don't have it dismissed, every time you load a page it pops up after the page load and pushes the content down. This extension has issues. ❦ Llwy-ar-lawr • talk • contribs • 23:22 16 May 2019

Enabling of optional features

User CSS and JS

Anyone? I see no evidence that anything in my common.js is being executed. Also, the Firefox Web Console warns that a variety of wg variables are deprecated since the last time I was on, and that addOnloadHook is not defined in ext.gadget.RealtimeRC. I recognize addOnloadHook as the function that lets you name a user routine to take effect when the page is loaded (but not yet rendered) to avoid visible glitches. Our sitewide MediaWiki:Common.js used jQuery, a toolbox from Yahoo, and a toolbox from Google; the various cooks who worked on this soup used the tools they were most familiar with. Presumably not all the toolboxes are enabled on the new website. (It would be better for performance if they were not and everyone used the same toolbox; I nominate jQuery, the TinkerToy of the Internet.) Spıke 🎙️01:38 14-May-19

I noticed that my CSS and JS pages weren't working either. I've just discovered that user CSS and JS are both disabled by default because of "security", so I turned them on. Some stuff is no longer available in 1.31, though, including addOnloadHook. This page covers at least some of that. ❦ Llwy-ar-lawr • talk • contribs • 01:57 14 May 2019

Yup, some stuff is now taking effect. jQuery has its own addOnloadHook equivalent:

 $(document).ready( yourFunctionName );

You can see in MediaWiki:Common.js that, after each definition of a useful function, there is a Hook to be sure the function is actually called after the page is loaded. Spıke 🎙️02:09 14-May-19

The signature button

Still unable to sign any pages here. I don't see that as an option on any pages. Romartus/sig

Hmm... I thought the lack of signature button was due to installing WikiEditor, but I've uninstalled it and it's still not there. Bother. I guess it's not a default part of the toolbar and will have to be specifically added somewhere. ❦ Llwy-ar-lawr • talk • contribs • 13:06 14 May 2019

There should now be a signature button on forum and project pages as well as talk pages (it was this setting). It looks like this: I'm still uncertain of the merits of WikiEditor, but at least you can disable it in your preferences (here, "Enable enhanced editing toolbar"). ❦ Llwy-ar-lawr • talk • contribs • 14:09 14 May 2019

Testing...--RomArtus*Imperator ITRA (Orate) ® 18:27, 14 May 2019 (UTC)

Parser functions enabled

My signature is screwed up! Trying Snarglefoop's "Edit preferences twice" tip didn't do it. Do I recall that, on Miraheze, #sub required a MediaWiki extension, which perhaps is not yet installed here either? Spıke 🎙️22:50 13-May-19

I had to set the ParserFunctions variable $wgPFEnableStringFunctions to true. #sub should be here now. ❦ Llwy-ar-lawr • talk • contribs • 23:10 13 May 2019

mw:Extension:SyntaxHighlight doesn't work

It's installed, but it doesn't do anything except put pages in Category:Pages with syntax highlighting errors. Here's the first example from the extension page:

1def quickSort(arr):
2	less = []
3	pivotList = []
4	more = []
5	if len(arr) <= 1:
6		return arr
7	else:
8		pass

It says it needs Python 3. I installed it, but that didn't help. I guess they're not talking to each other yet. ❦ Llwy-ar-lawr • talk • contribs • 15:47 17 May 2019

Fixed. Needed a symbolic link in /usr/bin because the instructions I followed put Python 3 in some obscure directory that couldn't be seen by PHP, Apache or whoever. ❦ Llwy-ar-lawr • talk • contribs • 22:00 17 May 2019

Ooh! JavaScript files now in color! Unfortunately, still doesn't show me where I'm screwing up Spıke 🎙️23:20 17-May-19

Gadgets

Remove the Wikia spotlight ads from the bottoms of pages.

I presume we won't be needing this (from Special:Gadgets and an option in My preferences)? Spıke 🎙️16:50 14-May-19

I'd presume the Wikia spotlight (and that ugly reskin last year) are violating the CC-BY-NC-SA licence by operating the wiki primarily with the objective of making a profit by driving traffic to pages laden with paid display advertising elsewhere on Wikia. For legal reasons, we shouldn't try to reproduce that mess? carlb (talk) 16:56, 14 May 2019 (UTC)

And one only runs cross-promotions while one has nothing revenue-producing to run. I don't believe we are in this business; but I was asking not to reproduce it but to rip out this vestige. Spıke 🎙️17:12 14-May-19

OK, this gadget is deleted, and is no longer shown in Preferences. But I see a vestige of it on Special:Gadgets. Spıke 🎙️02:11 18-May-19

I don't. Is it still there? ❦ Llwy-ar-lawr • talk • contribs • 02:51 22 May 2019

I don't either, now. D'ja reboot? Spıke 🎙️02:55 22-May-19

No, didn't reboot anything. Something must have been stuck in the cache. Whatever it was, I didn't deliberately flush it. ❦ Llwy-ar-lawr • talk • contribs • 03:57 22 May 2019

Category addition to articles

Is there a plan or existing tool for adding categories to articles? I know someone was playing with HotCat a while back. The tried and true old method works but the version available back on wikia spoiled us. -- (talk) 22:19, 15 May 2019 (UTC)

The old HotCat broke. Llwy changed this to point to the one at Wikipedia. I don't know if her experiment bore fruit. Spıke 🎙️22:25 15-May-19

I had created a special version of HotCat that worked on Wikia. The previous code was too outdated to work with 1.19 and didn't recognize the category bar on mainspace pages because of Wikia's CategorySelect extension. This is discussed at MediaWiki talk:Gadget-HotCat.js and Help:Gadget-HotCat. After we came here I replaced the page with an import of the current Wikimedia Commons code, which is for 1.27+. I tested it on my sandbox, and it seems to work. ❦ Llwy-ar-lawr • talk • contribs • 22:40 15 May 2019

Everyone be aware that there are articles added sometime in FANDOM end times where Categories exist in an article but do not report to the edit page. Recall we had two more ways of adding categories at that time. In a few cases, the Category tag is in a weird place like a header.

Add a new category manually and it's no problem. Just don't ignore existing categories listed and try to add duplicates. -- (talk) 00:31, 2 June 2019 (UTC)

Interwiki links

I see that Special:Interwiki is still a mess of outdated links, many of which point to Wikia, and only bureaucrats here have access to fix this mess? carlb (talk) 16:14, 15 May 2019 (UTC)

1. Interwikis are a nice way to avoid hard-coding the address of a website that is apt to move.
2. In view of Wikia's long history pestering and then snuffing out this project, we don't indeed owe them any favors such as direct links to other wikis in the Wikia Teen Shopping Club.
3. Editorially, I am still convinced that most cases where an editor includes a link to an external website are not humor, nor especially original humor, but a need to send his reader elsewhere for "evidence" to prove his point, when we would rather the reader stay right here.
4. I am a bureaucrat and can see Special:Interwiki but it is not clear how to edit it.
5. None of the above aesthetics argues for making global changes that would break a large number of articles. (Do we know how many, in any case?) The assertion that a given interwiki link is a Link to Nowhere does argue for removing the interwiki; creating a red-link is the right thing to do rather than send the reader to a date with a 404. Spıke 🎙️16:47 15-May-19

Well said. As to who should have access to fix them (or mess them up further), there are as yet unresolved questions as to who should be allowed to edit that stuff (crats only, as it is now, or should there be an additional group?), and if anyone additional should be made a bureaucrat and stuff like that. -- Snarglefoop (talk) 16:55, 15 May 2019 (UTC)

Anyone can see Special:Interwiki but not all can edit it. Wikis on my server have these settings:

wfLoadExtension( 'Interwiki' );

$wgGroupPermissions['sysop']['interwiki'] = true;

Here (and on .co) the default seems to be that only bureaucrats have the ability to fix obvious errors, like fr: pointing to desencyclopedie.wikia.com (which is defunct) when it needs to point to https://desencyclopedie.org/wiki/$1 - and this much shouldn't be controversial. Not sure how fixing this would "break a large number of articles"? There are ways to determine which pages are using interwiki links (it might've been a special page or API call, although the last time I looked at this was the Wikitravel/Wikivoyage split of 2012-13) but those should only be needed if we were to delete a dead prefix entirely instead of merely updating or correcting it. carlb (talk) 17:14, 15 May 2019 (UTC)

Things like the fr: change would not indeed break articles (see the remainder of my #5 above) and should be done. But I don't know how. Spıke 🎙️17:20 15-May-19

I'm told I was confused, and it's not the case that only bureaucrats could edit the Interwiki links. In fact nobody could, except for someone going in through the back door directly into the database (which is neither convenient nor safe and besides it's wrong). But that's all changed now -- as of a few minutes ago, any admin can edit them. (Careful with that axe, Eugene, it's sharp.) -- Snarglefoop (talk) 18:32, 15 May 2019 (UTC)

Yes, by default interwiki is assigned to no group. I wasn't sure if it should be given to all admins or just bureaucrats. On Wikia it's restricted to Wikia staff and volunteers, so there's no "obvious" thing to do here. For now I've given interwiki to all admins. All I'm sure of is that it shouldn't be limited to me, which it effectively is if it's not assigned. Anyone with database access can edit interwikis with queries like update interwiki set iw_url = 'http://example.com/wiki/$1' where iw_prefix = 'foo';, but I don't want to do this because it's harder, it's more error-prone (suppose you mistype the query and set every interwiki to example.com), and it's less transparent due to not leaving a log entry.

Since I now have on-wiki access, I've updated every interwiki that points to a nonfunctional domain, including uncyclopedia.ro which redirects to a porn site. I have not changed anything else. What about:

• be-x-old: and da:? These point to Wikia wikis that are still open but have Carlb-hosted counterparts. I'm unsure if they will remain open or which version is where "the community" is. Both of the Paudurapedyja (be) wikis are inactive, but both of the Spademanns (da) wikis are active.
• wikis that exist but are not on our list? These can be seen at meta:Special:Interwiki. A notable one is Celwyddoniadur (cy:), which was originally present but was removed by Wikia staff back in '13 or so because I did some stupid/inadvisable things with cy: links and they didn't know how to handle it. I believe there were also complaints about me being "in charge" there and hostile to uncyclopedia.wikia.com. I think these are all non-issues now, but I'd like input before readding it. (I changed the en: prefix on cy: to uncyclopedia.wikia.com twice in the past. It probably has en: and en-gb: now, which I can live with.) It's also inactive, so there may not be much benefit to anyone in linking to it, but that could change in the future.
• interwikis that point to "Babel" pages on uncyclopedia.org and uncyclopedia.wikia.com? These not only go nowhere but don't correspond to existing wikis, except for simple: which should go to simple.uncyclopedia.info.
• ru:, which moved to independent hosting years ago but left behind a Wikia wiki that continued to be used? I have pointed this to absurdopedia.wiki because the community that was most recently at absurdopedia.wikia.com moved there. Do we want to link to absurdopedia.net as well or instead?

❦ Llwy-ar-lawr • talk • contribs • 19:05 15 May 2019

There will be no need to point to any Evil HQ/Fandoom/GamePeddler hosted websites. --RomArtus*Imperator ITRA (Orate) ® 21:03, 15 May 2019 (UTC)

I'd been using olb: (Olbanian — "Олбанский") to link to ru-spoon, but that would require the code exist in $wgExtraLanguageNames, something like:

$wgExtraLanguageNames = array(
    'ain' => 'アイヌ',
    'ryu' => '沖縄',
    'cmn' => '正體中文',
    'dlm' => 'Dalmacija',
    'kp' => 'Kamel',
    'rus' => 'Россия',
    'olb' => 'Олбанский',
    'tlh' => 'tlhIngan Hol',
/*  'yue' => '香港語', */
    'zh' => '汉语',
    'zh-classical' => '文言',
    'zh-cn' => '汉语',
    'zh-hans' => '汉语',
    'zh-hant' => '正體中文',
    'zh-hk' => '香港語',
    'zh-mo' => '中文(澳門)',
    'zh-my' => '华语(马来西亚)',
    'zh-sg' => '华语(新加坡)',
    'zh-tw' => '正體中文',
    'zh-yue' => '香港語');

The only other obvious fork/spoon pairs are Japan (which was asking for ryu: for the Miraheze fork, as I host the original - which is the more active of the pair - I don't link to ryu:) and Poland (where I was linking to just the spoon https://nonsa.pl/wiki/$1 as the Miraheze fork looks to be just one or two users and nothing worth preserving). I've only linked both for en:/en-gb: and ru:/olb: (meta:Forum:Reorganization of the whole Uncycs#Russian Uncyclopedia) instead of trying to link every fork of something where the main project is elsewhere. carlb (talk) 21:58, 15 May 2019 (UTC)

edit preview?

Why is "show preview" showing me nothing when I'm editing? carlb (talk) 22:34, 15 May 2019 (UTC)

Yeah, noticed this intermittently on the Forum only. Preview worked okay for this post. -- (talk) 23:34, 15 May 2019 (UTC)

Smells like it might be some kind of caching problem. Is there anything identifiable about when it does it? (New pages only, full page edits only, edits to Alden Loveshade's template only, whatever.) I suspect the answer's going to be "no" but I figured it was worth asking. (I mean, TBH I have no idea what could be doing this, but we need to start somewhere to try to track it down (unless it just goes away on its own, hah).) -- Snarglefoop (talk) 00:21, 16 May 2019 (UTC)

For me, it was after replying to something already on the "Uncyclopedia's new home" thread (unknown what that was). Preview worked fine this time, too.-- (talk) 06:37, 16 May 2019 (UTC)

For me (Firefox, Ubuntu) it doesn't work at all, unless I log out and edit as either an anon-IP or a sockpuppet. Unfortunately, I don't really want to have to legally change a name I've had since the 1960's. carlb (talk) 14:39, 16 May 2019 (UTC)

Either the world is out to get you-and-no-one-else, or it's something in your personal CSS/JS. Recall Llwy said she recently enabled that. Spıke 🎙️15:09 16-May-19

I guess the paranoids are out to get me. It's an international conspiracy, probably hatched in the back rooms of Haskell's Library. The only user-JS I had was user:carlb/uncyclopedia.js and deleting that (even if I go to another browser) doesn't help. carlb (talk) 15:24, 16 May 2019 (UTC)

This is Firefox 66.0.2 on Ubuntu 18.04. Preview works for me on this page and User:Llwy-ar-lawr/sandbox. I don't know what it is. Something in your preferences? A broken JS gadget? ❦ Llwy-ar-lawr • talk • contribs • 18:52 16 May 2019

Please note -- Nigel says he saw this too. Therefore, unless he's got something in his personal JS or preferences which is just like whatever it is CarlB has that's tickling this, it almost has to be a configuration problem or bug in the site JS or something else global. If it doesn't show up for anyone else in the future we may never manage to track it down, but it still seems likely that it's something on the site that's at fault. -- Snarglefoop (talk) 19:47, 16 May 2019 (UTC)

Is this something that no one else can see? It looks to be in the preferences, Editing -> Preview -> Show preview before edit box. Unless that option is checked, the "Show preview" button is broken entirely. Weird. carlb (talk) 20:11, 16 May 2019 (UTC)

If it's unchecked, the preview is supposed to be underneath the edit box. I tried it and saw that. Is it not anywhere? ❦ Llwy-ar-lawr • talk • contribs • 21:31 16 May 2019

It's not so much "underneath the edit box" as buried waaaayyyy down, past the Creative Commies, past the "templates used in this preview", past the "parser profiling data", past everything so no one will see it. carlb (talk) 01:15, 17 May 2019 (UTC)

We can consider this resolved, since it may be a stupid setting but I didn't invent it. Seemed like a good idea at the time to some MediaWiki developer. I notice the copyright text appears twice; this should be dealt with. I'd still like to know what the problem for Nigel was, if it wasn't the same. ❦ Llwy-ar-lawr • talk • contribs • 02:11 2 June 2019

Solved Help with User:Spike/watchgadget-v3.js

A version of this script, which adds a button to unwatch watched pages in Special:RecentChanges and Special:Watchlist, worked fine in the old Uncyclopedia, but I don't know JavaScript beyond imitation and have no documentation on the new mw.Api.unwatch. If someone would take a look at this, I will make it available generally as a Gadget. You are welcome to edit it in my userspace. Spıke 🎙️12:55 16-May-19

The cosmetic stuff is now sorted. The only bug left is that pressing the buttons doesn't unwatch/rewatch. (That is, it now looks pretty but "merely" doesn't function.) Actually, there's one other bug, having the image files not point to Wikia. Here, too, others are more likely to know the answer than I am to ever figure it out. Spıke 🎙️00:53 17-May-19

I don't know enough to help you make it work, but I fixed the images. ❦ Llwy-ar-lawr • talk • contribs • 02:12 17 May 2019

So you did, thanks! Now, if only the unwatch/rewatch buttons actually did so! Spıke 🎙️02:34 17-May-19

Problem solved; had to load some packages with mw.loader(). Spıke 🎙️01:34 18-May-19

Issue Overload

With a purposeful grimace and a terrible sound
He pulls the spitting high-tension wires down
Bugzilla!

History shows again and again
How nature points out the folly of man
Bugzilla!

Oh, no, they say he's got to go
Go, go, Bugzilla (yeah!)

Anybody else getting the feeling we need a real bug tracking system? -- Snarglefoop (talk) 23:31, 16 May 2019 (UTC)

Some sort of triage would be nice. It's hard to know what to tackle first. ❦ Llwy-ar-lawr • talk • contribs • 23:36 16 May 2019

Potentially, yes. Right now, we are in birthing pains, everyone focused on that final push, and more formality wouldn't necessarily help. Spıke 🎙️00:54 17-May-19

Has the "Report a problem" been used in recent times? I can't remember an entry there in the last year or so. -- (talk) 06:58, 17 May 2019 (UTC)

User search autocomplete fail

Low priority, I think.

In searching for recent users to try a contact via email, I used the standard format User:unsername to search, making sure I didn't eff up exact format and capitalization. In a fair number of cases, the username, which turns out to have an account, did not autocomplete. I initially assumed they had bugged out (a few apparently did), but they often were findable in the search anyway without autocomplete. So, they looked to have left Uncyc but were actually still present.

The common thing seems to be that they all have nothing added to their userpage (like others without the autocomplete problem. Many have talk pages with entries.) and that they appear as red links in the user list (again like others without the autocomplete failure. Some were new accounts but some were old accounts that had become active again.) Examples are:

• SCM404
• KoreanBradPitt
• General Khor
• Mrkjanderson2018
• Tn129719
• Randomaspland
• Xeazar

If the user page doesn't exist, I don't see why it would come up in Special:Search. It's looking for pages, not user accounts. So some users with nonexistent user pages can be found that way, but others can't? The search index may be missing stuff and in need of a maintenance script to fill it in. Searching for "createbox" reveals only some of the pages with that tag, and I just tried to find "Llwy-ar-lawr" and "Snarglefoop" in userspace and found that only the first autocompleted. ❦ Llwy-ar-lawr • talk • contribs • 19:07 19 May 2019

I suppose it depends on the definition of "exists in the database". Why would these users above not have a userpage? I know these users from the last months of wikia. When you get to their userpages/newly created userpages, their talk page is linked (tabbed) and has content. Back at Wikia, I've seen a couple talk pages alone where an article was probably moved without it, but IIIRC didn't have an article page with them.

All of the above can be found exactly via the search as User:username, but if I enter the absolutely correct name, capitals, punctuation and all, autocomplete doesn't work so I originally thought each user page was deleted from the site because of that. Yes, other users with non-existent user pages can be found and do generate a suggested autocomplete; most also show as red links in the userlist. In fact, very few relatively recent users on the userlist are bluelinked. So, just a quirk of autocomplete? -- (talk) 00:30, 20 May 2019 (UTC)

Session failure warning

Low priority, also.

Several times, including saving the "User search autocomplete failure" section above, I have gotten a Session failure warning message fter trying to save it. Now I know I am slow writing, so if it is timeout problem, it's not useful. A sceond attempt at saving was successful, so no harm. -- (talk) 07:16, 17 May 2019 (UTC)

I've seen that too. Once I had two windows open simultaneously and, when it happened to the first, I predicted it would happen to the second, and was right. Doesn't dump what I had typed into the edit window, but it's startling. Spıke 🎙️11:04 17-May-19

That would be this? Me too. I've seen it a fair amount on other wikis, including the old site, where Oasis rendered the wikitext of our custom message nonfunctional. It does seem to be some sort of timeout. Is it happening more than normal? I don't know what could cause that or if there are any configuration options. ❦ Llwy-ar-lawr • talk • contribs • 18:54 19 May 2019

"Normal" to me would be "not at all." MediaWiki is not losing the edit and there ought to be no reason it doesn't keep trying or re-try. I don't know if reconfiguration would work nor what to reconfigure.

I've rewritten the recommended workaround. I don't know if our "technical staff have been notified" (sounds like a Wikia-style lie) so I replaced it with how I deal with the problem. Nor do I know whether the message comes up because of an actual loss of session data. If not, we might try levity such as the fact that the chipmunks got distracted from running on their treadmills. Spıke 🎙️19:56 19-May-19

I assume the notification goes to the same place as the report made when someone uses "sudo" without authorization. That text came from the original version by MediaWiki default. The current default message does not have it.

I found this page on a Firefox bug that causes this to happen because of cookie limits. According to this comment on the related Phabricator task, cookie limits in Chromium can cause the same thing. You're using Firefox, and I'm using a Chrome browser. The bug was supposedly fixed but only in Firefox 53 and later. ❦ Llwy-ar-lawr • talk • contribs • 22:46 19 May 2019

The "sudo without authorisation" notification goes to root@localhost (which may be ignored if no one monitors that address, but it is real).Conversely, I've been hosting MW since 2006 and have never received any automated "notification" as "technical staff" from any version of MediaWiki that displayed this error message to a user. carlb (talk) 12:17, 20 May 2019 (UTC)

I am really good at getting this message since I take so much time to write anything. I have yet to get any loss of data, though it is a worry. My immediate workaround if I don't get impatient is to do a "Show preview" before saving. Doing that always results in no warning given and then the page can be saved normally. I note that if I start work on something long, do a "Show preview" and then throw in some edits after, then try to save without doing another "Show preview", I will get the session warning. -- (talk) 21:36, 26 May 2019 (UTC)

JavaScript with importScript()

I'm not sure why this happens, but I need to disable javascript to see pages when I'm logged in. I have tried clearing my user.js but it didn't work. This doesn't happen when I'm logged out. Could anyone tell me why this happens?--The Pioneer JP (talk) 03:11, 18 May 2019 (UTC)

Never mind. It's working fine with my new account, and I will use this one from now on (besides, this is my standard user name across wikis).--The Pioneer (talk) 03:17, 18 May 2019 (UTC)

Welcome to the new site :) importScript, which you were using, doesn't exist anymore in MediaWiki 1.31. Blanking your JS should have fixed the problem. If it persisted, you probably needed to clear your cache or wait for the site cache to clear, or else you were using other broken JavaScript such as gadgets. ❦ Llwy-ar-lawr • talk • contribs • 07:08 18 May 2019

Cookies

I am delighted that this website runs on Firefox 10 on my kitchen table. (Wikia demanding that I discard my set-up was my personal last straw, two years ago.) Especially, I can run with orders to allow a cookie from uncyclopedia.ca, but disabling cookies in general. However, firing up the Big Machine with modern Firefox, and allowing a cookie from uncyclopedia.ca, every page rendered reports that I am logged out, unless I allow cookies in general, in which case I am suddenly logged in again. Is this phenomenon well-known? Is it something management could remedy? Spıke 🎙️11:07 18-May-19

This phenomenon is not well known. In fact I'd hazard to say it's completely unheard of (by me, at least). There must be some other domain getting into the act; somebody who cares is having their cookies blocked. I wonder ... um. Did you check the cookie owners? Under the covers, the server may still think it's named ns3243-some-horrible-long-string and maybe that's what the cookies are coming in as. There might also be some issue with the fact that we're using a cname record instead of an A record to publish the site URL (but that's over in Llwy-ar-lawr's realm -- I haven't touched dns). -- Snarglefoop (talk) 17:12, 18 May 2019 (UTC)

Nope, that doesn't seem to be the issue -- I just looked at my cookies and we're dribbling in as "uncyclopedia.ca". (More specifically, regarding the host name, it's named "ns532099" internally, because as yet, nobody's told it otherwise.) -- Snarglefoop (talk) 17:16, 18 May 2019 (UTC)

I got as far as flushing all cookies and logging in, and all that appeared were some cookies from uncyclopedia.ca. Nothing else. So, if you're allowing all cookies from that domain, I'm pretty much at a loss as to how that could be happening. (I'll poke further later; I've got a bunch of "block" and "allow" entries in my cookies permissions table for Firefox that I'm reluctant to flush in order to check your exact reported scenario just now.) -- Snarglefoop (talk) 17:23, 18 May 2019 (UTC)

The (probable) cause of the symptoms

Firefox is too stupid to know these are the same site

Firefox sees us as two different sites: http://uncyclopedia.ca and https://uncyclopedia.ca. If you're logging in on the secure side, you need to allow cookies for the "https" address; otherwise, the login will fail with a message of varying obscurity. With all cookies blocked, your cookie exceptions should look something like this (at right). -- Snarglefoop (talk) 03:40, 22 May 2019 (UTC)

Thank you for that awesome research; that has done the trick. Spıke 🎙️03:49 22-May-19

Special:NewPages is missing entries

medium concern here.

The wikia-era articles only go back to February 27. Not a tragedy, but remember, "Recent Articles" on the main page links to this page.

Of new articles made at .ca, UnNews:Grumpy_Barr_loses_a_sibling is missing and so is UnNews:Trump awards Woods Medal of Sexual Freedom. So then are news articles no longer to be found here? I'd like a check that project articles should report here also. -- (talk) 05:33, 19 May 2019 (UTC)

I don't know why anything from before April is there at all. Probably because NewPages relies on the recentchanges table and that table automatically fills in somehow after a certain amount of time has passed. The default period of time for recent changes to extend over is 90 days, which in May means back to February and no farther. Wikia does not seem to have such a time limit, while default MediaWiki does. I can change the limit if desired.

NewPages filters by namespace. The default is mainspace, but you can see other namespaces by using the dropdown. This shows UnNews: //uncyclopedia.com/w/index.php?title=Special:NewPages&namespace=102 The Grumpy Barr article is there, but Trump/Woods is not. I brought the latter to the new database with Special:Export and Special:Import, and pages added this way do not make it into the recentchanges table as new creations. I could try running rebuildrecentchanges.php to fix this, but it would probably take a long time and slow the site down, and if we're already seeing the effects of that table filling in it probably wouldn't work. ❦ Llwy-ar-lawr • talk • contribs • 18:43 19 May 2019

I seem to remember that 'new pages' never included UnNews for some reason when we were at Wikia. --RomArtus*Imperator ITRA (Orate) ® 22:51, 19 May 2019 (UTC)

Special:Newpages seems to include a drop-down box with a choice between one namespace and every namespace - the latter being too cluttered with talk and project pages to be useful. https://uncyclopedia.ca/wiki/Special:NewPages?namespace=102 finds Grumpy Barr but not the Medal of Sexual Freedom. carlb (talk) 12:00, 20 May 2019 (UTC)

Well, since pre-.ca articles shoud not report there, and that UnNews doesn't belong on that list (users can find it via the front page in any case), there is no need for further work here. I will say this case is closed; thanks for the investigation. -- (talk) 00:43, 20 May 2019 (UTC)

Featured article template

The green featured stamp on {{FA}} wasn't coming out in the right place. In Vector it appeared partway down the sidebar, while in Monobook it was in the right position but underneath the logo. It hasn't worked for almost a year because of Oasis (I believe the specific problem was overflow: hidden), but now we can finally fix it without worrying about violating the customization policy. So I did. Sort of.

It seems to be impossible to put an element inside the page content on top of the logo or sidebar with CSS alone. I don't know why it worked before or why it doesn't now. I resorted to JavaScript to pull it outside the main content div. This looks like what they're doing at the fork, but I didn't investigate it that closely. (Looking at their equivalent is how I stumbled on the problem seen in File:Caching.png.) This means the stamp will bounce when the page is loaded and won't be positioned correctly for anyone with JavaScript disabled. The alternative is to create a different logo image with the stamp superimposed on it, but this is more complicated because it requires mw:Extension:CSS, mw:Extension:LogoFunctions or yet more JavaScript and you need 12 images to cover all the content namespaces.

The stamp should be in about the right place now (though still not for Timeless), but it's been so long that I'm not sure exactly where it's meant to be. I'd already been gone for three years when Oasis came. Does it look right to you? I can move it around more if not.

That leaves the issue of the star placed in the upper right, which has also not worked properly ever since Oasis. Not sure what to do about that yet. ❦ Llwy-ar-lawr • talk • contribs • 05:00 21 May 2019

Final pages from the Wikia site

(Just in case folks were wondering about this...)
We've got the final XML dump from the Wikia site, and have run a script over it to pick out the pages which are missing from this site and pull out the <page>...</page> material for each one. There are about seventy-five of them. Unfortunately a bunch of them are garbage (stuff that was missing because it had been deleted, that kind of thing) and some human (looking at you, Llwy-ar-lawr) is going to have to poke at each one and figure out whether to pull it in. So, not done yet.
Edits to existing pages which were made on the Wikia site after the last pass over the site grabbing material with a script is buried in the XML dump, also, but it's less obvious how to slurp it out easily. -- Snarglefoop (talk) 05:20, 22 May 2019 (UTC)

I've imported all the new pages that were missing, including images. I did it with Special:Export/Special:Import. Some pages had edits from users that don't exist here, so they're now attributed to "wikia>Username". This doesn't really work for attribution because wikia:whatever goes to the main page of fandom.com regardless of what "whatever" is. Either the interwiki should be fixed or I should mess with the database to attribute the edits to local users and fill in the stub accounts. I'm not sure what to do with pages that have missing edits -- are those worth having? Some were reverted or would conflict with edits already here. ❦ Llwy-ar-lawr • talk • contribs • 04:24 26 May 2019

Do you need some help here? Is this actually done, or does someone still need to dig through the 78 or so files of stuff dumped since the last complete import, and see if there's anything interesting there? It looks like eyeball-killing boring work. It would be easy to stick the XML dumps someplace and have someone else look at them (it's just 90 megabytes of stuff altogether). -- Snarglefoop (talk) 22:20, 26 May 2019 (UTC)

Sure, you can look through the existing pages with new edits. It probably wouldn't be a big deal to bring them all in, though they could make page histories a little weird in spots. Edits that are already here won't cause a problem if imported, but importing too much at once causes it to fail. At least, it does if you're using Special:Import, which is easier than doing it server-side. ❦ Llwy-ar-lawr • talk • contribs • 02:13 2 June 2019

I got the last edits. I believe we now have everything from that time period that is in the final dump and the backup site. You can see what I imported at Special:Log/import/Llwy-ar-lawr -- might want to review it and decide if it's worth having. Some pages diverged a bit, so there are weird diffs like this. MediaWiki stores the full text of revisions, not the diffs. Might also want to do a histmerge between User:Romartus/Aphrodite and Aphrodite. Also note that those who began editing after 8 May on the Wikia site won't be able to log in here. They can recreate their accounts and (tediously) have their edits reattributed. ❦ Llwy-ar-lawr • talk • contribs • 03:33 5 June 2019

Deleted pages that weren't actually deleted

There seem to be pages that are deleted, i.e. only present in the archive table, even though they were not intentionally deleted (no log entry). I thought this happened to File:Aircraft_carrier_2.jpg and File:Bush_41_official_portrait.jpg because the file-related grabber scripts don't know how to deal with files that were moved, but they seem to exist now, though there are redundant deleted file entries for them. I discovered later that there were other pages this happened to for reasons I don't understand. Special:Undelete/Category:Computers and Special:Undelete/Fat Albert both show edits dated later than the last recorded deletion. Some script tripped over something. Probably because I ran grabNewText.php from an early date to get page protections and it saw deletion log entries and deleted the pages they affected. mw:Manual:Grabbers advises using it to "fill in the missing stuff", but outside of changes made after the initial import, it's really not designed for that purpose. ❦ Llwy-ar-lawr • talk • contribs • 05:40 22 May 2019

I've seen that sort of thing on other GrabNewText.php imports, but with pages with titles that had been deleted long ago and created later with different content - Niggers style. I wonder whether it would be worth checking the archive table for pages that have some absurdly-high number of revisions before being deleted for no apparent reason; another red flag would be that the deleted revisions are newer than the deletion log entry. The scripts seem to have been kludged together for one-time use when .co forked in 2013 and are buggy? carlb (talk) 14:11, 22 May 2019 (UTC)

Yes. Never trust the scripts; I've learned that well. To be fair, though, "grabNewText" is exactly what it says on the tin.

There's a query I can run to find pages like this, but it takes a very long time. Here it is limited to 10 entries:

MariaDB [uncyc6]> select ar_title from archive where not exists (select log_title from logging where log_title = ar_title and log_timestamp > ar_timestamp) limit 10;
+--------------------------------+
| ar_title                       |
+--------------------------------+
| 1920's_literature              |
| ??????????                     |
| ASHLIEGH_BELLLL!!!!!!          |
| A_Series_of_Unfortunate_Events |
| A_poop                         |
| A_random_zombie                |
| Aaron_Affeld                   |
| Aaron_Affeld                   |
| Aaron_Affeld                   |
| Alpha_Crypt                    |
+--------------------------------+
10 rows in set (3 min 44.039 sec)

Some of the pages it finds seem to be legitimately deleted but missing log entries. The only one I'm sure is supposed to be a live page is A Series of Unfortunate Events. I'll have to somehow pick and choose which ones to restore.

I restored a few of these pages (and undid Nigel deleting broken redirects, sorry -- they all pointed to pages that were supposed to exist). When I tried to do Category:Computers, it wouldn't let me because supposedly it was trying to insert a duplicate ipc_rev_id into the ip_changes table. Maybe grabNewText doesn't clear out that table when it deletes pages. ❦ Llwy-ar-lawr • talk • contribs • 04:47 24 May 2019

After deleting four rows from ip_changes, I was able to restore Category:Computers. ❦ Llwy-ar-lawr • talk • contribs • 04:49 26 May 2019

Grabbers + deleted pages = flaky mess. I've just discovered that two copies each of Telepaths under the bed and Absolute power ended up in the archive table. This is probably because I ran grabDeletedText.php before grabNewText.php and the former inserted deleted revisions while the live counterparts were still there, then the latter deleted the live ones. There should be some mechanism to detect and avoid that. I should go through at some point and get rid of all the duplicate deleted revisions. ❦ Llwy-ar-lawr • talk • contribs • 03:03 27 May 2019

Ok Llwy-ar-lawr. I hope we can find all the missing pages and edit histories.--RomArtus*Imperator ITRA (Orate) ® 08:52, 27 May 2019 (UTC)

Spellchecker

I notice that when I write an article, I am not receiving notification of a spelling error. I expect the older one at Wikia was set for American spelling rather than British but here nothing alerts me that I am writing gibberish. Intentional? :) --RomArtus*Imperator ITRA (Orate) ® 13:30, 28 May 2019 (UTC)

I'm sure this is an option. I don't want to be nagged while I'm typing! Llwy mentioned that the Preferences didn't get copied over, perhaps check there. Spıke 🎙️13:47 28-May-19

Wouldn't the spell checker be a browser extension, not a part of the server or the website? carlb (talk) 16:01, 28 May 2019 (UTC)

That would be the most sensible implementation! So, Romartus, are you seeing spell-checking outside of Uncyclopedia? (Were you ever?) Spıke 🎙️16:05 28-May-19

I have no idea why this would be different here. It should be a browser setting. Normally preferences do come over when you log in -- my comment was about the special case of the Spike account. ❦ Llwy-ar-lawr • talk • contribs • 16:43 28 May 2019

Assuming you're using the traditional bare-text editor, this is something your browser does. The website doesn't get a chance to touch your words until you hit 'save', whereas the browser has its fingers all over them while you're typing it in. (If you're using a WYSIWYG extension it's something else again -- the extension is a fancy piece of Javascript or something and it's going to be doing the checking, or so I would suppose -- but AFAIK we haven't got a visual editor installed at this time.) -- Snarglefoop (talk) 16:46, 28 May 2019 (UTC)

I have tried elsewhere. When I write on another website, I see 'red squiggles' under words that a spell checker wants me to double check. I think it would be a useful tool here. It's easy to make mistakes. --RomArtus*Imperator ITRA (Orate) ® 16:59, 28 May 2019 (UTC)

Eh???

Srsly? I had no idea we could even affect that -- I really thought that was entirely a thing that happened inside your browser. -- Snarglefoop (talk) 17:11, 28 May 2019 (UTC)

WFM -- after I click or type a space the red snakes appear

WFM -- see screenshot, at right. So at least it's not universally broken. I tried a number of different settings in my edit preferences and didn't find one that would shut it off. (I haven't tried poking in my browser preferences to see if there's something there that could selectively shut it off on our site -- I guess that's next.) -- Snarglefoop (talk) 17:23, 28 May 2019 (UTC)

Now that's interesting. Maybe that's why the sandbox exists(?) Now we did have autocomplete for bluelinks, but that's another story. -- (talk) 18:55, 28 May 2019 (UTC)

Browser settings

This wouldn't affect our site any differently from any other, but none the less, make sure you've got spell checking turned on in the browser. In Firefox it's easy; it's in the language section:

In Chromium it seems to be buried in the "advanced" section, under Languages. I think this is the preference you need there (though stuff I found online seemed to imply there's some other setting buried somewhere in the "Privacy" section which must also be enabled, because Chrome-family browsers use an offsite dictionary):

In Vivaldi, there are about 73,000 settings and in the enormous heap of buttons and knobs that control things like the exact shade of gray used to fade one image into another in the user interface, I can't find anything that seems to control spell checking. But, well, that's Vivaldi. (And that's it for browsers I use regularly. Didn't check it on phones.) -- Snarglefoop (talk) 20:12, 28 May 2019 (UTC)

In Firefox, if I right-click anywhere in the edit window, two of the menu options are "check speling" and "languages" - but that's coming from the browser. The only cue I see passed from the server is the HTML page header <html class="client-nojs" lang="en" dir="ltr"> but that looks normal enough and not lang='en-ca-hosers,eh?' or something weird. :) carlb (talk) 21:09, 28 May 2019 (UTC)

Indeed, language code is the one thing that seemed possible. It seems happy with Canadian, but maybe it doesn't speak British? I went as far as switching to British English in the browser and on the site but that didn't make any apparent difference (but maybe I didn't hit it where it mattered). -- Snarglefoop (talk) 23:35, 28 May 2019 (UTC)

.svg

I can't upload SVG at all (a vector file, from OpenClipart.org for instance). I presume that it would need to be enabled in the list of valid file extensions for upload and would need to have some available thumbnail-generation programme (such as RSVG, Inkscape, not sure if ImageMagick was one of the options...) before it would be usable? There looks to be a disambig https://www.mediawiki.org/wiki/SVG with a link to some pages that explain how to handle vector graphic file uploads. carlb (talk) 05:22, 1 June 2019 (UTC)

I've enabled SVG uploading. I noticed it wasn't listed as an option on Special:Upload -- it is now.

ImageMagick is here, as discussed under #Broken animated GIF thumbnails, but it's not what we really want for SVGs because it can't scale them up properly. This is something I've noticed but pushed down the mental list because other things seem higher priority. You can see the problem at 000000000!. To fix this I'll need to install another converter. Given what's available from the CentOS repositories, this will probably mean building whatever it is (Inkscape?) from source. The Inkscape package insisted on a particular downlevel version of ImageMagick that we don't have (specifically, the same one I ripped out to fix the GIF problem). ❦ Llwy-ar-lawr • talk • contribs • 06:48 1 June 2019

Uncyclopedia:Report a problem

I see that Uncyclopedia:Report a problem is linked from the sidebar, but it seems no one has looked at that page in the last five years? carlb (talk) 05:43, 1 June 2019 (UTC)

I really don't recall seeing it until the move the last year or so at Wikia, but there is a post from November 2017; been here only since mid-2017. All instructions say to squawk at an admin, which is what users have been doing the last couple of years. -- (talk) 23:56, 1 June 2019 (UTC)

Https

For some reason, both Microsoft Edge and Chrome browsers want to load all pages I try to look at when logged in as https:// rather than http://. And then they won't load until I force the browser to load them as http:// but as soon as I navigate to a new page, once again it loads as https. I know the mirror site doesn't have that problem, and en.co doesn't have that problem, so there must be some way to fix it. Until it is fixed, I won't be editing as extensively as I otherwise would, since things are finally starting to slow down slightly at work. -- Simsilikesims(♀GUN) Talk here. 17:36, 3 June 2019 (UTC)

Setting $wgServer to be just //example.com rather than http://example.com or https://example.com is supposed to make it possible to have fully separate HTTP and HTTPS sites, but I tried that and found that you could get bounced over to the HTTP site from HTTPS when clicking "random page" or logging in. Now $wgServer is https://uncyclopedia.ca and you can get bounced to HTTPS from HTTP. I thought this was less undesirable, but maybe I should try setting it back to //uncyclopedia.ca. I'd also like to know why https pages aren't loading. I haven't seen this problem. Can you give a screenshot? ❦ Llwy-ar-lawr • talk • contribs • 17:53 3 June 2019

Ok, I've set $wgServer back. HTTP doesn't bounce into HTTPS, but https://uncyclopedia.ca goes to the HTTP site, as does logging in to the HTTPS site and clicking on "Random page". sigh... really wish I knew what did this. Squid misconfiguration? Never seen anything like it before. Mirror Uncyc doesn't do it.

Does going directly to the HTTPS site also not work? ❦ Llwy-ar-lawr • talk • contribs • 18:18 3 June 2019

Going directly to the HTTPS works unreliably on Edge. Both Edge and Chrome try to default to leaving the http and the https out of the address bar, by the way. PS - The main page alone does not do this. The other pages do. Also, opening each new page in a new tab seems to help for some reason. But I don't like browsing that way, since I would end up with over 20 tabs open.

-- Simsilikesims(♀GUN) Talk here. 18:23, 3 June 2019 (UTC)

Just a thought. Do you think http://www.example.com or https://www.example.com would work? It might make the difference having the www in there. Or, if you have a configuration page at way, www.example.ca you could put the configuration page somewhere else less obvious and make www.example.ca a redirect to example.ca. -- Simsilikesims(♀GUN) Talk here. 18:44, 3 June 2019 (UTC)

As far as I know, www.example.ca and example.ca can be two completely different websites (one is a subdomain of the other), much like en.wikipedia.org and fr.wikipedia.org are different.

If you set $wgServer to '//example.ca' (in a protocol-independent manner) there is a $wgCanonicalServer which needs to be set to a URL with the protocol ('https://example.ca') as there are a few places (like the links inside the e-mail notifications) where the protocol-independent links don't work. carlb (talk) 19:14, 3 June 2019 (UTC)

Why do you (or anyone else) want to access the site as http? Your computer can't be that old(?) Are we leaving millions of people out of the loop that can't handle https? I suppose you can't answer that under the policy of omerta here, so just consider the numbers and decide for yourself. Llwy, you may remember a short-lived Firefox version that gave a warning instead of taking you to a non-https page?

Are all pages accessible in both configurations? If all is inherited from FANDOM, I'll bet they're not. And unless you're doing something with pointers, aren't we then doubling on pages for the site, in whole or in part? I suppose you won't be allowed to answer that publicly, either, so consider the value of keeping http. The slowpokes are still converting to https, and that seems to be one way.

I was told that having both is bad for SEO; the bots are looking at 2 sites in essence. Is that why we see dupe autocompletes in search results? And the crawlers do have a liking for https sites by giving them a very slightly higher rank than otherwise. -- (talk) 21:04, 3 June 2019 (UTC)

AFAIK everything should be accessible either way. Site configuration wasn't inherited from Wikia (heck, we can't even see that level of detail on their sites) so any breakage is entirely our own. Whether having it both ways is bad for SEO, I dunno ... separate question. And BTW last time I checked we just fell over if you tried to access us as "www.anything...". But dealing with the "www." was left as an exercise for later.
The interesting question here, IMHO, is why are folks on Macs seeing blank pages when they hit the site through HTTPS, and why are we getting reports of that from Edge and Chrome users on Windows boxes, as well? Chrome supposedly gifts you with a blank page if there's a Javascript error, but that explanation is kind of a Voodoo shark, since it leaves us wondering why these alleged Javascript errors only happen on certain systems with certain browsers.
Be that as it may, I've gotten as far as setting up a VMWare MacOS box to try to reproduce the Mac problems, but so far all it's done for me is refuse to change its resolution from "tiny-default" (doesn't think much of the fake hardware, apparently), and run Safari (which seems to run like blazes, for whatever that's worth). No blank windows in evidence, but there's far too little of it configured to hope they'd appear at this level. -- Snarglefoop (talk) 22:12, 3 June 2019 (UTC)

This guy is a squid (pt:Lula)

I fixed squid.conf earlier so the www site is accessible. It was previously blocking access through anything other than plain "uncyclopedia.ca". JavaScript errors happening only for some people would be due to custom JS in JS user subpages or gadgets. To tell what's causing the error, you can right-click on a page, click "Inspect", click the "Console" tab, and look for errors and what pages they're said to come from. User:Simsilikesims/common.js uses importScript, which was removed from MediaWiki core and generates an error. I added a test line to my common.js and didn't get blank pages, though. Could be a gadget.

I have another wiki I've set up to use both HTTP and HTTPS with a protocol-relative $wgServer, and it doesn't do the bouncy-HTTPS thing. It also doesn't use Squid or any other caching program. That's why I suspect Squid. I should try putting Squid there and seeing if the same thing happens. Maybe I should have gone with Varnish, but the documentation is bad and I couldn't get it to work. BTW I was on the HTTPS site and got taken to HTTP when saving the page. ❦ Llwy-ar-lawr • talk • contribs • 00:16 4 June 2019

From https://wiki.squid-cache.org/Features/HTTPS: "Squid can accept regular proxy traffic using https_port in the same way Squid does it using an http_port directive. Unfortunately, popular modern browsers do not permit configuration of TLS/SSL encrypted proxy connections. There are open bug reports against most of those browsers now, waiting for support to appear. If you have any interest, please assist browser teams with getting that to happen." Should we take this to mean that https_port, which I'm using, won't work in a lot of browsers? What are "popular modern browsers", exactly? Even if they're not modern now, some people probably still use them. ❦ Llwy-ar-lawr • talk • contribs • 00:40 4 June 2019

I was playing around with Chrome after the Squid fix was noted and could not get the http/https flipflop to happen, for whatever that is worth. -- (talk) 00:44, 4 June 2019 (UTC)

Fix? All I did is enable access through www.uncyclopedia.ca. I'm still getting the bouncing. It's on Special:Random, logging in and out, going to https://uncyclopedia.ca, and saving edits. Were you doing those or something else? What these all have in common is that the URL you go to redirects to a different one (301 Moved Permanently). Also happens with redirect pages, like unnews. ❦ Llwy-ar-lawr • talk • contribs • 01:20 4 June 2019

Unfortunately the above-quoted issue with Squid doesn't explain anything we're seeing here. The problem referred to on the Squid-cache wiki page occurred when using Squid as a forward proxy; in that case, to use https to get to the proxy, you'd need to double encrypt traffic which was going to continue on from the proxy to the endpoint, and some browsers thought that was just too weird. In our case, Squid is acting as the endpoint and there's no issue with double encryption.
None of this means it's not Squid causing our problems; it just means it's not that particular issue with Squid which is doing it. -- Snarglefoop (talk) 01:42, 4 June 2019 (UTC)

I turned off Squid and surprise, surprise, the HTTP bouncing doesn't happen anymore. It won't make much difference to speed because it wasn't caching properly for HTTPS -- wouldn't cache pages, just images. (Special:Random actually goes faster now.) I'm going to leave it off until we can find another solution. This doesn't address the blank page problem. ❦ Llwy-ar-lawr • talk • contribs • 01:51 4 June 2019

Maybe, when you change something like the URL format, you need to discard the outdated versions from /var/spool/squid or wherever they're lurking? carlb (talk) 17:09, 4 June 2019 (UTC)

Simsilikesims, would you try the HTTPS site again now that Squid is off? This may have nothing to do with the problem, but it would be good to know.

About the www site, https://www.uncyclopedia.ca still doesn't work because the SSL certificate only applies to uncyclopedia.ca. We need a better certificate. ❦ Llwy-ar-lawr • talk • contribs • 02:06 4 June 2019

Looks like I am still having the same problem so far. I will try clearing my browser cache and reloading the page in case that does anything. I still don't have any issues when I am logged out of the site though, browsing it as an IP. -- Simsilikesims(♀GUN) Talk here. 17:18, 4 June 2019 (UTC)

If it's only when you're logged in, that points to JavaScript. I copied your common.js and didn't get blank pages, but then I turned on all the gadgets and everything was blank (in Vivaldi and Chrome). Chrome complained that "This page is trying to load scripts from unauthenticated sources." The HTTP and HTTPS sites seem to be equally broken when I do this, which isn't quite your problem, but it's similar. Try turning off any gadgets you have on. I don't know which of them are responsible -- I'll figure it out later. As discussed in other sections of this page, a number of things have changed in MediaWiki that make old JS not work. ❦ Llwy-ar-lawr • talk • contribs • 18:23 4 June 2019

I enabled all the gadgets with Bazqux, then poked at the gadget pages until the site stopped coming up blank. I think the problem was two uses of document.write (in wikEd and "Auto tag"), which in Chrome browsers causes blank pages -- the page comes up and then immediately vanishes. This was happening with the main page before I fixed MediaWiki:Common.js. If blank pages persist, either there's something in someone's cache or this was a red herring. Or there's other JS that other browsers don't like, or different versions of browsers... the JS situation is nowhere near resolved yet. ❦ Llwy-ar-lawr • talk • contribs • 21:43 4 June 2019

Whatever you did, it seems to have fixed my issue on Chrome, which is the browser I currently use most. Next, to test with Edge. Firefox was ok before, so it should still be ok. Update: Edge is working fine now. -- Simsilikesims(♀GUN) Talk here. 05:23, 5 June 2019 (UTC)

Yay! Deleting page content is actually what document.write does. It doesn't cause this in Firefox because Firefox rejects the document.write call. Raises the question of why it worked on Wikia. ❦ Llwy-ar-lawr • talk • contribs • 05:36 5 June 2019

And search engines

I've finally contrived to load a search engine for uncyclopedia.ca into my browsers. But searching for a page lands me in that http: world, in which I am not logged in, and where every link on the page sends me to another page via http:. Like Simsie above, I can get around it by typing https:// myself, but the search engine should do this correctly. Spıke 🎙️04:10 7-Jun-19

The http site is the default when there are both http and https sites. Since there don't seem to be any problems with HTTPS at the moment, maybe it's time to force all traffic to HTTPS. I didn't do this when setting up SSL because I was having a hard enough time getting it working at all. I guess this is why other people pay for certificates. ❦ Llwy-ar-lawr • talk • contribs • 04:32 7 June 2019

We are now HTTPS-only. ❦ Llwy-ar-lawr • talk • contribs • 05:16 12 June 2019

Thanks; problem has disappeared on both my moderately old and very old browsers. Spıke 🎙️05:46 12-Jun-19

Tools

I notice I can't upload in the Tools section unless I have logged in. --RomArtus*Imperator ITRA (Orate) ® 16:34, 4 June 2019 (UTC)

That's normal; anon-IP's have never had access to Special:Upload in MediaWiki anywhere. Wikipedia:Project:Files for upload exists as a manual workaround on that one project, but otherwise uploaders need to register. carlb (talk) 16:53, 4 June 2019 (UTC)

Thanks. I guess that is a good idea. Don't want IPs loading up their gross image collection here. --RomArtus*Imperator ITRA (Orate) ® 08:58, 5 June 2019 (UTC)

UncyclopediansAwake! template doesn't autodelete

Low priority.

This is the welcome template placed on a new editor's page that says it will self-delete. It doesn't and hasn't for the longest time. I still see this on the userpage for Aswaldi, added August 2018. So, it's an old problem. Looking at the template, there's nothing I can see that could work as a timer. If you want to handle it simply, have a list of these by user on Special Pages so they can be deleted manually. -- (talk) 04:06, 19 June 2019 (UTC)

I always thought that that was an in-joke (inspired by the self-deleting magnetic tape in Mission: Impossible!). Romartus places this so as to avoid seeing red in RecentChanges pertaining to new editors he has already looked in on. Spıke 🎙️04:24 19-Jun-19

I know...I was showing my age with this pre-digital joke. Tape...phone boxes. Yes, it was put on a user's page to avoid a red link. RomArtus*Imperator ITRA (Orate) ® 11:38, 19 June 2019 (UTC)

I revised the template last night to, among other things, advise the recipient what the hell it is doing there and give introductory information on the uses of a user page. Spıke 🎙️12:13 19-Jun-19

Undeleting images

I got a weird error when trying to undelete image:HurricaneChow.jpg for use on Hurricane Katrina (2005):

Query: INSERT INTO `image` (img_name,img_size,img_width,img_height,img_metadata,img_bits,img_media_type,img_major_mime,img_minor_mime,img_timestamp,img_sha1,img_description,img_user,img_user_text) VALUES ('HurricaneChow.jpg','50410','343','432',,'8','UNKNOWN',NULL,NULL,'20050901102209',,'Yet another Simpsons refrence.','26586373','You want Million Dollar?!?')

Function: LocalFileRestoreBatch::execute

Error: 1048 Column 'img_major_mime' cannot be null (localhost)

This looks to be just the one image; a couple of others which I'd restored for the same article (which was a good page once, then was destroyed with unfunny additions, then was tagged "fix" as a stealth way to nominate it for deletion) look to be OK. I can likely easily get this one image back as it's on a mirror site, but I'm listing this here just in case it's affecting anything beyond this one undeletion. Carlb (talk) 16:55, 19 June 2019 (UTC)

I don't know what it's on about, since the major_mime value is right where it should be:

MariaDB [uncyc6]> select fa_major_mime from filearchive where fa_name = 'HurricaneChow.jpg';

+---------------+

| fa_major_mime |

+---------------+

| image |

+---------------+

1 row in set (0.000 sec)

It's somehow failing to retrieve the information and insert it into the image table. select * from filearchive where fa_major_mime is null; turned up nothing, so if it happens again, it will be equally mysterious. ❦ Llwy-ar-lawr • talk • contribs • 01:38 20 June 2019

Actually just checked the image itself and it's missing. It must be getting the mime information from the image instead of the database, and in this case, naturally, it can't. Not like you could restore it anyway. It was probably already like this -- images deleted before a certain date (which I'd thought was 2008 or earlier, though this one was deleted in 2009) seemed to be not there. (It's also possible we lost some because of some problem with downloading them, but that's a moot point now.) Looks like the mirror is your only choice here. ❦ Llwy-ar-lawr • talk • contribs • 01:49 20 June 2019

Special:Wantedpages

Special:Wantedpages (and anything using it, like Uncyclopedia:Requested articles#Top 50 Wanted Articles) is showing some pages from the UnDictionary: and Forum: namespaces as "wanted" redlinks, even though they already exist. Does this list (or the links) need to be rebuilt with one of the maintenance scripts? Carlb (talk) 14:25, 23 June 2019 (UTC)

I noticed this. It's the namespaces. It thinks those are links to (impossible) mainspace pages beginning with "Forum:" etc. I've learned my lesson well: set up custom namespaces before importing anything. But what to do now? Good question. I hope there's a more efficient solution to the remaining link problems than running refreshLinks.php again. ❦ Llwy-ar-lawr • talk • contribs • 20:02 23 June 2019