Forum:Broken links/pages

Forums: Index > Village Dump > Broken links/pages

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

I am going to add here for any missing pages, tables etc. --RomArtus*Imperator ITRA (Orate) ® 16:42, 16 May 2019 (UTC)

https://uncyclopedia.ca/wiki/Uncyclopedia:VFH/Featured

Featured picture on main page

Broken today in the same fashion seen earlier, it seems.

-- (talk) 04:21, 20 May 2019 (UTC)

The Pioneer warned me about this in Forum:Technical problems on the new website#Problems on VFP and VFH. I've implemented his fix for {{FI}}, so it shouldn't happen again. I have yet to solve the VFH problems. I did fix the broken VFH nomination transclusions only to discover that they shouldn't have been there in the first place, as they were already closed as featured. The DPL parameter notcategory is somehow being ignored. ❦ Llwy-ar-lawr • talk • contribs • 04:39 20 May 2019

Anniversaries redirect wonky

low priority

On the Uncyclopedia:Anniversaries/November 20 page, there is an entry with 1453 for a year date. Roll over that year date and you will find it is linked to a page 1000 AD - 1699 AD, now deleted. This was the original link. However, there is a page for 1453 which redirects to the [15th century]] page as it should. I'm surprised these can coexist. -- (talk) 08:53, 21 May 2019 (UTC)

It's a piped link. You added it in this diff. If you want it to link directly to 1453, it can just be changed. I'm not seeing the problem here. ❦ Llwy-ar-lawr • talk • contribs • 19:13 21 May 2019

My bad. Thought I removed all when linked page was deleted and this and others became broken links. And looking at the site when half asleep. -- (talk) 20:23, 21 May 2019 (UTC)

Uncyclopedia:VFH/Featured

Still coming up blankety-blank when I check the site in Firefox. --RomArtus*Imperator ITRA (Orate) ® 11:08, 26 May 2019 (UTC)

Scroll down more. There's a huge amount of padding for each entry for whatever reason. -- (talk) 06:48, 28 May 2019 (UTC)

Sadly it's not padding. It's a mess of broken code, and you won't see the whole extent of it unless you scroll to the right. Look at the length of the horizontal scrollbar.

I edited some templates to try and fix it, attempting to copy The Pioneer's changes to VFP templates, but it didn't help. He said I needed to remove duplicate headers, but I don't know what headers those are or what relation they have to the problem. All I've managed so far is this, a vastly simplified version of the list that only shows article names linked to nomination pages. I think our best bet in the long run is to either simplify the DPL code involved in VFH or just drop DPL from that area. If I fix it now, we can't expect that to last forever. I'll have to do upgrades at some point, and things could break again. Of course that would probably entail some amount of JavaScript and/or PHP, which would have to be maintained instead. Once we had that, though, I think we'd be better off. DPL is a pain. Wikipedia doesn't use it -- that should tell you something.

The open nomination list on VFH was showing closed nominations (with more broken code) but isn't anymore. It's supposed to exclude these based on categories, indicating that the table it's relying on isn't or wasn't complete. Remember the aborted refreshLinks job. Something similar might be happening with the last-featured list. Even if so, DPL is still difficult and fragile. Sneeze on the dominoes and they fall down. ❦ Llwy-ar-lawr • talk • contribs • 06:29 30 May 2019

I was going to say long ago that you should have the option to rewrite/recode things as you see fit. Things keep breaking too easily. If JS or PHP are the ticket, I say go for it. But I see things that seem to require a lot of manual handling despite supposedly having program help. So then, if manual methods work best, maybe that should be the choice. It should be a usable backup. But since Romartus and Spike have done most of that kind of work, they should really decide and include their wishlists. Something like a timer for VFH, VFP and VFD to end each listing might be very useful if the due time is adjustable. -- (talk) 08:33, 30 May 2019 (UTC)

I now have a slightly better DPL list here that shows the article name and the date it was featured. It's based on what they have at the fork (thanks Roza). I don't know why we need as much information as is there; this should do. Can we have this instead? I'd like a yes or no. ❦ Llwy-ar-lawr • talk • contribs • 22:20 1 June 2019

