Jump to content

Wikipedia:Wikipedia Signpost/2023-08-31/From the editor

Add links
From Wikipedia, the free encyclopedia
The Signpost
← Back to Contents
View Latest Issue


From the editor

Beta version of signpost.news now online

Contribute   —  
Share this
By JPxG
https://signpost.news — the website of tomorrow, today! in about a week when I am back from my vacation and get around to finishing it!

Over the last twenty years, much effort has been made to provide a wide variety of diverse ways to read The Signpost. Through the diligent work of industrious minds, we've crafted for ourselves the ability to stay in touch with our readers through notifications via email, feeds for RSS, posts on Facebook, tweets on Twitter, toots on Mastodon, glorbs on Kaffr, plovs on Quimbl, zelps on Frangus... kids these days don't know what it was like to while away the days Zelping on Frangus. And that's sad.

Anyway, all of these roads lead to the same place, which is https://en.wikipedia.org/wiki/Wikipedia:Wikipedia_Signpost.

But really, must this be the only way to read it? Try showing a Signpost article to someone who isn't an English Wikipedia editor.

My personal experience is that the conversation starts out with explaining the difference between a "Wikipedia page" and a "Wikipedia:" page — by the way, normal pages are called "articles", the term "page" just refers to all namespaces — what do you mean, you don't know what namespaces are? — we will get to that later — anyway, no, these aren't Wikipedia articles — well, they are articles, and they are on Wikipedia, they just aren't Wikipedia articles because they aren't in mainspace — oh, that is just what we call the primary namespace where the page title has no scope specified — no, the stuff in Signpost articles is not the official opinion of the whole English Wikipedia — yes, even though it's hosted there — well, okay, we can get brought to noticeboards or have pages deleted at MfD — that stands for "miscellany for deletion" — yes, M-I-S-C-E-L-L-A-N-Y — no, that's the official name of the process — wait, hold on, let me link you a few more things — yes, you'll be prepared to read the Signpost article in a few minutes...

In the last few months I have been giving some serious attention to the way that newspapers are run, and the way newspapers are structured — it turns out the answer in 2023 is usually "on the computer". But so long as we're on the computer, it is worth taking a look at the specifics.

Whether it's the New York Times, the Washington Post, Le Monde, Gawker, the Daily Mail, or the Wetumpka Herald, most news sites are easily recognizable as what they are; they provide some basic features like headers, navigational bars, sidebars, and overall purposeful website design to surround their engaging high-quality journalism. Well, okay — to surround their article content. But even if it is trash, it is trash on a fancy plate with shiny utensils.

The Signpost has accumulated a pretty decent collection of flatware over almost the last nineteen years, and — at least in my admittedly-biased opinion — the entreés are top-notch. But there are some shortcomings.

Limitations and woes

This article in the Wetumpka Herald starts with some clearly-indicated navigation links ("About us", "Contact us", "Contests", "Crossword", "TPJ Joboard") and login links, then indicates clearly that it's from the Wetumpka Herald, whose logo is the first thing on the page. There's a navigational header for the newspaper, then the headline and byline that tell you it's an article about some stacks of hay catching on fire.

This article in The Signpost starts with a hamburger menu icon, then the Wikipedia logo, then a search bar for the English Wikipedia. Then it has login links, then "Wikipedia:Wikipedia Signpost/2023-02-04/Section 230" — which isn't the headline of the article — in huge header text, then links to "Project page", "Talk", "Read", "Edit", "View history", and "Tools". After that, we have "From Wikipedia, the free encyclopedia", then "< Wikipedia:Wikipedia Signpost‎ | 2023-02-04". Several inches down the screen, we have the Signpost logo, our own navigation links, the issue date and the article's headline.

Conversely, linking the Wetumpka Herald article on Facebook, Twitter or Discord gives a preview card that looks something like this:
https://www.thewetumpkaherald.com/news/fire-destroys-barn-hay-on-redland-road/article_4918d284-41c5-11ee-a4b3-8fe7b7060575.html

The Wetumpka Herald

Fire destroys barn, hay on Redland Road
It could have been worse.

Linking the Signpost article gives this:
https://en.wikipedia.org/wiki/Wikipedia:Wikipedia_Signpost/2023-02-04/Section_230

Wikipedia:Wikipedia Signpost/2023-02-04/Section 230

That's it: just the page name. Since Signpost pages are in projectspace, we don't even get a snippet of the content in the preview, like normal articles do.

