What the sets contain 

This extension ships two content elements, so it ships two component sets, one set for the styles.content override described below, and one aggregate set that depends on all of them.

Both content elements are driven by one Extbase plugin, so they share one TypoScript block, plugin.tx_academicprograms . That block is shipped once, in Configuration/TypoScript/, and every component includes it. Which component sets a site names therefore decides which content elements the backend offers, not how much TypoScript is loaded.

Every content element 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 elements are hidden by default 

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

What the sets do not control 

The page type Academic program (doktype 20) and its backend layout AcademicProgram are not part of any set, and enabling or not enabling a set never changes them.

That is deliberate, not an oversight. Both are values stored on pages records: a page carries doktype = 20 and backend_layout = pagets__AcademicProgram long before any site configuration is read. Were they delivered by an opt-in set, every page tree on a site that does not use that set would show [ MISSING LABEL ] for the layout, the layout could not be picked for a new page, and the page type would disappear from the page tree wizard.

They are therefore registered installation-wide — the page type in TCA (Configuration/TCA/Overrides/pages.php), the backend layout in the always-included Configuration/page.tsconfig — and stay available on every site of the installation.

What a set does deliver for that page type is its frontend rendering: the page object that picks the Fluid template of the page type is part of the shared TypoScript block, so a site that includes no set of this extension renders such a page with whatever its own site package defines.

The content load override 

Configuration/TypoScript/ContentLoad/setup.typoscript redefines styles.content.getContent for the whole site so that it selects colPos = 0 only. This is an installation-wide rendering change, it applies to every page of the site and not only to the pages of this extension, and three academic extensions ship the same override.

It is therefore a set of its own, fgtclb/academic-programs-content-load. The aggregate set depends on it, so a site on fgtclb/academic-programs keeps what it had; a site that wants the content elements without the override names the component sets it needs instead of the aggregate.

Include the site set 

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

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

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 that is the plugin.tx_academicprograms constants block, the three Fluid root paths.

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.

What the file enhances 

The file declares a single enhancer of type Extbase named AcademicPrograms , bound to the plugin ProgramList of the extension AcademicPrograms . That pair is what determines the argument namespace the enhancer works on — tx_academicprograms_programlist .

It registers one route for the list action of \FGTCLB\AcademicPrograms\Controller\ProgramController :

routes:
  - routePath: '/{sorting_field}/{sorting_direction}'
    _controller: 'Program::list'
    _arguments:
      sorting_field: demand/sortingField
      sorting_direction: demand/sortingDirection

Both path variables are mapped by a StaticValueMapper , so only the values below ever appear in a URL, and anything else is rejected:

• sorting_field — the segment title selects the demand value title , last-updated selects lastUpdated and sorting selects sorting .
• sorting_direction — asc and desc .

Those are the values of \FGTCLB\AcademicPrograms\Enumeration\SortingOptions , which is also what the sorting select field of the plugin offers.

Both variables carry a default — title and asc . They are the trailing segments of the route path, so a link that uses the default sorting generates the plain page URL rather than /title/asc.

Importing it into a site configuration 

Add the resource to the imports of the site that contains the page with the program list plugin:

imports:
  - resource: 'EXT:academic_programs/Configuration/Yaml/Routes.yaml'

The import is merged into the site configuration, so an installation that already defines other enhancers keeps them as long as no key is named AcademicPrograms twice. That is a statement about the merge and about nothing else: distinct keys keep the entries, they do not keep two enhancers from producing routes which match the same URL.

Limiting the enhancer to its page 

TYPO3 offers every enhancer declared in a site configuration to every page of that site unless the enhancer says otherwise, and it takes the first candidate route whose path matches and whose aspects resolve. The order the candidates are tried in is the order of the imports .

