VOL. IX

• SCSS concatenation voting
• Development instance condition voting
• Big O Quiz - PHP Edition
• Dungeon Pick - That boolean hat boolean should probably be something else

SCSS concatenation voting

We’ve decided to adopt a fully flat BEM-style notation. That means:

• All element classes live at the root level, not nested inside their block.
• Pseudo-classes (e.g., :hover) remain nested within their class.

.c-block {
  color: red;
}

.c-block__element {
  background: black;

  &:hover {
    background: blue;
  }
}

You can check out the alternative approaches here.

Alternative versioning scheme for TYPO3 extensions

The Problem

In our current versioning scheme, the major and minor version of our extensions mirror the TYPO3 core version. For example:

TYPO3 13.4 → Extension v13.4.x

This keeps compatibility obvious, but it causes one issue: When we release a new version (e.g., 13.4.1 → 13.4.2), it looks like a small patch but actually might contain a breaking changes.

Why This Matters

Developers often assume patch updates are safe to apply automatically. But in our case, a “patch” could actually break something in production. That’s confusing and risky.

The Solution: Epoch Semantic Versioning

We might switch to a versioning approach called Epoch Semantic Versioning, inspired by Anthony Fu’s blog post.

Here’s the idea:

• We embed the TYPO3 major+minor version as an “epoch” by multiplying by 100.
• We then apply normal SemVer rules for breaking changes, features, and fixes.

For example:

TYPO3 Version	Epoch Base	Extension Version Example	Meaning
13.4	1300.400	v1300.400.0	Initial release for TYPO3 13.4
–	–	v1301.400.0	Breaking change within TYPO3 13.x
–	–	v1300.401.0	New feature (minor bump)
–	–	v1300.400.1	Patch/fix

This gives us the best of both worlds:

• Still instantly see the TYPO3 compatibility (1300.400 → 13.4).
• Use true semantic versioning for our releases.
• Avoid misleading “fake patch” releases.

RESULT: Epoch Semantic Versioning will be applied with introduction of TYPO3 v14.

Development instances on live servers

Decision (with Benny, if anyone has any arguments against this, please feel free to comment): due to quota sizes and because it is considered unprofitable, from now on there will be ‘only’ two instances online: production & staging.

Voting

Consequence in typo3-composer-template:

- condition: 'applicationContext == "Development" or applicationContext matches "@/Staging$@"'
+ condition: 'applicationContext matches "@/Staging$@"'

Side note from the dev chief:

For debug purposes someone might temporarily apply development context, even online. The condition itself has no real downside if we'll leave it as is.

If we'd reduce to single condition, we might add note – at least to env boilerplate – that for debug Development/Staging must be set, for simulating prod environment Production/Staging. This is still an option, just sounds curious when first reading/heard… We'll vote tomorrow.

RESULT: we will switch to condition: 'applicationContext matches "@/Staging$@"'

BigO Quiz PHP Edition

Question 1 – Finding the maximum value

Which one performs better for large arrays?

function maxA($arr) {
    sort($arr);
    return end($arr);
}

function maxB($arr) {
    $max = $arr[0];
    foreach ($arr as $x) {
        if ($x > $max) $max = $x;
    }
    return $max;
}

/**
 * @param list<int> $arr
 */
function maxC(array $arr): int
{
    return max(...$arr);
}

Question 2 – Checking if a value exists

Assume $arr is a normal indexed array and $map is an associative array with the same data as keys. Which one is faster for large datasets?

function existsA($arr, $x) {
    return in_array($x, $arr);
}

function existsB($map, $x) {
    return isset($map[$x]);
}

function existsC(array $map, int|string $x): bool
{
    return (bool)($map[$x] ?? false);
}

Question 3 – Counting elements

Which one is faster?

function countA($arr) {
    $c = 0;
    foreach ($arr as $v) $c++;
    return $c;
}

function countB($arr) {
    return count($arr);
}

Solutions

What is Big O?

Big O time is the language and metric we use to describe the efficiency of algorithms.

Big O describes how fast something gets slower as the input gets bigger.

In other words, it’s a way to measure how the running time (or memory use) of your code grows with the size of the input — without worrying about exact seconds, just about the trend.

Example

If your code goes through every item in a list once → O(n) → doubling the list roughly doubles the work.

If it has a loop inside a loop over the same list → O(n²) → doubling the list makes the work about 4× bigger.

If it sorts a list → O(n log n) → grows a bit faster than linear, but much less than quadratic.

So Big O tells you how well your algorithm scales as your data grows.

✅ Answers for Dev Dungeon Quiz

Question	Better	Function Reason
1	B	O(n) vs O(n log n)
2	B	O(1) average for isset vs O(n) for in_array
3	B	count() in PHP is O(1); manual loop is O(n)

Answer to 1:

• maxA sorts the whole array first. Sorting compares many elements and takes a lot of extra work.
• maxB just looks at each element once and keeps track of the biggest.

✅ Better: maxB — it scales linearly (O(n)) instead of O(n log n).

Answer to 2:

• existsA goes through the list item by item until it finds $x (like checking every box in a row).
• existsB uses an associative array (a hash map), where PHP can jump straight to the right box using the key.

✅ Better: existsB — constant-time lookup (O(1)) instead of scanning (O(n)).

Answer to 3:

• countA loops through every element to count them one by one.
• countB calls PHP’s built-in count() function, which already knows how many items are in the array (PHP stores the count internally).

✅ Better: countB — instant result (O(1)) vs looping through all items (O(n)).

Miscellaneous voting

rgb() formatting rules

Question was raised in a GitHub discussion.

MDN note

The rgba() functional notation is an alias for rgb(). They are exactly equivalent. It is recommended to use rgb().

While using Bootstrap Framework up to v5 (current) the preferred:

background: rgb(0, 51, 136, 10%);

In all other cases this should usually be the preferred way:

background: rgb(0 51 136 / 10%);

note

Bootstrap v6 needs to be verified on release, if new style can apply. Current dev at least uses new markup, too. 🤞

Prefer written out null and false (!) notation

Recommend as it makes code better readable:

- protected ?string $var
+ protected string|null $var

- if (!$condition)
+ if ($condition === false)

Dungeon Pick

That boolean should probably be something else. Read here.

The blog post argues that booleans are overused in data design—many fields stored as booleans are actually better served as more expressive types, like datetimes or enums. It suggests that using richer types improves system clarity, extensibility, and makes it easier to evolve code later. Booleans still have a place — especially as temporary results of conditionals or short-lived logic — but we should think more carefully before committing to them as persistent data types.