Contributions to this type must be valid Cascading Style Sheet (CSS) syntax and are always placed inside the <head> element, and is only valid in the co:head extension point.
Use generated CSS that uses relative URLs when referencing other resources like images or other CSS documents. By using relative URLs, resources can be resolved regardless of the context root in which they are placed.
Some of this configuration might be static across pages and can change only when the server is restarted, such as values that are retrieved from Resource Environment Provider custom properties. This data can be loaded as an external script so that it can be cached across users and pages.
Because it is possible to change through configuration changes, this configuration typically has relatively short cache expiration times so that it is still publicly cacheable but can still expire to pick up potential configuration changes.
The link to the URL that creates the aggregated content is part of a script tag.
Important: It is the responsibility of the contributor to ensure that the content of the contribution does not include malicious code. For example, configuration values read by a data source should be escaped before serializing the data.
It is the responsibility of the contributor to ensure that the content of the contribution does not include malicious code. For example, configuration values read by a data source should be escaped before serializing the data.
Contributions of this type should not vary based on the client to further optimize the code. For example, do not use a data source that generates different data for different browsers to eliminate code paths that branch based on the browser type or version. Instead, the data source should generate the same data that works across all supported browsers. Users can then download and save the combined output as a static resource in a separate domain.
Important: It is the responsibility of the contributor to ensure that the content of the contribution does not include malicious code.
Contributions to this type must be valid HTML in context of the extension point where they contribute to. For instance, contributions to the co:head extension point can include markup that is only valid for the <head> section of the page. Alternatively, contributions to the co:config extension point can include markup that is only valid inside the <body> tag.
This type is best used for contributions whose markup is not primarily visual but rather semantic, such as resource loading.
Modules that have visual markup should be documented and provided through a POC URI
dynamic content spot. You can place this contribution in a specific place within the theme template relative to the design of the theme. If these unique location-important markup contributions are intended to be configurable or modified by a user, the dynamic content spot mapping data source might be used to map the POC URI
to an alternative URI
. Also, you can associate a dynamic content spot with a module ID so that the rendering of the data can be influenced by the profile used for the page.
It is best not to use portal render request-dependent attributes, because there is no guarantee that those attributes are available in all cases. For example, when used in deferred mode, the render context is not available.
Parent topic: The module framework