The route of this extension is comparatively hard to collide with, and that is owed to its mappers rather than to its key: both path variables are handled by a StaticValueMapper , so a candidate is only accepted when the segments are one of the three sorting fields followed by asc or desc . Anything else is rejected and the next enhancer gets its turn. A route variable that is mapped less narrowly — one whose aspect comes without an explicit requirements entry compiles to .+ and crosses slashes — has no such protection, and even here a second extension mapping values of the same spelling is enough to make the two compete.

limitToPages settles it by naming the pages the enhancer applies to:

imports:
  - resource: 'EXT:academic_programs/Configuration/Yaml/Routes.yaml'

routeEnhancers:
  AcademicPrograms:
    limitToPages: [23]

The uid is the one of the page carrying the list plugin, and it is the uid of the default language: matching derives the page as l10n_parent ?: uid , so a single entry covers every translation of that page. Plain page uids work on every TYPO3 version this extension supports.

In academic_persons the same mechanism is not a precaution but a requirement — that extension ships three enhancers whose routes overlap each other by construction. See its route enhancer documentation.

What the URLs look like 

Assuming the plugin sits on a page with the slug /programs, a link that sorts by the last update, descending, is built without the enhancer as:

/programs?tx_academicprograms_programlist%5Bdemand%5D%5BsortingField%5D=lastUpdated&tx_academicprograms_programlist%5Bdemand%5D%5BsortingDirection%5D=desc

and with the enhancer imported as:

/programs/last-updated/desc

Caveats 

Two further points are worth knowing:

• The enhancer covers the list plugin only. The detail plugin ( ProgramDetails ) takes no arguments — it renders the program of the page it sits on — so there is nothing to map into a path for it.
• The two mappers are independent, which makes six combinations reachable while SortingOptions only defines five. /sorting/desc resolves although the plugin never offers it as an option.

Also available 

Breaking Changes 

Features 

Deprecation 

Important 

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) beforehand or within the same upgrade step.

Description 

Factory\DemandFactory::createDemandObject() read the submitted category filter itself:

foreach ($demandFromForm['filterCollection'] as $uids) {
    $categoryUids = array_merge($categoryUids, GeneralUtility::intExplode(',', $uids));
}

GeneralUtility::intExplode() takes a string, so a filter value that is a list ended in a TypeError:

TypeError: GeneralUtility::intExplode(): Argument #2 ($string) must be of
type string, array given

That is exactly what a filter select with multiple submits — the argument the category filter select gained in the same release. A filterCollection that is not an array at all did not raise, but emitted a PHP warning foreach() argument must be of type array|object and silently dropped the filter.

Both shapes are reachable from a crafted request without any template being involved, because the controller action takes the demand as a plain ?array $demand = null and validates nothing.

The filter is read through FGTCLB\CategoryTypes\Filter\CategoryFilterNormalizer now, which accepts a single value, a list and a comma separated string, and treats anything it cannot read as no filter.

Impact 

• A category filter select with multiple works.
• A request with an unreadable filter renders the list unfiltered instead of failing.
• An unselected filter no longer contributes uid 0 to the query. The prepended "all options" entry carries an empty value, and every unselected category type added one 0 to the uid list. The rendered result is unchanged — no category has uid 0 — but the list handed to CategoryRepository::findByGroupAndUidList() is empty now, which it accepts since the same release.
• A uid submitted twice is used once.

Affected Installations 

None have to act. Own code calling createDemandObject() with a hand built demand array keeps working, and gains the list shape.

References 

• CategoryFilterNormalizer in EXT:category_types — the class the filter is read with, and where its behaviour is documented.

Description 

ProgramRepository::findByDemand() orders by the sorting option the plugin demands — and by nothing else, so records equal in that ordering (two programs with the same title, for example) were returned in whatever relative order the database yielded. On PostgreSQL that is not the same list twice. The query now appends uid ascending as a tiebreaker.

Impact 

No visible change is expected: within records equal in the demanded ordering, uid ascending is the order every supported database returned in practice, it is simply guaranteed now rather than coincidental.

Affected Installations 

Every installation of this extension.

