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.

• With an understandable and customizable code by our developers.
• To generate an API Rest.
• That it had a content editor prepared to work in blocks.
• Purely done with JavaScript.

A static generator :

• That created the entire front of the web as fast as possible.
• Full control over the generated code.
• Developed in JavaScript.

And micro applications. For the dynamic parts of the web:

• Comments management.
• Searches.
• Also surveys.

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:

• That the changes made from the CMS were quickly reflected on the web.
• Maintain the option to add comments to articles and that when there is a new comment the article author is notified.
• To be able to display portions of code with their color and tabs within articles.
• To be able to schedule the publication of articles.
• Power preview articles so that our editors can see how an article looks before it is published.
• Do not lose efficiency or capacity in the definition of SEO tags.
• Management of URL redirects, so as not to penalize SEO.
• Continue to maintain the English version of the site.
• To be able to add several authors to an article.
• Maintain the versus surveys.
• Show related articles.
• RSS for the news feed.

It has some strong points that we really like:

• It has a very simple and understandable architecture .
• It is easily customizable.
• It is completely done with JavaScript . Strapi is developed with React, but the part that we must touch in order to customize it is native JavaScript.

On the other hand, it also had some scary risks:

• When we started it was still in Alpha version. Right now it is in Beta and many problems have already been solved, but it still lacks the maturity that other CMS already have.
• The content editor is too basic , since it can only be edited in Markdown mode, making it impossible to use visually complex code blocks.
• The management roles, to restrict access to parts of the administration is not yet developed. But despite these risks, knowing that the problems we have encountered are temporary (and their many advantages), has made us opt for Strapi as our new content editor.

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:

• We have developed and integrated a new content editor, to make it easy to create and edit content and use all the blocks that our designers had created.
• We have created some new services in the API to be able to easily import all the articles, events, authors ... from our WordPress.
• We have modified some services in the API so that it only shows the records visible and with a past publication date. We have also created new ones to be able to consult the records with a future publication date, in order to preview them.
• Created specific fields for SEO.
• Add a module in the administration panel to be able to launch the web compilation process when the editor wishes.

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:

• Simplicity of use, but powerful.
• Full control over the generated code.
• 100% JavaScript .
• Good documentation , and very fast support from its creator (Zach Leatherman).
• It gives you freedom to use any template engine. In our case, we use Nunjucks.

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:

• Simplicity: now the administration is easier, since we avoid all the extras that Wordpress gives you and that are not usually used.
• Being silly is cool: by having only static HTML published we improve security and the response speed is much better than before.
• Control over data: we now feel that we have better access to data and that makes it easy for us to change in the future. As everything is decoupled and more localizable, it will be much easier to do another migration in the future to another system, both CMS and static generator.
• Be up to date: now we are cooler. Make no mistake, it is cool to say that you work with the latest technologies and now we do. And we leave behind that bad reputation that WordPress always carries with it.

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:

• Available time: For me, it is still faster to make a website with WordPress. But solving this is a matter of continuing to gain experience.
• Profiles assigned to the project: Traditionally a WordPress project was carried out by a single developer, in charge of configuring the CMS and designing the front. This model for me is no longer valid and you must have a developer to manage the CMS, at least one for the front and another for managing the servers.
• The need for dynamic parts: HTML has many advantages, but if your project is going to have many dynamic sections, in which the user can interact, alarms will go off. You no longer have the range of WordPress plugins and you may have to chop them yourself.
• And the implication of systems: before in a WordPress project the involvement of systems was minimal (well, except for security management), and with this new system, I think they must be much more involved.

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.