[PLANNING] Yii CMS - a different approach

[size="6"]Yii Content Management System - a different approach[/size]

Working title [edited]


While we have a very good and reliable PHP-framework with Yii, it still seems like there is a need for a flexible and solid Content Management System based upon Yii.

For sure there are a few CMS-extensions for Yii, like FlexiaCMS, MongoCMS OvenCMS or phundament. But the workflow or project structure many Yii-developers choose for their applications simply does not fit in these predefined applications.

I think that the main problem is, that these CMS modules provide just „too much“ functionality and that they are very hard to integrate in a custom app. You usually have to start with the CMS module and add your custom code to it.

So, I would like to present a different approach for a Yii-based content management system.

[size="5"]The Goal[/size]

The main goal for me would be a system with really decoupled components for the tasks a user usually needs to perform to add content to a website.

For sure some components will have to be written first, not everything is ready for download, yet. But, if available, I would like to use existing and tested Yii extensions.

Basically it should be more a concept and a guideline on how to use the components available from the Yii extension repository and how to glue them together to create a dynamic web-application – Yii-style!

[size="5"]The Application[/size]

For phundament 2 I’ve created a picture which shows the fundamental components of a CMS. It’s based on the ancient greek view of the world with for elements.

These four elements would be air (users and authentification), soil (structure of the application), fire (content-widgets) and water (general content or data).

Let’s explain this a bit more in detail…

[size="3"]Authenification, Users & Permissions[/size]

If you want to add, edit or update any contents of your application you need to login first and have the appropriate permission to perform your task.

For this kind of component or module we find many entries in the extension repository, like the following:

These components should be easily exchangeable, because the framework connects the user and auth data with the rest of the application and provides an easy access to this data.

[size="3"]Application Structure & Pages[/size]

Another part of a CMS is the functionality to create a custom site structure.

We need something like a custom controller which renders views and layouts read from a data storage, like MySQL or XML.

There is already one in the extension repository and phundament also provides this functionality.



[size="3"]Widgets & Cells[/size]

Another important part would be a system to distribute widgets across views.

Phundament does this with it’s cellmanager widget, which simply instantiates other widgets with given parameters.


If it finds a CWidget it renders form fields for all public properties, if it finds a widget which implements a CellManagerWidgetInterface it uses a custom form from the widget to edit the data.

This widget can create any type of content for the application, as long as there’s a widget which displays the data.

[size="3"]Application Data[/size]

Content like HTML, media-files or model data should be handled by seperate widgets and modules. Therefore I will not go into further details here, because it does not really belong to the concept.


In my opinion that’s everything you need to create a basic CMS based upon Yii.

A very powerful and slim solution, where you can use just the components you want, to retain maximum flexibility within your application.

[size="5"]Development & Distribution[/size]

For code-development I would point out two platforms.

[size="3"]Subversion on code.google.com[/size]

Currently the most popular platform for development with a lot of nice features and many developers are familiar with subversion.

[size="3"]Git on github.com[/size]

While not having too much experiences with git, I like the concept of „everything-is-a-branch“ of git very much.

This approach could be very helpful, when dealing with a lot of different components, which are also dependent on each other.

[size="5"]Open tasks[/size]

  • Installation process

  • Internationalization / Localization / Meta-Data

  • Coding & Structural Guidelines

  • Application & Extension Manager


Some links I surfed, while creating this document:

Your experience with Yii CMS?


Is there any CMS base on Yii?


How to create CMS


Best rated extensions


Most popular extensions


YiiExt Unofficial Yii extensions repository



I would really like to hear some feedback from you regarding the structure and concept.

  • Is there already a similar project?

  • Do you see pitfalls or flaws?

  • What do you think about the way of development and distribution?

  • And most importantly, would you like to join this project?

Best regards,



Good initiative and news to Yii world - Yii CMS is definitely the gap to fill in!

Well about the feedback for the upcoming Yii CMS:

It definitely must be lightweight (in logic, code, etc.), easy to understand and learn from a powerful Yii Framework in a best practice way. I personally admit the phundament2 application structure logic (four elements).

Is there already a similar project? Regarding Yii CMS I really doubt there is one – now it’s the time to fill in the gap.

Do you see pitfalls or flaws? The only mater is to keep Yii CMS with Yii logic – easy, efficient, and extendible. (and to be more specific: Is it fast? … Is it secure? … Is it professional? … Is it right for my next project? … Yes, it is!) And for the application if used four elements - keep it DRY, clear and that it would be an example of best practice how to glue the working and tested extensions like SRBAC to build YiiCMS.

What do you think about the way of development and distribution? Most important to have a way to contribute and share it globally. Both options sounds good, I prefer Subversion, but Git is also an option.

And most importantly, would you like to join this project? Of course! I would be glad to contribute in YiiCMS team.

Installation process – could use modified phundament2 installation (to fit different OS etc.) also take a look at FlexicaCMS installation process (it’s not perfect but easy to navigate by browser).

Internationalization / Localization / Meta-Data – in our Yii community forum there are various topics about how to put I18N, L10N in the right order that YiiCMS would indeed support different languages, time zones, date formats, etc. (research TBD)

