ICanUp Grew from a Blog into a Managed Content Platform
Product

ICanUp Grew from a Blog into a Managed Content Platform

ICanUp gained dedicated Pages, a shared ContentBlock editor, and managed Main, Mobile, and Footer menus. The site could now grow beyond articles into full pages without hard-coded templates.

The first versions of ICanUp were centered around publications. Articles were the core of the site, while much of the public structure was still defined directly in code.

In August 2026, that model changed. The project gained a dedicated Page entity, a universal ContentBlock editor, and managed navigation.

From this point on, ICanUp was no longer only a blog. It became a platform capable of building different types of content pages.

Page became a dedicated content type

Pages

Informational and static pages no longer needed to be modeled as Posts or implemented as dedicated hard-coded Vue templates.

Localization

Pages reuse the shared multilingual infrastructure without introducing a separate Page-specific localization system.

SEO & SSR

Pages reuse the existing SEO, canonical, hreflang, and server-side rendering mechanisms.

Publication Lifecycle

Pages have publication status, preview, and public visibility rules like other managed content.

ContentBlocks became the shared language of pages

A universal ContentBlock editor was a key part of this transition.

Instead of creating a new frontend template for every page, an administrator can compose it from supported blocks, reorder them, edit localized content, and reuse the same components already used elsewhere on the site.

This created the architectural foundation for About, Services, landing pages, and other content without duplicating a separate rendering system.

Navigation became managed content too

Main Menu

Desktop navigation is built from managed structure instead of links hard-coded into the public layout.

Mobile Menu

Mobile navigation has its own independent structure and can support a different usage scenario.

Footer Menu

The footer gained a separate managed menu for persistent informational and service links.

Drag & Drop

Ordering and hierarchy can be changed in Admin without editing frontend code.

A menu item can target a managed Page entity instead of simply storing its URL as text.

This means a canonical slug change automatically updates the resolved URL, while an unavailable or deleted page should not leave a broken link in public navigation.

Menu structure and Page lifecycle remain independent, but work together through a clear contract.

The public site became assembled from managed parts

Public Pages

Published pages gained localized public routes and reuse the shared public layout.

Shared Renderer

Post and Page reuse the same ContentBlock components instead of maintaining separate rendering systems.

Admin Management

Pages can be created, edited, published, hidden, and deleted through Admin.

Access Control

Menu and Page operations gained dedicated permission and policy contracts for safe administration.

Even the author page became part of the system

At the same time, ICanUp gained a complete author page that connected publications, professional identity, and structured data into one clear entity.

It was another sign that the site was moving beyond a simple article feed and toward a complete information architecture.

This change opened the next stage of ICanUp development.

A new public capability no longer necessarily required a new page type in code. In many cases, it was enough to create a Page, compose it from ContentBlocks, and place it in the appropriate menu.

This is where ICanUp began turning from a blog into a managed content platform.