Change the templates using TypoScript constants 

As any Extbase based extension, you can find the templates in the directory Resources/Private/.

If you want to change a template, copy the desired files to the directory where you store the templates.

We suggest that you use a sitepackage extension. Learn how to Create a sitepackage extension.

# TypoScript constants
plugin.tx_academicprojects {
    view {
        templateRootPath = EXT:mysitepackage/Resources/Private/Extensions/myextension/Templates/
        partialRootPath = EXT:mysitepackage/Resources/Private/Extensions/myextension/Partials/
        layoutRootPath = EXT:mysitepackage/Resources/Private/Extensions/myextension/Layouts/
    }
}

Also available 

Breaking Changes 

Features 

Deprecation 

Important 

Description 

TYPO3 v14 removed the tt_content sub-type feature (the list_type column) and changed ExtensionManagementUtility::addPlugin() accordingly. The academic plugins have been registered as first-class content elements (CType) since the 2.0 version line (see the 2.0 breaking note about migrating from list_type to CType); for TYPO3 v14 support the internal registration was adapted to the new addPlugin() signature and the vestigial list_type handling was dropped.

In addition the "New Content Element" wizard TSconfig still created the plugins as CType=list with a list_type, contradicting the CType registration; it now creates them with the dedicated CType directly.

Impact 

On TYPO3 v14 the tt_content.list_type column no longer exists. Any content records still stored as CType=list with a list_type of one of the plugins below will no longer resolve, and custom TypoScript, TSconfig, page TSconfig or SQL that references list_type for these plugins stops working.

The change relates to the following plugins:

• academicprojects_projectlist
• academicprojects_projectlistsingle

Affected Installations 

Installations that upgrade to TYPO3 v14 and still hold content elements stored as CType=list + list_type=<plugin> (including elements created through the previous "New Content Element" wizard), or that reference list_type for these plugins in their own configuration.

Migration 

Run the provided upgrade wizard academicProjects_pluginUpgradeWizard before upgrading to TYPO3 v14 (it requires the list_type column, which v14 removes) to migrate the tt_content records to the dedicated CType values. Update any custom configuration referencing list_type to match on CType instead.

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 

The upgrade wizard academicProjects_flexFormUpgradeWizard (FGTCLB\AcademicProjects\Upgrades\FlexFormUpgradeWizard) never migrated a single content element. It built the WHERE constraint of its UPDATE statement on the query builder of the enclosing SELECT:

$updateQueryBuilder->update('tt_content')
    ->set('pi_flexform', $this->array2xml($flexFormData))
    ->where(
        $queryBuilder->expr()->in(                                   // select builder
            'uid',
            $queryBuilder->createNamedParameter($record['uid'], …)   // select builder
        )
    )
    ->executeStatement();

A named parameter is bound to the query builder that created it, so the statement carried a placeholder whose value was never bound to it — while set() had created a placeholder of its own on the update builder, holding the new FlexForm XML. The first record therefore ran

UPDATE tt_content SET pi_flexform = :dcValue1 WHERE uid IN (:dcValue1)

comparing the XML against uid, and every following record referred to a placeholder that did not exist on the update builder at all.

The constraint is now built on the builder that executes it, with eq() since the value is always a single uid:

->where(
    $updateQueryBuilder->expr()->eq(
        'uid',
        $updateQueryBuilder->createNamedParameter($record['uid'], Connection::PARAM_INT)
    )
)

Impact 

The wizard now performs the FlexForm migration it announces: settings.hideCompletedProjects becomes settings.activeState (value 1 maps to active, anything else to all), settings.filter.options becomes settings.hideFilter and settings.sorting.options becomes settings.hideSorting, each keeping its value.

Previously the outcome depended on the database:

• MySQL, MariaDB and SQLite reported success and changed nothing.
• PostgreSQL aborted with a Doctrine\DBAL\Exception\DriverException, invalid input syntax for integer.

Affected Installations 

Installations that ran the upgrade wizard of a previous version. The plugin FlexForm of academicprojects_projectlist and academicprojects_projectlistsingle content elements still carries the old setting names, and the plugins fall back to their default behaviour for those settings.

Migration 

Run the upgrade wizard again. An installation that already executed it has it recorded as done, so it has to be marked undone first — in the Install Tool under Upgrade > Upgrade Wizard, or on the command line:

vendor/bin/typo3 upgrade:mark:undone academicProjects_flexFormUpgradeWizard
vendor/bin/typo3 upgrade:run academicProjects_flexFormUpgradeWizard

Running it again is safe: the wizard only rewrites a FlexForm that still contains one of the old setting names and leaves every other record untouched.

Description 

FGTCLB\AcademicProjects\ViewHelpers\Format\ReplaceViewHelper documents and implements array support for three of its arguments, but registered all three as string:

$this->registerArgument('content', 'string', 'Content in which to perform replacement. Array supported.');
$this->registerArgument('substring', 'string', 'Substring to replace. Array supported.', true);
$this->registerArgument('replacement', 'string', 'Replacement to insert. Array supported.', false, '');

TYPO3 v14 rejects that. Fluid 5 validates a registered argument type with StrictArgumentProcessor, where Fluid 4 used LenientArgumentProcessor and let anything through:

InvalidArgumentValueException (1256475113): The argument "substring" was
registered with type "string", but is of type "array" in view helper
"FGTCLB\AcademicProjects\ViewHelpers\Format\ReplaceViewHelper".

The three arguments are registered as mixed now, which is the type the view helper always behaved as: it branches on is_scalar() and casts to (array) otherwise, before handing the values to str_replace() or str_ireplace().

Impact 

A template passing a list to content, substring or replacement works on TYPO3 v14 again. Nothing changes for a template passing strings.

caseSensitive and returnCount keep their boolean type - they rely on the coercion StrictArgumentProcessor performs for it.

A string|array union was tried first and is not equivalent. Fluid 5 matches its scalar coercion on the whole registered type string, so a union falls through uncoerced and is then validated against each member. An integer is neither a string nor an array, and the previous string type used to cast it - so the union would have exchanged one rejected value type for another. With mixed the view helper performs that cast itself, as it always did.

Affected Installations 

Installations on TYPO3 v14 whose templates pass an array or a non-string scalar to this view helper. It is used by no template shipped here.

References 

• Deprecation: #104789 - renderStatic() for Fluid ViewHelpers - the migration that brought the tests uncovering this.

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 

FGTCLB\AcademicProjects\ViewHelpers\Format\ReplaceViewHelper counted its replacements and returned the count instead of the replaced content when a returnCount argument was set:

if ($this->arguments['returnCount'] ?? false) {
    return $count;
}

That argument was never registered, and Fluid rejects an argument a view helper does not declare while it parses the template - so no template could reach the branch:

Undeclared arguments passed to ViewHelper
FGTCLB\AcademicProjects\ViewHelpers\Format\ReplaceViewHelper: returnCount.
Valid arguments are: content, substring, replacement, caseSensitive

returnCount is a registered boolean argument now, defaulting to false:

<ap:format.replace
    content="A research project of the research group"
    substring="research"
    replacement="teaching"
    returnCount="true"
/>

renders 2.

Impact 

Nothing changes for a template that does not pass the argument - the default returns the replaced content, as before. A template that passed returnCount used to raise the parse error above and renders the count now.

The count is the one str_replace() and str_ireplace() report, so it counts occurrences rather than distinct substrings, and it is 0 for a substring that does not occur.

References 

• str_replace - the $count parameter this returns.

Description 

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

• Projects ( academicprojects_projectlist )
• Projects (selected) ( academicprojects_projectlistsingle )

Both plugins share the single Configuration/FlexForms/ProjectSettings.xml data structure.

When the option is enabled, the frontend project 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.

Impact 

Editors can now opt in per plugin instance to display hidden projects 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_projects extension starting with version 2.4. No action is required for existing installations.

Description 

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

• \FGTCLB\AcademicProjects\Domain\Model\Dto\ProjectDemand has a new bool $showHiddenRecords property with setShowHiddenRecords(bool): void and getShowHiddenRecords(): bool accessors (default false ).
• \FGTCLB\AcademicProjects\Factory\DemandFactory::createDemandObject() now reads $settings['showHiddenRecords'] and sets the flag on the demand object.
• \FGTCLB\AcademicProjects\Domain\Repository\ProjectRepository::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 ProjectRepository::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 ProjectDemand themselves can opt in by calling setShowHiddenRecords(true) .

Affected Installations 

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

Breaking Changes 

Features 

Deprecation 

Important 