Actually never mind, I fixed it for real. ❦ Llwy-ar-lawr • talk • contribs • 22:30 1 June 2019

File:Human sacrifice.jpg

Low priority.

The above does not report on its File page as being used in Cheese naan. The link from the article does work.

The same goes for File:Screenshot 2019-01-11.png used in Fartium, so the problem probably exists around the same time period as these two. I can go through and tag these as "don't delete" but am currently leaving them for you to look at if you like. -- (talk) 06:45, 28 May 2019 (UTC)

User contributions broken, maybe

Low to medium priority.

This works just fine except when I check the box "Only show edits that are page creations":

• I may have the interpretation of the above phrase wrong, but I get edits of all sorts here (for my username).
• The list for me only runs back to 5 March 2019. That is likely due to not having the footer to go back further in the history.

-- (talk) 19:31, 30 May 2019 (UTC)

There's something wrong with imported edits from the Wikia dump that create new pages. They're there, but they don't have the "N" letter, so somehow they're not recorded properly. I don't know what is causing this or whether to blame Wikia or MWDumper for it. The initial dump I brought in only ran up to February, so every page creation after that is marked as such. For a revision to be marked as a page creation, it has to have rev_parent_id set to 0 in the revision table. I guess this isn't the case here, but I'll have to dig around in the database to figure out what's going on. ❦ Llwy-ar-lawr • talk • contribs • 19:45 30 May 2019

Page creations had rev_parent_id set to NULL instead of 0, and MediaWiki doesn't know what to do with this. Fixed.

MariaDB [uncyc6]> update revision set rev_parent_id = 0 where rev_parent_id is null;
Query OK, 368112 rows affected (41.317 sec)
Rows matched: 368112  Changed: 368112  Warnings: 0

Check your contributions again -- the list now goes back to 2017. Now, you said there are edits that aren't page creations listed when you check the box? I don't see those. Would you point them out? ❦ Llwy-ar-lawr • talk • contribs • 05:51 31 May 2019

Edits that are not page creations no longer appear on this delimited list. July 2017 is when I joined, so everything's there. Thanks! Consider this fixed. -- (talk) 06:08, 31 May 2019 (UTC)

Uncyclopedia:Privacy policy

When hosted by Fandom, we simply used their privacy policy and relied on their contact form and bots to enforce it. Now, we have to develop one on our own. I figured we need SOMETHING there, so I put something there. Take a look and see what you think. Does it need more? Less? -- Simsilikesims(♀GUN) Talk here. 18:02, 3 June 2019 (UTC)

The question of handling a user who wants to delete their own contributions is awkward if that edit is just one among many in the middle of the article history, ie:

• Alice writes "ABBA is a group of dancing queens..."
• Bob edits this to become "ABBA is a group of drag queens..."
• Caroline edits this to become "ABBA is a group of drag queens. Their popular act is quite flamboyant and colourful..."
• Bob exercises his right to be forgotten, removing that one edit from the pile. The result is that the history appears to have Caroline adding the words "drag queens" and taking the blame if someone objects to that characterisation.

A possible alternative would be to leave the edit history intact, but replace the name "Bob" with "Inactive user 12345" or something innocuous, Alan Smithee style, so that Caroline isn't blamed for Bob's edits. I think Wikipedia has some sort of "courtesy vanishing" policy which does something like this? carlb (talk) 16:12, 4 June 2019 (UTC)

wp:Wikipedia:Courtesy vanishing ❦ Llwy-ar-lawr • talk • contribs • 18:48 4 June 2019

Not receiving email notifications

I am no longer receiving changed notifications of followed pages in my email for a couple weeks now. Why the change? -- (talk) 22:06, 3 June 2019 (UTC)

I changed the DNS settings on the 26th. Did the problem start before or after that? I might need to add an MX record. ❦ Llwy-ar-lawr • talk • contribs • 04:49 11 June 2019

I'm not sure, but it was around 26 May. Unfortunately, that email account dumped the trash already, so I have no exact date. I remain confused that I was still getting notifications after the move to .ca as I understood you to say that email addys were not carried over in the move. I never re-added mine. -- (talk) 15:55, 11 June 2019 (UTC)

