My experience with WordPress has always been good and, although you have to understand that WordPress has some associated problems (mainly security for me), it also offers many advantages. I have managed to make complex websites with relative ease and quite a bit of control over their workflow.
That said, with the new change of brand of Paradigma, such a radical change of the web was associated, that without a doubt we would have to start from scratch, since almost all the previous structure changed. After studying the available options we knew the model we wanted. It had to be a structure in which the data and the front were decoupled.
It must be something like this:
A CMS:
It had to be simple and intuitive to be used by our editors.
A static generator :
And micro applications. For the dynamic parts of the web:
With this new system, they expected to gain a lot in security and in response times, but it should also continue to be as functional as WordPress was for our editors and developers.
We had the challenges of not losing any of these points:
It has some strong points that we really like:
On the other hand, it also had some scary risks:
Installing and configuring it is very simple. I was going to explain how, but I think you better look at it directly in its documentation, which is very well explained.
Strapi did not fit 100% with our needs and we have had to make some modifications to make it the CMS of our lives:
To select a CMS we doubted more, but for the static generator it was quite clear from the beginning that the winner would be 11ty, since we did not find any apparent risk, but many strengths:
The first thing Eleventy does when faced with a construction process is to obtain the data that it will later use to paint the HTML.
This information is found in the folder _data.
. Each file it finds will return a collection of data that can be referenced in any template. In that file you can return a JSON directly or obtain it by making a request to an API, as in this case:
In this case, a request is made to Strapi to obtain the entire list of job offers that we show on the web. Subsequently, its content is parsed to cover viewing needs. And finally, the result that will save a variable jobs (name given by the file name) with the resulting list is returned.
Once we have all the necessary data, we begin to "paint" each of the templates. I keep all of them inside the folder _pagesso they are more organized, but they can be wherever you want. Each file inside _pages will end up being an HTML (or several if there is pagination).
What does Eleventy understand by paging? For example, an item listing is paging. Until then it was very clear to me, but the template that paints the detail of each of >those items is also a pagination of 1 element per page.
For a file to be considered a template, come on, it ends up being a file in the final construction, it must have is that it has this structure :
1
2
3
4
permalink: /blog/index.html
title: Mi título de ejemplo
---
<h1>{{ title }}</h1>
The variables that we define in the first lines, among the symbols of ---are called front matter, and we can create as many as we want for later use.
Eleventy allows you to use the base layout to be able to extend them by means of blocks, where you can inject the content of each of our pages and use the data collections, filters, and imports of other files. All this explained quite well in its documentation.
We have improved on all these points:
Let's be honest, all that glitters is not gold and in some ways, we were better before the change:
Getting out of the comfort zone is scary and costs money. We have taken much more time to get things that with Wordpress would have been faster. But this is not a point against the new system, it is simply a consequence of changing from one technology that you control to another in which you are a novice.
WordPress is used by everyone and that has its problems, but also its advantages. Any problem you encountered with WordPress had happened to someone before and their solution is documented on the internet. Therefore, we now have less documentation at our disposal.
To carry out this new model, much more support is needed from the systems department, since where you used to have a single server, now you have three. In addition, they have to communicate with each other and be very well configured. This is something that we did not value well at the beginning of the project and it has been one of the parts that have brought us the most problems in the end.
And the same thing that happens with servers happens with applications, where before you only had to train in WordPress now you must control and manage several applications. Of course, simpler each of them separately.
In my opinion, the final decision depends on factors such as:
Having said all this, controlling all these problems and forgetting these six months of hard work, I still want to further refine this model and continue betting on it in future projects.