Description 

FileReferenceCollection::getCollectionByPageIdAndField() read sys_file_reference without an ordering, so a page with several images in one field rendered them in whatever order the database yielded — the sorting_foreign an editor arranges in the media field was ignored, and on PostgreSQL the order could differ between two renders of the same page. The query now orders by sorting_foreign with uid settling ties.

Impact 

Galleries and download lists built from this collection now render the images in the order the editor arranged them on the page — which is what every supported database happened to deliver for references that were never reordered, and what editors expressed but never got for references that were.

Affected Installations 

Every installation of this extension.

Description 

This extension registers a page type with a backend layout and ships the page template for it in Resources/Private/Pages/. Its TypoScript adds that directory to page.10.templateRootPaths , but it did not set page.10.templateName — the property that actually selects the file.

A site package deriving the name from the backend layout therefore did not find it. bk2k/bootstrap-package does exactly that:

templateName.cObject = TEXT
templateName.cObject {
  data = pagelayout
  case = uppercamelcase
  split {
    token = pagets__
    cObjNum = 1
    1.current = 1
  }
}

case = uppercamelcase is GeneralUtility::underscoredToUpperCamelCase() , which lowercases the whole string before it camel cases it on underscores. The registered backend layout pagets__AcademicProgram therefore resolved to Academicprogram.html, and the frontend ended in an InvalidTemplateResourceException — in a production context a page whose body reads Oops, an error occurred!.

The extension now sets the name itself, inside the page type condition it already uses:

[page && traverse(page, "doktype") == 20]
  page.10 {
    templateName >
    templateName = AcademicProgram
  }
[END]

The clear is not decoration. Bootstrap package assigns templateName.cObject , and a cObject overwrites the plain value in ContentObjectRenderer::stdWrapValue() , so assigning without clearing would change nothing.

Impact 

A page of this type renders its template on a site package that derives the name from the backend layout, where it previously did not render at all.

Nothing changes for a site package that sets the name itself, as long as it does so after this extension's TypoScript, and nothing changes for a PAGEVIEW page object — that content object ignores templateName and resolves the file from paths , which is why that integration worked before and is unaffected now.

Affected Installations 

All installations of this extension that use a FLUIDTEMPLATE page object. An installation that shipped Academicprogram.html in its own site package to work around this loses that override: the template of this extension is used instead. Clearing page.10.templateName after this extension's TypoScript restores it.

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.

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:

# before
@import 'EXT:academic_programs/Configuration/TsConfig/page.tsconfig'
# after
@import 'EXT:academic_programs/Configuration/TSconfig/page.tsconfig'

# before
@import 'EXT:academic_programs/Configuration/TsConfig/Page/BackendLayouts/*.tsconfig'
# after
@import 'EXT:academic_programs/Configuration/TSconfig/Page/BackendLayouts/*.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 

This extension ships a ready made route enhancer for its program list plugin in Configuration/Yaml/Routes.yaml, meant to be pulled into a site configuration:

imports:
  - resource: 'EXT:academic_programs/Configuration/Yaml/Routes.yaml'

That file was indented with tab characters. YAML forbids a tab as indentation, so it was never valid YAML: importing it aborts the whole site configuration with the ParseException A YAML file cannot contain tabs as indentation. It has not been usable since it was added.

Three further defects made it a no-op even once it parsed:

• The enhancer key was misspelled AacdemicPrograms . The key only names the enhancer within the site configuration and appears in no URL, but it is what an integrator reads and copies.
• plugin: List named a plugin that does not exist. The plugins this extension registers are ProgramList and ProgramDetails , so the enhancer bound to the argument namespace of neither.
• There was no routes: key. An Extbase enhancer registers one route per entry of that list, so an enhancer without it contributes nothing whatever else it declares.

The file now carries a complete enhancer for the program list plugin, mapping the sorting of the list into the path.

Impact 

