Content versioning question

[LoneShooter]

Just to ask, is some kind of content versioning planned as the core Pi-Engine feature?

[taiwen]

Currently I don't have concrete plan. Do you have any suggestion?

[LoneShooter]

Well, I have been thinking about it intensively. Together about multilingual support. And the more I'm thinking and researching solutions in other CMSs the more I'm sure that the solution for both problems could be more or less the same. This post is not short but please read it carefully.

Existing CMSs

Let's look the following revisioning solutions existing in some CMSs:

a) Drupal 8 (developed with Drupal and Symfony 2 framework), ExpressionEngine (developed with CodeIgniter framework) and Magento (developed with Zend Framework 1)

These CMSs have the ability to create custom data types not directly via SQL but rather through admin panel. In Drupal 8 each data type is not created as a separate table (e.g. PageTable) but they are actually represented as nodes (in table "nodes") and their fields are in table "node_fields" with revisions in table "node_fields_revision". All translations are in "node_fields" distinguished with the field "langcode". Here is the E/R diagram published a couple of weeks ago: https://drupal.org/files/Drupal8_UPsitesWeb_Schema_10-19-2013.png

Pi Engine is currently very different compared to this architecture because each data type has its own table(s) with fields inside them.

The reason why I'm mentioning it here is because it's relatively close to PHPCR (PHP Content Repository) standard that defines hierarchical semi-structured data In a consistent way allowing them to have native support for versioning and multilingual (http://phpcr.github.io/slides.html)

b) SilverStripe CMS (developed with SilverStripe framework, former Sapphire framework)

Its DB architecture is very similar to Pi Engine (including widgets or blocks) and it has native support for content versioning. Each datatype table has accompanied revision table for storing changes (e.g. "Page" table and "Page_revisions" table)

Possible solutions

To assume, basically we have got two possible solutions:

• Each table itself contains both "current" and "revisioned" records (as in WordPress)
• Revisioned data exists in two separate tables, "current" and "revisioned" (as in SilverStripe)

Additional notes

But for both of them we'll need to care the following:

• the revision logic should be a choice (e.g. enable/disable it in admin panel). Some datatypes will not support revisions.
• the revision logic should be a part of the core Pi Engine (e.g. DB module). Developers will not take care of it at all.
• if the second solution is used, updating or changing database structure of "current" data will trigger changing the structure of the "revision" data (e.g. adding new field in "active" table will also create this field in "revision" table)
• many other "smaller" catches

Please consider that I've been developing sites using all CMSs mentioned above and information I've provided here is not just "philosophical" thinking, but a wish to have fully featured Pi Engine as a product we'll all be able to use for both our own sites and sites we're developing for clients.

[taiwen]

The above analysis is extremely helpful, I will definitely think about it thoroughly. Really appreciated.

[taiwen]

BTW, it would be great if you could have more analysis on drupal8 in any aspects to see if we can learn. @LoneShooter

[LoneShooter]

@taiwen, I have to be involved in the analysis no matter whether I want to, it's clients' wish :)

Here is the article with new features and changes in Drupal 8: http://www.cmsobserver.com/whats-new-in-drupal-8/

Drupal 8 Pros:

• Drupal 8 has great architecture for creating custom content types. Almost none programming is required.
• Core revision system
• It has native multilingual support!
• Great user interface

Drupal 8 Cons:

• It's not built on-top of Symfony2 framework but rather includes Symfony2 components. This means that it still has its own programming logic.
• Not suitable for creating custom applications

Drupal 8 also use Twig template engine, but I don't like using these engines at all. However, it claims that can be compiled to the PHP level and stay in memory which could improve performances. I still prefer ZF logic.

Conclusion

For now, I would like to stick to more general system (like Pi Engine). No matter what system is used here are general users' requirements for almost ALL projects I've worked on:

• easy installation on system where clients don't have admin privileges or where a CMS needs to be installed in a subfolder, i.e. without creating virtual hosts (Pi Engine files should be reorganized to achieve this in order to remove www from the url)
• uniform interface for modules (Pi Engine is great here)
• WYSIWYG editor (CKEdit is nice editor, but file manager should be replaced because it's not free)
• multilingual (almost 90% of sites I worked on had at least two different languages)
• security and permissions (not sure whether it's could be set a user to edit or delete only his/her own content in Pi Engine)
• user content organization (Pi Engine is also great here with its blocks logic)
• themes (excellent theme logic in Pi Engine)
• sometimes media manager (not present in Pi Engine for now)

Of course, the Pi Engine has many other advanced features and its main strength is in ability to create custom applications using Zend Framework 2 and not learning all these different custom stacks and frameworks that fit only to those particular CMSs. I'm not sure why only few people have paid attention to the Pi Engine so far.

[Marc-pi]

needed in the future