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.

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.

• https://en.wikipedia.org/wiki/Wikipedia:Wikipedia_Signpost/2023-02-04/Section_230
• https://www.thewetumpkaherald.com/news/fire-destroys-barn-hay-on-redland-road/article_4918d284-41c5-11ee-a4b3-8fe7b7060575.html

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.

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.

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:

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:

• The server gets the URL path you are trying to access (in this case, /2023-02-04/Section_230).
• It processes this into the appropriate Wikipedia page (in this case, Wikipedia:Wikipedia_Signpost/2023-02-04/Section_230).
• It uses the MediaWiki Parse API to get the HTML content of the page.
  • https://en.wikipedia.org/w/api.php?action=parse&format=json&redirects=true&page=Wikipedia:Wikipedia_Signpost/2023-02-04/Section_230
• It processes that content to do a few things, like fix URL paths (i.e. the "back to contents" link should go to https://signpost.news/Archives/2023-02-04 and not https://en.wikipedia.org/wiki/Wikipedia:Wikipedia_Signpost/2023-02-04/Section_230).
  • It also adds a couple things, like page titles, a favicon link, and various meta tags for search engine indices and preview cards on Twitter, Facebook, Discord and the like. It also adds a sub-header link bar for various departments and pages, as well as a sub-footer row with links to the original en.wp location of the page, the Sinepost source code, and the Creative Commons 4.0 license.
  • It also loads a style sheet from Wikipedia:Wikipedia Signpost/Templates/external.css, which is why looks like a pizza menu from 1979, which is what I'm given to believe is de rigeure among modern, dynamic, digital-first, disruptive, and trendy 2020s news websites.

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.

"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 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. 704) 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.