It is old-man-shouting-at-clouds time.

“Get off my lawn, clouds! And stop mixing my metaphors!”

A bunch of years ago I started writing down my pet peeves, convinced that I would end up with a hefty list. ‘Peeves’, because, well that is what they are; and ‘pet’ because I would rather have them than solve them.

The list never grew to a significant size, so perhaps it is time to release the few I have gathered into the wild. Here goes:

Peeve 1. Histories of countries that go back considerably further than the country could reasonably be said to have existed. Neither historians nor encyclopaedians need be nationalists, and if they are, they should state so upfront.

I can make an exception for histories of the terroritory that a country currently and accidentally occupies, as long as those histories are rewritten everytime a border changes, i.e. every 5 or 10 years or so.

I could give you an example, but … it is all the countries, I am afraid.

Peeve 2. The use of the word masterpiece to describe anything other than a work or a coherent series of works made by an apprentice to prove that they have mastered the profession they have been training for.

I am willing to forgive the entire lack of an apprenticeship because, honestly, who does those anymore? I draw the line at one masterpiece per artist though.

Peeve 3. Something bothers me about tips – i.e. nodules of knowledge, specifically the suggestion that experts in a field are keeping small, easy to grasp bits of knowledge or skill close to their chest, but these nodules, once revealed, immediately make the recipient productively skillful or knowledgeable.

That is not how knowledge or skill works.

That is not to say that genuine tips do not exist. If I see someone struggling with mastering a certain skill and it takes me back to my own problems learning the same thing and what I needed to do to get over the hump… sure, I can share that story. That would be a genuine tip.

Any listicle that claims to contain tips does not contain tips, though.

Here is a photo for those who want to see what a Smartwares RM149 smoke detector looks like on the inside.

I opened one after it produced a false alarm in the middle of the night (apparently you need to vacuum them regularly to prevent bugs or dust from blocking the sensor) to see if I could see the blockage.

As you can see though, the sensor is in its own housing (the round black thing with the pencil marks) and I did not feel confident I could open it without breaking things, so I did not.

The metal plate in the right element lines up with the three springs in the top right of the left element.

The two elements are attached with four plastic clips (seen on the left element) and a small phillips screw (seen peeking through the battery compartment in the bottom right of the left element).

In the past 25 years I have had a bunch of web hosting providers turn bad.* Meaning I have had to look for new ones every 4 years or so. That may make me somewhat qualified to tell you how to select a new hosting provider for your website.

Or it may say something about me, namely that I am unfit to pick reliable hosting providers.**

But hear me out; I may be wrong, but I am also somewhat experienced.

When looking for a new web hosting provider, the following selection criteria keep popping up.

– Advertised technical criteria: bandwidth, storage and so on. These are basically the only criteria you can use to compare between providers.

– Basic support: how easy is it to get support for basic problems? For example, you tried to set up a second mailbox but something went wrong and now you need help fixing it. Some of this can be measured, e.g. when the hosting provider says they only provide support during weekdays, or when they will help you move your site between providers, but won’t help you set up new mailboxes.

– Crisis support: what happens when a server keels over? This has happened several times to me and there can be stark differences in the urgency with which a hosting provider tries to right their ship. Unfortunately, due the rarity of these cases, this is typically only something the quality of which you find out once it happens.

– Age. I mean, what is this provider’s life-cycle and at which stage are they now? Presumably providers start by paying for a lot of equipment upfront. This is a great time to be a customer, because your sites are hosted on brand spanking fresh stuff, top of the line, for competitive prices. Then the providers sit back and count their money, while gear ages out of relevance, quietly, in the background. Every new provider you discover offers the opportunity to discover a new Ponzi scheme.

Granted, I do not actually know if this is how it works. What I do know is that my customers and I have had several instances where we suddenly found ourselves on a server that was consistently a lot slower, which at the very least suggests that providers keep their old hardware around.

– Sharing. Sharing is good, right? Most providers share the hardware on which your site runs with dozens if not hundreds of other customers. This makes it so they can charge you 10 euros a month for hosting instead of 300. Sharing is possible because most websites only receive a few visitors per day. If you had the server to yourself it would be idling most of the time. Most web servers should be able to serve a few dozen visitors per second, let alone a day.

One thing, however, a provider can do to deal with rising operating costs is split the server beyond what would be good for your website. First it is 30 users per server, then 60, then 600. Unfortunately, visitors that have to wait a long time to receive a webpage from a busy server tend to leave at some point.

– Reputation: not many of the above criteria are measurable. In the end, the only way to decide is to look at the reputation of providers.

So what is my advice?

