What's coming in version 3.0

Published: 1/8/2014, Author: Håkan Edling

It's been quiet for a while, the reason being that I've been working like a mad man trying to get the core for the upcoming 3.0 release done. So here's a quick walkthrough of some of what's coming.

Please note that this blog-post was written over a year ago and is really outdated. Since then a lot of discussions have been made regarding the new version of Piranha CMS and what it should contain. If you want contribute to the process, please take time to visit the repository for the new version at github.com/piranhacms/piranha.vnext.

First of all, the upcoming version will not be a minor update with some new features, it's a complete rewrite of the core of Piranha CMS. To make a long story short, the first fundaments of Piranha CMS was implemented before many of the tools we consider best practices today existed and was therefore implemented in a way that is more or less future proof.

One example is the data model which was implemented using the active record pattern and the database creation which is done manually by executing SQL-scripts embedded in the library. Later when EF code first was released entity mappings of the data model was added on top of the existing database to provide support for LINQ queries but the old data model still remained. This portion of the core has now been completely rewritten using EF Code First and will use Code First Migrations to update the data model.

Enough said about that, let's go on with the new stuff that's coming.

1. Repository layer

The complexity of the data model has been encapsulated into a clean repository layer ensuring that all entities can be easily updated from code without having to go through the manager view models. The repositories returns flat models that are easy to work with and holds unit of work for transaction management.

The DataContext is now out-of-bounds and can't be instanciated outside of the core library. All data access must go through the repositories. The Repository API is easily created with the following line of code:

using (var api = App.Instance.CreateApi()) {
// Do stuff

With the new repository layer, adding a new post through code is as easy as writing the following:

using (var api = App.Instance.CreateApi()) {
var post = api.Posts.Create("POST_TYPE");

post.Title = "My first post";
post.Regions.Content.Body = "<p>This is the main content</p>";


This will create a post of the standard type included when the database is initially created.

1.1 Full integration tests

To ensure high reliability in the repository api all repositories have automated integration tests.

1.2 Asynchronous support

All methods in all of the repositories have both synchronous as well as asynchronous equivalents to make sure that all performance benefits in writing asynchronous web applications can be used.

using (var api = App.Instance.CreateApi()) {
// Make an asynchronous call to retrieve a post by its slug.
var post = await api.Posts.GetAsync("my-first-post");

1.3 Archive support

The api will contain an archive repository that provides an easy api for getting post archives by date, post type or category.

2. Web API services

A new NuGet-package containing Web API services for all of the repositories has been created. This package can be used when building single page web-applications or other clients wanting to fetch the data as JSON or XML. The web api services can have both read and write possibilities, so it's now possible to retrieve and update the information from any device or application.

3. Full multi-lingual support

The new model has been designed to be fully multi-lingual. The entities affected by localization are:

Categories, Extensions, Media, Pages, Posts, Site

The media entity hasn't been redesigned yet, but the goal is to be able to have different versions of the binary files for each language. This comes in handy when for example attaching documents to a page and you want these documents to be in a different language when viewing the page in another language.

4. Page & post types

Pages and posts are now equally powerful, meaning that both entities can have any number of regions and properties. Furthermore properties are no longer dumb string values, they are as flexible as regions and custom properties can be created in the same way as regions.

4.1 Included extensions

The included region types out of the box will be Html, Image, Markdown, String & Text. The included property types will be Boolean, Date, Image, Integer, String & Text.

4.2 Multiplicity

It is now possible to define a region or property as having multiple values. This means adding any number of values for the given region or property and having the possibility to sort and rearrange them. For example, this will simplify when creating regions for sliders and other featured content.

4.3 Serialization

The standard .NET Javascript serializer used to serialize Extensions has been replaced for Newtonsoft's JSON serializer. There's now also the possibility to specify custom serializers for extensions if you want the data to be serialized in another form or even store the extension data in a custom table.

5. Architecture

The manager interface as well as all components relying on a HTTP context has been removed from the core library. The manager interface will be distributed in a separate NuGet-package that can be included or exluded from public facing installations if desired.

6. Security

The framework itself is now security agnostic. It does not provide any built in security system and has very few access points for checking security. The access settings for pages (and now also posts) will rely on the standard role feature of .NET authentication. A separate NuGet-package for ASP.NET Identity will be created that besides authentication mechanisms will contain manager views for users. The base manager package will not contain any views for users or authentication.

7. Post areas

Another feature that I'd really love to implement but that's not started is the possibility to define post areas on pages which are like a special kind region. A post area would define a container where posts can be published, and can limit what post types is allowed and how posts should be ordered.

With this new entity it would be possible to create and publish posts to an area directly from the page, or from a specific post, list all areas available where the post can be inserted.

Backwards compatibility

In order for Entity Framework to fully control the data model, plus that fact that some things are fundamentally different from the current data model it will not be able to upgrade a 2.x installation to the upcoming version. However, migration scripts will be provided to help transfer data from 2.x to 3.0.

Get involved

If you want to get involved in making Piranha CMS better, create modules, extensions or perhaps poke around in the core libraries this is the perfect time to get started. The new core framework will be more pattern-centric and all of the redundant code making the current version difficult to grasp has been removed.

If you have solid experience in EF Code First Migrations, Windows Azure or ASP.NET Identity I'd be more than happy to hear from you. If have some other ideas on how Piranha CMS could be improved, don't hesitate to get your voice heard!

blog comments powered by Disqus