Scope of a CMS

[eluser]JanDoToDo[/eluser]
Hey guys. I know this is done to death but would appreciate some feedback.

So CMS allows the users to access an admin part of the site to add/change elements. However, to use the CMS properly does every page have to be controlled by a single controller? Otherwise how would you make a controller specific for a page that you've just made?

Also, if you had a site with say, a home page and then 4 other links to subpages each with their own menu systems in (that could equally be subdomains but for this purpose not so) how would you control the subpages? Would every single page on the site be through one controller? If so wouldnt then every page URL have to be prefixed with say domain.com "/page_controller/sports" And then what if the depth/url gets really long and the variables sent to the method for the sports page are completely different to the variables that get sent to the, e.g. movies method "page_controller/movies".

And then what if you only wanted it to show domain.com/sports i.e. remove completely any reference to the page_controller? Alternatively, if the "sports" section has its own controller, this would solve the problem however if each page had a controller then in the CMS you couldnt add new pages - only change previous ones as there would be no controller for a newly created page.

Hope you can understand this and point out any thoughts and direct me to some reading!
ty!

[eluser]da_n[/eluser]
This is a complicated topic because there are a lot of implementations possible. When I personally develop something which needs CMS functionality, I try and ensure that it is heavily abstracted between data (content etc) and presentation (html, css etc). I also try and ensure it is as modular in nature as possible and has a relational database design.

I use the default (root) controller to process all incoming requests, and it has associated functions and models which then parse and fetch any relevant data from the database. Here is a very simplified overview:

Code:

http://example.com/about

In the above example, the default controller first checks the segments in the URL. In this case there is only one segment (about). This info is passed over to a model which checks and matches it to any related entries and content. The model then sends this data back to the controller, which can process and parse it as variables and strings. The content is finally sent over to a view file which has just a simple skeleton structure, so that any content, navigation etc is filled-in from the data we just sent it.

The controller can also able to check if there are multiple url segments, meaning it can work with the models to determine if the page is in a different category/section etc. For example:

Code:

http://example.com/sports/football

The above url is a football page in the sports category. In the database there is a table called 'categories', and the model can check to see if there is a match in it for 'sports'. If it fins one, it can also check if the category entry contains anything else, such as if it needs to have a different view file than the default one. Once the model has passed this info back to the controller, the controller can then specify that a different view file needs to be served up with this page because it is in the sports category. The view can have a completely different style to the other ones, and use different css, html etc anything you want.

For admin I would have separate controllers for this as this is a wholly different job (admin user auth, editing/updating database entries etc). I would even put the admin section on its own sub domain for extra security (such as https://cms.example.com/).

Hope this helps.

[eluser]JanDoToDo[/eluser]
Ok, many thanks for that response it was useful, but one question:

You said "I use the default (root) controller to process all incoming requests" but if your uri(1) is "about" then it would load the "about" controller and not the default controller? How would you ensure it always goes to the default controller even if you supply the first uri segment? Secondly, does this mean that in actual fact you would have very few controllers? e.g. accounts(or users), admin, and default(for every page), and maybe one or two more depending what they were, + any modules?

[eluser]Bainzy[/eluser]
hello,

i am currenty developing a forum in cideigniter, now a forums script is just another CMS system in a different form, but i too had issues with what controllers i make and how. So what i have done is first edited my routing line to be http://localhost/forums/ from here i made a controller called page, this shows the full front end of the site i am also using the Template plugin to seperate my code from my view files, insted my code opens the view files and writes its data (eg users, topics etc) into the relevant holders.

Now say someone clicks on a topic ... my site then loads the "topics" controller, so now my url looks something like http://localhost/forums/topics/view/2 ... obviously in the topics controller i have a index() function and a view() function, this then allows me to use just the one controller to display 2 dirrerent pages in theroy and it seems to be working like a charm at the moment.

[eluser]JanDoToDo[/eluser]
Thx for the response. However, if as mentioned you were "above" the topics controller, in e.g. a "page" controller then "page" would have to prefix all subpages as that is the controller??

[eluser]da_n[/eluser]
You should be able to re-map this, there is a blog post which shows a method for it here:

http://bizwidgets.biz/web-design/codeign...rls-short/

Open up your routes.php file inside the application/config folder in your CI app and add the following line to the end of the routes.php file:

Code:

$route['^(?!ezstore|ezsell|login).*'] = “home/$0″;

This line uses a regular expression that means, If a visitor goes to any url EXCEPT ezstore, ezsell, or login, redirect them to the home controller, and the function inside the home controller ($0). This way, every time we call a function from the home controller, such as contact, about_us, services, etc., we can snip home out of the URL and keep our URLs short and pretty.

This should work but will need some adaptation to fit with your CMS structure.