Breaking Changes 

Features 

Deprecation 

Important 

Breaking Changes 

Features 

Deprecation 

Important 

Description 

Some partials got removed as the templating structure has changed.

Impact 

Those partials include:

• Resources/Private/Layouts/Default.html
• Resources/Private/Partials/Categories.html
• Resources/Private/Partials/Project/Items.html
• Resources/Private/Partials/Project/SingleItem.html

Affected Installations 

EXT:academic_partners installations overriding those partials.

Migration 

Adapt overrides accordingly to the new templating structure.

Description 

To unify the academic extensions the usage of locallang_db files was removed and the labels were moved to the locallang_be files.

Impact 

TYPO3 instances with extensions providing translation overrides or using the locallang_db keys with the full syntax directly no longer replaces or provide them or leading to untranslated key display.

Affected installations 

TYPO3 instances with extensions providing translation overrides or using the locallang_db keys with the full syntax directly.

Migration 

Use the keys from locallang_be files.

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 

FlexForm options of following plugins has changed:

• academicprojects_projectlist
• academicprojects_projectlistsingle

Changed options:

• settings.hideCompletedProjects => settings.activeState
• settings.filter.options => settings.hideFilter
• settings.sorting.options => settings.hideSorting

In case of settings.activeState that also includes supported values for the field, which also matches possible values of newly added PHP Enum \FGTCLB\AcademicProjects\Domain\Model\Dto\ActiveState :

Impact 

Plugin usage with custom set old options uses fallback values of new options and will behave not in the expected way until options are migrated using the provided wizard.

Further, plugin output may lead to unexpected output not adoption for changed option names in case fluid templates are overridden, either in a project site package extension or another extension.

Affected installations 

All TYPO3 instances upgrade from 1.x to 2.x of this extension and having at least one of the mentioned plugins used as content object, either as content element or direct rendering in TypoScript.

Also extensions overriding fluid templates of EXT:academics_projects.

Migration 

An TYPO3 UpgradeWizard academicProjects_flexFormUpgradeWizard is provided to migrate old plugin FlexForm options and values to the new settings and values, in case of activeState also transforming the value based on mapping mentioned in the table above.

Furthermore, overridden fluid template in projects needs to adopt for changed options listed above in the description.

Description 

TYPO3 v13 deprecated the tt_content sub-type feature, only used for CType=list sub-typing also known as list_type and mostly used based on old times for extbase based plugins. It has been possible since the very beginning to register Extbase Plugins directly as CType instead of CType=list sub-type, which has now done.

Technically this is a breaking change, and instances upgrading from 1.x version of the plugin needs to update corresponding tt_content records in the database and eventually adopt addition, adjustments or overrides requiring to use the correct CType.

Impact 

The change relates to following plugins:

• academicprojects_projectlist
• academicprojects_projectlistsingle

Affected Installations 

All installations using the above listed plugins prior V2.0.

Migration 

A TYPO3 UpgradeWizard academicProjects_pluginUpgradeWizard is provided to migrate plugins from CType=list to dedicated CTypes matching the new registration.

Description 

Following class methods has been removed:

• ProfileDemand::getHideCompletedProjects()
• ProfileDemand::setHideCompletedProjects()

Impact 

Using above mentioned removed ProfileDemand methods to call related methods in the ProfileRepository directly leads to FATAL PHP ERROR.

Affected installations 

TYPO3 instances using removed ProfileDemand methods.

Migration 

The removed method should be replaced using the new methods:

• ProfileDemand::setActiveState(string $activeState): void
• ProfileDemand::getActiveState(): string

instead, working slightly different now.

\FGTCLB\AcademicProjects\Domain\Model\Dto\ActiveState ENUM provided possible values for the active state but cannot be passed directly.

$demand = new ProfileDemand();
$demand->setHideCompletedProjects(true);
$demand->setHideCompletedProjects(false);

$demand = new ProfileDemand();
// setHideCompletedProjects(true)
$demand->setActiveState(ActiveState::ACTIVE);
// setHideCompletedProjects(false)
$demand->setActiveState(ActiveState::ALL);

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_projects now ships a default set of partner related category types, which can be found in ./Configuration/CategoryTypes.yaml

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

Configuration/CategoryTypes.yaml format uses following syntax:

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

Breaking Changes 

Features 

Deprecations 

Important notes