E-mail addresses were not carried over in the move, until the user actually successfully logs in using their old user name. My special:preferences is currently showing "email carlb613@hotmail... email address was confirmed on 1 June 2015 at 19:00" which suggests that the data does pre-date the move. I'm doubting the MX record is the issue, as that's for mail *to* (whomever)@uncyclopedia.ca and MediaWiki only sends outbound notifications. Any chance that outbound mail is being flagged as spam at destination for, well, any of a million arbitrary reasons? carlb (talk) 17:20, 11 June 2019 (UTC)

Got it on the carryover. Nope, nothing from here is in my spam file; that goes back to 20 May. -- (talk) 21:50, 11 June 2019 (UTC)

There's a MediaWiki setting for whether email notifications about watched pages can be enabled in preferences. Its default value is false. The documentation appears to say that, if it's left at the default, these notifications are just not available. It was explicitly set to false in LocalSettings.php in the part generated by the installer; I've now set it to true. But this doesn't explain why you were getting watch notifications from this site earlier. It seems you shouldn't have been getting any at all, ever. Before I changed the DNS records, emails came from apache@<internal server name>, whereas now they come from apache@uncyclopedia.ca. I tested Special:EmailUser yesterday and found that email could be sent and received from that address. The change could make a difference to something at your end, but you say it's not in your spam folder... ❦ Llwy-ar-lawr • talk • contribs • 05:59 22 June 2019

Main page is not updating

Captain Obvious says the front page has not advanced since June 7. While this might be a fine parody of the fork, your immediate attention to the problem is appreciated. -- (talk) 03:20, 11 June 2019 (UTC)

You know, we don't have a daily feature, like the Good Old Days. 6 On this day on the Main Page has updated, for example. I think my Advertising is still the article most recently featured. Spıke 🎙️03:50 11-Jun-19

Yes. I've been meaning to put together some sort of proposed replacement process where the featured article stays in place until it's time to put up a new one. The current system results in "Warning: No results" on the main page way too much of the time. Has for quite a while, since before we came here. That said, I've noticed that the main page doesn't immediately update for anonymous users unless its entry in the file cache is deleted. I'd like to stop using the file cache, but now that we don't have Squid that doesn't seem like as good an idea. Need to figure something out. ❦ Llwy-ar-lawr • talk • contribs • 04:48 11 June 2019

When we had daily features, our current system was designed to help Admins by letting them queue up several features, each to take over at 0:00 UTC. It was a feature not a bug that, if the queue were empty, it became obvious. The current system has surely been overtaken by events. Spıke 🎙️10:16 11-Jun-19

If there is a way of recycling our 'greatest hits' when no new feature can be queued up has to be the answer. --RomArtus*Imperator ITRA (Orate) ® 11:58, 11 June 2019 (UTC)

I think pt: does that in some form, just a random <choose><option> including all of the "featured" blurbs. There was a DPL on fr: which tried to do the "if there is no new (< 5 days) feature, take an old one at random" automation you describe, but it hasn't worked since fr: escaped from Wikia in 2019. carlb (talk) 13:24, 11 June 2019 (UTC)

This would mean replacing one complicated, difficult (to maintain and/or implement) system with another. Putting a chunk of every featured article into a template would be a lot of work and probably result in a page so large that MediaWiki doesn't allow it. The default maximum page size, which I haven't changed, is 2048 KB. Right now there are 2684 featured articles, according to Category:Featured. The blurb for Advertising is 1744 bytes. Say that's the average blurb size. 2684 * 1744 = 4680896. You could have multiple templates. That still leaves the question of who is going to take the time to dig up every blurb and put it wherever. It could be only some of the featured articles, but then we'd have to figure out which ones...

I don't think it's a big deal to have one article stay on the main page for an extended period -- most readers who come in aren't checking that page regularly and won't know the difference. Having manually updated non-DPL content seems like the option with the fewest drawbacks. I've written up a system for doing this and a gadget to semi-automate it. See Forum:Proposed replacement for the feature queue. ❦ Llwy-ar-lawr • talk • contribs • 01:47 14 June 2019

