Administration Panel in Yii

Hello all,

I planning to create a web application that will have an administration panel housing all CRUD operations. It will also have a client section (with login), and the public view as well (if the visitor is not logged in). I am only in the planning stage right now, but can anyone give me a few pointers on the best way to organize these basic elements of the app? Should the admin panel be a module, the client section be a module, then the public section be the default application? Or would there be a better way.

I know there are other topics related to creating a Yii admin area, but I wanted to get a definitive, clear answer.

Thanks for your time.

I was in your situation not long ago and while still a bit of a newbie my app is coming along nicely.

The decision to segregate admin vs. member vs. public for me was based on the approach of segregating access in one place, or many places.

Here is what I did:

Admin is setup as a module, with totally separate controllers, models, views. Exception is User model which is used to authenticate ALL users including admin user. I check access by using a custom flag in my user table (isAdmin) in the module config. If not admin user I redirect to login page. This works for now.

Members (Authenticated non-admins) and public are lumped together. I have very little public-facing code so what I do in the members pages is check if Yii::app()->user->isGuest and deal with public vs. member access that way.

Sorry to disappoint but there is not a ‘clear’ answer here. If I had more public facing code I might make my member area a module.

The two times I did this I just used the models and controllers generated by Gii, added a viewAdmin action as a separate view action for admins, and set a different layout for the viewAdmin, create, update, delete and admin actions.

Because in the app I was building it were always the same actions facing the public (index and view) and others facing the admin (viewAdmin, create, update, delete, admin) it was very clear what was what.

It might not be the best solution but it worked fine for me (in a application with ~15 models)

Thanks for the responses. Sorry, I have been on vacation so not much time to reply.

@dniznick - What exactly did you share across the public/admin areas? Is it conventional to access modules from within the main application? Or does it work like OOP’s inherited classes (i.e. the main app can use anything from any associated modules)? For instance, say I wanted the admin to update/create/save something in the database, then what would I use to allow the user to do the same thing? Just the same model?

I am still a bit confused as to how these two things relate. I know that there obviously has to be separate views for the admin section, member section, and public section, and probably separate controllers (different access levels can perform different tasks), but what happens when two things are shared? Such as controller actions which do similar things? Or the same tables (models)?

I hope that sounded somewhat sensible. Any thoughts would be wonderful.


All models live in /protected/models

Remember, access control is done at two levels which can be combined.

  1. Controller level (via accesscontrol filter or RBAC)

  2. Module level (via module config - beforeControllerAction)

Therefore, I keep all models in the base app model folder, not under modules/admin/models. Admin controllers live in the admin module and access control is done by checking on whether a user isAdmin (custom function at module wide level). This action is fired before any admin controllers are loaded.

Not necessarily. You can selectively display content in views based on whether a user isAdmin or isGuest vs. anonymous user. I chose to separate because my admin actions are quite distinct from what a user or public member can do.

Lets do an example of where this is not the case:

Lets say you have a Blog, and 3 classes of users can enter comments on a post:

  1. Yourself (as admin)

  2. Logged in users that are registered

  3. Guest

In this case the ‘create comment’ functionality is not admin-specific. You could create 3 types of create Comment actions in different controllers but you would be repeating code all over your app.

In this case I would have everything in the base app folders and use accesscontrol to define who can do what.


Guest can view posts

User can add posts, edit OWN posts (custom rule), view posts

Admin can do all of above PLUS edit others posts, delete posts

This is what RBAC is really made for - complex rules.

I’m finding that Yii has all the tools you need and implementing stuff is a matter of learning it and coding it. However, good application design is very challenging and it is much harder to define a good approach than it is to code it!

Im also starting out and needing to decide what approach to take, so far looks like making admin section a module is the most viable option for small to medium apps