Using MediaWiki as a CMS for Eleventy: Difference between revisions

From XPUB & Lens-Based wiki
m (Updated via Pöuli)
(Added to Tommi’s to-do list)
Line 1: Line 1:
<span id="context"></span>
== Context ==
== Context ==


Line 13: Line 12:
In my head, I had a faint idea of a solution that would avoid this issues.
In my head, I had a faint idea of a solution that would avoid this issues.


<span id="eleventy-backbone"></span>
[[Category: Tommi’s to-do list]]
 
== Eleventy backbone ==
== Eleventy backbone ==



Revision as of 21:05, 7 December 2025

Context

Since the beginning of the trimester, we (XPUB1 students) have been thinking about the best way to make a website for our first Special Issue, and the related event at Ubik.

All XPUB students use the wiki regularly, because it is a critical and ubiquitous tool of our learning process. Therefore, we all agreed that using MediaWiki (the software powering our wiki, as well as Wikipedia (this is why they look very similar)) would have been the easiest choice.

I asked Kim to give us an introduction to the MediaWiki API and walk us through the process she followed to make the website of the Special Issue 25. The workshop she hosted was super insightful. It helped a lot to (at least initially) overcome my terror for JavaScript and, even worse, my tremendous fear of APIs. Nevertheless, I see two major limitations with the approach Kim used.

  • It relies solely on front-end JavaScript: the HTML page the user visits is completely empty, and it’s populated with content only once the page has been fetched from the wiki. As a plain HTML lover, I want to avoid using client-side JavaScript as much as possible, and take advantage of it only when it’s strictly necessary to make something work. In our case, we would be asking the API to give us plain HTML ready to be published, so the page could be fetched beforehand, and just publish an HTML file.
  • Every time a website page is visited, the MediaWiki API is called. The more visits to a website page, the more API calls to fetch the same exact content. As the content will not be changing substantially too often, and above all because the XPUB Wiki sometimes goes down, it would be best generate HTML from cached pages.

In my head, I had a faint idea of a solution that would avoid this issues.

Eleventy backbone

I am a big fan and a heavy user of Eleventy, and I have never used the eleventy-fetch plugin, but I read many great things about it. This was the perfect occasion to learn more about it and put it to work.

I will skip introducing Eleventy, as we look forward to planning a workshop about it. For the time being, the essential information to get started is in the SI28 website repository README and in Eleventy’s docutmentation

I used AI to get some boilerplate code to start with. Of course it was not working, so I spent a couple of hours banging my head on it to make it work as I wanted to—not by prompting (🤮), but by debugging all functions step by step.

We need two JavaScript files. One contains the functions that get a Category, its members, and finally gets the content from the pages. As we want the pages belonging to this a category to become a collection, the second file is the default Eleventy config file, where we will be defining the collection by calling the function from the first JavaScript file.


This page was generated using Pöuli, and it’s part of PaJamas.