Absolutely! Frequent changes may be made to both bundled and non-bundled addons. Bundled addons will be updated via the upgrader. For non-bundled addons, you will have to update them through the addons management screen (Admin Zone > Structure > Addons). You will be informed which ones need updated.

Once version 11 reaches release candidate, we do not expect frequent updates to non-bundled addons anymore. But it is still good practice to check after every update.

Yes, for basic non-custom v10 sites. However, expect some issues to arise in the process. And please report those issues to the tracker.

For v10 sites with non-bundled addons or customisations, upgrading to v11 will likely break the site until you update the non-bundled addons or temporarily remove the customisations.

We aim to have the upgrader fully functional for a large majority of types of sites and for sites using non-bundled addons by the time version 11 reaches release candidate stage.

We do not recommend upgrading production v10 sites at this time until v11 reaches stable.

Yes (probably). Always remember especially during alpha and beta phases that things can break. Please make backups first. And let us know on the issue tracker if an issue occurs.
 

Note: You cannot upgrade from 11 alpha to 11 beta without first upgrading to 11.alpha4 (if you are not already on 11.alpha4).

As of July 22, 2024, we entered beta status where our focus is now smashing bugs and stabilising the software. All planned features have been implemented for 11.0 (and most others deferred to 11.1 or later), though we may still merge in a few minor features or tweaks. The upgrader has been tested on a typical non-custom v10 site.

We will be releasing several beta versions in the beta phase.

We do not know when we will be able to release the first Release Candidate or stable versions at this time.

These plans are all subject to change without notice.

• data-tpl: Used with the $cms.behaviors.initializeTemplates function and PARAMS_JSON tempcode directive to bind JavaScript logic to HTML templates.
• data-view: Used with the $cms.behaviors.initializeViews function to associate JavaScript view classes (inheriting from $cms.View) with specific HTML elements.

• Organization: They provide a structured way to access Composr-specific functionalities, avoiding global namespace pollution.
• Abstraction: They encapsulate common tasks, simplifying DOM manipulation, form handling, and interaction with Composr's UI.
• Consistency: They offer a consistent API across different parts of Composr.

• Model/API: The sources directory primarily houses scripts forming the Model/API, handling data logic and business rules.
• View: Templates in themes/default/templates represent the View, responsible for presenting data to the user. Comcode pages can also be considered part of the View.
• Controller: Entry scripts like index.php and site/dload.php act as front controllers, directing requests. Modules and blocks, residing in */pages/modules and sources/[mini]blocks, respectively, serve as controllers, managing user interactions and determining which View to render.

• Installing multiple language packs: Make sure you have at least two language packs installed.
• Enabling the Conversr multi-language option: Go to Admin Zone > Setup > Configuration > Site options > Internationalisation.
• Running a Commandr command: Execute the necessary command to set up the database structure for multi-language content (unless you already enabled Support content translations when installing).

• Template editing: You can modify templates to use different language strings based on user gender. This involves adding Tempcode logic to dynamically select the appropriate string.
• Custom Profile Fields: Create a Custom Profile Field for "Gender" and use it to conditionally display gendered language strings in templates.