As far as I know, whatever fr: was using would have worked except for two issues: (a) the "if something newer than five days exists, feature that" broke after the move, and (b) Lyrithya never rebuilt the categories, so "feature a random blurb from a best of (BO) category" is currently only displaying the few blurbs which were edited manually after the move. DPL should be able to return random-in-category if we keep this simple? carlb (talk) 14:44, 14 June 2019 (UTC)

This sounds more complicated than what I was imagining, which is just using <choose>. I don't know how it would be done exactly -- would have to look into it. We could implement it later, but for now the quickest and easiest thing to do is static content. I also think having DPL on the main page affects its performance, since User:Llwy-ar-lawr/main page seems to load a tiny bit faster than the actual main page (last I checked). (This probably has something to do with YFA having been left out, though.) ❦ Llwy-ar-lawr • talk • contribs • 01:40 22 June 2019

---

This works correctly now. -- (talk) 00:29, 23 July 2019 (UTC)

Fake main page

I leave it to you to decide if this page should be made to work like the current main page. -- (talk) 05:18, 21 June 2019 (UTC)

Would rather it be VFD'd. Uncyclopedia satirizing Uncyclopedia, we used to call Navelism, like contemplating our own navel rather than trying to amuse the outside world. All the foreign-language renditions of the Main Page are a waste of time and costly to maintain. This one, a rendering in baroque UNICODE characters, should be in someone's userspace. Spıke 🎙️11:49 3-Jul-19

Placeholder image is missing

This now appears as a redlink that just says "300px". I am not a fan of the blank square nor the earlier placeholder images. I've seen it ignored too many times in dumb ways, besides, like being left in place when other usable images were added to the page. If a message is to be sent, the AAP tag is more forceful. The real main problem is that, in general, nobody other than me is bothering to add lead images or any other images to old articles created by other editors.

So the placeholder lead image function is currently dead and I'd rather it be kept that way. Thoughts? -- (talk) 09:53, 22 June 2019 (UTC)

If you mean File:Placeholder, it's part of some Wikia-specific feature. I don't even know how we could have it here. Any instances of it should be removed. ❦ Llwy-ar-lawr • talk • contribs • 21:22 23 June 2019

Article count on main page does not update

Low priority

I have noticed in the past few days that the article count reported on the main page does not change. This is after several deletions via VFD and QVFD. This number used to fluctuate all the time, but maybe I am remembering times before the move to .ca . The number links to Special:Statistics, where that is linked to Special:AllPages that is linked as "Content Pages" on that Statistics page. -- (talk) 19:05, 23 June 2019 (UTC)

? I've seen it change multiple times. It may not be instant, but it's happening. Don't see why it would have frozen all of a sudden. It will probably sort itself out in another day or two. ❦ Llwy-ar-lawr • talk • contribs • 21:17 23 June 2019

It advanced yesterday to 32,217 while it was frozen at 32,216 for several days despite 5 articles being huffed in the name of QVFD in the last 2 days; 6 new articles certainly were not created in that time unless they were restored outside reported lists. I'll keep watching.

Sure, I've seen it change before and it was close to instantaneous. I follow this number as a sign of activity on Uncyclopedia. -- (talk) 20:33, 24 June 2019 (UTC)

I see this now only advancing upward. 32,223 at this point. My count of activity shows the number is reflecting additions only, including a template created, which should probably count. However, 7 pages have been huffed since 24 June including a disambiguation page. Looking at "All Pages", the huffed pages are gone as they should be, so obviously that file is not really being looked at by the system.

Is this DPL again? Then Death to DPL say I again. -- (talk) 23:45, 30 June 2019 (UTC)

At Wikia, some reports (such as the ones in the Maintenance tool) updated only "overnight." It could be, up here in the Dominions, that the schedule for this batch processing is different. Or nonexistent, or done only on reboot. Spıke 🎙️03:20 3-Jul-19

