Cms configuration

Webpagebytes CMS can be customized through a plugin architecture, which allows to replace various components with custom ones.
The customization is done through a xml configuration that the CMS engine will need to read in order to initialize itself.

The following areas can be customized

Content data storage

Webpagebytes CMS stores the site urls, site pages, page modules, messages, global parameters in a persistent storage which is represented by the WPBAdminDataStorage interface. This interface has methods to create, update, delete, query the CMS resources.
An application can select any kind of data storage (relational database, nosql database) as long as it can implement the WPBAdminDataStorage interface.

Use wpbadmindatastorage xml element to customize the data storage. The element factoryclass of wpbadmindatastorage needs to specify the full class path of WPBAdminDataStorage implementation.

Webpagebytes offers two plugins for content data storage.

Content cache

Webpagebytes CMS stores the internal resources in memory (cache) to optimize the performance of content delivery.
The interface WPBCacheFactory is a factory interface to specific cache resources. Each CMS resource has its own cache, for example site urls has WPBUrisCache cache interface. The cache implements WPBRefreshableCache interface, which allows its content to be refreshed. The implementation of WPBAdminDataStorage needs to refresh the cache of a resource that is added, modified or deleted so that any change is refrected instant in the CMS delivered content.

Use wpbcache xml element to customize the content cache. The element factoryclass of wpbcache needs to specify the full class path of WPBCacheFactory implementation.

Webpagebytes offers two plugins for content cache.

Files storage

Webpagebytes CMS stores site files in a persistent storage that is designed and optimized for files storage.
The interface WPBFileStorage is an abstract specification of a file system that allows to add, delete and get files together with their meta information. The interface is abstract and does not require a specific file storage, allowing the implementation to use a local file system or a cloud based file storage.

Use wpbfilestorage xml element to customize the files storage. The element factoryclass of wpbfilestorage needs to specify the full class path of WPBFileStorage implementation.

Webpagebytes offers two plugins for files storage.

Authentication and Authorization

Webpagebytes CMS can be customized so that requests to the administration interface to be authenticated and authorized.
The interface WPBAuthentication contains an abstract method checkAuthentication that is called on every administration operation.
The web application can choose any implementation for WPBAuthentication, a new one or to select one from the already implemented plugins, it can even be configured for no authentication (suitable only for non production environments).

Use wpbauthentication xml element to customize the authentication and authorization. The element factoryclass of wpbauthentication needs to specify the full class path of WPBAuthentication implementation.

Webpagebytes offers two plugins for WPBAuthentication interface.

Project base url

In most of the cases the servlet container that hosts the Webpagebytes CMS will be deployed behind a load balancer. Depending on the load balancer configuration, the Host header of the HTTP request might not preserve the original request destination once handled by the Webpagebytes servlet code.
A case to consider is also the batch mode, where there are no HTTP requests involved.

Webpagebytes CMS provides the access to the project base url through the wpbRequest model key of WPBModel.
The project base url value is obtained in the following order:

In case of batch mode, the only way to specify a project base url is to use the CMS configuration XML file.

See the xml example for project base url configuration.

General parameters

cache_query_param is an optional parameter, the default value is 'cqp'.
Site urls that are linked with site pages having plain text source interpretation, or with site files, can include a max-age header when the HTTP request uri contains a query parameter named with the value of cache_query_param. This can greatly improve the server performance and the user experience.
The Demo application has a style.css file available at, this is linked with a site page that contains the css content so it can be edited easy. In order to be able to benefit from the max-age header, the css url should contain a dynamic part so that everytime the css content is changed so will change the url too.
This dynamic part is the cache_query_param . The Demo application includes the css as
<link href="" rel="stylesheet">
The vv is the cache_query_param configuration value, and 3934878512 is a CRC value of the css content. See wpbUri Freemarker directive on how the CRC value can be generated automatically.

cache_max_age is an optional parameter, the default value is '31536000' which is 365 days converted in seconds.
The cache_max_age represents the time duration that will be used in the max-age header. See cache_query_param for more information.