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_academicjobs {
    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.1 version line (see the 2.1 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.

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:

• academicjobs_newjobform
• academicjobs_list
• academicjobs_detail

Affected Installations 

Installations that upgrade to TYPO3 v14 and still hold content elements stored as CType=list + list_type=<plugin>, or that reference list_type for these plugins in their own configuration.

Migration 

Run the provided upgrade wizard academicJobs_pluginContent 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 

Four columns of tx_academicjobs_domain_model_job were declared as TEXT with a default value:

company_name text NOT NULL DEFAULT '',
sector text NOT NULL DEFAULT '',
required_degree text NOT NULL DEFAULT '',
contractual_relationship text NOT NULL DEFAULT '',

MySQL cannot store a default value on a TEXT column. TYPO3 works around that from v13 on, by expressing the default in the DEFAULT ('') syntax MySQL 8.0.13 introduced — so the declarations are harmless on every core version this release supports. On TYPO3 v12 they were not: the columns ended up NOT NULL with no default at all, and every statement that did not name them was rejected with Field 'company_name' doesn't have a default value . Imports and data sets were the reachable case; the frontend form persists a full record, and the backend fills the columns from their default in TCA.

The columns keep their type and lose the default instead:

company_name text DEFAULT NULL,
sector text DEFAULT NULL,
required_degree text DEFAULT NULL,
contractual_relationship text DEFAULT NULL,

The change is carried here as well so that both maintained branches declare the columns identically.

Impact 

Records written without naming a column now store NULL where they previously stored an empty string. Existing rows are not changed, so a column can hold both. The domain model is unaffected — Extbase casts NULL to an empty string for its string properties — but code reading the columns directly should compare with empty() rather than with '' .

Affected Installations 

All installations of this extension. The database schema has to be updated, either in the maintenance area of the install tool or with typo3 extension:setup . The change only relaxes the columns, so no data is converted and nothing can be lost.

Description 

The job avatar image upload of the academicjobs_newjobform plugin was handled by the custom type converter FGTCLB\AcademicBase\Extbase\Property\TypeConverter\FileUploadConverter (EXT:academic_base). It has been replaced with the native Extbase file upload handling introduced in TYPO3 v13.3 (FileUploadConfiguration, see TYPO3 feature forge#103511).

The TypoScript configuration is unchanged. settings.jobAvatarImage.uploadFolder, settings.jobAvatarImage.validation.fileSize.maximum and settings.jobAvatarImage.validation.mimeType.allowedMimeTypes keep their names and meaning and are now mapped onto the core FileSizeValidator and MimeTypeValidator. The form template, the Job domain model and the plugin itself are untouched, so no integration or template change is required.

Impact 

The upload behaves differently in three ways:

• Stored file names change. The custom converter stored the file under the name supplied by the client and replaced an existing file of the same name. The native handling appends a random suffix and renames on conflict instead, so two visitors uploading logo.png no longer overwrite each other in the shared upload folder.
• The mime type is detected from the file content. The custom converter trusted the media type sent by the browser, which can be spoofed. The core MimeTypeValidator inspects the uploaded file itself and additionally cross-checks the file extension. An upload whose real content does not match an allowed mime type is now rejected, even if the browser announced an allowed one. Uploads that only passed because of a faked header stop working — this is intended.
• The file is only stored once the whole form validates. Previously the file was imported into FAL while mapping the request, so a job that failed validation afterwards left an unreferenced file behind in the upload folder. The file is now imported after successful validation, which avoids those orphaned files but requires the visitor to select the file again when the form is redisplayed with validation errors.

An empty allowedMimeTypes setting continues to mean "no mime type restriction".

Affected Installations 

Installations using the job creation form (academicjobs_newjobform) with image uploads. Installations that rely on the uploaded file keeping its original name — for example when referencing those files by a fixed path outside of FAL — need to review that assumption.

Migration 

No configuration change is required. Files uploaded before this change keep their existing names and references.

Description 

TYPO3 v14 rewrote the header partial of EXT:fluid_styled_content. Where v13 Header/All.html reads {data.header}, the v14 Header/All.fluid.html renders header and subheader with {record -> f:render.text(...)}, and that ViewHelper requires a record object.

Content elements based on lib.contentElement receive that record from the record-transformation data processor, but an Extbase plugin view assigns only the data array. Templates of this extension render the shared header partial, so on TYPO3 v14 they aborted with

The record argument must be an instance of ... Given: null

The plugin controllers now assign an additional record view variable, built from the tt_content row of the current content element. TYPO3 v13 ignores it, its header partial keeps reading data, so one implementation serves both core versions.

Impact 

The affected plugins render again on TYPO3 v14. Nothing was removed or renamed, so no configuration or template override needs to be adapted.

Custom templates and template overrides may use the new {record} variable, for example with <f:render.text record="{record}" field="header" />.

Affected Installations 

Installations running the plugins of this extension on TYPO3 v14. TYPO3 v13 installations are unaffected.

Migration 

None required.

Breaking Changes 

Features 

Deprecations 

Important notes 

Also available 

Breaking Changes 

Features 

Deprecation 

Important 

Description 

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

• Jobs List ( academicjobs_list )

When the option is enabled, the frontend job 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 jobs in the frontend, for example to preview upcoming or 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_jobs extension starting with version 2.4. No action is required for existing installations.

Description 

To support the new "Show hidden records" plugin option, the \FGTCLB\AcademicJobs\Domain\Repository\JobRepository gained an extended and a new method:

• findByJobType(int $jobType, bool $includeHidden = false): QueryResultInterface — the new optional $includeHidden parameter was appended.
• findAllJobs(bool $includeHidden = false): QueryResultInterface — new method used on the no-filter listing path in place of the inherited findAll() , so the option can be honoured there as well.

When $includeHidden is true , the query ignores only the disabled (hidden) enable field via the Extbase query settings.

Impact 

The change is non-breaking: the new parameter has a default value and the additional method does not alter existing signatures. Projects that extend or replace JobRepository should adopt the same signatures when overriding these methods.

Affected Installations 

Only installations that extend or override \FGTCLB\AcademicJobs\Domain\Repository\JobRepository need to take the extended signatures into account. All other installations are unaffected.

Breaking Changes 

Features 

Deprecation 

Important 

Breaking Changes 

Features 

Deprecation 

Important 

Breaking Changes 

Features 

Deprecation 

Important 

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:

• academicjobs_newjobform
• academicjobs_list
• academicjobs_detail

Affected Installations 

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

Migration 

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

Description 

Custom ImageUploadConverter implementation is removed in favour of the shared EXT:academic_base/Classes/Extbase/Property/TypeConverter/FileUploadConterter. The dropped implementation is considerable an internal implementation, but was never flagged internal and is therefore mentioned as breaking and added to the semver breaking exemption.

Impact 

The change relates usages of the ImageUploadConverter implementation.

Affected Installations 

All installations using the ImageUploadConverter.

Migration 

Use the shared \FGTCLB\AcademicBase\Extbase\Property\TypeConverter\FileUploadConverter provided by EXT:academic_base.

Description 

As the relation between database tables tx_academicjobs_domain_model_job and tx_academicjobs_domain_model_contact is 1:1 and there is no reuse of contact records, it does not make sense to have a separate table and record for these contacts. Therefore the relation was resolved and an upgrade wizard handles the migration to the new fields in the tx_academicjobs_domain_model_job .

Impact 

The change relates all records of type tx_academicjobs_domain_model_contact .

Affected Installations 

All installations using the database table tx_academicjobs_domain_model_contact .

Migration 

A TYPO3 UpgradeWizard academicJobs_contactRelation is provided to migrate contact records from relation to fields directly in the job record.

Description 

Following provided itemsProcFunc handlers now dispatches the new PSR-14 FGTCLBAcademicBaseEventModifyTcaSelectFieldItemsEvent:

• \FGTCLB\AcademicJobs\Backend\FormEngine\EmploymentTypeItems
• \FGTCLB\AcademicJobs\Backend\FormEngine\TypeItems

Impact 

This allows projects to modify the available select items for the backend (FormEngine) and also for the frontend using a PSR-14 event listener:

<?php

declare(strict_types=1);

namespace MyVendor\MyExt\EventListener;

use FGTCLB\AcademicBase\Event\ModifyTcaSelectFieldItemsEvent;
use FGTCLB\AcademicJobs\Domain\Model\JobType;

final class ModifyJobTypeItemsListener
{
    public function __invoke(ModifyTcaSelectFieldItemsEvent $event): void
    {
        if ($event->getFieldName() === 'type') {
            $items = $event->getItems();
            $items[] = [
                'Custom Type',
                JobType::CUSTOM_TYPE,
            ];
            $event->setItems($items);
        }
    }
}

Description 

JobController::newAction() dispatches now the newly introduced PSR-14 event FGTCLBAcademicJobsEventModifyJobControllerNewActionViewEvent providing following methods:

• function getPluginControllerActionContext(): PluginControllerActionAcontext to extbase controller action plugin context data, which can be used to make decisions using the event.
• function getView(): FluidViewInterface|CoreViewInterface to retrieve the view instance, which can be used to assign additional data, but disallowing to replace the instance.

Impact 

Implementing a event listener for this event allows attaching additional variables to the view for the JobController::newAction(), for example to provide additional select field options in case fields are changed, from text to a select field for example and avoid the need to implement a custom ViewHelper to retrieve the "select options" within the modified views.

<?php

declare(strict_types=1);

namespace MyVendor\MyExt\EventListener;

use FGTCLB\AcademicJobs\Event\ModifyJobControllerNewActionViewEvent;
use TYPO3\CMS\Fluid\View\FluidViewInterface;

final class ModifyJobControllerNewActionViewListener
{
    public function __invoke(ModifyJobControllerNewActionViewEvent $event): void
    {
        $view = $event->getView();
        if ($view instanceof FluidViewInterface) {
            // Assign additional variable to the view
            $view->assign('myCustomVariable', 'My Custom Value');
        }
    }
}

Breaking Changes 

Features 

Deprecation 

Important 

Breaking Changes 

Features 

Deprecations 

Important notes