What the sets contain 

The extension ships one content element, so it ships one component set and one aggregate set that depends on it.

The component set depends on fgtclb/academic-base-ctype-group, the set of EXT:academic_base that labels the content element group all academic extensions sort their elements into.

The content element is hidden by default 

EXT:academic_study_plan hides its content element for the whole installation and brings it back per component. Whichever of the two mechanisms below you use, it is what makes Academic Study Plan selectable in the backend again — without one of them the content element is not offered, and existing records keep rendering.

This is not new in version 2.4: this extension always hid its content element. What changed is the file that brings it back and the name it is registered under — see Breaking: Site sets and static templates have been restructured.

Include the site set 

Add the set to the config.yaml of the site that should offer the content element:

 base: 'https://example.com/'
 rootPageId: 1
+dependencies:
+  - fgtclb/academic-study-plan

See also TYPO3 Explained, Using a site set as dependency in a site.

Include static templates 

For an installation that still configures its frontend through sys_template records, the same files are registered as static templates and as selectable page TSconfig files.

Do not combine both 

A site that uses the site set and the static template reads the shipped files twice. The site set is applied before the sys_template record, so the second read happens after the site settings and after config/sites/<site>/constants.typoscript — and it resets every constant the extension ships a default for back to that default. For this extension those are the three Fluid root paths of the content element.

Nothing else is damaged: the Constants and Setup fields of the sys_template record, the page TSconfig of a page and the page TSconfig files selected on a page are all applied afterwards and still win. Use one mechanism per site and the question does not arise.

Report Issues 

You can report issues at https://github.com/fgtclb/academic-extensions/issues.

Also available 

Breaking Changes 

Features 

Deprecation 

Important 

Description 

The stylesheet and the script of the study plan are now compiled from sources in the repository rather than maintained as finished files, and both changed where they live and how they are loaded.

Their paths gained a frontend/ segment:

EXT:academic_study_plan/Resources/Public/Css/academic-study-plan.css
->  EXT:academic_study_plan/Resources/Public/Css/frontend/academic-study-plan.css

EXT:academic_study_plan/Resources/Public/JavaScript/academic-study-plan.js
->  EXT:academic_study_plan/Resources/Public/JavaScript/frontend/academic-study-plan.js

The script is now an ES module. It is registered in Configuration/JavaScriptModules.php and addressed by the bare specifier @fgtclb/academic-study-plan/frontend/academic-study-plan.js.

The TypoScript include Configuration/TypoScript/Includes/Page.typoscript has been removed. It added both files to every page of the site through page.includeCSS and page.includeJSFooter . There is no TypoScript counterpart for loading an ES module, so both assets are now loaded by the plugin template instead — which also means they are only requested on pages that actually render a study plan.

Impact 

An installation that uses the extension as shipped needs to do nothing: the template loads what it needs.

An installation that referenced either file by path, or that imported the removed TypoScript include, no longer gets the assets.

Affected installations 

Installations that override AcademicStudyPlan.html, that import Includes/Page.typoscript from their own TypoScript, or that reference either asset path from a site package.

Migration 

Remove any import of the deleted TypoScript include and drop your own includeCSS or includeJSFooter entries for these files.

In an overridden template, load them the way the shipped one does:

<f:asset.css identifier="academicStudyPlan" href="EXT:academic_study_plan/Resources/Public/Css/frontend/academic-study-plan.css" />
<f:asset.module identifier="@fgtclb/academic-study-plan/frontend/academic-study-plan.js" />

<f:asset.script> cannot be used for the script any more — a classic script tag does not execute an ES module.

Description 

Support for TYPO3 v12 has been removed for the 3.x version line, based on the dual TYPO3 core version support per major version of the academic extensions support matrix.

This includes removing build, test and configuration parts only required for TYPO3 v12. Version specific code paths are dropped in a dedicated step.

Impact 

TYPO3 v12 or older instances can no longer install or update to the 3.x version of the academic extensions and are required to upgrade TYPO3 first.

The extension cannot be installed on TYPO3 v12 anymore but does not break otherwise.

Affected installations 

All installations using an academic extension on TYPO3 v12 that want to upgrade to the 3.x version line.

Migration 

Upgrade the TYPO3 installation to a supported version - TYPO3 v13 or v14 - beforehand or within the same upgrade step.

Description 

The extensions of this set spelled their page TSconfig directory in three different ways — TsConfig, TSconfig and TSConfig. They now all use TSconfig, which is how TYPO3 spells the term and what the core documentation uses.

In this extension the directory was Configuration/TsConfig.

Nothing was broken before, because every import matched the directory it pointed at. The reason to change it is that a filesystem is case sensitive on Linux and case insensitive on macOS and Windows, so a path copied between two of these extensions resolved on one machine and silently not on another — and a page TSconfig @import that does not resolve raises no error, the configuration is simply absent.