Coding & Structural Guidelines – could use same clear OOP, DB naming conventions (is there a description of formal Yii used naming conventions?). As for a structural issue: a front/back end support for developing fully working YiiCMS.

Application & Extension Manager – Phundement2 offers quite good example how to manage the App, also extension manager would be a great to have, for rapid implementation of YiiCMS to various projects.

Keep in touch!



Wow! I feel this is a great idea.

I would like to commend you for this article and I can appreciate the thoughts you have put into it.

Sooner or later a project like this will eventually come to pass.

@Schmunk, I agree with you on this point. Some of the extensions you have listed in this article are potentially very good… providing it is easy to integrate. IMHO, I think what starts off as a good and simple idea grows to become a giant extension thus forgetting the purpose of its primary solution.

[size="2"]Goals: It is important to know when we get there! [/size]This type of project will need strict, ruthless and identifiable stop points. And I found the goals mentioned in this article - gravitating and if the team can be clear on the outcome; it may well benefit all yii-developers .

The end user or the developer?

I feel the final goals defined within this project must decide and be clear who its intended audience are.


[/b][/size][color="#1C2837"][size=“2”]Is there already a similar project?[/size][/color] Don’t know - However, it’s something to be explored.

[color="#1C2837"][size="2"]Do you see pitfalls or flaws? [/size][/color]Yes…the pitfalls depend on our attitude towards this project. If we forget why we love yii then this could well become just another cms…But if we never forget our first impression with yii…then it could become a standard or even an example of how things should work.

Why did we choose yii? Why do you love yii? I believe CoLT mentioned it in his response.

Well, let’s go back to the reason we all love yii. I feel I can speak for most, that is because; yii was easy to pick up. Yii is well documented. Yii has simple tutorial examples of how classes and components can be used. Yii was focused. And as Yii grew, it was in a focused direction.

And so, to iterate some of the points mentioned by CoLT. It needs to be easy and simple. Simple means it must be slim and basic enough. It’s not about how great a coder is, it is more important to be simple enough to package the basic components, so that the component and work flow are usable.

To illustrate my point, when ever you generate a new yii application. The new application appears deceivingly simple. Yet the genious lies within its simplicity. It is simple because a developer can pick up the project and begin customising to suit their personal requirements…It is good that schmunk has identified the components, its now a matter of making it work together but keeping it lean. [b][i]


[color="#1C2837"][size=“2”]What do you think about the way of development and distribution? [/size][/color]On a personal level I prefer google. However, for this type of project. Git is definitely the way to go. For the following reasons. Software developers by nature will have personal preferences and most would think their method is better (Probably, due to the fact that its what they know and its proven to have worked for them.) Going with Git distribution will provide yii-developers the confidence that if they don’t like what someone else has coded. Then they can improve the code without breaking an already working project. Git will allow many talented cooks in the kitchen without worrying about spoiling the food.

[color="#1C2837"][size="2"]And most importantly, would you like to join this project?[/size][/color]

Yes I would like to join. I can help out with some coding, testing and documentation

Can this project be realistically achieved? Yes… definitely. Most of the components are already out there. Most of the components were built by individuals. The genius will lie in how the sum of the whole fits together. If we take the sculpturer’s approach and chip away with the chisel… Then it will be easier to see how to put the pieces together.

Best regards,




Hi CoLT, Hi Seal,

thanks a lot for your feedback!

I think I agree with all of your points ;)

A few more thoughts from my side.

The intended audience is the type of guy, a developer which looks at most CMS, while almost never choosing one, because he had already experiences with all this bloated crap out there. And therefore writes his own stuff. B)

For me the choice of the versioning system is crucial. I am not that familiar with git, but (I think) I understood the great advantages you gain, when developing with a DCVS.

Maybe an example explains this better.

I set up a repository with a standard yii skeleton plus srbac (Roles Management) plus a user module plus a pages and a widget module as described above. I call this setup "shark" (just using some names from animals from the sea).

You could now fork the repository and replace the user and roles module with different ones, add a few extensions from the repository and call this setup "whale".

Another one forks "whale" and adds an extension manager, calls it "octopus" and so on.

With git you’ve a great tool to manage and merge these setups, which should also provide an easy way for everyone to create an own setup, while giving back his bugfixes and improvements to the community.

Also important is a clear structure and some guidelines, how to include extensions. Should an extension always be placed in its own directory, is a database installation required, … and so on.

Because in git everything is a fork I think nothing should stop us from creating some prototypes.

…setting up the repository was easy :) https://github.com/schmunk42/phundament

I will post a note here, if I add some files there…

Best regards,


Hi guys,

I played around with git a little bit and it’s looking great so far:


I created a webapp skeleton and added yii-user as a module.

Afterwards I created a branch called "p3-installer" just for testing an installation command feature.

The great advantage of git will be that you can merge these features in a nice way.

We could merge or branch only subtrees, everyone can create his special setup! Do not underestimate that.

Then I checked out the p3-installer branch and tried to access it, but then the first problems arise.

