Indeed, hooks does not require RESPONSE interface,
and should be setup before, at the system level (i.e CMS_API)
Added exportation solution via CMS_HOOK_EXPORT.
Updated blocks settings for demo example project.
Prepared evolution of feed module, by allowing json object to list feeds locations.
The associated key will be used to identify the location, and have category filter by location.
- for block {block_id}, to have a cache with 3600 seconds of expiration,
declare in the cms.ini
[blocks]
{block_id}.expiration=3600
Added support for size in feed aggregation with new field "size"
Redesigned the CMS_BLOCK system,
- added condition attribute. It can be set via configuration file
with
[blocks]
{blockid}.region={region_name}
{blockid}.conditions[]=is_front
{blockid}.conditions[]=path:location-path/foo/bar
- For backward compatibility, the CMS will check only conditions for block name prefixed by "?".
Improved the configuration library to support list and table properties.
Updated theme for now, to include the feed examples.
Added "cache" classes, to ease caching of html output for instance. (TODO: improve by providing a cache manager).
Revisited hooks management, and added new CMS_HOOK_MANAGER.
Added admin, and other link into navigation menu that goes into first sidebar.
Fixed theme info, and template for sidebar ids.
Better css class name for cms node content.
Added CMS_HOOK_RESPONSE_ALTER to give a last chance to alter the response before rendering.
This hook should not be used, when there are other alternative hook that answer the need, but this is proposed for now, as a way to alter response by adding css, js url, ...
Moved blog under official modules folder.
Cleaned theme of demo example project.
Renamed NODE_MODULE as CMS_NODE_MODULE.