The file parses, can be imported into a site configuration, and produces speaking URLs for the sorting arguments of the program list — for example /programs/last-updated/desc instead of a query string. The mapped values are those of \FGTCLB\AcademicPrograms\Enumeration\SortingOptions , which is also what the select fields of the plugin offer.

Note that the sorting and filter form shipped with the plugin submits by POST, so its own requests carry no arguments in the URL and are not enhanced. The enhancer takes effect for links built with the arguments as GET parameters.

Affected Installations 

All installations of this extension. Nothing has to be done, and nothing can have depended on the previous state: a site configuration that imported the file did not load at all.

An installation that worked around this by copying the enhancer into its own site configuration keeps that copy, including the spelling and the defects it copied. A key below routeEnhancers is freely chosen and appears in no URL, so renaming it there is optional; the plugin value and the missing routes: list are not.

Description 

ViewHelpers\Form\SortingSelectViewHelper::renderOptionTags() was removed. It was identical to the method it inherits from FGTCLB\CategoryTypes\ViewHelpers\Form\AbstractSelectViewHelper, down to the last character - the class only ever needed its own getOptions().

That base class writes every option through a single method now, which escapes the option value. It used to concatenate the value unchanged while escaping the label.

Impact 

The rendered markup is unchanged. The options of this select carry the values of Enumeration\SortingOptions - title, asc, desc and their siblings - and none of them needs escaping.

An own subclass overriding renderOptionTags() keeps working, and one calling parent::renderOptionTags() reaches the inherited implementation.

References 

• AbstractSelectViewHelper in EXT:category_types - the class writing the option markup, and where the change is documented.

Breaking Changes 

Features 

Deprecations 

Important notes 

Also available 

Breaking Changes 

Features 

Deprecation 

Important 

Description 

The TypoScript and the page TSconfig of this extension were shipped twice: the static template read Configuration/TypoScript/, and the site set fgtclb/academic-programs shipped its own constants.typoscript and setup.typoscript, each of them a single @import of that folder. The page TSconfig existed only as the wizard file Configuration/TSconfig/page.tsconfig, pulled in by a glob in Configuration/page.tsconfig, and was not selectable on a page at all.

Both mechanisms now read one physical copy of every file, and both of them deliver the extension per component instead of as one block:

• Configuration/TypoScript/ keeps the shared plugin.tx_academicprograms block and the page object of the page type. Both content elements are driven by the one plugin, so that block is shipped once and every component folder names it in a one-line include_static_file.txt.
• Configuration/TypoScript/ProgramList/ and Configuration/TypoScript/ProgramDetails/ are the two component folders — what the static template registers and what the matching set points its typoscript key at.
• Configuration/TSconfig/<Component>/page.tsconfig holds the page TSconfig of a component 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.

The content elements are now hidden by default. The always-included Configuration/page.tsconfig removes both content element types from the selectable ones, and the page TSconfig of a component adds its own back — so an element is offered where it is wanted instead of on every page of every installation. The TCA registration itself did not move, so the frontend renders existing records exactly as before. Editing such a record in the backend is a different matter — read the warning below before upgrading.

The styles.content.getContent override that Configuration/TypoScript/setup.typoscript used to import unconditionally is a component of its own now, Configuration/TypoScript/ContentLoad/setup.typoscript. It redefines a global TypoScript object path for every page of a site, so it must be possible to take the content elements without it.

The page type Academic program (doktype 20) and its backend layout AcademicProgram stay installation-wide. They are values stored on pages records and are not, and must not be, part of any opt-in set. The file that defines the layout moved from Configuration/TSconfig/Page/BackendLayouts/ to Configuration/TSconfig/BackendLayouts/, where the sibling extensions of this family keep theirs; the identifier pagets__AcademicProgram a page record stores is unchanged.

Impact 

A sys_template record that selected the static template of this extension keeps its stored value and keeps working: the registered folder is unchanged, only its label is. What it no longer delivers is the styles.content.getContent override, which moved into a component of its own.

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