For sure, I did not check in /assets and /protected/runtime, so I had to recreate these folders. ‘yiic webapp .’ can solve this problem and sets up the environment.

So, on to the next one … we should come up with a way how to check the installation of the modules (and the application), in this example ‘yii-user’. Checking and validating modules and extensions should be also one of the core features IMHO. In the first place a text file with instructions and a troubleshooting guide would be sufficient.

But it would be also possible, that we place an additional file into the module, which tells yii or yiic what to check.













Another candidate to store these values would be the module-class. But I think a separate file would be better, because yii does not provide properties for such a purpose.

Please feel free to fork or join the github repository. Since I am not that familiar with git I am looking forward to your ideas on how to use this as a rock-solid and super-flexible basis.

Best regards,


Forgot to mention that in the other posts…

Yii is the kernel

Which means that the approach - so far - takes advantage of Linus Torvalds’ (author of git) experience he gained while developing the Linux kernel.

Because he faced huge problems with other SCMs, when it comes to include and combine all the kernel-extensions, he wrote git.

We got a similar situation here, even though in a much smaller scale :)


It should definitely have a pluggable architecture, look at this thread: http://www.yiiframework.com/forum/index.php?/topic/11840-intercepting-method-calls/

So that we can extend the core features hooking inside the code flow.


What license? My vote is for GNU/LGPL 3.0

I’d use a pure PHP approach with PHP arrays instead of XML.

If you want a source of inspiration, try http://vanillaforums.org

I think that there are some common goals.


Try it.

There’s a simple dashboard with basic settings management, users management, themes management etc. then you have “applications” and “plugins”. Vanilla, the forum script, is an application that takes advantage of this structure and the underlying framework. You also have plugins which can hook inside the code flow and extend the core or the applications.

We could have a basic structure like that (templates management, users management ecc.) then we could build "applications" above it (i.e. articles app, file manager app etc.).

Hi ekerazha,

thanks a lot for your feedback, I’ll consider it.

One word about the license: I would prefer a BSD-style license or a dual license.

Best regards,


After having a few talks with other developers, I have a some news to post here:

[size="3"]Database Installation[/size]

It looks like the new db-migrations feature comes up very handy, when it we have to install a database for a module.

This feature has to be tested, but I think it would be great if every module or extension, which needs a database delivers the corresponding migrate command.

An installation then could be performed with:

./yiic migrate up --migrationPath=modules.modulename.migrations


A more suitable base component for dynamic widgets would be this one:



Another thing I stumbled upon:


This one may be used as a very slim dynamic pages module (for testing)

yiic? I think that a web-based solution would be better

I like to use existing yii-style solutions, instead of writing an own installer.

I would say, if it works with, yiic the process could also be triggered by a web-based installer.

Is there something to be said against it?

Here’s the first prototype.

As mentioned above I wanted to stay as close as possible to yii.

As the yii framework itself is not bundled with this application, you have to setup the web application skeletion with this command.

cd /path/to/extracted/app

/path/to/your/yii/framework/yiic webapp .

This will set up the missing files, like index.php, index-test.php with the correct paths to your framework installation.

You may place yii/framework into protected/lib if you want to.

… and now comes the cool part.

I added the extension module yii-user in protected/modules/user and wrote a database migration for it (just for testing the process).

Because yii does not track migration with migrationPath yet, we’ll use the migration command to install the module database with parameters:

protected/yiic migrate \

    --migrationPath=application.modules.user.migrations \


This creates the needed tables for the yii-user module.

One more thing would be an apache-style config approach. I created a custom config for the module in config/extensions-enabled/user.php which can easily be merged with the default config, by modifying config/main.php like this:

$config = array(

 [...exisiting config...]


$config = CMap::mergeArray(




return $config;

That should be it :)

Would love to hear some feedback about this, is this a cool way to handle module database installations?

Best regards,


Good evening Gentleman,

now here is something to play around with!

Download: https://github.com/schmunk42/phundament/archives/3463fc4144920b71d053d9b56882a3929c34903c


  • Web-based Installer using yiic migrate

  • Backend Module Mashup

Installation should be fairly easy:

  • Download and extract

  • Use an existing yii framework installation to re-create the webapp paths (./yiic webapp .)

  • Go to the backend ?r=p3admin and click through the database setup

Everything very rough - for sure :)

My questions for you guys:

  • What do you think about yiic migrate doing that job?

  • What about the apache-style way to handle configurations (include & merge at the end of config/main.php)?

  • Could these be conventions for a unified module installation?

  • Are there more tasks a module has to perform that database installaton?

Best regards,


Hi Schmunk,

I will be test this and get back to you with feedback.


Hi Seal,

that would be cool, please feel free to try github, also… if you have the time.

Best regards,


Awesome, would like to contribute with some UI design.

I missed this topic - I’ll definitely check it out. :)

So, Phundament on Google.code is now quite different from Phundament on Github, right?

Yes, you’re right!

While on Google you’ll find a complete CMS application, the stuff on GitHub is in very early stage of development.

But git will play a key role in the development process, see here for more information.