Template Settings and Inheritance

JoomLeague separates competition data, sport rules and presentation settings. Template settings decide which supported sections a frontend view may present; they do not change participants, results, standings calculations or any other canonical competition record.

This separation is essential on an installation that publishes several sports. A football project, running race and tennis tournament can share one component without inheriting one global football-oriented layout.

Template settings are not com_config

Joomla's System → Global Configuration → JoomLeague contains installation-wide operational options such as timezone inheritance, automation and telemetry preferences. It does not contain sport rules or frontend template parameters.

Use these JoomLeague screens instead:

• Components → JoomLeague → Templates shows template values associated with each active bundled sport-profile version;
• Project Panel → Project Templates stores presentation differences for one project;
• Joomla menu items and modules provide the final view-instance controls they explicitly expose.

Project Rules are a separate contract. A rule can change how the competition works; a template setting can only change presentation.

The five resolution layers

JoomLeague resolves a template field from five ordered layers. A later layer wins over an earlier one:

1. Template-definition default — versioned fallback known by the component.
2. Bundled sport-profile default — presentation selected by the immutable profile version.
3. Local profile-version override — a sparse installation-specific difference for that exact profile version.
4. Project override — a sparse difference belonging to one project.
5. Menu or module override — a presentation difference for one rendered Joomla menu item or module instance.

For example, the generic Results definition may hide set scores, while the volleyball profile enables them. One volleyball project can override that choice, and a dedicated menu item can make a final supported adjustment without changing either the profile or project.

Sparse inheritance

An override stores only fields whose Override switch is enabled. An unchecked field is absent from the override and continues to inherit its value. It is not stored as false, zero or an empty string.

If every switch in one project template is disabled, JoomLeague removes the empty override record and restores complete inheritance. This keeps projects eligible for compatible profile-default changes without copying entire configuration objects.

Associative objects may merge recursively. Lists, where supported by a future definition, replace the inherited list as one complete value. Unknown fields, wrong data types and values outside a declared option list are rejected.

Available template definitions

The 6.2 development contract currently defines six typed presentation areas. A project exposes only definitions listed under template_defaults by its bound sport-profile version.

The field labels and descriptions shown in administration come from en-GB language constants. The values are typed as Yes/No, integer or a closed dropdown option; administrators do not edit raw JSON.

Inspect profile defaults

Open Components → JoomLeague → Templates. All profile accordions start closed. Each heading shows the translated profile name, profile code and version in separate columns.

Expand one profile and inspect every template section:

• Bundled is the value in that immutable profile payload;
• Override contains only a published local profile-version difference;
• Effective is the resolved profile value before a project is considered;
• Inherited means no local profile difference exists;
• Overridden means at least one local field differs.

This page is an audit overview, not a raw JSON editor. Profile defaults are part of a versioned contract. During normal administration, customise one project in Project Templates instead of modifying a bundled profile file.

Configure one project

Open the project name, then choose Project Templates from the Project Panel. The page is limited to template definitions supported by the immutable profile version attached to that project.

Each row contains five pieces of information:

1. Field — translated label and a description of its visual effect.
2. Inherited — effective value after definition, profile default and local profile override.
3. Override — whether this project owns a value for the field.
4. Project value — typed control used only when Override is enabled.
5. Effective — value currently produced by layers 1–4.

To customise a field:

1. enable Override;
2. choose the new project value;
3. save the form;
4. reopen Project Templates and verify the Effective column.

To restore inheritance, disable Override and save. Do not copy the inherited value into an enabled project field: that creates an unnecessary override and prevents later inherited changes from reaching the project.

All submitted project templates are validated before any are written and are saved in one transaction. A failure therefore does not leave half of the project changed.

Menu and module settings

The final layer belongs to one Joomla presentation instance. Use it for a specific page or module position, not as a substitute for a sensible project default.

Examples:

• a compact homepage standings module can use a lower row limit than the full Standings menu item;
• one Results page can expose venues while another project navigation link remains concise;
• a participant module can show a summary while the full participant page retains complete information.

Only parameters explicitly defined by that menu item or module participate in this layer. A Joomla parameter with no corresponding template field remains a view-specific option and is not silently added to the central template contract.

Development status in 6.2-dev

The five-layer resolver, typed registry, profile overview, sparse project persistence, validation, checksums and MariaDB/PostgreSQL behavior are implemented. The project editor correctly displays inherited, project and effective values.

The central resolved settings are consumed by the Project, Results, Standings, Participant and Event Report component views. This includes the visibility of project identity sections, result grouping and detail links, period or set scores, ranking columns, participant data, lineups, staff, officials, timelines and Schema.org output. Unsupported template groups are ignored by generic views instead of preventing the page from rendering.

Current limitation: frontend modules retain their own Joomla module parameters. They do not yet inherit every corresponding central template field. Race Results also uses the universal result data currently available; its dedicated filters, category, split and team presentation controls remain scheduled for the specialised race output.

This limitation concerns presentation only. It does not alter canonical sport profiles, project rules, results or other competition data.

Choosing the correct layer

Use this decision order:

• Should every sport use the same fallback? Change the versioned template definition in development, not site administration.
• Should every project using one profile version behave this way? Use the profile default or an explicitly supported local profile-version override.
• Is this project the exception? Use Project Templates.
• Is only this page or module instance the exception? Use its Joomla menu or module parameters.
• Does the change affect scoring, participants or progression? It is not a template setting; review Project Rules or the sport profile.

Profile-version boundaries

Profile template overrides reference one immutable profile version. They do not automatically attach to a different version merely because both versions have the same sport code. This prevents a new profile schema from silently reinterpreting an old value.

Projects retain the profile-version reference selected at creation. In the 6.2 pre-release development phase, bundled profiles may still be synchronised in place because historical released versions are intentionally not retained yet. Immutable historical retention becomes mandatory with the first official profile-contract release.

Clone and migration behavior

Cloning a project copies its sparse project-template configuration. It does not duplicate template definitions or rewrite the source sport profile.

Legacy JoomLeague template rows cannot be treated as a new inheritance chain. Migration must resolve the old effective values and convert only meaningful differences into new sparse overrides. This avoids cycles and prevents a legacy master-template relationship from controlling future projects.

Troubleshooting

A template group is missing

The project's immutable sport profile does not list that template code. Check the profile in Sport Profiles and do not insert an unsupported project override manually.

Saving reports an invalid value

Use the rendered switch, number field or dropdown. The registry rejects an incorrect type, unknown field or value outside the allowed options.

Effective equals inherited after saving

Confirm the Override checkbox was enabled. A value entered while Override is disabled is intentionally not persisted.

I cannot restore the profile value

Disable Override and save. Selecting the same visible value while leaving Override enabled does not restore inheritance.

The frontend did not change

First verify the Effective column after reload. Then check whether a menu or module parameter supplies a later value. For modules and the specialised Race Results controls, account for the 6.2-dev limitation described above.

A profile update changed nothing

A local profile override, project override or menu/module override may still win. Inspect the layers from last to first rather than editing the database.

Verification checklist

• [ ] The project uses the intended sport-profile version.
• [ ] The desired template group is supported by that profile.
• [ ] Only intentional project fields have Override enabled.
• [ ] Inherited and Effective columns show the expected difference.
• [ ] Page-specific behavior is configured at menu/module level only when necessary.
• [ ] Public output is tested while logged out and at mobile width.
• [ ] Presentation changes did not become scoring or competition-rule hacks.