No, it's an internal MediaWiki thing. I don't know what's going on, but the article count on Wikia was somewhere above 32400, so I suspect there's a deeper problem involving something not being properly filled in. I tried running updateArticleCount.php, and the number is now 32,239. So much for that. ❦ Llwy-ar-lawr • talk • contribs • 06:07 3 July 2019

Nigel's observation that his QVFD deletions are not reflected in the count is not proof of anything; some of us are creating new pages at the same time. Spıke 🎙️11:46 3-Jul-19

Sorry, that's baloney. I'm fully aware that the count is dynamic. Unless new pages are created that are considered articles and do not report to "Recent changes", I stand by my observations. Yes, that would include new templates, new dab pages and suchlike. All one has to do is follow "Recent changes". Otherwise, where are these secret pages that are pumping up the count beyond what is observable? I suggest you examine the situation rather than make a royal pronouncement from the top of your mountain. Treating people like idiots is par for the course for you; curb your dog. -- (talk) 23:07, 5 July 2019 (UTC)

I ran a test just now. First I forced an update to the article count and obtained the number 32247. Then I deleted an article on VFD (Horton High School), then forced another update. This time the number was 32246. (No articles were created between those updates.) It looks like MediaWiki is reflecting deletions here properly, unless something is going wrong with the automatic updates it does. Since the automatic updating isn't instant, it's not as easy to test it.

Besides the updates normally not happening right away, another complicating factor is how articles are counted. Pages in multiple namespaces are considered "articles" -- as well as mainspace, there are 11 others, including UnNews (but not templates). Also, by default a page is only considered an article if it contains a link. This means that adding a link to an article that previously had none would increase the count.

I believe you saw what you saw, but I don't know if there is really a problem. I can't rule it out yet. If I'm right about the article count being way too low, seemingly erroneous increases could also be due to something gradually filling in. ❦ Llwy-ar-lawr • talk • contribs • 00:14 6 July 2019

Thanks for checking this out and giving a reasoned answer. The count has always been fairly quick to change but not instantaneously, whereas something like the Broken redirects page would/does only clear after a day or so, probably on a schedule.

Again, I consider this low priority and now should be moved to the bottom of the "to do" list. -- (talk) 02:37, 7 July 2019 (UTC)

Per-page custom CSS and icons

That is, the potato in the upper left corner was intended to be replaced by a special page-specific image in certain cases. The pumpkin potato is shown here failing to position correctly. This is obviously used on Halloween-related articles, like Halloween (holiday) AFAIK. Is this worth saving? Can it be prevented from being easily broken by any changes down the road? -- (talk) 01:30, 24 June 2019 (UTC)

Yes, this stuff works in Monobook but not Vector. I've been meaning to get to that ever since I found and fixed the problem with the stamp in {{FA}}. I can just extend the fix I did there. There's an extension that allows for easy replacement of the logo with a parser function, which is in use on the fork and Illogicopedia. I seem to recall it broke on the latter after a MediaWiki upgrade. Don't know if they ever got it working again; adjusting the current setup is probably a more stable solution. ❦ Llwy-ar-lawr • talk • contribs • 01:55 24 June 2019

Note to all: the FEATURED stamp may appear out of place if you've reached a featured article that has not been read since the fix. Refresh the page to purge and the stamp will be in its proper place.

Can you find the articles with other types of replacement header images easily? Otherwise, we need to report as we find these. I suspect that they were not all built the same way. -- (talk) 20:44, 24 June 2019 (UTC)

A different one: Dance. -- (talk) 04:09, 27 June 2019 (UTC)

And one that renders correctly: Lego Escher. -- (talk) 03:05, 30 June 2019 (UTC)

A lot of these use either {{logo}} or an element with the class logothing. I've changed the former so the option to just give an image link works. Doing it this way produces an image in the correct location, but the logothing method (used by the other way of using {{logo}}) still does not. I'll have to do more work on that. Ghost uses a different method, in this case a table. It may not be alone. Finding pages like that is not easy. ❦ Llwy-ar-lawr • talk • contribs • 06:26 30 June 2019