Both content elements are no longer offered in the backend until the page TSconfig of their component is included, through the site set or through the page field Page TSconfig.

The set fgtclb/academic-programs keeps its name and keeps delivering everything, so a site configuration that depends on it needs no change.

The duplicated backend template registration is gone 

This extension registered its EXT:backend template override twice, under two different keys and pointing at the same directory: templates.typo3/cms-backend.1730990129 in Configuration/page.tsconfig and templates.typo3/cms-backend.academic-programs in Configuration/TSconfig/page.tsconfig, which the first file globbed in. BackendViewFactory does not deduplicate, so fgtclb/academic-programs:Resources/Private/Backend was appended twice to every backend template, layout and partial root path on every page render.

Only templates.typo3/cms-backend.academic-programs is left, in Configuration/page.tsconfig, which is what the sibling extensions of this family use. Nothing an integrator configures changes with it — but an own site package that overrode the numeric key templates.typo3/cms-backend.1730990129 has to be adjusted.

Affected Installations 

Installations that import one of the shipped files from an own site package, that use one of the content elements of this extension without including its page TSconfig, or that relied on the styles.content.getContent override arriving with the plugin configuration.

Migration 

Adjust every @import in an own site package:

The entry in the sys_template record keeps its value and changes its label:

Add the page TSconfig entry, which did not exist before, in the page record of the site root, tab Resources, field Page TSconfig: Academic Programs: All components (academic_programs), stored as EXT:academic_programs/Configuration/TSconfig/Full/page.tsconfig. Without it the content elements are not selectable any more, and existing records of them lose their CType when they are saved from the backend form.

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

A site configuration may name the new component sets instead of the aggregate:

Description 

A new boolean plugin option Show hidden records ( settings.showHiddenRecords , checkbox/toggle, default off) was added to the following plugin:

• Program List ( academicprograms_programlist )

When the option is enabled, the frontend program listing includes hidden (disabled) records, independent of the Context API visibility settings. Only the hidden enable column (disabled) is ignored; the deleted, starttime/endtime and fe_group restrictions stay in effect.

The option is core-version-aware and available in both the TYPO3 v12 and v13 flexform data structures of the plugin.

Impact 

Editors can now opt in per plugin instance to display hidden programs in the frontend, for example to preview intentionally hidden records without changing the global preview settings. The option is off by default, so existing plugin instances keep their current behaviour.

Affected Installations 

All installations using the EXT:academic_programs extension starting with version 2.4. No action is required for existing installations.

Description 

To support the new "Show hidden records" plugin option, the program demand pipeline gained a new transport flag:

• \FGTCLB\AcademicPrograms\Domain\Model\Dto\ProgramDemand has a new bool $showHiddenRecords property with setShowHiddenRecords(bool): void and getShowHiddenRecords(): bool accessors (default false ).
• \FGTCLB\AcademicPrograms\Factory\DemandFactory::createDemandObject() now reads $settings['showHiddenRecords'] and sets the flag on the demand object.
• \FGTCLB\AcademicPrograms\Domain\Repository\ProgramRepository::findByDemand() honours the flag: when it is true , the query ignores only the disabled (hidden) enable field via the Extbase query settings.

The public method signatures of DemandFactory::createDemandObject() and ProgramRepository::findByDemand() are unchanged.

Impact 

The change is non-breaking: the new flag defaults to false and no existing method signature changed. Projects that build a ProgramDemand themselves can opt in by calling setShowHiddenRecords(true) .

Affected Installations 

Only installations that extend or replace the ProgramDemand DTO, the DemandFactory or the ProgramRepository need to take the added flag into account. All other installations are unaffected.

Description 

TYPO3 v13 has no allowedRecordTypes TCA option and resolves the tables allowed on a page type through PageDoktypeRegistry . This extension registered its page type 20 there, from Configuration/TCA/Overrides/pages.php.

