I was tempted to call this the "2025 update" but since I usually take leave in December and spend most of it tinkering, quite likely I'll do some of this before new year or at least by the end of January.

The next Tuskfish CMS release will be version 2.1. Core functionality will remain unchanged, but I will add support for blocks, and if I can sort out a couple of issues, native multilanguage. Not a crappy hacked up multilanguage, but one that is baked into the core and seamless.

I'll be making use of some of the more recent langauge features in PHP, which will raise the minimum version required to PHP 8.3. Please note that the contemporary versions of PHP are now V8.3 and V8.4, with V8.2 reaching end of life in December.

Blocks

Blocks are probably the main missing feature of Tuskfish. I haven't been bothered with them because they fell out of fashion with mobile-first layouts and I tend to just code them statically. They are also add heavy constraints to your layout, and until a few days ago I couldn't think of a way to implement them without also tying people down into fixed column layouts. So:

• In the interests of preserving 100% layout flexibility, you will be able to define your own block positions, but you will have to manually insert position placeholders into your layout files where you want the blocks to appear.
• Block display will be regulated by route. You will be able to select which route (pages) a block is displayed on based on entries in the routing table and, if the block allows, filter the content by tag, and later, language. You can add custom routes in routingTable.php.
• Block templates will work the same way as content templates: You'll be able to add a few variations and select the one you want to use for a particular block instance from a list.
• Block configuration data will stored as serialised JSON.

Native multi-language

Multi-language capability is something many CMS struggle with because they are usually designed as a single-language system from the outset, and then people try to hack multi-language on top of that, which usually ends up 'workable but ugly'. But I left a few hooks in Tuskfish from the start with a view to making multi-language a fully native capability. These include: A language property on all content objects, a Language.php trait where you can just add languages to a selectable list, and the site language constants are also separated into language-specific files.

To implement native multi-language capability I need to move to use of composite primary keys (ID + language code) instead of just using a standard integer ID primary key. If you had a piece of content available in three languages, they would all share the same ID but the language code would vary, and this allows the various translations to be filtered, based on the language preference of the user, carried in a session cookie. There are a few policy issues to sort out regarding how search results, tag and collection content will be handled but it's within reach.

What I will need is contributions from Tuskfish users to translate the core language files. But I suspect now that you will be able to just ask an AI to have a go at it first, and it will just be a case of checking that it didn't do anything weird.

Raising the minimum PHP version to 8.3

In the interests of keeping the code base modern, I want to take advantage of some of the more recent language features in PHP. This will raise the minimum compatible version to PHP 8.3. If you're curious, the features I want to use are:

• Typed properties, largely for scalar and compound types.
• Union types for parameters, return values and properties, as a measure to strengthen typing.
• Match expression as a more concise alternative to switch, but only for simple cases.
• Constructor property promotion, but only for simple classes.
• Enums look like they could be useful, but in a namespaced project they might be more trouble than they are worth.
• json_validate() will be used in JSON serialisation operations relating to block configuration.

Most of this is already implemented in the development branch. Turns out my previous work on strict_types made typed properties a breeze.