Aha. Lego Escher uses template logo|filename which works and is the method used in Wikipedia, referenced as I stumbled around; I couldn't find it mentioned/buried in WikiMedia. 120px is probably the max size. I used it to repair the logo for Fire; the ugly line showing is in the gif. If you give the okay we can use this and replace it in articles as we find them. Current editors are okay, but I hesitate to publicize this generally since somebody will go crazy with this. Maybe we can just require the Uncyclopedia blurb to be in the image to prevent abuse. -- (talk) 08:39, 30 June 2019 (UTC)

I'd tried to get {{logo}} to work when I created the page on Wikivoyage, but gave up and listed the custom logo in the MediaWiki sitewide .css; it looks like the fork is using an extension which allows users to create custom .css on a page-by-page basis? Carlb (talk) 17:37, 30 June 2019 (UTC)

Not with a MediaWiki extension; the "Reskin parser" in MediaWiki:Common.js lets individual pages or entire namespaces invoke a custom .css file. An Admin had to be convinced that your page or namespace needed this treatment enough to have it added to the list. Spıke 🎙️18:00 30-Jun-19

CarlB, template "logo" on Lego Escher clearly has a built-in limit of 120px; nothing displays if set larger. I see the logo for the Wikivoyage page is larger than that. -- (talk) 20:00, 30 June 2019 (UTC)

Yes, they are using mw:Extension:CSS. We were using the JavaScript method, but it stopped working (and broke the main page in Chrome browsers) after the move because document.write is no longer accepted, so I commented it out. If we want the custom CSS back, we'll have to either install that extension or fix the JS. I'd prefer the former, as it's easier to work with and probably better for performance. However, IIRC it wouldn't do anything for the logo issue because you can't use it to specify background images for security reasons. ❦ Llwy-ar-lawr • talk • contribs • 05:55 3 July 2019

"Report a problem" can use an "Add topic" tab/control

Plus, when the list gets long enough, do we archive old pages with resolved problems or what? -- (talk) 01:34, 27 June 2019 (UTC)

Good idea; done (by adding __NEWSECTIONLINK__ at the top). There's a little box with archive subpages. Another archive can be made if necessary. ❦ Llwy-ar-lawr • talk • contribs • 02:24 27 June 2019

https://uncyclopedia.ca/wiki/HOS

Not set as before with the highest number of features at the top of the page. RomArtus*Imperator ITRA (Orate) ® 11:17, 30 June 2019 (UTC)

We discussed this before; HOS uses DPL to build this table of authors from their individual feature pages, and the version used on this website seems to provide no way to sort in numerical order. At Forum:Technical problems on the new website#Hall of Shame Spıke 🎙️12:02 30-Jun-19

Yes, you're right. Thanks for the link. So we're currently stuck with this for now. Hope it can be fixed sometime. RomArtus*Imperator ITRA (Orate) ® 12:27, 30 June 2019 (UTC)

It is also not building the table from FA and hasn't for a long time. It looks like it was probably broken even before Wikia made the forced change to Oasis. HOS only reports 2 FA for me with the third oldest, Empire State Building, attaining FA status 22 Dec 2017, not appearing.

Death to DPL. -- (talk) 20:26, 30 June 2019 (UTC)

As far as I know, the lists of articles were always created and updated manually. Given the complexity of the issue, I don't think there's any way we could get DPL to do it for us. In the section Spike linked I've posted my suggested solution -- transcluding the subpages. Originally all the content was directly on Uncyclopedia:Hall of Shame, which might be preferable (or not). ❦ Llwy-ar-lawr • talk • contribs • 05:49 3 July 2019

Yes, editors have always had to maintain HoS/username manually. Romartus has done so for a long time on behalf of fallen-away editors. Spıke 🎙️11:42 3-Jul-19

It has been fixed! How did that happen?? Anyways, congrats. RomArtus*Imperator ITRA (Orate) ® 09:56, 6 July 2019 (UTC)

Happened because Llwy did what she said she was going to do: a manual solution that will have to be maintained manually. Spıke 🎙️10:35 6-Jul-19

Actually I hadn't yet. It fixed itself on its own. Baffling. Might still be a good idea to do what I was going to do, though, in case it breaks again. ❦ Llwy-ar-lawr • talk • contribs • 19:32 6 July 2019