That is too early. The first call to PageDoktypeRegistry->add() collects every table declaring security.ignorePageTypeRestriction - tt_content, sys_template and backend_layout - from the TcaSchemaFactory and latches the result for the rest of the request. A TCA override file runs while the TCA is still being assembled, before TcaSchemaFactory::load() , so that factory is still empty and none of the three ever reaches the allow list of the default page type.

TYPO3 then refuses content elements on ordinary pages:

Attempt to insert record on pages:1 where table "tt_content" is not allowed

This happens while the TCA cache is cold, which is every import run after a cache flush and the first backend request after one. Once the TCA cache is warm the override files are not executed at all - and then the page type of this extension is not registered either, and silently falls back to the allow list of the default page type instead of allowing every record type.

The registration moved to an event listener on \TYPO3\CMS\Core\Core\Event\BootCompletedEvent , \FGTCLB\AcademicPrograms\EventListener\RegisterAcademicPageDoktype . That event is dispatched one line after TcaSchemaFactory::load() and on every request, warm cache included, which is what both halves of the defect need. The listener does nothing on TYPO3 v14, where the TCA option carries the configuration and PageDoktypeRegistry->add() is deprecated.

Impact 

Content elements can be created on standard pages again while the TCA cache is cold, and the page type 20 of this extension allows every record type while it is warm.

Affected Installations 

All installations of this extension on TYPO3 v13. TYPO3 v14 is not affected, it resolves the allowed tables from TCA. Nothing has to be done beyond the usual cache flush after an update.

Breaking Changes 

Features 

Deprecation 

Important 

Breaking Changes 

Features 

Deprecation 

Important 

Breaking Changes 

Features 

Deprecation 

Important 

Description 

The identifier of the backend layout was changed to unify the naming within all of the academic extensions.

Impact 

The backend layout identifier was changed from AcademicPrograms to AcademicProgram.

Affected Installations 

Installations using the backend layout with the old identifier.

Migration 

Adapt to new naming of the backend layouts.

Description 

As some labels used for the backend were maintained in the locallang files for frontend usage, these labels were organized accordingly.

Impact 

Some labels in the backend might not be translated anymore, if a custom translation was only added to the frontend locallang file.

Affected Installations 

Installations with custom translations only added to the frontend locallang files.

Migration 

Add the custom translations to the correct locallang files.

Description 

Some partials got removed as the templating structure has changed.

Impact 

Those partials include:

• Resources/Private/Layouts/Default.html
• Resources/Private/Pages/AcademicPrograms.html
• Resources/Private/Partials/Categories.html
• Resources/Private/Partials/Program/FilterCategories.html
• Resources/Private/Partials/Program/FilterSorting.html

Affected Installations 

TYPO3 instances with extensions overriding those partials of EXT:academic_programs.

Migration 

Adapt overrides accordingly to the new templating structure.

Description 

The default templating now supports basic bootstrap styling and is semantically optimized to also not lack any major accessibility.

Breaking Changes 

Features 

Deprecation 

Important 

Description 

Category type based handling has been streamlined and centralized within the EXT:category_types extension and the known implementation based on deprecated TYPO3 Enumeration has been replaced with a modern PHP API provided by the EXT:category_type extension.

Extension specific category types are now grouped and are now defined by newly introduced yaml file format, following a concrete convention to look and auto-register these files.

EXT:academic_programs now ships a default set of partner related category types, which can be found in ./Configuration/CategoryTypes.yaml

EXT:academic_programs related category types can be extended by any other TYPO3 extension providing a Configuration/CategoryTypes.yaml file containing category-types using the group-identifier programs.

Configuration/CategoryTypes.yaml format uses following syntax:

types:
    - identifier: <unique_identifier>
      title: '<type-translation-lable-using-full-LLL-syntax'
      group: programs
      icon: '<icon-file-using-EXT-syntax-needs-to-be-an-as-svg>'

Breaking Changes 

Features 

Deprecations 

Important notes