Skip to content
Mickey Liechtenstein
All cases

New WordPress site on a bespoke theme and plugin

Unge Investorer

An investing publication rebuilt from scratch: a new installation, a bespoke block theme and one custom plugin holding all functionality. Shares its codebase with sister site Vækstaktier, and runs almost no third-party plugins.

Unge Investorer is a Danish publication about investing, aimed at young people. The site was rebuilt from scratch: a new WordPress installation, a new block theme and one custom plugin holding all the functionality. It went live alongside its sister site Vækstaktier, which shares the same codebase.

The front page: the two people behind the site, then the newsletter. The design is theirs; the theme under it is shared with the sister site.
The front page: the two people behind the site, then the newsletter. The design is theirs; the theme under it is shared with the sister site.

Two sites, one theme, one plugin

The job was two publications, each with its own audience, look and content. The easy route would have been two installations with two sets of code. It would also have meant making every fix twice — and the two sites drifting apart over time.

Instead there is one block theme and one plugin, and both sites run on them. The theme holds presentation only: colours, typography, patterns and templates. The plugin holds all functionality, split into modules that can be switched on per site. That is why Vækstaktier can have insider trades and company profiles while Unge Investorer has a shop and a podcast, without the two sites having separate codebases.

Almost no plugins

Beyond analytics and cookie consent, which the client chose, the site runs one functional plugin: the custom one. No page builder, no SEO suite, no collection of small plugins each covering one detail.

That is deliberate. Every plugin is a dependency that has to be updated, can be acquired, can stop working after a WordPress update, and widens the attack surface. When the functionality is written for the job, there is one place to look when something misbehaves.

What was built

The article page is a publication's most important page, and it is built accordingly: an automatic table of contents, an FAQ with structured data, related articles, newsletter inserts and ad slots placed by counting paragraphs rather than being pasted into the text. The editorial team has author profiles with image upload and their own archive pages.

On top of that come calculators, price-target pages for individual shares, a shop and a podcast section. The newsletter and the ads share one resolver deciding where in an article an insert may land — so they never end up on top of each other.

The migration

A publication with several thousand articles cannot simply swap sites. Every old address is a page someone has linked to, or that sits in a search result.

So every old address was checked after the switch, and they still answer. The old WordPress stayed on the server behind an access block, the old database tables were left untouched, and two database dumps and a full file copy were taken both before and during the switch, all with matching checksums. Rolling back was one script.

Operations

The site runs on the client's own hosting. The code lives in a private Git repository with tests, and updates go through a release — not by editing on the server.

Shall we have a chat?

Tell me briefly about your task — I will get back to you with an honest take on what makes sense.

Write to me

Describe your task in a few lines and I will get back to you — usually the same day.

Your details are used only to reply — no newsletter.