If you are looking for a hosting provider, make sure you compare the metrics that you can compare; then pay a lot of attention to reputation. If a close friend with very similar needs to yours is ecstatic about their hosting provider, that should probably count for more than if a hosting provider checks all the checkboxes, metrics-wise.

If you are happy with your provider, always keep an eye out for signs of trouble. A good sign can be when something goes wrong, but the provider immediately and flawlessly fixes it. Providers that learn are a good sign. Providers that, as I have had happen recently, try to force you onto a new product that seems worse than the old one and expect you to pay 3 times as much for it — those are a sign of trouble (regardless of whether the new product objectively makes sense).

Basically, how providers deal with challenges may not always be transparent, but it always seems educational.

Footnotes

* A couple of patterns emerged. The most common was: hosting provider gets bought by bigger fish, hosting provider turns to garbage.

This is not necessarily an indicator that the bigger fish is garbage. Bigger fish can engage in asset stripping, where they keep the customers that overpay by orders of magnitude and try to entice the rest into buying a different product, by reducing the service on the current product.

If that happens to you, your best bet is to get ready to move to a different provider. Unfortunately you don’t always realise on time that that is happening to you.

The other pattern then is logically the smaller, fiercely independent provider who gets things wrong because they simple lack the knowledge and experience that being big can bring.^

** “But Branko,” I hear you say, “you are a web developer. Should you not know this?”

The thing is, new customers are not new to the web. They already have a site somewhere and that is where they will host the next one. It rarely happens that I have to also recommend the provider. ^

I was hired recently by two companies to upgrade their Drupal-based websites from D9 to D10.

Both had in common that their sites weren’t controlled by Composer, but had been manually installed.

This is relevant to this post in 2 ways: 1) most online documentation assumes you use Composer and is therefore of limited use for the upgrade process if you are not using composer, and 2) a Composer upgrade may go wrong in ways that a manual upgrade does not and vice versa.

1) Read the Drupalize.me upgrade tutorial.

In the following I am going to assume you have read that document.

2) Drupal 10 is Drupal 9.5 with bits taken out.

That is still from the above document, but I am going to explain what that means.

What it means is that if you have upgraded everything as far as it goes in the D9 branch, and I do not just mean Drupal core, but also contrib modules, contrib themes, custom modules and custom themes, you are 90 % of the way there.

Upgrading everything means also upgrading contrib modules to a next major version that supports both D9 and D10 if the current version only works with D9. Upgrading to a major version may mean loss of functionality, so make sure that after all those upgrades the site still runs the way you like.

2a) The Metatag module pretends to not be upgradeable.

This is a known bug that has been solved in later versions.

3) Remove unused and uninstalled modules.

As in, uninstall and then remove the files. Drupal will try and read uninstalled modules, and D10 will definitely croak if it finds incompatible uninstalled modules.

4) Learn how to clear caches without a running Drupal install.

There are going to be conflicts between the cached database configuration and the actual code. They will lead to a down website. Being able to clear those caches and then log in and run the database scripts is important.

5) Learn where your PHP and/or web server error logs are.

Modern error messages can be confusingly woolly, but they typically at least give you some idea of which contrib module or theme is acting up.

If you forgot to upgrade a contrib module to a version that supports D10, now is when you will find out.

Error messages are great for googling. Often times you will be sent on a wild goose chase by people who don’t know either but who cannot avoid pretending they do, but sometimes you will find the solution.

6) Update custom themes.

One of the changes in D10 as compared to D9 is that it uses Twig 3 instead of Twig 2. In Twig 2 a number of features were deprecated, so check your custom themes for these features.

If you are confident that your theme will work with D10, you can edit your *.info.yml file so that the core_version_requirement field lists ^10.

There probably are a lot more things that can go wrong and a lot more tips that can be given, but these are the ones I have for you.

If you can learn one thing from this post, learn that you should get your D9 install as close to D10 as you can before attempting the actual upgrade. Failing to do so will almost guarantee a broken site. An upgrade to D10 can be a lot of work, so it can be tempting to skip things. Drupal can unfortunately be pretty fragile at times, so a proper preparation is important.

I never quite understood what headless Wordpress means in practice, but then I decided to apply some maths to the problem.

Tell me if you believe this works:

• headless chickens = wordpress developers;
• headless = (wordpress developers) / chickens;
• headless wordpress = (wordpress^3 developers) / chickens.

(Disclosure: this may work for me but not for others, see the bottom of this piece for why.)

Vue is one of the larger and more popular Javascript frameworks.

