View source for Using MediaWiki as a CMS for Eleventy

<span id="context"></span>
== Context ==

Since the beginning of the trimester, we ([https://pzwiki.wdka.nl/mediadesign/Students#2025/2027 XPUB1 students]) have been thinking about the best way to make a website for [https://pzwiki.wdka.nl/mediadesign/Writing_Machines%E2%80%93Protocols%E2%80%93Feedback our first Special Issue], and the related event at [https://worm.org/spaces/ubik/ Ubik].

All XPUB students use [https://pzwiki.wdka.nl/mediadesign/Main_Page the wiki] regularly, because it is a critical and ubiquitous tool of our learning process. Therefore, we all agreed that using [https://mediawiki.org 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 [https://pzwiki.wdka.nl/mediadesign/User:Kim Kim] to give us an introduction to the MediaWiki API and walk us through the process she followed to make the website of the [https://hub.xpub.nl/cerealbox/Special-Issue-25/view.html Special Issue 25]. [https://pzwiki.wdka.nl/mediadesign/Wiki_Website_Workshop%20‘Wiki%20Website%20Workshop%20–%20XPUB%20Wiki The workshop] she hosted was super useful 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.

<span id="eleventy-backbone"></span>
== Eleventy backbone ==

I am a big fan and a heavy user of [https://11ty.dev/ Eleventy], and I have never used the [https://www.11ty.dev/docs/plugins/fetch/ <code>eleventy-fetch</code> 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 any introduction about Eleventy, getting straight to fetching pages from MediaWiki.

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 <q>prompting</q> (🤮), 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.

<span id="challenges"></span>
== Challenges ==

* How to automate builds every time a page is changed on the wiki
<!-- START AUTO-GENERATED SNIPPET -->
<noinclude>


<!-- Cross-posting disclaimer banner -->
<div style='display: block; color: #FFF; background: #D00000; padding: .5em 1em; margin: 1em auto 3em; width: calc(100% - 6em); box-shadow: 5px 5px 0 #000'>This page was generated using [https://codeberg.org/tommi/poouli Pöuli], and it’s part of '''[[User:Tommi/PaJamas|<cite>PaJamas</cite>'''.]]</div>

</noinclude>
<!-- END AUTO-GENERATED SNIPPET -->