This extension additionally registers a selectable static page TSconfig include, through ExtensionManagementUtility::registerPageTSConfigFile() . The registration was updated with the directory — and reorganised again in the same release, which changed both its label and the value a page record stores. See Breaking: Site sets and static templates have been restructured for what to select instead.

Impact 

Every file this extension ships moved with the directory. The imports inside the extension were updated in the same change, so an installation that only installs the extension has nothing to do.

An integrator who references these paths from their own configuration has to update them, because the old path no longer exists. The files below the directory were reorganised in the same release, so the new path is not the old one with the spelling corrected — take it from the table in Breaking: Site sets and static templates have been restructured:

# before
@import 'EXT:academic_study_plan/Configuration/TsConfig/Default.tsconfig'
# after
@import 'EXT:academic_study_plan/Configuration/TSconfig/ContentElement/page.tsconfig'

# before
@import 'EXT:academic_study_plan/Configuration/TsConfig/Includes/academic-study-plan.tsconfig'
# after
@import 'EXT:academic_study_plan/Configuration/TSconfig/ContentElement/page.tsconfig'

Affected Installations 

Every installation that imports a page TSconfig file of this extension by path, or that copied such a path into its own site package. An installation that relies only on the auto-included Configuration/page.tsconfig of the extension, or on its site set, is unaffected.

Description 

The three tables of this extension pointed at their icon files directly, through the TCA ctrl.iconfile option. That bypasses the icon registry altogether: the file gets the core provider, which renders the default markup as an <img> tag. An image is opaque to CSS, so the icons kept the colours of their files whatever the backend colour scheme said.

The tables now point at the identifiers academic-study-plan-category , academic-study-plan-module and academic-study-plan-semester through ctrl.typeicon_classes . Those identifiers were already registered in Configuration/Icons.php and unused; they now carry \FGTCLB\AcademicBase\Imaging\IconProvider\CurrentColorSvgIconProvider .

The three files were three-colour illustrations and are redrawn in a single colour, which is what following the text colour means. The shapes are kept: the coloured body becomes an outline, the lighter shapes on it become solid. The module and the semester icon differed in colour and in size only, so they now look alike apart from their proportions.

Impact 

The category, module and semester record icons take the text colour of the backend, so they stay legible in a dark colour scheme - and they no longer carry an orange, teal or grey of their own.

Affected Installations 

Every installation of this extension.

Description 

The table tx_academicstudyplan_domain_model_category was the only one of the three record tables of this extension without 'versioningWS' => true in its TCA ctrl section. It now carries the flag, like tx_academicstudyplan_domain_model_semester and tx_academicstudyplan_domain_model_module already did.

The two of them were declared workspace aware because they are inline children of the workspace aware tt_content . Categories are related to a module through the intermediate table tx_academicstudyplan_module_category_mm instead, so the same reasoning applies to them, but nothing pointed it out — neither TYPO3 nor the test suite reports a missing declaration for that relation type.

Impact 

The flag is what \TYPO3\CMS\Core\Database\Schema\DefaultTcaSchema derives the t3ver_oid , t3ver_wsid , t3ver_state and t3ver_stage columns and their index from, so the table needs those columns added. Run the database analyzer once after updating, in the Admin Tools > Maintenance module or with vendor/bin/typo3 extension:setup .

This is not optional and it does not wait for someone to open a workspace. A workspace aware table is queried with a WorkspaceRestriction in the live workspace too, so until the analyzer has run, both of these raise a database error about the unknown columns:

• the backend list of study plan categories — DatabaseRecordList adds the restriction unconditionally, with the backend user's workspace, including workspace 0 ;
• the frontend rendering of any translated study plan — the language overlay in \TYPO3\CMS\Core\Domain\Repository\PageRepository selects the overlay record with a FrontendRestrictionContainer , which carries the restriction by default.

Once the columns are there, categories can be created and changed in a workspace, and any consumer that gates on ctrl.versioningWS — the workspaces module, and third party extensions that restrict themselves to versionable tables — sees the table.

That also flips how an editor's change is stored. In a workspace with live editing enabled, a category edit previously went straight to live, because TYPO3 permits live editing only for tables that are not workspace aware. It now becomes a workspace version that has to be published.

What does not change is the frontend rendering of the study plan itself. This extension selects semesters, modules and categories with its own queries, which add no WorkspaceRestriction and perform no version overlay, and they resolve their relations through live uids. A workspace preview therefore keeps showing the live study plan. The one exception is a side effect of the language handling: the translation of a record is fetched through PageRepository , which does overlay it, so in a workspace preview a translated category can differ from its default language row. That asymmetry is not new — it applies to the semester and module tables in the same way — and it is tracked separately.

Affected Installations 