It is very versatile and has great documentation. It can be used in different ways, either using Single File Components or as a library. It supports different API styles (options or composition) and offers a range of build tools. If you want to learn Vue, there is the Guide, the Quick Start and the Tutorial.

In other words, there are a ton of resources for beginners and quite frankly, when I tried to start learning Vue a couple of weeks ago, it was too much. I could not see the forest for the trees.

And by that I mean: I failed to start making even the simplest of applications in Vue.

So here is what I ended up doing:

(The underlying assumption being that you, like I, already know the 3 web technologies of HTML, CSS and Javascript.)

• Follow the exercises in the Tutorial.
• Create a minimal app in the Playground.
  • Hello World suffices, but if you want to see if you can make something more complex, you can do that too.
• Download your prototype from the Playground (button: Download Project Files).
• Download and install node.js.
• CD to your project files.
• npm install
• npm run dev

This is more or less the same procedure as the one outlined in the Quick Start section of vue.js. That section, however, tripped me up, because it produced a more than minimal app, and as such it didn’t give me a very good idea of what a minimal Vue app looks like. (The Quick Start app might help to provide some contrast though, I am certainly not saying that it is useless.)

I ended up scooping out the parts I did not need from the Quick Start app, but this left me with a broken app. I needed a gentler start, something that would let me put “Hello World” on the screen without having to worry about a ton of other things.

The tutorial let me do exactly that, but it would not let me save the results as an app.

The Playground would.

In fact I still use the Playground even now that I am working on my own app, just to quickly try out things that don’t work in my (currently) 550-line (and counting) app.

Note that if you use Vue as a library you end up with none of these problems and quite frankly, to each their own. I personally liked the workflow from the Tutorial (Single File Components and Composition API), so I tried to recreate that.

Pet peeve: people asking Vue questions on Stack Overflow without reducing their code to the minimum required to reproduce their problem.

Discussion: note that the Vue Playground only uses the Composition API at the time of writing. This is a fairly recent API: if I am not mistaken, it was introduced a little under 3 years ago. If you had tried Vue before or already have some Vue experience, this might not be the way for you.

My 2008 article about digital deterioration of e-books has, in a fit of irony, become unfindable through Google. The reason may be that no-one links to it any more, including the platform on which it was published.

So let me link to it myself:

The printed book as a preservation device

In the article I discuss three dangers that beset digital works:

1. Format deterioration
2. Digital Rights Management (DRM)
3. An adversive position of archivists

I offer no achievable solutions to these problems, but point out that, ironically, because of these dangers a print version of a book offers a greater chance of said book surviving the ages than the digital version does.

Every four years since 2010 I have been writing the ‘state of the CMS’ in which I compare how the major Free and Open Source (FOSS) content-management systems (CMSes) call themselves.

Today’s version will likely be the last of the series.

This is because in the past 12 years the main contenders for the title ‘popular CMS’ were all basically offering the same thing, namely an open source, LAMP-based generic CMS. That made them a natural category. Now that other types of CMS have started to compete in the top ten, it has become much harder to define a category to which these systems belong.

Wordpress is still by far the biggest fish in the pond, but in the past 4 years hosted CMS-es have grown in importance and have grown bigger than what were for a good 10 years Wordpress’ only rivals, Drupal and Joomla. In fact, according to W3Techs (which I won’t link to, because their chart changes weekly or so), the three most popular CMS-es after Wordpress are now Shopify, Wix and Squarespace. And where four years ago Drupal and Joomla were the only CMS-es after Wordpress that had a better than 1% market share — my personal measure of significance here — now between 6 to 10 do, depending on who you ask and how you calculate market share.

It seems, in other words, that the very definition of what a CMS is, is shifting, and that makes it less meaningful to continue this series.

How have these systems called themselves over time and can we glean anything useful from any changes?

Wordpress
2010: Semantic personal publishing platform
2014: Web software you can use to create a beautiful website or blog
2018: Open source software you can use to create a beautiful website, blog, or app
2022: Open source software you can use to create a beautiful website, blog, or app

Drupal
2010: Open source content management system
2014: Open source content management platform
2018: Open source content management system
2022: Digital experience platform (DXP)

Joomla
2010: Dynamic portal engine and content management system
2014: Content management system
2018: Content management system
2022: Content management system

Wix
2022: [undefined]

Squarespace
2022: [undefined]

I have tried to figure out what Wix and Squarespace call themselves, but being commercial entities they are not really calling themselves anything. Instead they present themselves as a bunch of solutions to any number of problems you might have and leave it to the historians to provide them with a label. So Wix opens with “Create a website you’re proud of” and Squarespace with “Everything to sell anything”.

See also: State of the CMS in 2018.