PHP Controllers - 1

Okay, so what’s a controller and why would I want one?



In cs-cart, a controller is the basis for navigation and collection of data and presentation of information… Whew, that was a mouthful.



The home page of your store is the ‘index’ controller. it is special and not handled like most others. But it can be modified in the same way as other controllers.



Anything related to a product is the ‘products’ controller and then there are ‘categories’, ‘checkout’, etc. You can identify which controllers are associated with each AREA (customer or admin) by looking in the controllers/ directories.



A controller has several standard properties to it and are part of the URL or “dispatch” of the controller. A controller is invoked by the parameter “dispatch=” in the URL. The standard properties of a controller are separated by dots ‘.’ after the controller. These are:

MODE ($mode)

ACTION ($action)

DISPATCH_EXTRA ($dispatch_extra)



In the above properties there is a PHP define for the property (like MODE) and a variable that is defined when a controller is executed (like $mode). These are used within the controller to tell it how to behave.



So a dispatch of “dispatch=checkout.add…1234” would come to the ‘checkout’ controller with

$mode = ‘add’

$action = ‘’ (empty)

$dispatch_extra = ‘1234’



This is generally how single products are added to the cart via an ajax request where 1234 is the product_id. Just wanted to give an example of using all the properties…



Other times the key info is sent as an http REQUEST. I.e. “&order_id=123”. So these are not really consistent. But for the most part things like product_id, category_id, order_id, etc. are passed as REQUEST parameters either via http POST or GET methods.



For the basics about what a controller does, let’s look at a simple one. We’ll walk through controllers/customer/pages.php.



You’ll see if( $mode == ‘view’) This means that we’re only going to do something for the ‘view’ mode. There are no other modes available to customers. But if you look in controllers/admin/pages.php you’ll see other modes avaiable.



The first line:

$_REQUEST[‘page_id’] = empty($_REQUEST[‘page_id’]) ? 0 : $_REQUEST[‘page_id’];

simply makes sure there is a page_id set and that it’s an integer if not set.



The next line

$preview = ($auth[‘area’] == ‘A’ && !empty($_REQUEST[‘action’]) && $_REQUEST[‘action’] == ‘preview’) ? true : false;

will always have $preview == false since this is the customer controller. So not sure why it’s even in there other than it’s a bug!



The next line

$page = fn_get_page_data($_REQUEST[‘page_id’], CART_LANGUAGE, $preview);

Loads the page data from the database for page_id 1.



The next line checks to see if the page is active or not. If not, it returns a value so that a 404 Page Not Found header will be generated. (we’ll talk about returning from a controller later. But it is critical that this be done correctly).



The next lines set the template variables for the page’s meta-description and for the meta-keywords. Note the $view variable which always points to the current template page that will be constructed. However, I’ve found that $view is NOT always set so it is safer to use Registry::get(‘view’)-> instead of $view-> (just an observation).



The next line assigns the page title and the next one extracts the page heirarchy into the $parent_ids array from the id_path comma separated value (csc calls this a hash). It then uses the parent_ids to build the breadcrumbs.



And finally, the $page template variable is set with all the page data from the database.



For consistency, this controller should end with

return array(CONTROLLER_STATUS_OK) for consistency.



So what happens next. The system will look for a template based on the ‘mode’ of the controller. So by default, it will look for:

skins//customer/views/pages/view.tpl



If it can’t find that file it will return a page not found. Otherwise, all the template variables assigned so far will be available for use in the template.



So in summmary, a controller is what’s specified to tell the system what to do. The mode, action and dispatch_extra properties tell the controller what to do. The mode is special in that it also identifies the template file to use.



I’m tired of typing so we’ll end this one here. In the next post I’ll talk about addons and how they behave just like general controllers…

[quote name=‘tbirnseth’]$preview = ($auth[‘area’] == ‘A’ && !empty($_REQUEST[‘action’]) && $_REQUEST[‘action’] == ‘preview’) ? true : false;

will always have $preview == false since this is the customer controller. So not sure why it’s even in there other than it’s a bug![/QUOTE]

This is not a bug. You can preview disabled pages.

In Admin Panel when you edit a page on the right you can see: This link allows you to view the page as if logged in as the administrator.

As I stated, this was being discussed in the context of a customer controller. Hence $auth[‘area’] will never == ‘A’ and the statement will return false.



In the admin controller, it can return true.



My guess is that since ‘preview’ is not available to customers, that the same code was simply cut/pasted between the two controllers.

Thank you for your work :wink:

If someone need: russian translation of this article.

Excellent post. Thank you for taking the time to explain this.



Is there a possibility of any more? Addons etc?

Hi tbirnseth,



You said: “The home page of your store is the 'index' controller. it is special and not handled like most others. But it can be modified in the same way as other controllers.”



So what is “special and not handled like most others”. Can you show me how, please ?



I need modify $product in Skin/myskin/customer/blocks/list_template/products_list.tpl but i dont know where is $products in this tpl was assigned from (from which controller or php file ? ). I also looked in controller index.php but didn't see anything.



Please help me !