Using MediaWiki as a CMS for Eleventy - Revision history

Tommi: Updated via Pöuli

2025-12-12T13:13:33Z

Updated via Pöuli

Tommi: Added to Tommi’s to-do list

2025-12-07T19:05:32Z

Added to Tommi’s to-do list

← Older revision		Revision as of 21:05, 7 December 2025
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 ==

Tommi: Updated via Pöuli

2025-11-11T15:58:07Z

Updated via Pöuli

← Older revision		Revision as of 17:58, 11 November 2025
Line 6:		Line 6:
	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.		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.		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 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.		* 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.
Line 18:		Line 18:
	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 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 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 [https://git.xpub.nl/XPUB/SI28 in the SI28 website repository README] and in [https://11ty.dev/docs/ 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 <q>prompting</q> (🤮), but by debugging all functions step by step.		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.		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 -->		<!-- START AUTO-GENERATED SNIPPET -->
	<noinclude>		<noinclude>

Tommi: Updated via Pöuli

2025-11-01T11:39:20Z

Updated via Pöuli

New page

<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

<noinclude>


<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>