Every installation of this extension. No existing record is touched and no rendered output changes — but the database analyzer has to run, and until it does the two places named under Impact are broken. Development instances built from a committed database snapshot need the same treatment.

Description 

\FGTCLB\AcademicStudyPlan\Service\StudyPlanService builds the queries for semesters, modules and categories itself. They carried no workspace constraint and no version overlay, with two consequences.

Unpublished drafts were served to the public. A workspace version is an ordinary row in the database, told apart from a live record only by t3ver_wsid . With no condition on that column every draft was selected alongside the record it is a draft of, and rendered next to it — including records created in a workspace and never published, which have no live counterpart at all.

A workspace preview was not a preview. It showed the live records and the workspace records together, rather than the workspace state.

Both are fixed by the two pieces TYPO3 provides for it: a WorkspaceRestriction on each query, which in the live workspace constrains to t3ver_wsid = 0 , and PageRepository::versionOL() on each fetched row, which replaces a record with its draft in a preview and drops it where the workspace deletes it.

Impact 

On the live site, records disappear that should never have been there. If a study plan showed duplicated or unexpected semesters, modules or categories, those were workspace drafts and they are gone now. No live record is affected.

In a workspace preview the study plan now shows the workspace state.

What still is not previewed is a relation changed in a workspace. Attaching or detaching a category from a module inside a workspace is not reflected: the overlay keeps the live uid of the module, so the categories are looked up through the live relations. The content of a record — its label, colour, note, credit points — is previewed correctly. Only the wiring between records is not.

Affected Installations 

Every installation that uses workspaces for study plan content. An installation that never created a workspace version of a semester, module or category renders exactly as before.

Breaking Changes 

Features 

Deprecations 

Important notes 

Also available 

Breaking Changes 

Features 

Deprecation 

Important 

Description 

This extension already shipped both delivery mechanisms, and it already hid its content element by default — it is the only academic extension that did. What it shipped them through were four one-line @import files around two real ones:

• Configuration/TypoScript/Default/setup.typoscript and Configuration/Sets/AcademicStudyPlan/setup.typoscript both imported Configuration/TypoScript/Includes/ContentElement.typoscript.
• Configuration/TSconfig/Default.tsconfig and Configuration/Sets/AcademicStudyPlan/page.tsconfig both imported Configuration/TSconfig/Includes/academic-study-plan.tsconfig.

The indirection is gone. Both mechanisms now read one physical copy of every file, and both of them deliver the extension per component:

• Configuration/TypoScript/ContentElement/ holds the TypoScript of the Academic Study Plan content element and is what the static template registers and what the set points its typoscript key at.
• Configuration/TSconfig/ContentElement/page.tsconfig holds its page TSconfig and is what the page field Page TSconfig offers and what the set points its pagets key at.
• Configuration/TypoScript/Full/ and Configuration/TSconfig/Full/page.tsconfig are the aggregates for installations that do not use site sets.

Three things changed beyond the paths:

• The three Fluid root paths of the content element are constants now, plugin.tx_academicstudyplan.view.templateRootPath , …partialRootPath and …layoutRootPath . They were assigned in the setup directly and could only be changed by overriding the content element object. The shipped values are unchanged, and the new constants.typoscript is delivered by both mechanisms together with the setup.
• The wizard entry of the content element is registered unconditionally. It used to sit in a [typo3.branch == "12.4"] condition, which never matched on a version this release supports.
• The published set fgtclb/academic-study-plan-default is an alias without payload now. It depends on the new aggregate fgtclb/academic-study-plan , which depends on the component set fgtclb/academic-study-plan-content-element .

Impact 

A sys_template record that selected the old static template keeps its stored value, and that value now points at a folder holding no constants.typoscript and no setup.typoscript. It is not an error — the frontend simply loses the content element configuration, and the element renders as an empty content element.

A page record that selected the old page TSconfig file keeps its stored value too, and that value now points at a file that does not exist. An unresolved page TSconfig include is silent, so the content element stops being selectable on that page tree without any message.

A site package that imported one of the shipped files by path fails to resolve it. @import of a missing file is silent, so this also shows up as missing configuration rather than as an error message.

Affected Installations 

Installations that select the static template or the page TSconfig file of this extension, that depend on its site set, or that import one of the shipped files from an own site package.

Migration 

Replace the static template entry in the sys_template record:

Replace the page TSconfig entry in the page record of the site root, tab Resources, field Page TSconfig:

Sites that use the site set instead need no migration — but they must not use both mechanisms at once, see the Configuration chapter.

Adjust every @import in an own site package:

A site configuration may name the new sets instead of the published one:

Breaking Changes 

Features 

Deprecation 

Important 

Breaking Changes 

Features 

Deprecation 

Important 

Breaking Changes 

Features 

Deprecation 

Important 

Breaking Changes 

Features 

Deprecation 

Important 

Breaking Changes 

Features 

Deprecations 

Important notes