The examples on this site are currently tested to work on Phalcon V3.4 and Phalcon Devtools V3.2 Some issues may arise when using later versions.

Please get in touch or post a comment below the post if you encounter a problem.

"Assets" in a web application generally refers to the resources which make up the application. This could include text, images, video, icons, color palette codes, audio, css stylesheets. From a programmer's point of view, assets generally have a narrower scope. In the context of building and implementing a website when we refer to assets we're generally talking about items which may be re-used in various parts of the website. The organisation's logo for example is likely to appear many times throughout the site. Certain snippets of css styling are also likely to be re-used.

Inexperienced web developers who want to re-use an image or a piece of code will generally copy and paste that code onto a different page or into a different folder associated with that that page. This approach creates a nightmare for the future development and maintenance of the site/system. Any time the icon, image or stylesheet changes it must be updated in all the locations where it has been re-used. This can be dozens of locations and people who use the cut and paste approach don't tend to keep a log of where the item was re-used. Using the same code in multiple locations is a violation of the programming principle DRY (Don't Repeat Yourself) which is fundamental to writing good code.

Assets or resources which are re-used in a site or system should be stored in one location and then referred to from the various different folders, paths and pages of the website. This can often be achieved through careful use of relative path referencing. For example, referring back to the css folder when incorporating a style on a page using something like <link type="text/css" href="../../../css/mystyle.css">. The dot dot will reference the folder one level up the tree from the folder the the page is stored in. This approach can work fine for a small website but can become unwieldy for larger sites. Small websites tend to evolve into larger sites so use of good techniques early on can be the difference between success and failure of a site or system which experiences rapid expansion. Given that rapid expansion tends to be the goal of most websites this area merits further consideration.

Another advantage of using assets is that you can pre-process them before serving them up to the user. The main reason for doing something like this is to compress the file before it is downloaded with the ultimate aim of improving the overall response time of the application.

Most 3rd party components are made available in minified or sass format but if your website has a lot of css and js code which you or your organisation is maintaining yourselves this approach to pre-processing the assets can be useful. There are also a number of popular third party applications such as Grunt and Gulp which can do this for you. 

The phalcon assets manager is a service which allows programmer to add assets to the general list of assets as follows:


For this to work the file sytle.css must be placed in the folder /public/css within the application folder structure.

For js assets the equivalent code is:


and the file must be placed in the folder /public/js.

Whenever those assets are required the programmer can add them to a view from the corresponding controller action using either PHP

<?php $this->assets->outputCss(); ?>

Or Volt

{{ assets.outputCss() }}

Similarly for Javascript files outputCss becomes outputJs.

This approach works well for components such as jquery or bootstrap that you may want to add to the general collection of assets and have them appear in every view. Typically, however, you will want a named collection of assets which will only appear on certain views.

Naming a collection of assets gives you much more control over when they are deployed. Ideally you only want to add assets to a view when they are specifically required by that view otherwise your application could become bloated and performance will be affected.

For a simple example of using a named collection of assets and loading/using them in a more surgical way see this example which describes how to integrate FullCalendar into your application.

When and Where to Add asssets

Deciding when and where to add assets in you application about understanding whether you want your assets to be generally available. Assets such as jquery and bootstrap could be loaded by the base level template of your application. In this way they will probably appear on almost every page as it is loaded. In this case I have found that adding an initialize() function to the ControllerBase class and adding the assets to the general collection there seems to work well. All Controller classes should extend from ControllerBase so the initialize function will be called as each Controller class is loaded. The general collection of assets will then be available throughout the application.

public function initialize()

If the goal is that they should appear on every view (as would generally be the case with bootstrap and jquery) then they could be added in the base template index.phtml or index.volt file which is in the /views folder of the application. Where in that file the assets are added relative to the rest of the content which will be inherited from other templates and views is also likely to be important. Often components have interdependencies and one component might need to be loaded on a webpage before another component in order for it to work.

Consider the following code:

Buy default the scaffolder creates code which loads jquery and bootstrap after other content which is inherited. If that content depends on boostrap and jquery you need to load them before other content. In the above example boostrap and jquery are hosted on Content Delivery Networks. This is perfectly sensible and will probably improve the performance of the overall application. There are situations where it may be desirable for the programmer to host those components locally rather than on a CDN in which case they could be loaded as assets. The line 


Which would output those assets would still have to be moved above the <div> block which encloses the inherited content.