Meanwhile, a Google news search for Fire destroys barn, hay on Redland road returns the Wetumpka Herald as the top result; a Google news search for Twenty-six words that created the internet, and the future of an encyclopedia returns nothing.

Finally, our URLs are highly constrained and baroque, in a way that makes sense from a technical perspective (and believe me, I've become quite familiar with said perspective lately) but makes no sense from a reader's perspective.

Our URL says "Wikipedia" three separate times (and "wiki" four times) for no apparent reason. It's a mouthful to say, an eyeful to look at, and a handful to type.

Why?

These issues are a natural and unavoidable consequence of the extremely unique nature of The Signpost's content management system; as far as I know, it is the only periodical on the entire Internet which uses the specific tech stack of content being served by a combination of pages composed by JavaScript/JQuery publishing scripts, Lua modules maintained by Python scripts, and English Wikipedia template logic to implement MediaWiki markup on a MW PHP/MariaDB backend. Certainly, it is the only such periodical that's been in continuous operation for nearly nineteen years. It's called "Wikipedia:Wikipedia Signpost" because it exists in Wikipedia's projectspace, was named "The Wikipedia Signpost" in 2005, and subsequent discussions that changed its name to "The Signpost" didn't involve actually renaming the pages because nobody wanted to run an unbelievably gigantic AWB mass-move job and afterwards spend a week having every template and thousands of pages be hopelessly broken for the sake of removing ten bytes from the URL.

Website listings in Google News, Apple News and the like require DNS records to be added by the root domain's owner; it would be impossible for us to mess around with the DNS records for all of wikipedia.org, a site in the top 10 of traffic worldwide. Moreover, even if we could, it would be the height of absurdity to claim all of wikipedia.org as exclusive Signpost turf in the eyes of Google News!

Similarly, preview cards for social media sites are very simple, but they are scanned out of attributes in pages' HTML <head> elements. There's no way to specify them in body content, i.e. where all of the visible text goes, which means that with the way MediaWiki is set up it's impossible for us to implement this on The Signpost on Wikipedia. And even if we were able to convince all of the English Wikipedia's top brass to let us mess around with the raw HTML of our pages, it's not really clear how this would happen: it would probably involve shoving some hoopty MediaWiki extension into en.wp's already-heavily-modified MW install, at the risk of busting the whole site for billions of users.

What is to be done?

Well, luckily, your editor-in-chief is a galaxy-brain geniouse [sic] electron wrangler, meaning that fixing these issues in a way that looks cool and doesn't break the current functioning of the Signpost is a simple one-day project.

Two-day project.

Three-day project.

Okay, I am on day eight. But to be fair, I had everything except the domain name working on day six. It wasn't my fault Toolforge's Kubernetes ingress settings don't permit external domain names to resolve to tools, and that I had to reconfigure everything to deploy to my own VPS, and that I had to figure out how to do a reverse proxy through Apache so that it could keep serving normal pages for a different domain while routing signpost.news queries to a different port for the same protocol.

It was my fault that I had to spend a whole night galloping the VPS through six years of procrastinated Ubuntu distribution upgrades before I could get current versions of the application's dependencies to run right.

It's up for debate whether it is my fault that I'm deploying a complicated Web application immediately before taking a four-day out-of-town trip where I have virtually no Internet access; reliable fact-checkers indicate that the answer is a "mixture of true and false".

Anyway, here is what it is:

The signpost.news stack

Since you have already soldiered through quite a lot of text on this page, I will restrain myself here to a brief overview.

What I have running on signpost.news right now is Sinepost, a lightweight Express application I wrote to act as middleware between the client (the reader) and backend (the Wikipedia). Essentially, what happens when you go to a page there — like https://signpost.news/2023-02-04/Section_230 — is this:

One thing you'll notice about this is that, unlike most webapps, the backend isn't a database stored on the signpost.news server. The backend is this: the existing Signpost pages, as they are right now, here on en.wp (although it's possible that in some disaster scenario, like the often-predicted-yet-never-happened Death of Wikipedia, it could be reconfigured to fetch pages from other MediaWiki sites). This means that, rather than an extremely painful process of replacing the Signpost structure and content and template ecosystem, the application simply augments it with an improved interface and design. This means, further, that this application doesn't require any sort of separate process to write, publish, or maintain pages beyond what we already do. Everything that happens here happens there instantaneously.

Essentially, the application (I will never write an "app") is set up to serve as a presentable frontend for a system which has worked well, continues to work well, and has almost nineteen years of attestation to that fact.

The beauty of choice

"This sucks," you may be thinking: "it looks like crap and I hate it".

First of all, please tell me how, because hitherto the only people who have been able to evaluate this are my friends whose necks I keep breathing on while I look over their shoulders and command them to "keep browsing". If possible link to a screenshot, because I have not tested this on every browser and device yet, and while it looks fine on my computer and my girlfriend's computer, it would be nice to have a broader evaluation.

Well, it is a free country. You will be pleased to hear that the existence of this application changes nothing about the experience of reading the Signpost on Wikipedia, which will always be possible, and if you hate the idea of a slick web interface, you will lose nothing by ignoring it completely. There is not going to be some social media scenario where we cram the .news domain full of ads and user-hostile engagement-maximizing anti-features while slowly pushing the original site's content model behind an increasingly onerous litany of opt-out settings, API restrictions and planned obsolescence.

What is next?

What you see at signpost.news right now is a minimum viable product; it's a start. It's basically what I could get out the door in a week before leaving on a long trip with no Internet service. There is a lot of work that remains to be done.

  • Design
Most importantly — because this is the most visible thing, and I am sure it will feature heavily in feedback — the current design of the site is not intended to be its final form. The fonts and shades are the best I could come up with in an afternoon of playing around with various things. It could probably do with a bit more color, and the formatting of articles could do with a bit more customization.
  • Styles
You will note that a few things, like image gallery elements or collapsible boxes or sortable tables, do not render as they do on-wiki. This is not inevitable — there are stylesheets and scripts that can be loaded to make these work — but I have not had time to implement this for everything yet. There are also some things that could (and probably should) be done, but are difficult to do right now because not all Signpost elements have distinct classes and rules sometimes work in unexpected ways.
  • Code
Should you venture into the Sinepost repository, you will notice that a lot of the code is a dog's breakfast. This is definitely not in its final form; lots of stuff (like base URLs, paths, and header/footer content) is hardcoded because of time constraints. In the future, this stuff will be drawn from templates or files on the webserver, or even from Signpost pages on-wiki (like "external.css" already is). Moreover, the code is just fugly in a lot of places, and stuff like 404 handling is not dealt with very beautifully.

Overall, there are a few things that do not work as they should — one of my favorites is that the search box on https://signpost.news/Archives just dumps you out to a Wikipedia search where if a query gets no results, it defaults to showing results for the query minus its quotation marks, which means that it is easy to get giant walls of irrelevant nonsense. In general, Signpost styling is somewhat inconsistent; while most pages and templates use TemplateStyles, many have inline styles that are declared in div or span tags themselves within the wikitext source. Hunting these down and moving them to more general stylesheets is a long and complicated task.

Moreover, there are a bunch of things that are just strange or busted for no apparent reason; as a trivial example, when trying to get {{Signpost/Number of issues}} (i.e. 703) to work properly, the numbers kept being off by a few, and I discovered there was such a thing as a ghost issue, where an issue page (like Wikipedia:Wikipedia Signpost/2013-06-17) existed but had no subpages (i.e. no articles) and was never actually sent out to subscribers. One of these would be enough of a mystery — but there were twelve!

But that kind of thing is enough for an article of its own, and I did say I would keep this short. So let me know what you think, and I will do my best.

← Previous "From the editor"
Next "From the editor" →
+ Add a comment

Discuss this story

These comments are automatically transcluded from this article's talk page. To follow comments, add the page to your watchlist. If your comment has not appeared here, you can try purging the cache.

New site looks beautiful, but note that pages such as https://signpost.news/Newsroom/Quick_Start have links to edit such as https://signpost.news/w/index.php?title=Wikipedia:Wikipedia_Signpost/Newsroom/Quick_Start&action=edit&section=1 which pull up errors:

An error occurred
500
TypeError: Cannot read properties of undefined (reading 'redirects')
at Object.fetchAndProcessData (/root/2023-aug-sinepost/sinepost/controllers/wikiController.js:14:29)
at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
at async /root/2023-aug-sinepost/sinepost/routes/index.js:48:25

Nice job otherwise. ―Justin (koavf)❤T☮C☺M☯ 00:54, 31 August 2023 (UTC)[reply]

Oh, yeah. I am not really sure how to implement section-edit links for now, and had meant to .mw-editsection { display:none; } but forgot. jp×g 01:13, 31 August 2023 (UTC)[reply]

Could you send me the newspaper to my email inbox, like an email newsletter? Benjamin (talk) 02:59, 31 August 2023 (UTC)[reply]

So this is a live mirror with no caching? -- John of Reading (talk) 06:29, 31 August 2023 (UTC)[reply]

Yeah, if you write "peepee poopoo" in this article and then go to it over there it'll show up lickety-split. I have some vaguely defined future plan to set up a caching system (since right now my server has to transfer the data twice for each query) but while thinking about this in the shower I realized it would be pretty complicated and require a lot of work. We will see how motivated I am when I look at the hosting bill next month, I guess. jp×g 09:06, 31 August 2023 (UTC)[reply]
Note: I would suggest that anyone interested in actually doing this come up with a different string to test with, and do it on some page that isn't from the current issue. jp×g 09:22, 31 August 2023 (UTC)[reply]

Interesting idea, I will say the thing that stands out most immediately is the yellowed paper look of the website, not exactly appealing in my opinion. —The Editor's Apprentice (talk) 08:25, 31 August 2023 (UTC)[reply]

This looks pretty promising, thank you for the immensely hard work you're putting in! I've taken a quick look at the various sections, and I'd just point out a few graphical issues. Firstly, some of the pictures included in the articles look misplaced and tend to "invade" quotes (see this page for context); secondly, I think you could just stick to the "standard" layout used here, that is, white background and blue hyperlinks, instead of rose and grey, or maybe you could just use an ever lighter shade of rose! Finally, the bold font used for the articles' headlines and paragraphs is a bit too hard-hitting for the eyes, but maybe my myopia is the one to blame in this case... On a similar note, what about including an option to switch from light to dark background, and vice versa? Anyway, keep it up! : ) Oltrepier (talk) 09:47, 31 August 2023 (UTC)[reply]

This whiffs of the URL shortener problem to me. When the mirror inevitably ceases to function (and I do think it's inevitable) and assuming it sees much use (though I don't think it will, which adds to the inevitability) are we not just generating future dead links? I suppose directly translating from en.wp to sp.news URLs does mitigate the issue somewhat (I can search "2023-08-31/From_the_editor", for example, and get to the Wikipedia article just fine) but I remain very wary. Tantusar (talk) 10:55, 31 August 2023 (UTC)[reply]

Well, in that case, due to the URL structure, I could do what was on signpost.news for about a year before that (a simple DNS redirect from the root domain to https://en.wikipedia.org/wiki/Wikipedia:Wikipedia_Signpost/*). This costs somewhere on the order of a couple hundred bucks per decade, so maybe we can hold a "fun raiser" of sorts. jp×g 19:07, 31 August 2023 (UTC)[reply]

Feedback: I enjoyed the new site of The Signpost. However, it felt that this site needs some improvements. Basically what I mean is that, even though the it is in the beta stages, I would suggest adding more features to be level to other news sites. No mobile view (which can be hard for users to read its content in some cases), no share links, search bar behind the "Archives" section, lack of illustration on the main page, and others. Overall, the site fells like one browsing a site in the 2010's. While some features are okay, like the yellow tint, it would be favorable to add such features. Toadette (chat)/(logs) 11:45, 1 September 2023 (UTC)[reply]

Hot dog!! JPxG you've done a gorgeous, uplifting thing. I happen to like the look of the site very much ;~). And you imported the backlog with all of its tags... it took me all of ten seconds to satisfy idle curiosity and track down some ancient history on early Wikimania coverage. – SJ + 22:24, 1 September 2023 (UTC)[reply]

I think this is a pretty cool initiative ! When i get back from vacation ill take a deeper look. —TheDJ (talk • contribs) 09:03, 2 September 2023 (UTC)[reply]

I'm confused by the comparison of Wikipedia URLs with The Wetumpka Herald URLs. Surely ours are better than the fugly UUID in the Herald URL? 93.72.49.123 (talk) 21:53, 2 September 2023 (UTC)[reply]

Beautiful, incredible, amazing, wondrous, dope, awesomesauce, etc. Thanks! Can't wait to see where this goes! Crunchydillpickle🥒 (talk) 01:25, 4 September 2023 (UTC)[reply]
Want the latest Signpost delivered to your talk page each month?
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Wikipedia_Signpost/2023-08-31/From_the_editor&oldid=1193882224"