Download the PHP package mcms/front-end without Composer

FrontEnd

View composers

Upon installation a new service provider is installed "ViewComposerServiceProvider". This provider is responsible for containing all of your view composers, for example menus, sidebars etc. It comes with a menu composer which looks for header-menu and footer-menu slugs to pass them on to the partials.header and partials.footer views as $HeaderMenu and $FooterMenu respectively. Any new composers should be registered in that service provider

Editable regions

An editable region is a part in the layout that you can either allow the user to add types of content or you can add stuff by using a class. It needs to be configured in the "editableRegions.php" file in the config folder. Each region can be either of type generic or class. Each item must have a type and an item property to be valid

OR

If it is of type class you need to provide the class name

This allows for creating sort of widgets that the user cannot edit (e.g. latest articles) but you can allow the user to change custom settings of yours, like results per page.

This can be very powerful when you need to add custom logic to your area or need to be sure that the user will not "break" something.

The generic type is versatile and extremely powerful. It allows any type of content to be presented in that area. The default types are :

• HTML : plain html, can be anything, so be careful in your templates
• image : An image accompanied by meta data like link and alt-title
• item : Using the ItemSelector class, you get items from any module. Don't forget to "process()"
• structured-data : you decide what the user should input. Allows for default data types

Using the API

Start using the API by filtering the region, for example the front page regions is what you want

The $regions object now holds all the editable regions for the frontPage layout. The quickest way to proceed is to do a simple which will get you all of the regions.

Usually though, we need to process the regions, cause if they contain items, we need to get them from the DB. So we need to do a in order to go to the DB and fetch the actual items.

Remember, the actual item will be in the "item" property.

Sometimes, we know how our layout is going to be and for example, we know that we only need to process 1 or 2 regions, thus we filter for improved performance. . This will only process the 2 regions mentioned in the array.

There can be a case where we only need one region. We can filter it down and the result will not be an array, but the actual object (like doing a $regions[0]).

This will fetch the slider region, processed as a single object.

Process multiple regions

which will return a named array of the results

A word of caution

Though editable regions can be extremely powerful and handy to use, try not to overdo it. Giving total control to the user can break the design or possibly make that layout slow because of all the stuff the user is adding

Layouts

typical config

Layouts support settings that can be filled by the user and they are saved in the item settings field. You can use them to customize your layouts.

API

First of you can access the item layout via the property. Then, you can find the layout using the layout manager

The second parameter refers to whether you choose to process the layout or not, doing so, it wil fetch all layout data (execute classes, fetch items, etc).

If you have set the 'beforeRender' option, then you will get a handler class back which you can use to get the result of your "beforeRender" class. For example, we have a class which grabs a single id set in the layout settings and fetches that page as an object. You can gain access to that object simply by doing this :

The parameters in the handle class are just an example of how you can pass whatever you feel like to that handler class

You can add a new layout at runtime by calling the method like so