TYPO3 v15 dev-main snapshot ()

This commit is contained in:
2026-08-10 22:31:09 +02:00
commit af8cc155b5
6818 changed files with 642608 additions and 0 deletions
@@ -0,0 +1,62 @@
.. include:: /Includes.rst.txt
.. _breaking-100224-1688541732:
=======================================================
Breaking: #100224 - MfaViewType migrated to backed enum
=======================================================
See :issue:`100224`
Description
===========
The class :php:`\TYPO3\CMS\Core\Authentication\Mfa\MfaViewType` has been
migrated to a native PHP backed enum.
Impact
======
Since :php:`MfaViewType` is no longer a class, the existing class constants
are no longer available, but are enum instances instead.
In addition, it's not possible to instantiate the class anymore or call
the :php:`equals()` method.
The :php:`\TYPO3\CMS\Core\Authentication\Mfa\MfaProviderInterface`, which
all MFA providers need to implement, does now require the third argument
:php:`$type` of the :php:`handleRequest()` method to be a :php:`MfaViewType`
instead of a :php:`string`.
Affected installations
======================
All installations directly using the class constants, instantiating the
class or calling the :php:`equals()` method.
All extensions with custom MFA providers, which therefore implement the
:php:`handleRequest()` method.
Migration
=========
To access the string representation of a :php:`MfaViewType`, use the
corresponding :php:`value` property, e.g.
:php:`\TYPO3\CMS\Core\Authentication\Mfa\MfaViewType::SETUP->value` or on a
variable, use :php:`$type->value`.
Replace class instantiation by :php:`\TYPO3\CMS\Core\Authentication\Mfa\MfaViewType::tryFrom('setup')`.
Adjust your MFA providers :php:`handleRequest()` method to match the interface:
.. code-block:: php
public function handleRequest(
ServerRequestInterface $request,
MfaProviderPropertyManager $propertyManager,
MfaViewType $type
): ResponseInterface;
.. index:: Backend, PHP-API, NotScanned, ext:core
@@ -0,0 +1,71 @@
.. include:: /Includes.rst.txt
.. _breaking-JSConfirmation-1687503100:
======================================================
Breaking: #100229 - Convert JSConfirmation to a BitSet
======================================================
See :issue:`100229`
Description
===========
The class :php:`\TYPO3\CMS\Core\Type\Bitmask\JSConfirmation` is replaced by
:php:`\TYPO3\CMS\Core\Authentication\JsConfirmation`. The new class is
extending the :php:`\TYPO3\CMS\Core\Type\BitSet` class instead of
:php:`\TYPO3\CMS\Core\TypeEnumeration\Enumeration`.
Impact
======
Since :php:`JSConfirmation` is now extending the class :php:`\TYPO3\CMS\Core\Type\BitSet`
it's no longer possible to call the following public methods:
- :php:`matches()`
- :php:`setValue()`
- :php:`isValid()`
The only static method left is:
:php:`compare()`
Affected installations
======================
Custom TYPO3 extensions calling public methods:
- :php:`matches()`
- :php:`setValue()`
- :php:`isValid()`
Custom TYPO3 extensions calling static methods in
:php:`\TYPO3\CMS\Core\Type\Bitmask\JSConfirmation`
except for the method :php:`\TYPO3\CMS\Core\Type\Bitmask\JSConfirmation::compare()`.
Custom TYPO3 extensions calling
:php:`\TYPO3\CMS\Core\Authentication\BackendUserAuthentication->jsConfirmation()`,
if first argument passed is not an :php:`int`.
Migration
=========
Replace existing usages of :php:`\TYPO3\CMS\Core\Type\Bitmask\JSConfirmation`
with :php:`\TYPO3\CMS\Core\Authentication\JsConfirmation`.
There is no migration for the methods:
- :php:`matches()`
- :php:`setValue()`
- :php:`isValid()`
Remove existing calls to static methods
:php:`\TYPO3\CMS\Core\Type\Bitmask\JSConfirmation::method()`
and where :php:`JSConfirmation::compare()` is used, replace the namespace from
:php:`\TYPO3\CMS\Core\Type\Bitmask\JSConfirmation` to
:php:`\TYPO3\CMS\Core\Authentication\JsConfirmation`.
Ensure an int value is passed to:
- :php:`\TYPO3\CMS\Core\Authentication\BackendUserAuthentication->jsConfirmation()`
.. index:: Backend, NotScanned, ext:backend, ext:core, ext:filelist
@@ -0,0 +1,516 @@
.. include:: /Includes.rst.txt
.. _breaking-100963-1686129084:
====================================================
Breaking: #100963 - Deprecated functionality removed
====================================================
See :issue:`100963`
Description
===========
The following PHP classes that have previously been marked as deprecated with v12 have been removed:
- :php:`\TYPO3\CMS\Backend\Configuration\TypoScript\ConditionMatching\ConditionMatcher`
- :php:`\TYPO3\CMS\Backend\EventListener\SilentSiteLanguageFlagMigration`
- :php:`\TYPO3\CMS\Backend\Template\Components\Buttons\Action\HelpButton`
- :php:`\TYPO3\CMS\Backend\Tree\View\BrowseTreeView`
- :php:`\TYPO3\CMS\Backend\Tree\View\ElementBrowserPageTreeView`
- :php:`\TYPO3\CMS\Core\Configuration\Loader\PageTsConfigLoader`
- :php:`\TYPO3\CMS\Core\Configuration\PageTsConfig`
- :php:`\TYPO3\CMS\Core\Configuration\Parser\PageTsConfigParser`
- :php:`\TYPO3\CMS\Core\Configuration\TypoScript\ConditionMatching\AbstractConditionMatcher`
- :php:`\TYPO3\CMS\Core\Configuration\TypoScript\Exception\InvalidTypoScriptConditionException`
- :php:`\TYPO3\CMS\Core\Controller\RequireJsController`
- :php:`\TYPO3\CMS\Core\Database\Query\Restriction\BackendWorkspaceRestriction`
- :php:`\TYPO3\CMS\Core\Database\Query\Restriction\FrontendWorkspaceRestriction`
- :php:`\TYPO3\CMS\Core\Exception\MissingTsfeException`
- :php:`\TYPO3\CMS\Core\ExpressionLanguage\DeprecatingRequestWrapper`
- :php:`\TYPO3\CMS\Core\Resource\Service\MagicImageService`
- :php:`\TYPO3\CMS\Core\Resource\Service\UserFileInlineLabelService`
- :php:`\TYPO3\CMS\Core\Resource\Service\UserFileMountService`
- :php:`\TYPO3\CMS\Core\TypoScript\Parser\TypoScriptParser`
- :php:`\TYPO3\CMS\Core\TypoScript\TemplateService`
- :php:`\TYPO3\CMS\Core\Utility\ResourceUtility`
- :php:`\TYPO3\CMS\Dashboard\Views\Factory`
- :php:`\TYPO3\CMS\Fluid\ViewHelpers\Be\Buttons\CshViewHelper`
- :php:`\TYPO3\CMS\Fluid\ViewHelpers\Be\Labels\CshViewHelper`
- :php:`\TYPO3\CMS\Frontend\Configuration\TypoScript\ConditionMatching\ConditionMatcher`
- :php:`\TYPO3\CMS\Frontend\Plugin\AbstractPlugin`
The following PHP classes have been declared :php:`final`:
- :php:`\TYPO3\CMS\Core\Database\Driver\PDOMySql\Driver`
- :php:`\TYPO3\CMS\Core\Database\Driver\PDOPgSql\Driver`
- :php:`\TYPO3\CMS\Core\Database\Driver\PDOSqlite\Driver`
The following PHP interfaces that have previously been marked as deprecated with v12 have been removed:
- :php:`\TYPO3\CMS\Backend\Form\Element\InlineElementHookInterface`
- :php:`\TYPO3\CMS\Backend\RecordList\RecordListGetTableHookInterface`
- :php:`\TYPO3\CMS\Backend\Wizard\NewContentElementWizardHookInterface`
- :php:`\TYPO3\CMS\Core\Configuration\TypoScript\ConditionMatching\ConditionMatcherInterface`
- :php:`\TYPO3\CMS\Core\Domain\Repository\PageRepositoryGetPageOverlayHookInterface`
- :php:`\TYPO3\CMS\Core\Domain\Repository\PageRepositoryGetRecordOverlayHookInterface`
- :php:`\TYPO3\CMS\Dashboard\Widgets\RequireJsModuleInterface`
- :php:`\TYPO3\CMS\Frontend\ContentObject\Menu\AbstractMenuFilterPagesHookInterface`
- :php:`\TYPO3\CMS\Frontend\ContentObject\TypolinkModifyLinkConfigForPageLinksHookInterface`
- :php:`\TYPO3\CMS\Frontend\Http\UrlProcessorInterface`
The following PHP interfaces changed:
- :php:`\TYPO3\CMS\Adminpanel\ModuleApi\ShortInfoProviderInterface` method :php:`setModuleData()` added
- :php:`\TYPO3\CMS\Backend\Form\NodeInterface` method :php:`setData()` added
- :php:`\TYPO3\CMS\Backend\Form\NodeInterface` method :php:`render()` must return :php:`array`
- :php:`\TYPO3\CMS\Backend\Form\NodeResolverInterface` method :php:`setData()` added
- :php:`\TYPO3\CMS\Backend\Form\NodeResolverInterface` method :php:`resolve()` must return :php:`?string`
- :php:`\TYPO3\CMS\Extbase\Configuration\ConfigurationManagerInterface` method `getContentObject()` removed
- :php:`\TYPO3\CMS\Extbase\Configuration\ConfigurationManagerInterface` method `isFeatureEnabled()` removed
- :php:`\TYPO3\CMS\Extbase\Configuration\ConfigurationManagerInterface` method `setContentObject()` removed
- :php:`\TYPO3\CMS\Extbase\Configuration\ConfigurationManagerInterface` method `setRequest()` added
The following PHP class aliases that have previously been marked as deprecated with v12 have been removed:
- :php:`\TYPO3\CMS\Backend\ElementBrowser\FileBrowser`
- :php:`\TYPO3\CMS\Backend\ElementBrowser\FolderBrowser`
- :php:`\TYPO3\CMS\Backend\Form\Element\InputColorPickerElement`
- :php:`\TYPO3\CMS\Backend\Form\Element\InputDateTimeElement`
- :php:`\TYPO3\CMS\Backend\Form\Element\InputLinkElement`
- :php:`\TYPO3\CMS\Backend\Provider\PageTsBackendLayoutDataProvider`
- :php:`\TYPO3\CMS\Frontend\Service\TypoLinkCodecService`
- :php:`\TYPO3\CMS\Frontend\Typolink\LinkResultFactory`
- :php:`\TYPO3\CMS\Recordlist\Browser\AbstractElementBrowser`
- :php:`\TYPO3\CMS\Recordlist\Browser\DatabaseBrowser`
- :php:`\TYPO3\CMS\Recordlist\Browser\ElementBrowserInterface`
- :php:`\TYPO3\CMS\Recordlist\Browser\ElementBrowserRegistry`
- :php:`\TYPO3\CMS\Recordlist\Browser\FileBrowser`
- :php:`\TYPO3\CMS\Recordlist\Browser\FolderBrowser`
- :php:`\TYPO3\CMS\Recordlist\Controller\AbstractLinkBrowserController`
- :php:`\TYPO3\CMS\Recordlist\Controller\AccessDeniedException`
- :php:`\TYPO3\CMS\Recordlist\Controller\ClearPageCacheController`
- :php:`\TYPO3\CMS\Recordlist\Controller\ElementBrowserController`
- :php:`\TYPO3\CMS\Recordlist\Controller\RecordDownloadController`
- :php:`\TYPO3\CMS\Recordlist\Controller\RecordListController`
- :php:`\TYPO3\CMS\Recordlist\Event\ModifyRecordListHeaderColumnsEvent`
- :php:`\TYPO3\CMS\Recordlist\Event\ModifyRecordListRecordActionsEvent`
- :php:`\TYPO3\CMS\Recordlist\Event\ModifyRecordListTableActionsEvent`
- :php:`\TYPO3\CMS\Recordlist\Event\RenderAdditionalContentToRecordListEvent`
- :php:`\TYPO3\CMS\Recordlist\LinkHandler\AbstractLinkHandler`
- :php:`\TYPO3\CMS\Recordlist\LinkHandler\FileLinkHandler`
- :php:`\TYPO3\CMS\Recordlist\LinkHandler\FolderLinkHandler`
- :php:`\TYPO3\CMS\Recordlist\LinkHandler\LinkHandlerInterface`
- :php:`\TYPO3\CMS\Recordlist\LinkHandler\MailLinkHandler`
- :php:`\TYPO3\CMS\Recordlist\LinkHandler\PageLinkHandler`
- :php:`\TYPO3\CMS\Recordlist\LinkHandler\RecordLinkHandler`
- :php:`\TYPO3\CMS\Recordlist\LinkHandler\TelephoneLinkHandler`
- :php:`\TYPO3\CMS\Recordlist\LinkHandler\UrlLinkHandler`
- :php:`\TYPO3\CMS\Recordlist\RecordList\DatabaseRecordList`
- :php:`\TYPO3\CMS\Recordlist\RecordList\DownloadRecordList`
- :php:`\TYPO3\CMS\Recordlist\Tree\View\LinkParameterProviderInterface`
- :php:`\TYPO3\CMS\Recordlist\View\FolderUtilityRenderer`
- :php:`\TYPO3\CMS\Recordlist\View\RecordSearchBoxComponent`
The following PHP class methods that have previously been marked as deprecated with v12 have been removed:
- :php:`\TYPO3\CMS\Backend\Template\Components\ButtonBar->makeHelpButton()`
- :php:`\TYPO3\CMS\Backend\Template\ModuleTemplate->getBodyTag()`
- :php:`\TYPO3\CMS\Backend\Template\ModuleTemplate->getDynamicTabMenu()`
- :php:`\TYPO3\CMS\Backend\Template\ModuleTemplate->getView()`
- :php:`\TYPO3\CMS\Backend\Template\ModuleTemplate->header()`
- :php:`\TYPO3\CMS\Backend\Template\ModuleTemplate->isUiBlock()`
- :php:`\TYPO3\CMS\Backend\Template\ModuleTemplate->registerModuleMenu()`
- :php:`\TYPO3\CMS\Backend\Template\ModuleTemplate->renderContent()`
- :php:`\TYPO3\CMS\Backend\Template\ModuleTemplate->setContent()`
- :php:`\TYPO3\CMS\Backend\Tree\View\AbstractTreeView->addTagAttributes()`
- :php:`\TYPO3\CMS\Backend\Tree\View\AbstractTreeView->determineScriptUrl()`
- :php:`\TYPO3\CMS\Backend\Tree\View\AbstractTreeView->getRootIcon()`
- :php:`\TYPO3\CMS\Backend\Tree\View\AbstractTreeView->getRootRecord()`
- :php:`\TYPO3\CMS\Backend\Tree\View\AbstractTreeView->getThisScript()`
- :php:`\TYPO3\CMS\Core\Authentication\BackendUserAuthentication->modAccess()`
- :php:`\TYPO3\CMS\Core\Configuration\FlexForm\FlexFormTools->removeElementTceFormsRecursive()`
- :php:`\TYPO3\CMS\Core\Database\Driver\PDOMySql\Driver->getName()`
- :php:`\TYPO3\CMS\Core\Database\Driver\PDOPgSql\Driver->getName()`
- :php:`\TYPO3\CMS\Core\Database\Driver\PDOSqlite\Driver->getName()`
- :php:`\TYPO3\CMS\Core\Database\Query\Expression\CompositeExpression->add()`
- :php:`\TYPO3\CMS\Core\Database\Query\Expression\CompositeExpression->addMultiple()`
- :php:`\TYPO3\CMS\Core\Database\Query\Expression\ExpressionBuilder->andX()`
- :php:`\TYPO3\CMS\Core\Database\Query\Expression\ExpressionBuilder->orX()`
- :php:`\TYPO3\CMS\Core\Database\Query\QueryBuilder->execute()`
- :php:`\TYPO3\CMS\Core\Domain\Repository\PageRepository->getExtURL()`
- :php:`\TYPO3\CMS\Core\Environment->getBackendPath()`
- :php:`\TYPO3\CMS\Core\Localization\LanguageService->getLL()`
- :php:`\TYPO3\CMS\Core\Localization\Locales->getIsoMapping()`
- :php:`\TYPO3\CMS\Core\Page\JavaScriptModuleInstruction->shallLoadRequireJs()`
- :php:`\TYPO3\CMS\Core\Page\PageRenderer->loadRequireJs()`
- :php:`\TYPO3\CMS\Core\Page\PageRenderer->loadRequireJsModule()`
- :php:`\TYPO3\CMS\Core\Page\PageRenderer->setRenderXhtml()`
- :php:`\TYPO3\CMS\Core\Page\PageRenderer->getRenderXhtml()`
- :php:`\TYPO3\CMS\Core\Page\PageRenderer->setCharSet()`
- :php:`\TYPO3\CMS\Core\Page\PageRenderer->getCharSet()`
- :php:`\TYPO3\CMS\Core\Page\PageRenderer->setMetaCharsetTag()`
- :php:`\TYPO3\CMS\Core\Page\PageRenderer->getMetaCharsetTag()`
- :php:`\TYPO3\CMS\Core\Page\PageRenderer->setBaseUrl()`
- :php:`\TYPO3\CMS\Core\Page\PageRenderer->getBaseUrl()`
- :php:`\TYPO3\CMS\Core\Page\PageRenderer->enableRemoveLineBreaksFromTemplate()`
- :php:`\TYPO3\CMS\Core\Page\PageRenderer->disableRemoveLineBreaksFromTemplate()`
- :php:`\TYPO3\CMS\Core\Page\PageRenderer->getRemoveLineBreaksFromTemplate()`
- :php:`\TYPO3\CMS\Core\Page\PageRenderer->enableDebugMode()`
- :php:`\TYPO3\CMS\Core\Resource\Filter\FileExtensionFilter->filterInlineChildren()`
- :php:`\TYPO3\CMS\Core\Session\UserSessionManager->createFromGlobalCookieOrAnonymous()`
- :php:`\TYPO3\CMS\Core\Site\Entity\SiteLanguage->getTwoLetterIsoCode()`
- :php:`\TYPO3\CMS\Core\Site\Entity\SiteLanguage->getDirection()`
- :php:`\TYPO3\CMS\Core\Type\DocType->getXhtmlDocType()`
- :php:`\TYPO3\CMS\Dashboard\DashboardInitializationService->getRequireJsModules()`
- :php:`\TYPO3\CMS\Extbase\Configuration\BackendConfigurationManager->getContentObject()`
- :php:`\TYPO3\CMS\Extbase\Configuration\BackendConfigurationManager->setContentObject()`
- :php:`\TYPO3\CMS\Extbase\Configuration\ConfigurationManager->getContentObject()`
- :php:`\TYPO3\CMS\Extbase\Configuration\ConfigurationManager->isFeatureEnabled()`
- :php:`\TYPO3\CMS\Extbase\Configuration\ConfigurationManager->setContentObject()`
- :php:`\TYPO3\CMS\Extbase\Configuration\FrontendConfigurationManager->getContentObject()`
- :php:`\TYPO3\CMS\Extbase\Configuration\FrontendConfigurationManager->setContentObject()`
- :php:`\TYPO3\CMS\Extbase\Mvc\Web\Routing\UriBuilder->getRequest()`
- :php:`\TYPO3\CMS\Extbase\Persistence\Generic\Typo3QuerySettings->setLanguageOverlayMode()`
- :php:`\TYPO3\CMS\Extbase\Persistence\Generic\Typo3QuerySettings->getLanguageOverlayMode()`
- :php:`\TYPO3\CMS\Extbase\Persistence\Generic\Typo3QuerySettings->setLanguageUid()`
- :php:`\TYPO3\CMS\Extbase\Persistence\Generic\Typo3QuerySettings->getLanguageUid()`
- :php:`\TYPO3\CMS\Extbase\Property\AbstractTypeConverter->canConvertFrom()`
- :php:`\TYPO3\CMS\Extbase\Property\AbstractTypeConverter->getPriority()`
- :php:`\TYPO3\CMS\Extbase\Property\AbstractTypeConverter->getSupportedTargetType()`
- :php:`\TYPO3\CMS\Extbase\Property\AbstractTypeConverter->getSupportedSourceTypes()`
- :php:`\TYPO3\CMS\Fluid\View\StandaloneView->getFormat()`
- :php:`\TYPO3\CMS\Fluid\View\StandaloneView->getRequest()`
- :php:`\TYPO3\CMS\Fluid\View\StandaloneView->getTemplatePathAndFilename()`
- :php:`\TYPO3\CMS\FrontendLogin\Event\PasswordChangeEvent->getErrorMessage()`
- :php:`\TYPO3\CMS\FrontendLogin\Event\PasswordChangeEvent->isPropagationStopped()`
- :php:`\TYPO3\CMS\FrontendLogin\Event\PasswordChangeEvent->setAsInvalid()`
- :php:`\TYPO3\CMS\FrontendLogin\Event\PasswordChangeEvent->setHashedPassword()`
- :php:`\TYPO3\CMS\Frontend\Authentication\FrontendUserAuthentication->getUserTSconf()`
- :php:`\TYPO3\CMS\Frontend\Controller\TypoScriptFrontendController->baseUrlWrap()`
- :php:`\TYPO3\CMS\Frontend\Controller\TypoScriptFrontendController->checkEnableFields()`
- :php:`\TYPO3\CMS\Frontend\Controller\TypoScriptFrontendController->doWorkspacePreview()`
- :php:`\TYPO3\CMS\Frontend\Controller\TypoScriptFrontendController->getPagesTSconfig()`
- :php:`\TYPO3\CMS\Frontend\Controller\TypoScriptFrontendController->initUserGroups()`
- :php:`\TYPO3\CMS\Frontend\Controller\TypoScriptFrontendController->isBackendUserLoggedIn()`
- :php:`\TYPO3\CMS\Frontend\Controller\TypoScriptFrontendController->isUserOrGroupSet()`
- :php:`\TYPO3\CMS\Frontend\Controller\TypoScriptFrontendController->whichWorkspace()`
- :php:`\TYPO3\CMS\Frontend\Typolink\LinkFactory->createFromUriString()`
- :php:`\TYPO3\CMS\Frontend\Typolink\LinkFactory->getATagParams()`
- :php:`\TYPO3\CMS\Frontend\Typolink\LinkFactory->getMailTo()`
- :php:`\TYPO3\CMS\Frontend\Typolink\LinkFactory->getQueryArguments()`
- :php:`\TYPO3\CMS\Frontend\Typolink\LinkFactory->getTreeList()`
- :php:`\TYPO3\CMS\Frontend\Typolink\LinkFactory->getTypoLink_URL()`
- :php:`\TYPO3\CMS\Frontend\Typolink\LinkFactory->getTypoLink()`
- :php:`\TYPO3\CMS\Frontend\Typolink\LinkFactory->getUrlToCurrentLocation()`
- :php:`\TYPO3\CMS\Scheduler\Scheduler->addTask()`
- :php:`\TYPO3\CMS\Scheduler\Scheduler->fetchTaskRecord()`
- :php:`\TYPO3\CMS\Scheduler\Scheduler->fetchTaskWithCondition()`
- :php:`\TYPO3\CMS\Scheduler\Scheduler->fetchTask()`
- :php:`\TYPO3\CMS\Scheduler\Scheduler->isValidTaskObject()`
- :php:`\TYPO3\CMS\Scheduler\Scheduler->removeTask()`
- :php:`\TYPO3\CMS\Scheduler\Scheduler->saveTask()`
- :php:`\TYPO3\CMS\Scheduler\Task\AbstractTask->isExecutionRunning()`
- :php:`\TYPO3\CMS\Scheduler\Task\AbstractTask->markExecution()`
- :php:`\TYPO3\CMS\Scheduler\Task\AbstractTask->remove()`
- :php:`\TYPO3\CMS\Scheduler\Task\AbstractTask->unmarkAllExecutions()`
- :php:`\TYPO3\CMS\Scheduler\Task\AbstractTask->unmarkExecution()`
- :php:`\TYPO3\CMS\Setup\Event\AddJavaScriptModulesEvent->addModule()`
- :php:`\TYPO3\CMS\Setup\Event\AddJavaScriptModulesEvent->getModules()`
The following PHP static class methods that have previously been marked as deprecated for v12 have been removed:
- :php:`\TYPO3\CMS\Backend\Utility\BackendUtility::ADMCMD_previewCmds()`
- :php:`\TYPO3\CMS\Backend\Utility\BackendUtility::cshItem()`
- :php:`\TYPO3\CMS\Backend\Utility\BackendUtility::getClickMenuOnIconTagParameters()`
- :php:`\TYPO3\CMS\Backend\Utility\BackendUtility::getDropdownMenu()`
- :php:`\TYPO3\CMS\Backend\Utility\BackendUtility::getFuncCheck()`
- :php:`\TYPO3\CMS\Backend\Utility\BackendUtility::getFuncMenu()`
- :php:`\TYPO3\CMS\Backend\Utility\BackendUtility::getLinkToDataHandlerAction()`
- :php:`\TYPO3\CMS\Backend\Utility\BackendUtility::getPreviewUrl()`
- :php:`\TYPO3\CMS\Backend\Utility\BackendUtility::getRecordToolTip()`
- :php:`\TYPO3\CMS\Backend\Utility\BackendUtility::getThumbnailUrl()`
- :php:`\TYPO3\CMS\Backend\Utility\BackendUtility::getUpdateSignalCode()`
- :php:`\TYPO3\CMS\Backend\Utility\BackendUtility::isModuleSetInTBE_MODULES()`
- :php:`\TYPO3\CMS\Core\FormProtection\FormProtectionFactory::get()`
- :php:`\TYPO3\CMS\Core\FormProtection\FormProtectionFactory::purgeInstances()`
- :php:`\TYPO3\CMS\Core\Page\JavaScriptModuleInstruction::forRequireJS()`
- :php:`\TYPO3\CMS\Core\Type\ContextualFeedbackSeverity::transform()`
- :php:`\TYPO3\CMS\Core\Utility\DebugUtility::debugInPopUpWindow()`
- :php:`\TYPO3\CMS\Core\Utility\DebugUtility::debugRows()`
- :php:`\TYPO3\CMS\Core\Utility\DebugUtility::printArray()`
- :php:`\TYPO3\CMS\Core\Utility\ExtensionManagementUtility::addCoreNavigationComponent()`
- :php:`\TYPO3\CMS\Core\Utility\ExtensionManagementUtility::addLLrefForTCAdescr()`
- :php:`\TYPO3\CMS\Core\Utility\ExtensionManagementUtility::addModule()`
- :php:`\TYPO3\CMS\Core\Utility\ExtensionManagementUtility::addNavigationComponent()`
- :php:`\TYPO3\CMS\Core\Utility\ExtensionManagementUtility::allowTableOnStandardPages()`
- :php:`\TYPO3\CMS\Core\Utility\ExtensionManagementUtility::getFileFieldTCAConfig()`
- :php:`\TYPO3\CMS\Core\Utility\ExtensionManagementUtility::insertModuleFunction()`
- :php:`\TYPO3\CMS\Core\Utility\GeneralUtility::_GET()`
- :php:`\TYPO3\CMS\Core\Utility\GeneralUtility::_GP()`
- :php:`\TYPO3\CMS\Core\Utility\GeneralUtility::_GPmerged()`
- :php:`\TYPO3\CMS\Core\Utility\GeneralUtility::_POST()`
- :php:`\TYPO3\CMS\Core\Utility\GeneralUtility::linkThisScript()`
- :php:`\TYPO3\CMS\Extbase\Utility\ExtensionUtility::registerModule()`
- :php:`\TYPO3\CMS\Extbase\Utility\ExtensionUtility::registerTypeConverter()`
The following methods changed signature according to previous deprecations in v12 at the end of the argument list:
- :php:`\TYPO3\CMS\Backend\Form\FormDataCompiler->compile()` (argument 2 is now required)
- :php:`\TYPO3\CMS\Core\Messaging\AbstractMessage->setSeverity()` (argument 1 is now of type :php:`ContextualFeedbackSeverity`)
- :php:`\TYPO3\CMS\Core\Messaging\FlashMessageQueue->clear()` (argument 1 is now of type :php:`ContextualFeedbackSeverity|null`)
- :php:`\TYPO3\CMS\Core\Messaging\FlashMessageQueue->getAllMessagesAndFlush()` (argument 1 is now of type :php:`ContextualFeedbackSeverity|null`)
- :php:`\TYPO3\CMS\Core\Messaging\FlashMessageQueue->getAllMessages()` (argument 1 is now of type :php:`ContextualFeedbackSeverity|null`)
- :php:`\TYPO3\CMS\Core\Messaging\FlashMessageQueue->removeAllFlashMessagesFromSession()` (argument 1 is now of type :php:`ContextualFeedbackSeverity|null`)
- :php:`\TYPO3\CMS\Core\Messaging\FlashMessages->__construct()` (argument 3 is now of type :php:`ContextualFeedbackSeverity`)
- :php:`\TYPO3\CMS\Core\Page\PageRenderer->setLanguage()` (argument 1 is now of type :php:`Locale`)
- :php:`\TYPO3\CMS\Core\Utility\File\ExtendedFileUtility->addMessageToFlashMessageQueue()` (argument 2 is now of type :php:`ContextualFeedbackSeverity|null`)
- :php:`\TYPO3\CMS\Core\Utility\GeneralUtility::intExplode()` (argument 4 :php:`$limit` has been removed)
- :php:`\TYPO3\CMS\Extbase\Mvc\Controller\ActionController->addFlashMessage()` (argument 2 is now of type :php:`ContextualFeedbackSeverity`)
- :php:`\TYPO3\CMS\Extbase\Utility\LocalizationUtility::translate()` (argument 4 has been removed)
- :php:`\TYPO3\CMS\Frontend\ContentObject\ContentObjectRenderer->start()` (argument 3 :php:`$request` has been removed)
- :php:`\TYPO3\CMS\Reports\Status->__construct()` (argument 4 is now of type :php:`ContextualFeedbackSeverity`)
- :php:`\TYPO3\CMS\Scheduler\AbstractAdditionalFieldProvider->addMessage()` (argument 2 is now of type :php:`ContextualFeedbackSeverity`)
The following public class properties have been dropped:
- :php:`\TYPO3\CMS\Backend\Tree\View\AbstractTreeView->BE_USER`
- :php:`\TYPO3\CMS\Backend\Tree\View\AbstractTreeView->thisScript`
- :php:`\TYPO3\CMS\Core\Localization\LanguageService->debugKey`
- :php:`\TYPO3\CMS\Core\Security\ContentSecurityPolicy\ConsumableNonce->b64`
- :php:`\TYPO3\CMS\Frontend\ContentObject\ContentObjectRenderer->lastTypoLinkLD`
- :php:`\TYPO3\CMS\Frontend\ContentObject\ContentObjectRenderer->lastTypoLinkTarget`
- :php:`\TYPO3\CMS\Frontend\ContentObject\ContentObjectRenderer->lastTypoLinkUrl`
- :php:`\TYPO3\CMS\Frontend\Controller\TypoScriptFrontendController->baseUrl`
- :php:`\TYPO3\CMS\Frontend\Controller\TypoScriptFrontendController->extTarget`
- :php:`\TYPO3\CMS\Frontend\Controller\TypoScriptFrontendController->fileTarget`
- :php:`\TYPO3\CMS\Frontend\Controller\TypoScriptFrontendController->intTarget`
- :php:`\TYPO3\CMS\Frontend\Controller\TypoScriptFrontendController->spamProtectEmailAddresses`
- :php:`\TYPO3\CMS\Frontend\Controller\TypoScriptFrontendController->tmpl`
- :php:`\TYPO3\CMS\Frontend\Controller\TypoScriptFrontendController->xhtmlDoctype`
- :php:`\TYPO3\CMS\Frontend\Controller\TypoScriptFrontendController->xhtmlVersion`
The following class method visibility has been changed to protected:
- :php:`\TYPO3\CMS\Core\Domain\Repository\PageRepository->getRecordOverlay()`
The following class methods are now marked as internal:
- :php:`\TYPO3\CMS\Core\Authentication\AbstractUserAuthentication->isSetSessionCookie()`
- :php:`\TYPO3\CMS\Core\Authentication\AbstractUserAuthentication->isRefreshTimeBasedCookie()`
- :php:`\TYPO3\CMS\Core\Authentication\AbstractUserAuthentication->removeCookie()`
- :php:`\TYPO3\CMS\Core\Authentication\AbstractUserAuthentication->isCookieSet()`
- :php:`\TYPO3\CMS\Core\Authentication\AbstractUserAuthentication->unpack_uc()`
- :php:`\TYPO3\CMS\Core\Authentication\AbstractUserAuthentication->appendCookieToResponse()`
The following class methods now have a native return type and removed the
:php:`#[\ReturnTypeWillChange]` attribute:
- :php:`\TYPO3\CMS\Core\Collection\AbstractRecordCollection->current()`
- :php:`\TYPO3\CMS\Core\Collection\AbstractRecordCollection->key()`
- :php:`\TYPO3\CMS\Core\Log\LogRecord->offsetGet()`
- :php:`\TYPO3\CMS\Core\Messaging\FlashMessageQueue->dequeue()`
- :php:`\TYPO3\CMS\Core\Resource\Collection\AbstractFileCollection->key()`
- :php:`\TYPO3\CMS\Core\Resource\MetaDataAspect->offsetGet()`
- :php:`\TYPO3\CMS\Core\Resource\MetaDataAspect->current()`
- :php:`\TYPO3\CMS\Core\Resource\Search\Result\EmptyFileSearchResult->current()`
- :php:`\TYPO3\CMS\Core\Resource\Search\Result\EmptyFileSearchResult->key()`
- :php:`\TYPO3\CMS\Core\Routing\SiteRouteResult->offsetGet()`
- :php:`\TYPO3\CMS\Extbase\Persistence\Generic\LazyLoadingProxy->current()`
- :php:`\TYPO3\CMS\Extbase\Persistence\Generic\LazyLoadingProxy->key()`
- :php:`\TYPO3\CMS\Extbase\Persistence\Generic\LazyObjectStorage->current()`
- :php:`\TYPO3\CMS\Extbase\Persistence\Generic\LazyObjectStorage->offsetGet()`
- :php:`\TYPO3\CMS\Extbase\Persistence\Generic\QueryResult->offsetGet()`
- :php:`\TYPO3\CMS\Extbase\Persistence\Generic\QueryResult->current()`
- :php:`\TYPO3\CMS\Extbase\Persistence\Generic\QueryResult->key()`
- :php:`\TYPO3\CMS\Extbase\Persistence\ObjectStorage->current()`
- :php:`\TYPO3\CMS\Extbase\Persistence\ObjectStorage->offsetGet()`
- :php:`\TYPO3\CMS\Filelist\Dto\ResourceCollection->current()`
- :php:`\TYPO3\CMS\Filelist\Dto\ResourceCollection->key()`
The following class properties visibility have been changed to protected:
- :php:`\TYPO3\CMS\Core\Domain\Repository\PageRepository->where_hid_del`
- :php:`\TYPO3\CMS\Core\Domain\Repository\PageRepository->where_groupAccess`
- :php:`\TYPO3\CMS\Frontend\Controller\TypoScriptFrontendController->type`
The following class property visibility has been changed to private:
- :php:`\TYPO3\CMS\Core\Type\DocType->getXhtmlVersion`
The following class properties have been marked as internal:
- :php:`\TYPO3\CMS\Core\Authentication\AbstractUserAuthentication->lastLogin_column`
- :php:`\TYPO3\CMS\Core\Authentication\AbstractUserAuthentication->formfield_uname`
- :php:`\TYPO3\CMS\Core\Authentication\AbstractUserAuthentication->formfield_uident`
- :php:`\TYPO3\CMS\Core\Authentication\AbstractUserAuthentication->formfield_status`
- :php:`\TYPO3\CMS\Core\Authentication\AbstractUserAuthentication->loginSessionStarted`
- :php:`\TYPO3\CMS\Core\Authentication\AbstractUserAuthentication->dontSetCookie`
- :php:`\TYPO3\CMS\Core\Authentication\FrontendUserAuthentication->formfield_permanent`
- :php:`\TYPO3\CMS\Core\Authentication\FrontendUserAuthentication->is_permanent`
The following class property has changed/enforced type:
- :php:`\TYPO3\CMS\Core\Page\PageRenderer->endingSlash` (is now string)
The following eID entry point has been removed:
- :php:`requirejs`
The following ViewHelpers have been changed or removed:
- :html:`<f:be.buttons.csh>` removed
- :html:`<f:be.labels.csh>` removed
- :html:`<f:translate>` Argument "alternativeLanguageKeys" has been removed
The following TypoScript options have been dropped or adapted:
- :typoscript:`config.baseURL`
- :typoscript:`config.removePageCss`
- :typoscript:`config.spamProtectEmailAddresses` (only `ascii` value)
- :typoscript:`config.xhtmlDoctype`
- :typoscript:`plugin.[pluginName]._CSS_PAGE_STYLE`
- :typoscript:`[ip()]` condition function must be used in a context with request
- :typoscript:`[loginUser()]` condition function removed
- :typoscript:`[usergroup()]` condition function removed
- :typoscript:`constants` setup top-level-object and :typoscript:`constants` property of :typoscript:`parseFunc`
- :typoscript:`plugin.tx_felogin_login.settings.passwordValidators` has been removed
The following constant has been dropped:
- :php:`TYPO3_mainDir`
The following class constants have been dropped:
- :php:`\TYPO3\CMS\Core\Messaging\AbstractMessage::ERROR`
- :php:`\TYPO3\CMS\Core\Messaging\AbstractMessage::INFO`
- :php:`\TYPO3\CMS\Core\Messaging\AbstractMessage::NOTICE`
- :php:`\TYPO3\CMS\Core\Messaging\AbstractMessage::OK`
- :php:`\TYPO3\CMS\Core\Messaging\AbstractMessage::WARNING`
- :php:`\TYPO3\CMS\Core\Messaging\FlashMessage::ERROR`
- :php:`\TYPO3\CMS\Core\Messaging\FlashMessage::INFO`
- :php:`\TYPO3\CMS\Core\Messaging\FlashMessage::NOTICE`
- :php:`\TYPO3\CMS\Core\Messaging\FlashMessage::OK`
- :php:`\TYPO3\CMS\Core\Messaging\FlashMessage::WARNING`
- :php:`\TYPO3\CMS\Core\Page\JavaScriptModuleInstruction::FLAG_LOAD_REQUIRE_JS`
- :php:`\TYPO3\CMS\Reports\Status::ERROR`
- :php:`\TYPO3\CMS\Reports\Status::INFO`
- :php:`\TYPO3\CMS\Reports\Status::NOTICE`
- :php:`\TYPO3\CMS\Reports\Status::OK`
- :php:`\TYPO3\CMS\Reports\Status::WARNING`
The following global option handling have been dropped and are ignored:
- :php:`$GLOBALS['TYPO3_CONF_VARS']['FE']['defaultUserTSconfig']`
- :php:`$GLOBALS['TYPO3_CONF_VARS']['FE']['versionNumberInFilename']` only accepts a boolean value now
The following global variables have been removed:
- :php:`$GLOBALS['TBE_STYLES']`
- :php:`$GLOBALS['TBE_STYLES']['stylesheet']`
- :php:`$GLOBALS['TBE_STYLES']['stylesheet2']`
- :php:`$GLOBALS['TBE_STYLES']['skins']`
- :php:`$GLOBALS['TBE_STYLES']['admPanel']`
- :php:`$GLOBALS['TCA_DESCR']`
The following hooks have been removed:
- :php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['ext/install']['update']`
- :php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['RequireJS']['postInitializationModules']`
- :php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['t3lib/cache/frontend/class.t3lib_cache_frontend_abstractfrontend.php']['flushByTag']`
- :php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['t3lib/class.t3lib_befunc.php']['viewOnClickClass']`
- :php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['t3lib/class.t3lib_userauth.php']['logoff_post_processing']`
- :php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['t3lib/class.t3lib_userauth.php']['logoff_pre_processing']`
- :php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['t3lib/class.t3lib_userauth.php']['postLoginFailureProcessing']`
- :php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['t3lib/class.t3lib_userauthgroup.php']['backendUserLogin']`
- :php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['t3lib/class.t3lib_userauthgroup.php']['getDefaultUploadFolder']`
- :php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['TYPO3\CMS\Lowlevel\Controller\ConfigurationController']['modifyBlindedConfigurationOptions']`
The following single field configuration has been removed from TCA:
- :php:`MM_insert_fields` (for TCA fields with `MM` configuration)
The following event has been removed:
- :php:`\TYPO3\CMS\Core\Configuration\Event\ModifyLoadedPageTsConfigEvent`
The following fallbacks have been removed:
- Usage of the :file:`ext_icon.*` file locations for extension icons
- Usage of the result property :php:`additionalJavaScriptPost` of the form engine result array
- Using chart.js v3 compatible widgets in ext:dashboard
- Usage of :js:`.t3js-contextmenutrigger` to trigger and configure context menus
- Usage of the jsonArray property :php:`scriptCall` for AjaxController's
- Binding the selected menu items to callback actions in context menus
- Checking for :php:`\TYPO3\CMS\Core\Site\SiteLanguageAwareTrait` is removed in :php:`\TYPO3\CMS\Core\Routing\Aspect\AspectFactory`
- :html:`f:format.html` ViewHelper no longer works in BE context
- Usage of :php:`JScode` containing inline JavaScript for handing custom signals
- Usage property :php:`$resultArray['requireJsModules']` of the form engine result array
- Using backend FormEngine, the current ServerRequestInterface request must be provided in key "request" as
initialData to FormDataCompiler, the fallback to :php:`$GLOBALS['TYPO3_REQUEST']` has been removed.
- Compatibility layer for "TCEforms" key in FlexFormTools has been removed
- Compatibility layer for using array parameters for files in extbase (use `UploadedFile` instead)
The following upgrade wizards have been removed:
- Wizard for migrating backend user languages
- Wizard for installing the extension "legacy_collections" from TER
- Wizard for migrating the :php:`transOrigDiffSourceField` field to a json encoded string
- Wizard for cleaning up workspace `new` placeholders
- Wizard for cleaning up workspace `move` placeholders
- Wizard for migrating shortcut records
- Wizard for sanitizing existing SVG files in the `fileadmin` folder
- Wizard for populating a new channel column of the sys_log table
The following features are now always enabled:
- `security.backend.enforceContentSecurityPolicy`
The following feature has been removed:
- Regular expression based validators in ext:form backend UI
The following database table fields have been removed:
- :sql:`fe_users.TSconfig`
- :sql:`fe_groups.TSconfig`
The following backend route identifier has been removed:
- `ajax_core_requirejs`
The following global JavaScript variable has been removed:
- :js:`TYPO3.Tooltip`
The following global JavaScript function has been removed:
- :js:`Global_JavaScript_Function_Name`
The following JavaScript module has been removed:
- :js:`tooltip`
The following JavaScript method behaviour has changed:
- :js:`ColorPicker.initialize()` always requires an :js:`HTMLInputElement` to be passed as first argument
The following JavaScript method has been removed:
- :js:`getParameterFromUrl()` of :js:`@typo3/backend/utility`
The following CKEditor plugin has been removed:
- :js:`SoftHyphen`
The following dependency injection service aliase has been removed:
- :yaml:`@dashboard.views.widget`
Impact
======
Using above removed functionality will most likely raise PHP fatal level errors,
may change website output or crashes browser JavaScript.
.. index:: Backend, CLI, Database, FlexForm, Fluid, Frontend, JavaScript, LocalConfiguration, PHP-API, RTE, TCA, TSConfig, TypoScript, PartiallyScanned
@@ -0,0 +1,50 @@
.. include:: /Includes.rst.txt
.. _breaking-100966-1686062649:
====================================
Breaking: #100966 - Remove jquery-ui
====================================
See :issue:`100966`
Description
===========
The `NPM package jquery-ui <https://www.npmjs.com/package/jquery-ui>`__ has
been removed completely for TYPO3 v13 without any substitute.
According to the `TYPO3 Deprecation Policy <https://typo3.org/article/typo3-deprecation-policy>`__,
JavaScript code and packages used only in the TYPO3 backend are not
considered to be part of that policy:
The deprecation policy does not cover the deprecations of backend components
such as JavaScript code, CSS code, HTML code, and backend templates.
Impact
======
TYPO3 does not ship the NPM package `jquery-ui` any longer. Third-party
extensions that rely on this package will be broken and need to be adjusted.
Since TYPO3 exposed only parts of `jquery-ui`, only the components `core`,
`draggable`, `droppable`, `mouse`, `resizable`, `selectable`, `sortable` and
`widget` are affected - other components simply did not exist.
Affected installations
======================
Those having custom or third-party extensions using `jquery-ui` from
:file:`typo3/sysext/core/Resources/Public/JavaScript/Contrib/jquery-ui/`.
Migration
=========
TYPO3 does not provide any substitute. In TYPO3 the `draggable` and `resizable`
features of `jquery-ui` have been reimplemented in the new custom element
:html:`<typo3-backend-draggable-resizable>`.
.. index:: Backend, JavaScript, NotScanned, ext:core
@@ -0,0 +1,55 @@
.. include:: /Includes.rst.txt
.. _breaking-Action-1687355374:
========================================================
Breaking: #101129 - Convert Action to native backed enum
========================================================
See :issue:`101129`
Description
===========
The class :php:`\TYPO3\CMS\Scheduler\Task\Enumeration\Action` is now
converted to a native backed enum. In addition the class is moved to
the namespace :php:`\TYPO3\CMS\Scheduler` and renamed to
:php:`SchedulerManagementAction`.
Impact
======
Since :php:`\TYPO3\CMS\Scheduler\Task\Enumeration\Action` is no longer
a class, the existing class constants are no longer available.
In addition it's not possible to instantiate it anymore.
Affected installations
======================
Third-party extensions using the following class constants:
- :php:`\TYPO3\CMS\Scheduler\Task\Enumeration\Action::ADD`
- :php:`\TYPO3\CMS\Scheduler\Task\Enumeration\Action::EDIT`
- :php:`\TYPO3\CMS\Scheduler\Task\Enumeration\Action::LIST`
Class instantiation:
- :php:`new Action('a-string')`
Migration
=========
Include the enum :php:`SchedulerManagementAction` from namespace :php:`\TYPO3\CMS\Scheduler`
as a replacement for :php:`Action`.
Use the new syntax
- :php:`\TYPO3\CMS\Scheduler\SchedulerManagementAction::ADD`
- :php:`\TYPO3\CMS\Scheduler\SchedulerManagementAction::EDIT`
- :php:`\TYPO3\CMS\Scheduler\SchedulerManagementAction::LIST`
as well as the :php:`tryFrom($aString)` static method of the backed enum.
.. index:: Backend, NotScanned, ext:linkvalidator, ext:recycler, ext:reports, ext:scheduler
@@ -0,0 +1,55 @@
.. include:: /Includes.rst.txt
.. _breaking-101131-1687289195:
===========================================================
Breaking: #101131 - Convert LoginType to native backed enum
===========================================================
See :issue:`101131`
Description
===========
The class :php:`\TYPO3\CMS\Core\Authentication\LoginType` is now
converted to a native backed enum.
Impact
======
Since :php:`\TYPO3\CMS\Core\Authentication\LoginType` is no longer
a class, the existing class constants are no longer available.
Affected installations
======================
Custom authenticators using the following class constants:
- :php:`\TYPO3\CMS\Core\Authentication\LoginType::LOGIN`
- :php:`\TYPO3\CMS\Core\Authentication\LoginType::LOGOUT`
Migration
=========
Use the new syntax:
:php:`\TYPO3\CMS\Core\Authentication\LoginType::LOGIN->value`
:php:`\TYPO3\CMS\Core\Authentication\LoginType::LOGOUT->value`
Alternatively, use the enum method :php:`tryFrom` to convert a
value to an enum. For direct comparison of two enums, the null-coalescing
operator shall be used to ensure that the parameter is a string:
.. code-block:: php
<?php
use TYPO3\CMS\Core\Authentication\LoginType;
if (LoginType::tryFrom($value ?? '') === LoginType::LOGIN) {
// Do login stuff
}
if (LoginType::tryFrom($value ?? '') === LoginType::LOGOUT) {
// Do logout stuff
}
.. index:: Backend, Authentication, NotScanned, ext:core
@@ -0,0 +1,39 @@
.. include:: /Includes.rst.txt
.. _breaking-101133-1687875354:
===========================================================
Breaking: #101133 - IconFactory->getIcon() signature change
===========================================================
See :issue:`101133`
Description
===========
The public method :php:`getIcon()` in :php:`\TYPO3\CMS\Core\Imaging\IconFactory`
has changed its 4th parameter, in order to prepare the removal
of class :php:`\TYPO3\CMS\Core\Type\Icon\IconState`.
Impact
======
Custom extensions extending the :php:`getIcon()` method of class
:php:`\TYPO3\CMS\Core\Imaging\IconFactory` not having the same signature
will fail with a PHP fatal error.
Affected installations
======================
Custom extensions extending the :php:`getIcon()` method from class
:php:`\TYPO3\CMS\Core\Imaging\IconFactory`.
Migration
=========
Adapt the 4th parameter of :php:`getIcon()` to be of type
:php:`\TYPO3\CMS\Core\Type\Icon\IconState|IconState $state = null`
In addition, adapt the code in the body of the method.
.. index:: Backend, NotScanned, ext:core
@@ -0,0 +1,58 @@
.. include:: /Includes.rst.txt
.. _breaking-101133-1687875355:
============================================
Breaking: #101133 - Icon->state changed type
============================================
See :issue:`101133`
Description
===========
The protected property :php:`\TYPO3\CMS\Core\Imaging\Icon->state` holds now a native
enum :php:`\TYPO3\CMS\Core\Imaging\IconState` instead of an instance of
:php:`\TYPO3\CMS\Core\Type\Icon\IconState`.
Impact
======
Custom extensions calling :php:`\TYPO3\CMS\Core\Imaging\Icon->getState()` will
receive an enum now, which will most probably lead to PHP errors in the runtime.
Custom extensions calling :php:`\TYPO3\CMS\Core\Imaging\Icon->setState()` with an
instance of :php:`\TYPO3\CMS\Core\Type\Icon\IconState` will receive a PHP
TypeError.
Affected installations
======================
Custom extensions calling :php:`\TYPO3\CMS\Core\Imaging\Icon->getState()` or
:php:`\TYPO3\CMS\Core\Imaging\Icon->setState()`.
Migration
=========
Adapt your code to handle the native enum :php:`\TYPO3\CMS\Core\Imaging\IconState`.
.. code-block:: php
use TYPO3\CMS\Core\Imaging\Icon;
use TYPO3\CMS\Core\Type\Icon\IconState;
use TYPO3\CMS\Core\Utility\GeneralUtility;
// Before
$icon = GeneralUtility::makeInstance(Icon::class);
$icon->setState(IconState::cast(IconState::STATE_DEFAULT));
$state = $icon->getState();
$stateValue = (string)$state;
// After
$icon = GeneralUtility::makeInstance(Icon::class);
$icon->setState(IconState::STATE_DEFAULT);
$state = $icon->getState();
$stateValue = $state->value;
.. index:: Backend, NotScanned, ext:core
@@ -0,0 +1,49 @@
.. include:: /Includes.rst.txt
.. _breaking-101137-1688397315:
===================================================
Breaking: #101137 - Page Doktype "Recycler" removed
===================================================
See :issue:`101137`
Description
===========
TYPO3 had multiple concepts of a recycler / trash bin. One of the oldest
concepts was the ability to create a manual page of the type "Recycler"
(page records with doktype=255 set) where editors could manually move content
to such a page instead of deleting it. One other option is to use the
:guilabel:`Web > Recycler` backend module (available with the shipped recycler
system extension). This process is much more user-friendly: Any kind of record
which has been (soft-)deleted can be viewed and re-added via this module, no
manual process during the deletion process is needed.
For reasons of consistency and de-cluttering the UI, the former functionality
has been removed from TYPO3 Core, along with the PHP class
constant :php:`\TYPO3\CMS\Domain\Repository\PageRepository::DOKTYPE_RECYCLER`.
Impact
======
The recycler doktype has been removed and cannot be selected or used anymore. Any
existing recycler pages are migrated to a page of type "Backend User Section"
which is also not accessible, if there is no valid backend user with permission
to see this page.
Affected installations
======================
TYPO3 installations using this special page doktype "Recycler".
Migration
=========
A migration is in place, it is recommended to use the :guilabel:`Recycler`
module with soft-deleting records.
.. index:: Backend, PHP-API, PartiallyScanned, ext:core
@@ -0,0 +1,41 @@
.. include:: /Includes.rst.txt
.. _breaking-LinktypeInterface-1687413563:
======================================================
Breaking: #101143 - Strict typing in LinktypeInterface
======================================================
See :issue:`101143`
Description
===========
All methods in the interface :php:`\TYPO3\CMS\Linkvalidator\Linktype\LinktypeInterface`
are now strictly typed.
Impact
======
Classes implementing the interface must now ensure all methods are strictly typed.
Affected installations
======================
Custom classes implementing :php:`\TYPO3\CMS\Linkvalidator\Linktype\LinktypeInterface`
Migration
=========
Ensure that classes that implement :php:`\TYPO3\CMS\Linkvalidator\Linktype\LinktypeInterface`
have the following signatures:
.. code-block:: php
public function checkLink(string $url, array $softRefEntry, LinkAnalyzer $reference): bool;
public function fetchType(array $value, string $type, string $key): string;
public function getErrorParams(): array;
public function getBrokenUrl(array $row): string;
public function getErrorMessage(array $errorParams): string;
.. index:: Backend, NotScanned, ext:linkvalidator
@@ -0,0 +1,35 @@
.. include:: /Includes.rst.txt
.. _breaking-PageTsBackendLayoutDataProvider-1687440947:
=================================================================
Breaking: #101149 - Mark PageTsBackendLayoutDataProvider as final
=================================================================
See :issue:`101149`
Description
===========
The class :php:`\TYPO3\CMS\Backend\View\BackendLayout\PageTsBackendLayoutDataProvider`
is marked as final.
Impact
======
It is no longer possible to extend the class
:php:`\TYPO3\CMS\Backend\View\BackendLayout\PageTsBackendLayoutDataProvider`.
Affected installations
======================
Classes extending :php:`\TYPO3\CMS\Backend\View\BackendLayout\PageTsBackendLayoutDataProvider`.
Migration
=========
Instead of extending the data provider, it is recommended to register a custom
DataProvider for backend layouts, which can already be used since TYPO3 v7.
.. index:: Backend, NotScanned, ext:backend
@@ -0,0 +1,69 @@
.. include:: /Includes.rst.txt
.. _breaking-VersionState-1687856333:
==============================================================
Breaking: #101175 - Convert VersionState to native backed enum
==============================================================
See :issue:`101175`
Description
===========
The class :php:`\TYPO3\CMS\Core\Versioning\VersionState` is now
converted to a native PHP backed enum.
Impact
======
Since :php:`\TYPO3\CMS\Core\Versioning\VersionState` is no longer
a class, the existing class constants are no longer available, but are
enum instances instead.
In addition it's not possible to instantiate it anymore or call
the :php:`equals()` method.
Affected installations
======================
TYPO3 code using the following code:
Using the following class constants:
- :php:`\TYPO3\CMS\Core\Versioning\VersionState::DEFAULT_STATE`
- :php:`\TYPO3\CMS\Core\Versioning\VersionState::NEW_PLACEHOLDER`
- :php:`\TYPO3\CMS\Core\Versioning\VersionState::DELETE_PLACEHOLDER`
- :php:`\TYPO3\CMS\Core\Versioning\VersionState::MOVE_POINTER`
Class instantiation:
- :php:`new \TYPO3\CMS\Core\Versioning\(VersionState::*->value)`
where * denotes one of the enum values.
Method invocation:
- :php:`\TYPO3\CMS\Core\Versioning\VersionState::cast()`
- :php:`\TYPO3\CMS\Core\Versioning\VersionState::cast()->equals()`
Migration
=========
Use the new syntax for getting the values:
- :php:`\TYPO3\CMS\Core\Versioning\VersionState::DEFAULT_STATE->value`
- :php:`\TYPO3\CMS\Core\Versioning\VersionState::NEW_PLACEHOLDER->value`
- :php:`\TYPO3\CMS\Core\Versioning\VersionState::DELETE_PLACEHOLDER->value`
- :php:`\TYPO3\CMS\Core\Versioning\VersionState::MOVE_POINTER->value`
Class instantiation should be replaced by:
- :php:`\TYPO3\CMS\Core\Versioning\VersionState::tryFrom($row['t3ver_state'])`
Method invocation of :php:`cast()`/:php:`equals()` should be replaced by:
- :php:`\TYPO3\CMS\Core\Versioning\VersionState::tryFrom(...)`
- :php:`\TYPO3\CMS\Core\Versioning\VersionState::tryFrom(...) === VersionState::MOVE_POINTER`
.. index:: Backend, NotScanned, ext:backend, ext:core, ext:frontend, ext:workspaces
@@ -0,0 +1,42 @@
.. include:: /Includes.rst.txt
.. _breaking-UnableToLinkException-1687953808:
==========================================================
Breaking: #101186 - Strict typing in UnableToLinkException
==========================================================
See :issue:`101186`
Description
===========
The class constructor in :php:`\TYPO3\CMS\Frontend\Exception\UnableToLinkException`
is now strictly typed. In addition, the variable :php:`$linkText` has type :php:`string`.
Impact
======
The class constructor is now strictly typed.
Affected installations
======================
TYPO3 sites using the :php:`\TYPO3\CMS\Frontend\Exception\UnableToLinkException` exception.
Migration
=========
Ensure that the class constructor is called properly, according to the changed signature:
.. code-block:: php
public function __construct(
string $message = '',
int $code = 0,
?\Throwable $previous = null,
string $linkText = ''
);
.. index:: Backend, NotScanned, ext:fluid, ext:frontend, ext:redirects
@@ -0,0 +1,53 @@
.. include:: /Includes.rst.txt
.. _breaking-101192-1688017013:
==============================================================
Breaking: #101192 - Remove fallback for CKEditor removePlugins
==============================================================
See :issue:`101192`
Description
===========
Remove fallback for CKEditor configuration `removePlugins` as a string.
Impact
======
Runtime Javascript errors can occur if the CKEditor configuration
`removePlugins` isn't an array.
Affected installations
======================
TYPO3 installation which have CKEditor configuration `removePlugins`
configured as a string.
Migration
=========
Adjust your CKEditor configuration and pass :yaml:`removePlugins` as array.
Before
------
.. code-block:: yaml
editor:
config:
removePlugins: image
After
-----
.. code-block:: yaml
editor:
config:
removePlugins:
- image
.. index:: Backend, NotScanned, RTE, ext:rte_ckeditor
@@ -0,0 +1,90 @@
.. include:: /Includes.rst.txt
.. _breaking-101266-1688654482:
====================================
Breaking: #101266 - Remove RequireJS
====================================
See :issue:`101266`
Description
===========
The RequireJS project has been `discontinued`_ and was therefore
deprecated in TYPO3 v12 with :issue:`96510` in favor of native ECMAScript
v6/v11 modules (added in :issue:`96510`).
The infrastructure for configuration and loading of RequireJS
modules is now removed.
Impact
======
Registering FormEngine JavaScript modules via :php:`'requireJsModules'` will
have no effect. The PageRenderer endpoints
:php:`\TYPO3\CMS\Core\Page\PageRenderer->loadRequireJs()` and
:php:`\TYPO3\CMS\Core\Page\PageRenderer->loadRequireJsModule()`
have been removed and must no longer be called.
The respective :html:`includeRequireJsModules` property of the
:html:`<f:be.pageRenderer>` ViewHelper has also been removed.
Affected installations
======================
TYPO3 installations using RequireJS modules to provide JavaScript in the TYPO3
backend, or less common use PageRenderer RequireJS infrastructure for
frontend JavaScript module loading.
Migration
=========
Migrate your JavaScript from the AMD module format to native ES6 modules and
register your configuration in :php:`Configuration/JavaScriptModules.php`,
also see :issue:`96510` and :ref:`t3coreapi:backend-javascript-es6`
for more information:
.. code-block:: php
# Configuration/JavaScriptModules.php
<?php
return [
'dependencies' => ['core', 'backend'],
'imports' => [
'@vendor/my-extension/' => 'EXT:my_extension/Resources/Public/JavaScript/',
],
];
Then use :php:`\TYPO3\CMS\Core\Page\PageRenderer->loadJavaScriptModule()` instead
of :php:`\TYPO3\CMS\Core\Page\PageRenderer->loadRequireJsModule()` to load the ES6 module:
.. code-block:: php
// via PageRenderer
$this->pageRenderer->loadJavaScriptModule('@vendor/my-extension/example.js');
In Fluid templates `includeJavaScriptModules` is to be used instead of
`includeRequireJsModules`:
In Fluid template the `includeJavaScriptModules` property of the
:html:`<f:be.pageRenderer>` ViewHelper may be used:
.. code-block:: xml
<f:be.pageRenderer
includeJavaScriptModules="{
0: '@vendor/my-extension/example.js'
}"
/>
.. seealso::
:ref:`t3coreapi:backend-javascript-es6` for more info about JavaScript in TYPO3 Backend.
.. _discontinued: https://github.com/requirejs/requirejs/issues/1816
.. index:: Backend, JavaScript, PHP-API, PartiallyScanned, ext:core
@@ -0,0 +1,90 @@
.. include:: /Includes.rst.txt
.. _breaking-101281-1688708590:
====================================================================
Breaking: #101281 - Introduce type declarations in ResourceInterface
====================================================================
See :issue:`101281`
Description
===========
The following methods of interface
:php:`\TYPO3\CMS\Core\Resource\ResourceInterface` have been given return
type declarations:
.. code-block:: php
public function getIdentifier(): string;
public function getName(): string;
public function getStorage(): ResourceStorage;
public function getHashedIdentifier(): string;
public function getParentFolder(): FolderInterface;
Impact
======
This affects many classes due to the following implementation
rules:
- :php:`\TYPO3\CMS\Core\Resource\Folder`, because it implements
:php:`\TYPO3\CMS\Core\Resource\FolderInterface` which extends
:php:`\TYPO3\CMS\Core\Resource\ResourceInterface`
- :php:`\TYPO3\CMS\Core\Resource\FileReference`, and
:php:`\TYPO3\CMS\Core\Resource\AbstractFile` because both implement
:php:`\TYPO3\CMS\Core\Resource\FileInterface` which extends
:php:`\TYPO3\CMS\Core\Resource\ResourceInterface`
- :php:`\TYPO3\CMS\Core\Resource\File` and
:php:`\TYPO3\CMS\Core\Resource\ProcessedFile`
because both extend :php:`\TYPO3\CMS\Core\Resource\AbstractFile`
In consequence, the following methods are affected:
- :php:`\TYPO3\CMS\Core\Resource\Folder::getIdentifier()`
- :php:`\TYPO3\CMS\Core\Resource\Folder::getName()`
- :php:`\TYPO3\CMS\Core\Resource\Folder::getStorage()`
- :php:`\TYPO3\CMS\Core\Resource\Folder::getHashedIdentifier()`
- :php:`\TYPO3\CMS\Core\Resource\Folder::getParentFolder()`
- :php:`\TYPO3\CMS\Core\Resource\FileReference::getIdentifier()`
- :php:`\TYPO3\CMS\Core\Resource\FileReference::getName()`
- :php:`\TYPO3\CMS\Core\Resource\FileReference::getStorage()`
- :php:`\TYPO3\CMS\Core\Resource\FileReference::getHashedIdentifier()`
- :php:`\TYPO3\CMS\Core\Resource\FileReference::getParentFolder()`
- :php:`\TYPO3\CMS\Core\Resource\AbstractFile::getIdentifier()`
- :php:`\TYPO3\CMS\Core\Resource\AbstractFile::getName()`
- :php:`\TYPO3\CMS\Core\Resource\AbstractFile::getStorage()`
- :php:`\TYPO3\CMS\Core\Resource\AbstractFile::getHashedIdentifier()`
- :php:`\TYPO3\CMS\Core\Resource\AbstractFile::getParentFolder()`
- :php:`\TYPO3\CMS\Core\Resource\File::getIdentifier()`
- :php:`\TYPO3\CMS\Core\Resource\File::getName()`
- :php:`\TYPO3\CMS\Core\Resource\File::getStorage()`
- :php:`\TYPO3\CMS\Core\Resource\File::getHashedIdentifier()`
- :php:`\TYPO3\CMS\Core\Resource\File::getParentFolder()`
- :php:`\TYPO3\CMS\Core\Resource\ProcessedFile::getIdentifier()`
- :php:`\TYPO3\CMS\Core\Resource\ProcessedFile::getName()`
- :php:`\TYPO3\CMS\Core\Resource\ProcessedFile::getStorage()`
- :php:`\TYPO3\CMS\Core\Resource\ProcessedFile::getHashedIdentifier()`
- :php:`\TYPO3\CMS\Core\Resource\ProcessedFile::getParentFolder()`
Affected installations
======================
Affected installations are those which either implement the :php:`ResourceInterface`
directly (very unlikely) or those that extend any of mentioned implementations
(Core classes).
The usage (the API) of those implementation itself has not changed!
Migration
=========
Use the same return type declarations as :php:`ResourceInterface` does.
.. index:: FAL, PHP-API, NotScanned, ext:core
@@ -0,0 +1,89 @@
.. include:: /Includes.rst.txt
.. _breaking-101291-1688740732:
==================================================
Breaking: #101291 - Introduce capabilities bit set
==================================================
See :issue:`101291`
Description
===========
The capabilities property of the :php:`ResourceStorage` and drivers
(:php:`LocalDriver`/:php:`AbstractDriver`) have been converted from an integer
(holding a bit value) to an instance of a new :php:`BitSet` class
:php:`\TYPO3\CMS\Core\Resource\Capabilities`.
This affects the public API of the following interface methods:
- :php:`\TYPO3\CMS\Core\Resource\Driver\DriverInterface::getCapabilities()`
- :php:`\TYPO3\CMS\Core\Resource\Driver\DriverInterface::mergeConfigurationCapabilities()`
In consequence, all mentioned methods of implementations are affected as well,
those of:
- :php:`\TYPO3\CMS\Core\Resource\Driver\AbstractDriver::getCapabilities()`
- :php:`\TYPO3\CMS\Core\Resource\Driver\LocalDriver::mergeConfigurationCapabilities()`
Also the following constants have been removed:
- :php:`\TYPO3\CMS\Core\Resource\ResourceStorageInterface::CAPABILITY_BROWSABLE`
- :php:`\TYPO3\CMS\Core\Resource\ResourceStorageInterface::CAPABILITY_PUBLIC`
- :php:`\TYPO3\CMS\Core\Resource\ResourceStorageInterface::CAPABILITY_WRITABLE`
- :php:`\TYPO3\CMS\Core\Resource\ResourceStorageInterface::CAPABILITY_HIERARCHICAL_IDENTIFIERS`
Impact
======
The return type of the following methods, respective their implementations have
changed from :php:`int` to :php:`\TYPO3\CMS\Core\Resource\Capabilities`:
- :php:`\TYPO3\CMS\Core\Resource\Driver\DriverInterface::getCapabilities()`
- :php:`\TYPO3\CMS\Core\Resource\Driver\DriverInterface::mergeConfigurationCapabilities()`
The type of the parameter :php:`$capabilities` of the method
:php:`mergeConfigurationCapabilities()` has been changed from :php:`int` to
:php:`\TYPO3\CMS\Core\Resource\Capabilities`.
The usage of the mentioned, removed constants of
:php:`\TYPO3\CMS\Core\Resource\ResourceStorageInterface` will lead to errors.
Affected installations
======================
Installations that implement custom drivers and therefore directly implement
:php:`\TYPO3\CMS\Core\Resource\Driver\DriverInterface` or extend
:php:`\TYPO3\CMS\Core\Resource\Driver\AbstractDriver`.
Also, installations that use the removed constants of
:php:`\TYPO3\CMS\Core\Resource\ResourceStorageInterface`.
Migration
=========
When using mentioned methods that formerly returned the bit value as integer or
expected the bit value as integer parameter need to use the :php:`Capabilities`
class instead. It behaves exactly the same as the plain integer. If the plain
integer value needs to be retrieved, :php:`__toInt()` can be called on
:php:`Capabilities` instances.
The following removed constants
- :php:`\TYPO3\CMS\Core\Resource\ResourceStorageInterface::CAPABILITY_BROWSABLE`
- :php:`\TYPO3\CMS\Core\Resource\ResourceStorageInterface::CAPABILITY_PUBLIC`
- :php:`\TYPO3\CMS\Core\Resource\ResourceStorageInterface::CAPABILITY_WRITABLE`
- :php:`\TYPO3\CMS\Core\Resource\ResourceStorageInterface::CAPABILITY_HIERARCHICAL_IDENTIFIERS`
can be replaced with public constants of the new :php:`Capabilities` class:
- :php:`\TYPO3\CMS\Core\Resource\Capabilities::CAPABILITY_BROWSABLE`
- :php:`\TYPO3\CMS\Core\Resource\Capabilities::CAPABILITY_PUBLIC`
- :php:`\TYPO3\CMS\Core\Resource\Capabilities::CAPABILITY_WRITABLE`
- :php:`\TYPO3\CMS\Core\Resource\Capabilities::CAPABILITY_HIERARCHICAL_IDENTIFIERS`
.. index:: FAL, PHP-API, NotScanned, ext:core
@@ -0,0 +1,45 @@
.. include:: /Includes.rst.txt
.. _breaking-101294-1688885539:
================================================================
Breaking: #101294 - Introduce type declarations in FileInterface
================================================================
See :issue:`101294`
Description
===========
Return and param type declarations have been introduced for all methods stubs
of :php:`\TYPO3\CMS\Core\Resource\FileInterface`.
Impact
======
In consequence, all implementations of :php:`\TYPO3\CMS\Core\Resource\FileInterface` need
to reflect those changes and add the same return and param type declarations.
In case, any of the Core implementations are extended, overridden methods might need
to be adjusted. The Core classes, implementing :php:`\TYPO3\CMS\Core\Resource\FileInterface`, are:
- :php:`\TYPO3\CMS\Core\Resource\AbstractFile`
- :php:`\TYPO3\CMS\Core\Resource\File`
- :php:`\TYPO3\CMS\Core\Resource\FileReference`
- :php:`\TYPO3\CMS\Core\Resource\ProcessedFile`
Affected installations
======================
Only those installations that implement :php:`\TYPO3\CMS\Core\Resource\FileInterface` directly
or that extend any of those mentioned core implementations.
Migration
=========
Return and param type declarations have to be synced with the ones of the interface.
.. index:: FAL, PHP-API, NotScanned, ext:core
@@ -0,0 +1,104 @@
.. include:: /Includes.rst.txt
.. _breaking-101305-1689059968:
==================================================================================
Breaking: #101305 - Introduce type declarations for some methods in GeneralUtility
==================================================================================
See :issue:`101305`, :issue:`101453`
Description
===========
Native return and param type declarations have been introduced for the following
methods of :php:`\TYPO3\CMS\Core\Utility\GeneralUtility`:
- :php:`addInstance()`
- :php:`array2xml()`
- :php:`callUserFunction()`
- :php:`cmpFQDN()`
- :php:`cmpIP()`
- :php:`cmpIPv4()`
- :php:`cmpIPv6()`
- :php:`copyDirectory()`
- :php:`createDirectoryPath()`
- :php:`createVersionNumberedFilename()`
- :php:`explodeUrl2Array()`
- :php:`fixPermissions()`
- :php:`flushInternalRuntimeCaches()`
- :php:`getAllFilesAndFoldersInPath()`
- :php:`getBytesFromSizeMeasurement()`
- :php:`getClassName()`
- :php:`getFileAbsFileName()`
- :php:`getFilesInDir()`
- :php:`getIndpEnv()`
- :php:`getInstances()`
- :php:`getLogger()`
- :php:`getSingletonInstances()`
- :php:`getUrl()`
- :php:`get_dirs()`
- :php:`get_tag_attributes()`
- :php:`implodeArrayForUrl()`
- :php:`implodeAttributes()`
- :php:`intExplode()`
- :php:`isAllowedAbsPath()`
- :php:`isOnCurrentHost()`
- :php:`isValidUrl()`
- :php:`jsonEncodeForHtmlAttribute()`
- :php:`jsonEncodeForJavaScript()`
- :php:`locationHeaderUrl()`
- :php:`makeInstanceForDi()`
- :php:`mkdir_deep()`
- :php:`mkdir()`
- :php:`normalizeIPv6()`
- :php:`purgeInstances()`
- :php:`quoteJSvalue()`
- :php:`removePrefixPathFromList()`
- :php:`removeSingletonInstance()`
- :php:`resetSingletonInstances()`
- :php:`resolveBackPath()`
- :php:`revExplode()`
- :php:`rmdir()`
- :php:`sanitizeLocalUrl()`
- :php:`setIndpEnv()`
- :php:`setSingletonInstance()`
- :php:`split_tag_attributes()`
- :php:`tempnam()`
- :php:`trimExplode()`
- :php:`unlink_tempfile()`
- :php:`upload_copy_move()`
- :php:`upload_to_tempfile()`
- :php:`validEmail()`
- :php:`validIP()`
- :php:`validIPv4()`
- :php:`validIPv6()`
- :php:`validPathStr()`
- :php:`webserverUsesHttps()`
- :php:`wrapJS()`
- :php:`writeFileToTypo3tempDir()`
- :php:`writeFile()`
- :php:`writeJavaScriptContentToTemporaryFile()`
- :php:`writeStyleSheetContentToTemporaryFile()`
- :php:`xml2arrayProcess()`
- :php:`xml2array()`
- :php:`xml2tree()`
- :php:`xmlRecompileFromStructValArray()`
Impact
======
Calling any of the mentioned methods with invalid types will result in a
PHP error.
Affected installations
======================
Only those installations that use the mentioned methods with invalid types.
Migration
=========
Make sure to pass parameters of the required types to the mentioned methods.
.. index:: PHP-API, NotScanned, ext:core
@@ -0,0 +1,66 @@
.. include:: /Includes.rst.txt
.. _breaking-101309-1689061837:
==================================================================
Breaking: #101309 - Introduce type declarations in DriverInterface
==================================================================
See :issue:`101309`
Description
===========
Return and param type declarations have been introduced for all methods stubs
of :php:`\TYPO3\CMS\Core\Resource\Driver\DriverInterface`.
Also, method :php:`\TYPO3\CMS\Core\Resource\Driver\AbstractDriver::sanitizeFileName()`
has been removed.
Impact
======
In consequence, all implementations of :php:`\TYPO3\CMS\Core\Resource\Driver\DriverInterface` need
to reflect those changes and add the same return and param type declarations.
In case, any of the Core implementations are extended, overridden methods might need to be adjusted.
The Core classes, implementing :php:`\TYPO3\CMS\Core\Resource\DriverInterface`, are:
- :php:`\TYPO3\CMS\Core\Resource\Driver\AbstractDriver`
- :php:`\TYPO3\CMS\Core\Resource\Driver\AbstractHierarchicalFilesystemDriver`
- :php:`\TYPO3\CMS\Core\Resource\Driver\LocalDriver`
Concerning removed method :php:`\TYPO3\CMS\Core\Resource\Driver\AbstractDriver::sanitizeFileName()`:
Said method didn't sanitize at all, it didn't respect the given :php:`$charset` param and simply
returned the input string. Abstract classes MAY fulfill the interface contract but if they do so,
they MUST do it right. There is no benefit in fulfilling it just signature wise, it MUST fulfill
it functional wise and in this case it didn't. That's why :php:`LocalDriver`
reimplements :php:`sanitizeFileName()` completely.
As a consequence of this removal, all classes that extend either
:php:`\TYPO3\CMS\Core\Resource\Driver\AbstractDriver` or
:php:`\TYPO3\CMS\Core\Resource\Driver\AbstractHierarchicalFilesystemDriver`, need to
implement method :php:`sanitizeFileName()`.
Affected installations
======================
All installations that implement :php:`\TYPO3\CMS\Core\Resource\DriverInterface` or that
extend either :php:`\TYPO3\CMS\Core\Resource\Driver\AbstractDriver` or
:php:`\TYPO3\CMS\Core\Resource\Driver\AbstractHierarchicalFilesystemDriver`.
Migration
=========
As for the type declarations:
Add the same param and return type declarations the interface does.
As for the removed method :php:`\TYPO3\CMS\Core\Resource\Driver\AbstractDriver::sanitizeFileName()`:
Implement the method according to your driver capabilities.
.. index:: FAL, PHP-API, NotScanned, ext:core
@@ -0,0 +1,36 @@
.. include:: /Includes.rst.txt
.. _breaking-101311-1689067519:
====================================================================================
Breaking: #101311 - Make the parameter for GeneralUtility::sanitizeLocalUrl required
====================================================================================
See :issue:`101311`
Description
===========
The (only) parameter for :php:`\TYPO3\CMS\Core\Utility\GeneralUtility::sanitizeLocalUrl()`
is now required.
Impact
======
Calling :php:`GeneralUtility::sanitizeLocalUrl()` without an argument will result
in a PHP error.
Affected installations
======================
Only those installations that call :php:`GeneralUtility::sanitizeLocalUrl()`
without an argument.
The extension scanner will detect affected usages as a strong match.
Migration
=========
Make sure to pass an argument to :php:`GeneralUtility::sanitizeLocalUrl()`.
.. index:: PHP-API, FullyScanned, ext:core
@@ -0,0 +1,45 @@
.. include:: /Includes.rst.txt
.. _breaking-101327-1689092559:
===================================================
Breaking: #101327 - Harden FileInterface::getSize()
===================================================
See :issue:`101327`
Description
===========
A return type declaration has been added to the method stub :php:`\TYPO3\CMS\Core\Resource\FileInterface::getSize()`.
As a consequence, implementations of said method, :php:`\TYPO3\CMS\Core\Resource\AbstractFile::getSize()`
and :php:`\TYPO3\CMS\Core\Resource\FileReference::getSize()` received return type declarations as well.
Also, :php:`\TYPO3\CMS\Core\Resource\AbstractFile::getSize()` has been adjusted to actually just
return an integer. Previously, it returned :php:`null`, if the actual size could not be gathered. It now returns
:php:`0` in that case.
Impact
======
Code, that calls :php:`\TYPO3\CMS\Core\Resource\AbstractFile::getSize()` through derivatives like
:php:`\TYPO3\CMS\Core\Resource\File::getSize()` might be adjusted to not respect :php:`null` any more.
Implementations (classes) that implement :php:`\TYPO3\CMS\Core\Resource\FileInterface`, have to
adjust the return type of the method :php:`getSize()` to match the contract.
Affected installations
======================
Installations that implement :php:`\TYPO3\CMS\Core\Resource\FileInterface` or that call
:php:`\TYPO3\CMS\Core\Resource\FileInterface::getSize()` via derivatives.
Migration
=========
Adjust the return type and possible :php:`null` checks.
.. index:: FAL, PHP-API, NotScanned, ext:core
@@ -0,0 +1,39 @@
.. include:: /Includes.rst.txt
.. _breaking-101398-1689861816:
======================================================================
Breaking: #101398 - Remove leftover $fetchAllFields in RelationHandler
======================================================================
See :issue:`101398`
Description
===========
The :php:`\TYPO3\CMS\Core\Database\RelationHandler` had an unused property
:php:`$fetchAllFields` since TYPO3 v11.5.0. The related method
:php:`setFetchAllFields()` has been removed with it.
Impact
======
Custom extensions calling :php:`\TYPO3\CMS\Core\Database\RelationHandler->setFetchAllFields()`
will result in a PHP Fatal error.
Affected installations
======================
All installations with custom extensions calling
:php:`\TYPO3\CMS\Core\Database\RelationHandler->setFetchAllFields()`.
Migration
=========
Remove the affected line of code. This method has had no effect since
TYPO3 v11.5.0.
.. index:: PHP-API, FullyScanned, ext:core
@@ -0,0 +1,46 @@
.. include:: /Includes.rst.txt
.. _breaking-101469-1690528614:
==================================================================
Breaking: #101469 - Introduce type declarations in FolderInterface
==================================================================
See :issue:`101469`
Description
===========
Return and param type declarations have been introduced for all methods stubs
of :php:`\TYPO3\CMS\Core\Resource\FolderInterface`.
Impact
======
In consequence, all implementations of :php:`\TYPO3\CMS\Core\Resource\FolderInterface`
need to reflect those changes and add the same return and param type declarations.
In case, any of the Core implementations are extended, overridden methods might need to
be adjusted. The Core classes, implementing :php:`\TYPO3\CMS\Core\Resource\FolderInterface`
are:
- :php:`\TYPO3\CMS\Core\Resource\Folder`
- :php:`\TYPO3\CMS\Core\Resource\InaccessibleFolder`
Affected installations
======================
All installations that implement :php:`\TYPO3\CMS\Core\Resource\FolderInterface`
or that extend either :php:`\TYPO3\CMS\Core\Resource\Folder` or
:php:`\TYPO3\CMS\Core\Resource\InaccessibleFolder`.
Migration
=========
Add the same param and return type declarations the interface does.
.. index:: FAL, PHP-API, NotScanned, ext:core
@@ -0,0 +1,52 @@
.. include:: /Includes.rst.txt
.. _breaking-101471-1690531810:
=================================================================
Breaking: #101471 - Introduce type declarations in AbstractDriver
=================================================================
See :issue:`101471`
Description
===========
Return and param type declarations have been introduced for all methods and method
stubs of :php:`\TYPO3\CMS\Core\Resource\Driver\AbstractDriver` and
:php:`\TYPO3\CMS\Core\Resource\Driver\AbstractHierarchicalFilesystemDriver`
Impact
======
In consequence, all classes, extending any of those abstract classes and overriding
any of those affected methods need to reflect those changes and add the same return
and param type declarations.
Affected methods are:
- :php:`\TYPO3\CMS\Core\Resource\Driver\AbstractDriver::isValidFilename()`
- :php:`\TYPO3\CMS\Core\Resource\Driver\AbstractDriver::getTemporaryPathForFile()`
- :php:`\TYPO3\CMS\Core\Resource\Driver\AbstractDriver::canonicalizeAndCheckFilePath()`
- :php:`\TYPO3\CMS\Core\Resource\Driver\AbstractDriver::canonicalizeAndCheckFileIdentifier()`
- :php:`\TYPO3\CMS\Core\Resource\Driver\AbstractDriver::canonicalizeAndCheckFolderIdentifier()`
- :php:`\TYPO3\CMS\Core\Resource\Driver\AbstractHierarchicalFilesystemDriver::isPathValid()`
- :php:`\TYPO3\CMS\Core\Resource\Driver\AbstractHierarchicalFilesystemDriver::canonicalizeAndCheckFilePath()`
- :php:`\TYPO3\CMS\Core\Resource\Driver\AbstractHierarchicalFilesystemDriver::canonicalizeAndCheckFileIdentifier()`
- :php:`\TYPO3\CMS\Core\Resource\Driver\AbstractHierarchicalFilesystemDriver::canonicalizeAndCheckFolderIdentifier()`
Affected installations
======================
Installations that extend any of those abstract classes might be affected.
Migration
=========
Add the same param and return type declarations the interface does.
.. index:: FAL, PHP-API, NotScanned, ext:core
@@ -0,0 +1,48 @@
.. include:: /Includes.rst.txt
.. _breaking-101519-1690884375:
==============================================================
Breaking: #101519 - Remove `immediate` flag in `DebounceEvent`
==============================================================
See :issue:`101519`
Description
===========
With the introduction in TYPO3 v10, the :js:`DebounceEvent` module had the
possibility to shift the event handler execution to the beginning of the
debounce sequence, enabled via the optional :js:`immediate` parameter.
The parameter is unused in TYPO3 and using this feature has a negative impact
on :abbr:`UX (User Experience)`. If used, the event handler is directly executed
and the user has to wait a specific time after the last event was triggered,
before any further execution is possible.
The flag :js:`immediate` has been therefore removed.
Impact
======
The :js:`DebounceEvent` module now always waits until a certain time has passed
after the last trigger of the event happened before executing the event handler.
This is mostly used in potential heavy tasks, for example, an Ajax request that
is sent depending on the content of a search field.
Affected installations
======================
All extensions using the removed flag are affected.
Migration
=========
There is no direct migration possible. An extension author either may
re-implement the removed behavior manually, or use the :js:`ThrottleEvent`
module, providing a similar behavior.
.. index:: JavaScript, NotScanned, ext:core
@@ -0,0 +1,38 @@
.. include:: /Includes.rst.txt
.. _breaking-101603-1691322822:
=======================================================================
Breaking: #101603 - Removed hook for overriding icon overlay identifier
=======================================================================
See :issue:`101603`
Description
===========
The hook :php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['TYPO3\CMS\Core\Imaging\IconFactory']['overrideIconOverlay']`
has been removed in favor of a new PSR-14 event :php:`\TYPO3\CMS\Core\Imaging\Event\ModifyRecordOverlayIconIdentifierEvent`.
Impact
======
Any hook implementation registered is not executed anymore in TYPO3 v13.0+.
Affected Installations
======================
TYPO3 installations with custom extensions using this hook. The extension
scanner will report usages as strong match.
Migration
=========
The hook is removed without deprecation in order to allow extensions
to work with TYPO3 v12 (using the hook) and v13+ (using the new event)
when implementing the event as well without any further deprecations.
Replace any hook usage with the new
:doc:`PSR-14 event <../13.0/Feature-101603-PSR-14EventForModifyingRecordOverlayIconIdentifier>`.
.. index:: Backend, PHP-API, FullyScanned, ext:core
@@ -0,0 +1,49 @@
.. include:: /Includes.rst.txt
.. _breaking-101612-1691447955:
==========================================================
Breaking: #101612 - LinkParameterProviderInterface changed
==========================================================
See :issue:`101612`
Description
===========
The PHP interface :php:`\TYPO3\CMS\Backend\Tree\View\LinkParameterProviderInterface`
has changed. The interface is used to generate URLs with query parameters for links
within element browsers or link browsers in the TYPO3 backend.
The methods :php:`getScriptUrl()` and :php:`isCurrentlySelectedItem()` have been removed
from the interface, as the implementing link browsers do not need this information anymore
due to simplification in routing.
The method :php:`getUrlParameters()` now has a native return type :php:`array`, whereas
previously this was only type-hinted.
Impact
======
When accessing implementing PHP objects, it should be noted that these methods do not
exist anymore. When called this might result in fatal PHP errors.
When implementing the PHP interface, the implementing code will fail due to missing return
types.
Affected installations
======================
TYPO3 installations with custom implementations of this interface.
Migration
=========
For extensions implementing the interface, the return type for :php:`getUrlParameters()`
can be added in order to be TYPO3 v12+ compatible. For v13-only compatibility,
it is recommended to remove the superfluous methods.
.. index:: PHP-API, PartiallyScanned, ext:backend
@@ -0,0 +1,52 @@
.. include:: /Includes.rst.txt
.. _breaking-101647-1691669710:
====================================================================
Breaking: #101647 - Unused graphical assets removed from EXT:backend
====================================================================
See :issue:`101647`
Description
===========
The TYPO3 system extension "backend" accumulated many graphical assets over the
years that became unused piece by piece.
The following icons have been removed from the Icon Registry:
* `status-edit-read-only`
* `warning-in-use`
* `warning-lock`
The following assets have been removed from the directory :file:`EXT:backend/Resources/Public/Images/`:
* :file:`FormFieldWizard/wizard_forms.gif`
* :file:`clear.gif`
* :file:`filetree-folder-default.png`
* :file:`filetree-folder-opened.png`
* :file:`Logo.png`
* :file:`pages.gif`
* :file:`tt_content.gif`
Impact
======
Calling any of the removed icons from the Icon Registry will render the default
icon. Accessing any of the removed files directly will lead to a 404 error.
Affected installations
======================
All extensions using the removed icons and assets are affected.
Migration
=========
No direct migration is available.
.. index:: Backend, NotScanned, ext:backend
@@ -0,0 +1,88 @@
.. include:: /Includes.rst.txt
.. _breaking-101671-1691924837:
==============================================================================
Breaking: #101671 - Disable external linktypes by default in EXT:linkvalidator
==============================================================================
See :issue:`101671`
Description
===========
There are several known problems with external link checking in Linkvalidator,
such as:
* "False positives": Some links are reported broken, but are not broken, see
:issue:`101670`.
* External sites are checked without rate limit which may cause sites which
perform link checking to be blocked, see :issue:`89287`.
* No caching of results (except for a runtime cache during link checking which
will be invalid on next run)
These issues are currently not easily solvable and should also be addressed
specifically for the site concerned.
We now deactivate checking external link types by default in the configuration:
:ref:`ext_linkvalidator:linktypes`.
The "external" link types checking still works but must be enabled explicitly.
This will make administrators more aware of problems and the specific problems
can be addressed, for example, by providing a custom class to replace
:php:`\TYPO3\CMS\Linkvalidator\Linktype\ExternalLinktype`. Additionally, a page
:ref:`Known Problems <ext_linkvalidator:known-problems>` was
already added to the documentation in a previous `patch
<https://review.typo3.org/c/Packages/TYPO3.CMS/+/80421>`__.
Impact
======
External links will no longer be checked by default in EXT:linkvalidator
unless :typoscript:`mod.linkvalidator.linktypes` is specifically set via page
TSconfig.
Affected installations
======================
Installations using EXT:linkvalidator.
Migration
=========
Either leave external link checking deactivated or find ways to mitigate the
problems with external link checking.
Solutions:
* do not use external link checking
* or, create a custom linktype class to replace :php:`ExternalLinktype`
* the custom link type should rate limit when checking external links,
for example, by adding a crawl delay in the link targets with the same domain
* the custom link type should find a way to handle possible false positives
* alternatively the external link type should restrict link checking to known
domains without problems
* alternatively, there should be a method to exclude specific URLs or domains
from link checking
* excessive checking of external links should be avoided, for example, by
using a link target cache
More information is available in the Linkvalidator documentation:
* :ref:`ext_linkvalidator:known-problems`
* :ref:`ext_linkvalidator:linktype-implementation`
Example for activating external linktype
----------------------------------------
.. code-block:: typoscript
:caption: EXT:my_sitepackage/Configuration/page.tsconfig
mod.linkvalidator.linktypes = db,file,external
.. index:: Backend, NotScanned, ext:linkvalidator
@@ -0,0 +1,58 @@
.. include:: /Includes.rst.txt
.. _breaking-101820:
=======================================================================
Breaking: #101820 - Remove bootstrap jQuery interface and window.jQuery
=======================================================================
See :issue:`101820`
Description
===========
The bootstrap jQuery interfaces required a global :js:`window.jQuery` variable
to be set. The jquery drop-in is dropped in order to remove this non-optional
jQuery dependency.
As a side effect the :js:`window.jQuery` global is removed as well.
Note that global jQuery usage has already been deprecated in :issue:`86438` and
removed in :issue:`97243` with the suggestion to use JavaScript modules instead.
:js:`window.jQuery` was basically left in place for bootstrap to operate and
therefore only :js:`window.$` was removed back then.
Impact
======
Loading the ES6 'bootstrap' module no longer has side effects, as the global
scope :js:`window` is no longer polluted by writing to the property :js:`jQuery`.
This also means jQuery will no longer be loaded when it is not actually needed.
Affected Installations
======================
All installations that use bootstrap's jQuery interface or applications that
use `window.jQuery` to invoke jQuery.
Following method calls are affected:
- :js:`$(…).alert()`
- :js:`$(…).button()`
- :js:`$(…).carousel()`
- :js:`$(…).collapse()`
- :js:`$(…).dropdown()`
- :js:`$(…).tab()`
- :js:`$(…).modal()`
- :js:`$(…).offcanvas()`
- :js:`$(…).popover()`
- :js:`$(…).scrollspy()`
- :js:`$(…).toast()`
- :js:`$(…).tooltip()`
Migration
=========
Use bootstrap's ES6 exports :js:`import { Carousel } from 'bootstrap';` instead.
.. index:: Backend, JavaScript, NotScanned, ext:core
@@ -0,0 +1,49 @@
.. include:: /Includes.rst.txt
.. _breaking-101822-1693575438:
==========================================================================================
Breaking: #101822 - Change callback interruption in `@typo3/backend/document-save-actions`
==========================================================================================
See :issue:`101822`
Description
===========
The JavaScript module :js:`@typo3/backend/document-save-actions` is used in
FormEngine and Scheduler context mainly to disable the submit button in the
according forms, where also a spinner is rendered within the button to visualize
a running action.
Over the time, the module took over some tasks that logically belong to
FormEngine, which lead to slimming down the module. In a further effort, jQuery
has been removed from said module, leading to a change in behavior how the
callback chain can be aborted.
Native JavaScript events cannot get asked whether event propagation has been
stopped, making changes in the callbacks necessary. All callbacks registered via
:js:`DocumentSaveActions.getInstance().addPreSubmitCallback()` now need to
return a boolean value.
Impact
======
Using :js:`stop[Immediate]Propagation()` on events passed into registered
callbacks is now unsupported and may lead to undefined behavior.
Affected installations
======================
All extensions using :js:`DocumentSaveActions.getInstance().addPreSubmitCallback()`
are affected.
Migration
=========
Callbacks now need to return a boolean value, where returning :js:`false` will
abort the callback execution chain.
.. index:: Backend, JavaScript, NotScanned, ext:backend
@@ -0,0 +1,56 @@
.. include:: /Includes.rst.txt
.. _breaking-101933-1695472624:
===========================================================================
Breaking: #101933 - Dispatch AfterUserLoggedInEvent for frontend user login
===========================================================================
See :issue:`101933`
Description
===========
The :php:`\TYPO3\CMS\Core\Authentication\Event\AfterUserLoggedInEvent` PSR-14
event is now also dispatched for a successful frontend user login.
Impact
======
Listeners to the :php:`AfterUserLoggedInEvent` event should evaluate the
implementation type of the :php:`$user` property, if custom functionality
after a user login should be executed for backend login only.
Affected installations
======================
Installations with an event listener to the php:`AfterUserLoggedInEvent` PSR-14
event.
Migration
=========
If custom functionality in a listener to the :php:`AfterUserLoggedInEvent`
event should be executed for the backend user login only, a type check for the
:php:`$user` property must be added.
.. code-block:: php
// Before
public function __invoke(AfterUserLoggedInEvent $afterUserLoggedInEvent): void
{
// custom logic after backend user login
}
// After
public function __invoke(AfterUserLoggedInEvent $afterUserLoggedInEvent): void
{
if ($afterUserLoggedInEvent->getUser() instanceof BackendUserAuthentication) {
// custom logic after backend user login
}
}
.. index:: Backend, NotScanned, ext:backend
@@ -0,0 +1,61 @@
.. include:: /Includes.rst.txt
.. _breaking-101941-1695060791:
==============================================================
Breaking: #101941 - Various GFX-related legacy options removed
==============================================================
See :issue:`101941`
Description
===========
TYPO3's powerful image manipulation suite has legacy options which were used
20 years ago where it was more important to deliver GIF files instead of PNG
files due to the size of the file.
However, PNG supports transparency and 24 bit, and is supported widely nowadays
and the preferred option.
For this reason, TYPO3's default behavior is now to generate PNG files instead
of GIF files when creating thumbnails.
In addition, the GIFBUILDER option "reduceColors" has been removed, along with
the option to additionally compress GIF files via ImageMagick or GDLib.
The following PHP code has been removed:
* :php:`\TYPO3\CMS\Core\Imaging\GraphicalFunctions->dontCompress`
* :php:`\TYPO3\CMS\Core\Imaging\GraphicalFunctions->IMreduceColors()`
* :php:`\TYPO3\CMS\Core\Imaging\GraphicalFunctions::gifCompress()`
The following global settings have no effect anymore and are automatically removed
if still in use:
* :php:`$GLOBALS['TYPO3_CONF_VARS']['GFX']['gif_compress']` (removed)
* :php:`$GLOBALS['TYPO3_CONF_VARS']['GFX']['thumbnails_png']` (always active)
Impact
======
When generating thumbnail images or images via GIFBUILDER from various sources which
aren't supported by TYPO3's graphical processing, a PNG is now created instead of a GIF.
This can happen, for instance, when previewing PDF files. JPG files are still kept the same.
Affected installations
======================
TYPO3 installations which used these settings or customized GifBuilder code.
Migration
=========
For 99% of the installations, these options have been activated already, so there is no change
necessary when upgrading and also no visual change.
.. index:: FAL, Frontend, LocalConfiguration, PHP-API, TypoScript, FullyScanned, ext:core
@@ -0,0 +1,102 @@
.. include:: /Includes.rst.txt
.. _breaking-101948-1695118827:
===============================================================
Breaking: #101948 - File-based AbstractRepository class removed
===============================================================
See :issue:`101948`
Description
===========
When the base architecture of File Abstraction Layer (FAL) was introduced in
TYPO3 v6.0, various functionality was based on concepts based on Extbase's
architecture. Some concepts never flourished. One of them being the
:php:`\TYPO3\CMS\Core\Resource\AbstractRepository` class from FAL.
This PHP class served as a basis for 2 PHP classes,
:php:`\TYPO3\CMS\Core\Resource\FileRepository` and
:php:`\TYPO3\CMS\Core\Resource\ProcessedFileRepository`.
Nowadays, it is obvious that some decisions in this area were not useful:
1. The coupling to Extbase's repository architecture does not work out, as the
manual database queries that return objects should not be bound to Extbase's
QueryRestrictions.
These never worked and were never implemented in the mentioned repository
classes from FAL.
It becomes abundantly clear that the concepts do not match by looking at the
:php:`AbstractRepository` class which even had exceptions for methods that were
not compatible with Extbase.
2. The concept of inheritance did not work out for Dependency Injection
introduced in TYPO3 v10, and with PHP 8.x which reveals various typing problems
that arose around :php:`AbstractRepository`.
:php:`AbstractRepository` is thus removed, and the implementing classes do not
extend from this class anymore, as they only include the methods required for
their purpose, and are now completely strictly typed.
Additionally, :php:`FileRepository` has been cleaned up by removing
:php:`findFileReferenceByUid()` as it is only a wrapper to
:php:`ResourceFactory::getFileReferenceObject()`
Impact
======
Code that uses the three classes in a third-party extension might fail as the
implementing PHP repositories :php:`FileRepository` and
:php:`ProcessedFileRepository` have only necessary methods available.
PHP extensions that derive from the :php:`AbstractRepository` will stop working.
Code that used :php:`FileRepository::findFileReferenceByUid()` will break.
Affected installations
======================
As all three PHP classes are low-level in the FAL API, the impact for regular
installations will be rather low. Third-party extensions that extend from the
:php:`AbstractRepository` of FAL, which is a wild use-case will stop working. It is
safe to say, that only edge-case extensions that worked with the FAL API might
be affected, but regular installations will see no difference.
Migration
=========
Only extension authors working with the low-level API of File Abstraction Layer
would need to adapt their code to be type-safe. Extensions that extend from the
:php:`AbstractRepository` class of FAL should implement the necessary methods
themselves and remove the dependency from :php:`AbstractRepository`.
It is highly recommended to not use any of these classes, but rather stick
to high-level API of FAL, such as :php:`ResourceFactory`, :php:`File`
or :php:`ResourceStorage`.
Replace former calls to :php:`FileRepository::findFileReferenceByUid()` like:
.. code-block:: php
$fileRepository = GeneralUtility::makeInstance(FileRepository::class);
$reference = $fileRepository->findFileReferenceByUid($referenceUid);
by using the :php:`ResourceFactory` with new code like:
.. code-block:: php
$resourceFactory = GeneralUtility::makeInstance(ResourceFactory::class);
$reference = $resourceFactory->getFileReferenceObject($referenceUid);
.. note::
Ideally use dependency injection instead of :php:`GeneralUtility::makeInstance()` to
retrieve the instance for :php:`ResourceFactory`.
.. index:: FAL, PHP-API, PartiallyScanned, ext:core
@@ -0,0 +1,49 @@
.. include:: /Includes.rst.txt
.. _breaking-101950-1695121128:
===================================================================================
Breaking: #101950 - Removed legacy setting 'GFX/processor_allowTemporaryMasksAsPng'
===================================================================================
See :issue:`101950`
Description
===========
`GFX/processor_allowTemporaryMasksAsPng` is a setting that stems from an even older
setting called `im_mask_temp_ext_gif`. This setting was added because generally PNG
generation of Image/GraphicsMagick is always faster than generating GIF files, but
there were issues with PNG files in earlier versions of ImageMagick 5.
TYPO3 requires newer versions of GraphicsMagick and at least ImageMagick version 6,
in which the above reported behaviours couldn't be replicated anymore, obsoleting
the need for a non-PNG setting entirely.
The following global settings have no effect anymore and are automatically removed
if still in use:
* :php:`$GLOBALS['TYPO3_CONF_VARS']['GFX']['processor_allowTemporaryMasksAsPng']` (removed)
Impact
======
Temporarily saved masking images are now saved as PNG files rather than GIF images.
Testing has revealed no visual changes between this setting being turned on or off,
with both ImageMagick or GraphicsMagick.
Affected installations
======================
Every instance that already didn't set `processor_allowTemporaryMasksAsPng` to true.
Migration
=========
The configuration value has been removed without replacement. No migration is necessary.
.. index:: LocalConfiguration, FullyScanned, ext:core
@@ -0,0 +1,118 @@
.. include:: /Includes.rst.txt
.. _breaking-101955-1695195288:
======================================================================
Breaking: #101955 - Removed public methods related to Image Generation
======================================================================
See :issue:`101955`
Description
===========
For historical reasons, there is a PHP API class
:php:`\TYPO3\CMS\Core\Imaging\GraphicalFunctions` which deals with general
imaging functionality such as converting, scaling or cropping images - mainly
with ImageMagick / GraphicsMagick as a basis. In addition, the PHP class
:php:`\TYPO3\CMS\Frontend\Imaging\GifBuilder` which works with instructions
originally built for use with TypoScript and image manipulation such as masking,
combining text with images based mainly on the PHP extension GDLib.
Even though TYPO3 works best having both GDLib and ImageMagick installed and
properly configured, the inter-dependency within the TYPO3 Core API when to
use what class has always been unclear - mostly because this
functionality has not been cleaned up in the past 20 years.
For this reason, :php:`GifBuilder` now contains all functionality related to
GDLib, and all related methods from GraphicalFunctions have been removed.
:php:`GraphicalFunctions` thus is only contains ImageMagick/GraphicsMagick
functionality.
In addition, :php:`GifBuilder` and :php:`GraphicalFunctions` are now two separate classes
without inheritance, but utilizes the Composition pattern.
The following public methods from :php:`GraphicalFunctions` have been removed:
- :php:`\TYPO3\CMS\Core\Imaging\GraphicalFunctions->adjust()`
- :php:`\TYPO3\CMS\Core\Imaging\GraphicalFunctions->applyImageMagickToPHPGif()`
- :php:`\TYPO3\CMS\Core\Imaging\GraphicalFunctions->applyOffset()`
- :php:`\TYPO3\CMS\Core\Imaging\GraphicalFunctions->autolevels()`
- :php:`\TYPO3\CMS\Core\Imaging\GraphicalFunctions->convertColor()`
- :php:`\TYPO3\CMS\Core\Imaging\GraphicalFunctions->copyImageOntoImage()`
- :php:`\TYPO3\CMS\Core\Imaging\GraphicalFunctions->crop()`
- :php:`\TYPO3\CMS\Core\Imaging\GraphicalFunctions->destroy()`
- :php:`\TYPO3\CMS\Core\Imaging\GraphicalFunctions->getTemporaryImageWithText()`
- :php:`\TYPO3\CMS\Core\Imaging\GraphicalFunctions->hexColor()`
- :php:`\TYPO3\CMS\Core\Imaging\GraphicalFunctions->imageCreateFromFile()`
- :php:`\TYPO3\CMS\Core\Imaging\GraphicalFunctions->ImageTTFBBoxWrapper()`
- :php:`\TYPO3\CMS\Core\Imaging\GraphicalFunctions->ImageTTFTextWrapper()`
- :php:`\TYPO3\CMS\Core\Imaging\GraphicalFunctions->ImageWrite()`
- :php:`\TYPO3\CMS\Core\Imaging\GraphicalFunctions->inputLevels()`
- :php:`\TYPO3\CMS\Core\Imaging\GraphicalFunctions->makeBox()`
- :php:`\TYPO3\CMS\Core\Imaging\GraphicalFunctions->makeEffect()`
- :php:`\TYPO3\CMS\Core\Imaging\GraphicalFunctions->makeEllipse()`
- :php:`\TYPO3\CMS\Core\Imaging\GraphicalFunctions->makeEmboss()`
- :php:`\TYPO3\CMS\Core\Imaging\GraphicalFunctions->makeOutline()`
- :php:`\TYPO3\CMS\Core\Imaging\GraphicalFunctions->makeShadow()`
- :php:`\TYPO3\CMS\Core\Imaging\GraphicalFunctions->makeText()`
- :php:`\TYPO3\CMS\Core\Imaging\GraphicalFunctions->maskImageOntoImage()`
- :php:`\TYPO3\CMS\Core\Imaging\GraphicalFunctions->output()`
- :php:`\TYPO3\CMS\Core\Imaging\GraphicalFunctions->outputLevels()`
- :php:`\TYPO3\CMS\Core\Imaging\GraphicalFunctions->scale()`
- :php:`\TYPO3\CMS\Core\Imaging\GraphicalFunctions->splitString()`
- :php:`\TYPO3\CMS\Core\Imaging\GraphicalFunctions->unifyColors()`
- :php:`\TYPO3\CMS\Core\Imaging\GraphicalFunctions::readPngGif()`
The following public properties from :php:`GraphicalFunctions` have been removed:
- :php:`\TYPO3\CMS\Core\Imaging\GraphicalFunctions->colMap`
- :php:`\TYPO3\CMS\Core\Imaging\GraphicalFunctions->h`
- :php:`\TYPO3\CMS\Core\Imaging\GraphicalFunctions->map`
- :php:`\TYPO3\CMS\Core\Imaging\GraphicalFunctions->saveAlphaLayer`
- :php:`\TYPO3\CMS\Core\Imaging\GraphicalFunctions->setup`
- :php:`\TYPO3\CMS\Core\Imaging\GraphicalFunctions->truecolorColors`
- :php:`\TYPO3\CMS\Core\Imaging\GraphicalFunctions->w`
- :php:`\TYPO3\CMS\Core\Imaging\GraphicalFunctions->workArea`
The following public properties in :php:`GifBuilder` have been removed:
- :php:`\TYPO3\CMS\Frontend\Imaging\GifBuilder->charRangeMap`
- :php:`\TYPO3\CMS\Frontend\Imaging\GifBuilder->myClassName`
The following public properties in :php:`GifBuilder` are now marked as protected:
- :php:`\TYPO3\CMS\Frontend\Imaging\GifBuilder->charRangeMap`
- :php:`\TYPO3\CMS\Frontend\Imaging\GifBuilder->combinedFileNames`
- :php:`\TYPO3\CMS\Frontend\Imaging\GifBuilder->combinedTextStrings`
- :php:`\TYPO3\CMS\Frontend\Imaging\GifBuilder->data`
- :php:`\TYPO3\CMS\Frontend\Imaging\GifBuilder->defaultWorkArea`
- :php:`\TYPO3\CMS\Frontend\Imaging\GifBuilder->objBB`
- :php:`\TYPO3\CMS\Frontend\Imaging\GifBuilder->XY`
Impact
======
When using the classes directly in PHP code of extensions, calling any of the
methods or accessing / setting the affected properties will result in a PHP
error.
Affected installations
======================
TYPO3 installations with custom extensions utilizing the PHP API of these two
classes directly.
For any usages of these classes via TypoScript or the File Abstraction Layer API
will continue to work and are not affected by this breaking change.
Migration
=========
Use static analysis tools such as PHPStan or Psalm to detect if PHP code of
custom extensions is affected, and make use of :php:`GifBuilder` class instead of
:php:`GraphicalFunctions` when needing GDLib functionality.
.. index:: PHP-API, FullyScanned, ext:core
@@ -0,0 +1,63 @@
.. include:: /Includes.rst.txt
.. _breaking-102009-1695376655:
============================================
Breaking: #102009 - imagesizes cache removed
============================================
See :issue:`102009`
Description
===========
A cache layer called "imagesizes" was added in 2004 (= TYPO3 3.x) to cache
width and height of any kind of images - mostly generated by GifBuilder or
ImageMagick. It was using the PHP function :php:`getimagesizes()` or, if this
failed, ImageMagick identify command, which is costly.
In 2012, the new processing layer for File Abstraction Layer (FAL - via
:sql:`sys_file_processedfile`) was introduced with a more modern API, which persists
final information about processed images in a separate database table.
Any kind of information processing then is first checked in FAL and then stored
again in `cache_imagesizes`. Some more files, which do not use FAL still utilize
this functionality, but the second level cache layer (by default in the database),
is unneeded nowadays.
For this reason, the lowlevel cache "imagesizes" is removed along with some
methods which were not marked as internal, but marked public:
- :php:`\TYPO3\CMS\Core\Imaging\GraphicalFunctions->cacheImageDimensions()`
- :php:`\TYPO3\CMS\Core\Imaging\GraphicalFunctions->getCachedImageDimensions()`
The main entry point :php:`\TYPO3\CMS\Core\Imaging\GraphicalFunctions->getImageDimensions()`
is still available but does not use a cache layer anymore.
Impact
======
Calling the removed public methods will result in a fatal PHP error. In addition,
accessing the database table directly or via TYPO3's CacheManager is not possible
anymore, as the "imagesizes" cache is removed.
Affected installations
======================
TYPO3 installations which use the cache directly or access these methods
directly, which is very very unlikely.
Migration
=========
The now unused database tables are automatically removed when using the database
compare update is called. When trying to retrieve image dimensions,
the :php:`\TYPO3\CMS\Core\Type\File\Imageinfo` PHP class should be used instead in
favor of the main :php:`GraphicalFunctions` method.
The removed methods should be moved also towards the :php:`Imageinfo` PHP class.
.. index:: Database, PHP-API, PartiallyScanned, ext:core
@@ -0,0 +1,60 @@
.. include:: /Includes.rst.txt
.. _breaking-102020-1695429353:
==========================================================
Breaking: #102020 - Removed legacy setting 'GFX/gdlib_png'
==========================================================
See :issue:`102020`
Description
===========
`GFX/gdlib_png` is a setting that adjusted rendering of temporary images
used by GDLib to be PNG files instead of GIF files.
PNG files offer many benefits over GIF files, one of them being faster
processing times using Image/GraphicsMagick.
In line with this change, the property :php:`GraphicalFunctions::$gifExtension` has
been removed, as it mainly was used by this class and :php:`GifBuilder` to determine
if a temporary PNG or GIF image should be rendered.
`GFX/processor_colorspace` now defaults to an empty value and is migrated to one if
you use the recommended colorspace for the given processor (`sRGB` for ImageMagick,
`RGB` for GraphicsMagick). Image processing now will pick the recommended colorspace
unless you configure it to be another one.
Additionally, all GIF assets that are now not shown anymore due to those changes have been
removed as well:
* `EXT:core/Resources/Public/Images/NotFound.gif`
* `EXT:install/Resources/Public/Images/TestReference/Gdlib-*.gif`
Impact
======
Temporary layers/masks are now saved as PNG files instead of GIF files.
Affected installations
======================
Every instance that already didn't set `gdlib_png` to true. Output differences may
only occur on instances that use :typoscript:`GIFBUILDER` functionality (see Migration
section for more information).
Migration
=========
The configuration value has been removed without replacement. `GFX/processor_colorspace` is
automatically migrated to the recommended value for setups using the default configuration.
:php:`GraphicalFunctions::$gifExtension` has been removed without replacement. If this has been
used to determine what type of file should be rendered using :php:`GraphicalFunctions::imageMagickConvert`,
please specify the filetype manually now.
.. index:: LocalConfiguration, NotScanned, ext:core
@@ -0,0 +1,43 @@
.. include:: /Includes.rst.txt
.. _breaking-102023-1695557477:
=====================================================================
Breaking: #102023 - Remove security.usePasswordPolicyForFrontendUsers
=====================================================================
See :issue:`102023`
Description
===========
The feature toggle :php:`security.usePasswordPolicyForFrontendUsers` has been
removed, because TypoScript-based password validation in ext:felogin has been
removed, too.
Impact
======
The password policy configured in
:php:`$GLOBALS['TYPO3_CONF_VARS']['FE']['passwordPolicy']` is now always active
for frontend user records in DataHandler and for the password recovery
functionality in ext:felogin.
Affected installations
======================
Installations, where :php:`security.usePasswordPolicyForFrontendUsers` is
deactivated.
Migration
=========
To disable the password policy for frontend users,
:php:`$GLOBALS['TYPO3_CONF_VARS']['FE']['passwordPolicy']` must be set to an
empty string. Note, that it is not recommended to disable the password policy
on production websites.
.. index:: Backend, Frontend, NotScanned, ext:felogin
@@ -0,0 +1,52 @@
.. include:: /Includes.rst.txt
.. _breaking-102108-1696618684:
=====================================================
Breaking: #102108 - TCA `[types][bitmask_*]` settings
=====================================================
See :issue:`102108`
Description
===========
Handling of two settings has been removed from the
TYPO3 Core codebase:
* :php:`$GLOBALS['TCA']['someTable']['types']['bitmask_excludelist_bits']`
* :php:`$GLOBALS['TCA']['someTable']['types']['bitmask_value_field']`
Impact
======
These two fields allowed to set record "sub types" based on a record
bitmask field, typically :php:`'type' => 'check'` or :php:`'type' => 'radio'`.
This has been removed, the settings are not considered anymore when
rendering records in the backend record editing interface.
Affected installations
======================
Both settings have been used very rarely: Neither Core nor published TER extensions
revealed a single usage. The extension scanner will find affected extensions.
Migration
=========
In case extensions still use these two rather obscure settings, they should
switch to casual :php:`$GLOBALS['TCA']['someTable']['ctrl']['type']` fields instead,
which can be powered by columns based on string values.
Note the overall "subtype" record logic of TCA is within an ongoing process to
be removed in TYPO3 v13, so the basic thinking should be: There is a record, and its
details can be configured using :php:`$GLOBALS['TCA']['someTable']['ctrl']['type']`,
and that's it. Extensions using "sub types" or this bitmask detail need to simplify
and eventually deliver according upgrade wizards to adapt existing records.
.. index:: TCA, FullyScanned, ext:backend
@@ -0,0 +1,38 @@
.. include:: /Includes.rst.txt
.. _breaking-102113-1696697947:
======================================================
Breaking: #102113 - Removed legacy setting 'GFX/gdlib'
======================================================
See :issue:`102113`
Description
===========
'GFX/gdlib' is a setting that enables or disables image manipulation
using GDLib, functionality used in :typoscript:`GIFBUILDER`, depending if
the host system did not provide GDLib functionality.
With this change, the configuration value 'GFX/gdlib' has been removed, and
TYPO3 will simply check for the :php:`GdImage` PHP class being available to
determine if it can be used.
Impact
======
TYPO3 now always enables GDLib functionality as soon as relevant GDLib classes
are found.
Migration
=========
The configuration value has been removed without replacement.
Custom code that relied on :php:`$GLOBALS['TYPO3_CONF_VARS']['GFX']['gdlib']`
should instead adopt the simpler check
:php:`if (class_exists(\GdImage::class))`.
.. index:: LocalConfiguration, FullyScanned, ext:core
@@ -0,0 +1,45 @@
.. include:: /Includes.rst.txt
.. _breaking-102146-1697045119:
==================================================================
Breaking: #102146 - Removed legacy setting 'BE/flexformForceCDATA'
==================================================================
See :issue:`102146`
Description
===========
The TYPO3 configuration option :php:`$GLOBALS['TYPO3_CONF_VARS']['BE']['flexformForceCDATA']`
has been removed without substitution.
This setting was an ancient workaround for an issue in libxml in old PHP versions that has
been resolved long ago.
This was the last usage of :php:`useCDATA` option in FlexForm-related XML methods in
the Core, so that option is removed along the way. Values of XML data should still be
encoded properly when dealing with related methods like :php:`GeneralUtility::array2xml()`.
Impact
======
There should be no impact on casual instances, except if single extensions tamper with
the :php:`useCDATA` options when dealing with XML data.
Affected installations
======================
Instances with extensions that explicitly call XML-related transformations methods
provided by the Core that tamper with :php:`useCDATA` may need a look. Chances are
everything is ok, though.
Migration
=========
No direct migration possible.
.. index:: LocalConfiguration, PartiallyScanned, ext:core
@@ -0,0 +1,43 @@
.. include:: /Includes.rst.txt
.. _breaking-102151-1697111006:
================================================================
Breaking: #102151 - XML prologue always added in flexArray2Xml()
================================================================
See :issue:`102151`
Description
===========
The second argument :php:`$addPrologue = false` on
:php:`\TYPO3\CMS\Core\Configuration\FlexForm\FlexFormTools->flexArray2Xml()`
has been dropped: When imploding a FlexForm array to an XML string using
this method, the "XML prologue" is always added.
Impact
======
This should have no impact for consumers of this method. The counterpart method
:php:`\TYPO3\CMS\Core\Utility\GeneralUtility::xml2array()` happily deals with this.
Affected installations
======================
Instances with extensions using :php:`FlexFormTools->flexArray2Xml()` can drop
the second argument. The extension scanner will find usages with a weak match.
Since this is a detail method of the TYPO3 Core FlexForm handling, not often
handled by extensions themselves, few instances will be affected in the first place.
Migration
=========
No data migration needed, PHP consumers should drop the second argument
when calling the method.
.. index:: FlexForm, PHP-API, FullyScanned, ext:core
@@ -0,0 +1,66 @@
.. include:: /Includes.rst.txt
.. _breaking-102165-1698700428:
=================================================================================
Breaking: #102165 - File Abstraction Layer: Processing APIs and interface changed
=================================================================================
See :issue:`102165`
Description
===========
The Task API for processing files (mainly images) in the File Abstraction Layer
(FAL) has been reworked. This mainly accommodates to the fact, that the API was
revisited, the functionality has been updated to be up-to-date with PHP
standards and further adaptions.
The PHP interface :php:`\TYPO3\CMS\Core\Resource\Processing\TaskInterface` has
lost the :php:`__construct()` method as part of the interface, as the
constructor is an implementation detail and should not be part of an interface
definition. In addition, the method :php:`sanitizeConfiguration()` has been added
to clean and sort the properties required for a task. All other methods have
been fully typed.
The PHP class :php:`\TYPO3\CMS\Core\Resource\Processing\AbstractGraphicalTask`
has been removed in order to reduce complexity, as all of the methods have
been moved into the respective subclasses.
The PHP class :php:`\TYPO3\CMS\Core\Resource\Processing\Task` now has two
abstract methods :php:`getName()` and :php:`getType()` in favor of the protected
properties :php:`$name` and :php:`$type`.
The PHP class :php:`\TYPO3\CMS\Core\Resource\ProcessedFile` is now fully typed.
Impact
======
Custom FAL processing tasks will result in a fatal error if not adapted to the
new interface.
If an extension was depending on :php:`AbstractGraphicalTask`, calling this
code will now result in a PHP fatal error.
Affected installations
======================
TYPO3 installations working with the internals of the processing part of the
File Abstraction Layer, e.g. when extensions add custom FAL processors or
custom tasks.
Migration
=========
Implementing a custom FAL processing task will require the extension author to
adapt to the new interface requirements.
When a custom task was built on top of the :php:`AbstractGraphicalTask`, this
now needs to be removed and be compliant with the :php:`TaskInterface`, optionally
inheriting from the :php:`AbstractTask` class. This can already be achieved for
TYPO3 v12 to make an implementation compatible with TYPO3 v12 and TYPO3 v13.
.. index:: FAL, PHP-API, PartiallyScanned, ext:core
@@ -0,0 +1,52 @@
.. include:: /Includes.rst.txt
.. _breaking-102181-1697467272:
===========================================================================
Breaking: #102181 - Removed CLI options using `bin/typo3 cleanup:flexforms`
===========================================================================
See :issue:`102181`
Description
===========
The CLI command :bash:`bin/typo3 cleanup:flexforms` of extension :php:`lowlevel`
can be used to clean up database record :php:`type="flex"` fields that contain values
not reflected in the current FlexForm data structure anymore.
The command has been changed slightly: The CLI options :bash:`-p` / :bash:`--pid`
and :bash:`-d` / :bash:`--depth` have been removed.
The "dry run" CLI option :bash:`--dry-run` is kept.
The command implementation has been rewritten in TYPO3 v13 and is some orders
of magnitudes quicker than before: While the command could easily run hours for
a seasoned instance, it is now usually a matter of seconds. The "pid" and
"depth" options were a hindrance to this drastic performance improvement and
have been removed.
Impact
======
The command exits with an error when called with one of :bash:`-p`, :bash:`--pid`,
:bash:`-d` or :bash:`--depth` option. It is no longer possible to restrict the
command to single page tree sections, the command always checks all (not soft-deleted)
records.
Affected installations
======================
The command is not very well known and - if ever - often only used when deploying
major upgrades of TYPO3 instances. Instances using one of the above options should
remove them from their deployment scripts, and enjoy the massive speed improvement.
Migration
=========
No migration, remove the above mentioned options.
.. index:: CLI, FlexForm, NotScanned, ext:lowlevel
@@ -0,0 +1,73 @@
.. include:: /Includes.rst.txt
.. _breaking-102224-1697983588:
======================================================================
Breaking: #102224 - TemplaVoila related FlexForm dataStructure lookups
======================================================================
See :issue:`102224`
Description
===========
The following TCA config options for :php:`'type' = 'flex'` column fields are
not handled anymore:
* :php:`['config']['ds_pointerField_searchParent']`
* :php:`['config']['ds_pointerField_searchParent_subField']`
* :php:`['config']['ds_tableField']`
The following related exception classes have been removed and are no longer thrown:
* :php:`\TYPO3\CMS\Core\Configuration\FlexForm\Exception\InvalidParentRowException`
* :php:`\TYPO3\CMS\Core\Configuration\FlexForm\Exception\InvalidParentRowLoopException`
* :php:`\TYPO3\CMS\Core\Configuration\FlexForm\Exception\InvalidParentRowRootException`
* :php:`\TYPO3\CMS\Core\Configuration\FlexForm\Exception\InvalidPointerFieldValueException`
Impact
======
When dealing with TCA type :php:`flex` fields, there needs to be a "data structure" that
defines which fields are rendered when editing the record. The default is looking up
the data structure using the :php:`['ds']['default']` value.
Multiple different data structures can be defined, so there is a strategy to find the
data structure relevant for current record. For table :sql:`tt_content`, this is
defined using :php:`ds_pointerField`, which determines the specific data structure based
on the combination of the fields :sql:`CType` and :sql:`list_type`.
There have been more sophisticated lookup mechanisms based on the TCA config options
:php:`ds_pointerField_searchParent`, :php:`ds_pointerField_searchParent_subField`
and :php:`ds_tableField`. Those lookup mechanisms have been removed with TYPO3 v13.
Affected installations
======================
Instances with extensions having :php:`flex` fields using one of the TCA options
:php:`ds_pointerField_searchParent`, :php:`ds_pointerField_searchParent_subField`
or :php:`ds_tableField` will fail to retrieve their data structure. Most likely,
an exception will be thrown when editing such records.
Those three fields have been implemented long ago for heavily flex form driven
instances based on "TemplaVoila" (TV). This detail never found broader acceptance in
not-TV driven instances.
Instances not driven by one of the TemplaVoila forks are most likely not affected
by this change. Instances actively using TemplaVoila forks may be affected, but
those forks seem to implement the data structure lookup on their own already,
affected instances should wait for their templavoila maintainers to catch up.
Migration
=========
There are appropriate events that allow manipulating the data structure
lookup logic in class :php:`\TYPO3\CMS\Core\Configuration\FlexForm\FlexFormTools`.
Those can be used to re-implement the logic that has been removed from TYPO3
Core if needed.
.. index:: FlexForm, PHP-API, TCA, PartiallyScanned, ext:core
@@ -0,0 +1,80 @@
.. include:: /Includes.rst.txt
.. _breaking-102229-1698053674:
====================================================================
Breaking: #102229 - Removed FlexFormTools->traverseFlexFormXMLData()
====================================================================
See :issue:`102229`
Description
===========
Class :php:`\TYPO3\CMS\Core\Configuration\FlexForm\FlexFormTools` got a series
of cleanup and removal patches.
The following public class properties have been removed:
* :php:`$reNumberIndexesOfSectionData`
* :php:`$flexArray2Xml_options`
* :php:`$callBackObj`
* :php:`$cleanFlexFormXML`
The following public methods have been removed:
* :php:`traverseFlexFormXMLData()`
* :php:`traverseFlexFormXMLData_recurse()`
* :php:`cleanFlexFormXML_callBackFunction()`
The following public methods have been marked `@internal`:
* :php:`cleanFlexFormXML()`
* :php:`flexArray2Xml()`
* :php:`migrateFlexFormTcaRecursive()`
The class is now a stateless service and can be injected as shared service
without any risk of triggering side effects.
Impact
======
In general, these changes should have relatively low impact on extensions, if they
don't build additional low level functionality on top of the general TYPO3 Core
FlexForm related features. Extensions like the TemplaVoila forks may need to have
a look for required adaptions, though.
Using the removed methods or properties in TYPO3 v13 will of course trigger PHP
fatal errors.
Affected installations
======================
Instances that extend functionality of FlexForm handling may be affected if they
use methods of class :php:`FlexFormTools`. This is a relatively rare case, most
instances will not be affected when they just provide and use casual FlexForm
definitions in extensions.
The extension scanner will find possible extensions that consume the methods or
properties as a weak match.
Migration
=========
If at all, method :php:`traverseFlexFormXMLData()` is probably the one used in
extensions. The easiest way is to copy the method and it's recursive worker method
to an own class.
Extension developers are however encouraged to refactor their code since
:php:`traverseFlexFormXMLData()` with its callback logic was ugly, hard to follow
and maintain. The Core switched away from the method by implementing own traversers
that match the specific use cases. Method :php:`cleanFlexFormXML()` is an
example of such an implementation. Note FlexForms are *not* recursive since
section containers can not be nested since TYPO3 v8 anymore. The Core thus
uses some nested foreach loops instead of a recursive approach.
.. index:: FlexForm, PHP-API, FullyScanned, ext:core
@@ -0,0 +1,46 @@
.. include:: /Includes.rst.txt
.. _breaking-102260-1698252706:
======================================================
Breaking: #102260 - Removed TCA ['softref'] = 'notify'
======================================================
See :issue:`102260`
Description
===========
:php:`TCA` columns type fields like :php:`input` and :php:`text` obey the :php:`config` key
:php:`softref`. One of the allowed soft reference parsers is :php:`notify` implemented
by class :php:`\TYPO3\CMS\Core\DataHandling\SoftReference\NotifySoftReferenceParser`.
This soft reference parser fits no apparent use case and has been removed.
Impact
======
Involving the :php:`notify` key in the comma-separated list of TCA columns config
:php:`softref` or a flex form data structure column definition does not trigger
any action anymore and may log a warning this parser hasn't been found.
Affected installations
======================
There was little reason to activate this soft reference parser in the first place
since it essentially did nothing. Instances with extensions having TCA column config
:php:`softref` set to a value including :php:`notify` will be affected. That's a very
rare use case. The extension scanner will not notify about this, but the
:php:`SoftReferenceParserFactory` will add a log entry this parser was not found upon
using an affected record.
Migration
=========
Remove key :php:`notify` from TCA columns :php:`softref` list.
.. index:: TCA, NotScanned, ext:core
@@ -0,0 +1,59 @@
.. include:: /Includes.rst.txt
.. _breaking-102440-1700638677:
========================================================
Breaking: #102440 - EXT:t3editor merged into EXT:backend
========================================================
See :issue:`102440`
Description
===========
TYPO3 comes with a code editor extension called "t3editor" for a long time.
Since then, the extension was always optional. When the extension is installed,
selected text areas are converted to code editors based on CodeMirror.
The optional extension has been merged into `EXT:backend`, making the code
editor always available.
Impact
======
An integrator cannot optionally install the code editor anymore as it's part of
the mandatory "backend" extension now.
By default, this affects the following occurrences:
* TCA: `be_groups.TSconfig`
* TCA: `be_users.TSconfig`
* TCA: `pages.TSconfig`
* TCA: `sys_template.constants`
* TCA: `sys_template.config`
* TCA: `tt_content.bodytext`, if the content element is of type "HTML"
* EXT:filelist: edit file content
* Composer status view in Extension Manager
Also, checks whether the extension is installed via
:php:`\TYPO3\CMS\Core\Utility\ExtensionManagementUtility::isLoaded('t3editor')`
are now obsolete.
Affected installations
======================
All installations are affected.
Migration
=========
Extension checks using :php:`\TYPO3\CMS\Core\Utility\ExtensionManagementUtility::isLoaded('t3editor')`
don't have an effect anymore and must get removed.
In addition, please see :ref:`deprecation-102440-1700638677`.
.. index:: Backend, JavaScript, PHP-API, NotScanned, ext:t3editor
@@ -0,0 +1,73 @@
.. include:: /Includes.rst.txt
.. _breaking-102499-1700813634:
======================================================================
Breaking: #102499 - User TSconfig setting "overridePageModule" removed
======================================================================
See :issue:`102499`
Description
===========
The user TSconfig setting :typoscript:`options.overridePageModule` has been
removed.
This option allowed to change links within some modules to be redirected to an
alternative page module, mainly introduced in TYPO3 4.x to allow to link to
the TemplaVoila page module.
However, as this has never been applied consistently across all modules
provided by TYPO3 Core, it has been removed. The only few places within TYPO3
Core where this option was still evaluated was within the Workspaces
Administration and the Info module.
The alternative, using a different routing endpoint and support for module
aliases via the introduced Module API in TYPO3 v12, is much more robust and
consistent.
Impact
======
Setting the user TSconfig option :typoscript:`options.overridePageModule` has
no effect anymore.
Affected installations
======================
TYPO3 installations using this setting in user TSconfig, mainly when used in
conjunction with TemplaVoila and having mixed installations where both
TemplaVoila page module and the default Page module are used for different
editors.
Migration
=========
In order to replace the Page module within a third-party extension such as
TemplaVoila, it is possible to create a custom module entry in an
extensions' :file:`Configuration/Backend/Modules.php` with the following entry:
.. code-block:: php
return [
'my_module' => [
'parent' => 'web',
'position' => ['before' => '*'],
'access' => 'user',
'aliases' => ['web_layout'],
'path' => '/module/my_module',
'iconIdentifier' => 'module-page',
'labels' => 'LLL:EXT:backend/Resources/Private/Language/locallang_mod.xlf',
'routes' => [
'_default' => [
'target' => \MyVendor\MyPackage\Controller\MyController::class . '::mainAction',
],
],
],
];
.. index:: Backend, TSConfig, NotScanned, ext:backend
@@ -0,0 +1,39 @@
.. include:: /Includes.rst.txt
.. _breaking-102518-1701035329:
========================================================
Breaking: #102518 - Database engine version requirements
========================================================
See :issue:`102518` and :issue:`102594`
Description
===========
TYPO3 v13 supports these database products and versions:
* MySQL 8.0.17 or higher
* MariaDB 10.4.3 or higher
* PostgresSQL 10.0 or higher
* SQLite 3.8.3 or higher
Impact
======
Environments with older MariaDB or MySQL database engines will report an unsupported
database version and stop working properly with the upcoming Doctrine DBAL v4 upgrade.
Affected installations
======================
Hosting a TYPO3 instance based on version 13 may require an update of the MariaDB or
MySQL database engine.
Migration
=========
TYPO3 v12 supports MariaDB 10.4.3 or MySQL 8.0.17 and higher database engines required by v13.
This allows upgrading the platform in a first step and upgrading to TYPO3 v13 in a second step.
.. index:: Database, PHP-API, NotScanned, ext:core
@@ -0,0 +1,41 @@
.. include:: /Includes.rst.txt
.. _breaking-102581-1701449553:
=======================================================================
Breaking: #102581 - Removed hook for manipulating ContentObjectRenderer
=======================================================================
See :issue:`102581`
Description
===========
The hook :php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['tslib/class.tslib_content.php']['postInit']`
has been removed in favor of the new PSR-14 event
:php:`\TYPO3\CMS\Frontend\ContentObject\Event\AfterContentObjectRendererInitializedEvent`.
Impact
======
Any hook implementation registered is not executed anymore
in TYPO3 v13+.
Affected installations
======================
TYPO3 installations with custom extensions using this hook.
Migration
=========
The hook is removed without deprecation in order to allow extensions
to work with TYPO3 v12 (using the hook) and v13+ (using the new event)
when implementing the event as well without any further deprecations.
Use the :doc:`PSR-14 event <../13.0/Feature-102581-PSR-14EventForModifyingContentObjectRenderer>`
to allow greater influence in the functionality.
.. index:: Frontend, PHP-API, FullyScanned, ext:frontend
@@ -0,0 +1,47 @@
.. include:: /Includes.rst.txt
.. _breaking-102583-1701510037:
=====================================================
Breaking: #102583 - Removed context aspect typoscript
=====================================================
See :issue:`102583`
Description
===========
The :php:`\TYPO3\CMS\Core\Context\Context` aspect :php:`typoscript` has been
removed without direct substitution. This aspect was implemented by now removed
class :php:`\TYPO3\CMS\Core\Context\TypoScriptAspect`, handling the
EXT:adminpanel-related property :php:`forcedTemplateParsing`.
Impact
======
The following calls will throw PHP exceptions:
.. code-block:: php
/** @var \TYPO3\CMS\Core\Context\Context $context */
$context->getPropertyFromAspect('typoscript', 'forcedTemplateParsing');
$context->getAspect('typoscript');
// Returns false
$context->hasAspect('typoscript');
Affected installations
======================
Extensions typically do not use this context aspect since it only carried an
EXT:adminpanel-related information.
Migration
=========
No direct migration possible. There should be little reason for extensions to
work with this EXT:adminpanel related detail.
.. index:: Frontend, PHP-API, PartiallyScanned, ext:core
@@ -0,0 +1,38 @@
.. include:: /Includes.rst.txt
.. _breaking-102590-1701598566:
==============================================================
Breaking: #102590 - TSFE->generatePage_preProcessing() removed
==============================================================
See :issue:`102590`
Description
===========
Frontend-related method :php:`TypoScriptFrontendController->generatePage_preProcessing()`
has been removed without substitution.
Impact
======
Calling the methods will raise a fatal PHP error.
Affected installations
======================
There is little to no need for extensions to call or override this method and it
should have been marked as :php:`@internal` already. It was part of a removed
"safety net" when extensions did set :php:`TypoScriptFrontendController->no_cache`
to :php:`false` after it has been set to :php:`true` already, which is not allowed.
Migration
=========
No migration, do not call the method anymore.
.. index:: Frontend, PHP-API, FullyScanned, ext:frontend
@@ -0,0 +1,62 @@
.. include:: /Includes.rst.txt
.. _breaking-102600-1701707508:
=================================================
Breaking: #102600 - TSFE->applicationData removed
=================================================
See :issue:`102600`
Description
===========
Frontend-related property :php:`TypoScriptFrontendController->applicationData`
has been removed without substitution.
This property has been used by a few rather old-school extensions to park and
communicate state using this global "extension-specific state array".
When looking at the TYPO3 frontend rendering chain, class :php:`TypoScriptFrontendController`
is by far the biggest technical debt: It mixes a lot of concerns and carries tons of state
and functionality that should be modeled differently, which leads to easier to understand
and more flexible code. The class is shrinking since various major versions already and will
ultimately dissolve entirely at some point. Changes in this area are becoming more aggressive
with TYPO3 v13. Any code using the class will need adaptions at some point, single patches
will continue to communicate alternatives.
In case of the :php:`applicationData` property, this is simply a misuse of the
class instance to park arbitrary state in a global object. This is why it needs to
fall and why there is no direct substitution.
Impact
======
Using :php:`TypoScriptFrontendController->applicationData` (or
:php:`$GLOBALS['TSFE']->applicationData`) will raise a PHP fatal error.
Affected installations
======================
Instances with extensions that use :php:`applicationData` to store and communicate
state.
Migration
=========
There are various solutions to communicate state to avoid :php:`applicationData`:
In some cases, an extension could establish a frontend middleware and attach a
request attribute that carries the state.
In other cases an event could be fired to gather information from other extensions.
One example is the indexed_search extension which dispatches the new event
:php:`EnableIndexingEvent` to get know if indexing should be performed. The
third-party crawler extension should use this instead of setting that information
on :php:`$GLOBALS['TSFE']`.
.. index:: Frontend, PHP-API, FullyScanned, ext:frontend
@@ -0,0 +1,85 @@
.. include:: /Includes.rst.txt
.. _breaking-102605-1701772495:
=========================================
Breaking: #102605 - TSFE->fe_user removed
=========================================
See :issue:`102605`
Description
===========
Frontend-related property :php:`TypoScriptFrontendController->fe_user` has been removed.
When looking at the TYPO3 frontend rendering chain, class :php:`TypoScriptFrontendController`
is by far the biggest technical debt: It mixes a lot of concerns and carries tons of state
and functionality that should be modeled differently, which leads to easier to understand
and more flexible code. The class is shrinking since various major versions already and will
ultimately dissolve entirely at some point. Changes in this area are becoming more aggressive
with TYPO3 v13. Any code using the class will need adaptions at some point, single patches
will continue to communicate alternatives.
In case of the :php:`fe_user` property, two alternatives exist: The frontend user
can be retrieved from the PSR-7 request attribute :php:`frontend.user`, and basic frontend user
information is available using the :php:`Context` aspect :php:`frontend.user`.
Note accessing TypoScript :typoscript:`TSFE:fe_user` details continues to work for now, using
for example :typoscript:`lib.foo.data = TSFE:fe_user|user|username` to retrieve the username of a
logged in user is still ok.
Impact
======
Using :php:`TypoScriptFrontendController->fe_user` (or
:php:`$GLOBALS['TSFE']->fe_user`) will raise a PHP fatal error.
Affected installations
======================
Instances with extensions dealing with frontend user details may be affected, typically
custom login extensions or extensions consuming detail data of logged in users.
Migration
=========
There are two possible migrations.
First, a limited information list of frontend user details can be retrieved using the :php:`Context`
aspect :php:`frontend.user` in frontend calls. See class :php:`\TYPO3\CMS\Core\Context\UserAspect` for a
full list. The current context can retrieved using dependency injection. Example:
.. code-block:: php
use TYPO3\CMS\Core\Context\Context;
final class MyExtensionController {
public function __construct(
private readonly Context $context,
) {}
public function myAction() {
$frontendUserUsername = $this->context->getPropertyFromAspect('frontend.user', 'username', ''));
}
}
Additionally, the full :php:`\TYPO3\CMS\Frontend\Authentication\FrontendUserAuthentication` object is
available as request attribute :php:`frontend.user` in the frontend. Note some details of that object
are marked :php:`@internal`, using the context aspect is thus the preferred way. Example of an extension
using Extbase's :php:`ActionController`:
.. code-block:: php
final class MyExtensionController extends ActionController {
public function myAction() {
// Note the 'user' property is marked @internal.
$frontendUserUsername = $this->request->getAttribute('frontend.user')->user['username'];
}
}
.. index:: Frontend, PHP-API, FullyScanned, ext:frontend
@@ -0,0 +1,49 @@
.. include:: /Includes.rst.txt
.. _breaking-102614-1701869646:
================================================================
Breaking: #102614 - Removed Hook for manipulating GetData result
================================================================
See :issue:`102614`
Description
===========
The hook :php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['tslib/class.tslib_content.php']['getData']`
has been removed in favor of the new PSR-14 event
:php:`\TYPO3\CMS\Frontend\ContentObject\Event\AfterGetDataResolvedEvent`.
Impact
======
Any hook implementation registered is not executed anymore
in TYPO3 v13.0+.
Affected installations
======================
TYPO3 installations with custom extensions using this hook.
Migration
=========
The hook is removed without deprecation in order to allow extensions
to work with TYPO3 v12 (using the hook) and v13+ (using the new event)
when implementing the event as well without any further deprecations.
Use the :doc:`PSR-14 event <../13.0/Feature-102614-PSR-14EventForModifyingGetDataResult>`
to allow greater influence in the functionality.
.. note::
The new event is no longer executed for every "section" of the provided
parameter string, but only once, before the final result of :php:`getData()`
is about to be returned. This therefore means, the former :php:`$secVal`
is no longer available in the new event. Please adjust your implementation
accordingly.
.. index:: Frontend, PHP-API, FullyScanned, ext:frontend
@@ -0,0 +1,131 @@
.. include:: /Includes.rst.txt
.. _breaking-102621-1701937690:
==================================================================
Breaking: #102621 - Most TSFE members marked internal or read-only
==================================================================
See :issue:`102621`
Description
===========
Most properties and methods of class :php:`TypoScriptFrontendController` have
been marked :php:`@internal` or "read-only".
:php:`TypoScriptFrontendController` ("TSFE") is a god object within the TYPO3 frontend
rendering chain: It is used by multiple middlewares that call TSFE methods to create
state in it, it is used within :php:`ContentObjectRenderer` and various other
classes to update and retrieve state. It is also registered as :php:`$GLOBALS['TSFE']`
at some point and thus available as global state object.
This makes the class the biggest anti-pattern we have within the frontend - class
:php:`ContentObjectRenderer` is problematic as well, but that is a different story.
The current role of :php:`TypoScriptFrontendController` leads to very complex and
opaque state handling within the frontend rendering, is the true source of many
hard to fix issues and prevents Core development from implementing cool new features.
The TYPO3 Core strives to resolve large parts of this with TYPO3 v13: State needed
by lower level code is being modeled as request attributes or handled locally in
middlewares, methods are moved out of the class into middlewares to improve
encapsulation and code flow.
To do that within continued TYPO3 v13 development, the Core needs to mark various
methods and properties :php:`@internal`, and needs to mark more strict access patterns
on others.
The solution is to look at public properties of :php:`TypoScriptFrontendController`,
and to declare those as :php:`@internal`, which extensions typically should not need to
deal with at all. Others (like for instance :php:`id`) are actively used by extensions and
will be substituted by something different later, and are thus marked as "allowed to read,
but never write" for extensions. This allows implementation of a deprecation layer for those
"read-only" properties later, while those marked :php:`@internal` can vanish without
further notice. A similar strategy is added for methods, leaving only a few not
marked :php:`@internal`, which the Core will deprecate with a compatibility layer later.
The following public class properties have been marked "read-only", and have later been
deprecated with the full deprecation of :php:`TypoScriptFrontendController` in
TYPO3 v13.4, see :ref:`deprecation-105230-1728374467`.
* :php:`TypoScriptFrontendController->id` - Use :php:`$request->getAttribute('frontend.page.information')->getId()` instead
* :php:`TypoScriptFrontendController->rootLine` - Use :php:`$request->getAttribute('frontend.page.information')->getRootLine()` instead
* :php:`TypoScriptFrontendController->page` - Use :php:`$request->getAttribute('frontend.page.information')->getPageRecord()` instead
* :php:`TypoScriptFrontendController->contentPid` - Avoid usages altogether, available as :php:`@internal` call using
:php:`$request->getAttribute('frontend.page.information')->getContentFromPid()`
* :php:`TypoScriptFrontendController->sys_page` - Avoid altogether, create own instance using :php:`GeneralUtility::makeInstance(PageRepository::class)`
* :php:`TypoScriptFrontendController->config['config']` - Use :php:`$request->getAttribute('frontend.typoscript')->getConfigArray()` instead`
* :php:`TypoScriptFrontendController->config['rootLine']` - Use :php:`$request->getAttribute('frontend.page.information')->getLocalRootLine()` instead
* :php:`TypoScriptFrontendController->cObj` - Create an own :php:`ContentObjectRenderer` instance, call :php:`setRequest($request)`
and :php:`start($request->getAttribute('frontend.page.information')->getPageRecord(), 'pages')`
The following public class properties have been marked :php:`@internal` - in general
all properties not listed above. They contain information usually not relevant within
extensions. The TYPO3 core will model them differently.
* :php:`TypoScriptFrontendController->absRefPrefix`
* :php:`TypoScriptFrontendController->no_cache` - Use request attribute :php:`frontend.cache.instruction` instead
* :php:`TypoScriptFrontendController->additionalHeaderData`
* :php:`TypoScriptFrontendController->additionalFooterData`
* :php:`TypoScriptFrontendController->register`
* :php:`TypoScriptFrontendController->registerStack`
* :php:`TypoScriptFrontendController->recordRegister`
* :php:`TypoScriptFrontendController->currentRecord`
* :php:`TypoScriptFrontendController->content`
* :php:`TypoScriptFrontendController->lastImgResourceInfo`
The following methods have been marked :php:`@internal` and may vanish anytime:
* :php:`TypoScriptFrontendController->__construct()` - extensions should not create own instances of TSFE
* :php:`TypoScriptFrontendController->determineId()`
* :php:`TypoScriptFrontendController->getPageAccessFailureReasons()`
* :php:`TypoScriptFrontendController->calculateLinkVars()`
* :php:`TypoScriptFrontendController->isGeneratePage()`
* :php:`TypoScriptFrontendController->preparePageContentGeneration()`
* :php:`TypoScriptFrontendController->generatePage_postProcessing()`
* :php:`TypoScriptFrontendController->generatePageTitle()`
* :php:`TypoScriptFrontendController->INTincScript()`
* :php:`TypoScriptFrontendController->INTincScript_loadJSCode()`
* :php:`TypoScriptFrontendController->isINTincScript()`
* :php:`TypoScriptFrontendController->applyHttpHeadersToResponse()`
* :php:`TypoScriptFrontendController->isStaticCacheble()`
* :php:`TypoScriptFrontendController->newCObj()`
* :php:`TypoScriptFrontendController->logDeprecatedTyposcript()`
* :php:`TypoScriptFrontendController->uniqueHash()`
* :php:`TypoScriptFrontendController->set_cache_timeout_default()`
* :php:`TypoScriptFrontendController->set_no_cache()` - Use :php:`$request->getAttribute('frontend.cache.instruction')->disableCache()` instead
* :php:`TypoScriptFrontendController->sL()` - Use :php:`GeneralUtility::makeInstance(LanguageServiceFactory::class)->createFromSiteLanguage($request->getAttribute('language'))->sL()` instead
* :php:`TypoScriptFrontendController->get_cache_timeout()`
* :php:`TypoScriptFrontendController->getRequestedId()` - Use :php:`$request->getAttribute('routing')->getPageId()` instead
* :php:`TypoScriptFrontendController->getLanguage()` - Use :php:`$request->getAttribute('language') ?? $request->getAttribute('site')->getDefaultLanguage()` instead
* :php:`TypoScriptFrontendController->getSite()` - Use :php:`$request->getAttribute('site')` instead
* :php:`TypoScriptFrontendController->getContext()` - Use dependency injection or :php:`GeneralUtility::makeInstance()` instead
* :php:`TypoScriptFrontendController->getPageArguments()` - Use :php:`$request->getAttribute('routing')` instead
Impact
======
Writing to the listed read-only properties may break the frontend rendering,
using the properties or methods marked as :php:`@internal` may raise fatal PHP errors.
Affected installations
======================
The majority of extensions should already use the above properties that are marked read-only
for reading only: Updating their state can easily lead to unexpected behavior. Most
extensions also don't consume the properties or methods marked as :php:`@internal`.
Extension developers should watch out for usages of :php:`TypoScriptFrontendController` in
general and reduce usages as much as possible.
Migration
=========
The migration strategy depends on the specific use case. The frontend rendering chain
continues to add state that is needed by extensions as PSR-7 request attributes. Debugging
the incoming request within an extension often reveals a proper alternative.
.. index:: Frontend, PHP-API, PartiallyScanned, ext:frontend
@@ -0,0 +1,41 @@
.. include:: /Includes.rst.txt
.. _breaking-102624-1701943942:
======================================================================
Breaking: #102624 - PSR-14 Event for modifying image source collection
======================================================================
See :issue:`102624`
Description
===========
The hook :php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['tslib/class.tslib_content.php']['getImageSourceCollection']`
has been removed in favor of the new PSR-14 event
:php:`\TYPO3\CMS\Frontend\ContentObject\Event\ModifyImageSourceCollectionEvent`.
Impact
======
Any hook implementation registered is not executed anymore
in TYPO3 v13.0+.
Affected installations
======================
TYPO3 installations with custom extensions using this hook.
Migration
=========
The hook is removed without deprecation in order to allow extensions
to work with TYPO3 v12 (using the hook) and v13+ (using the new event)
when implementing the event as well without any further deprecations.
Use the :doc:`PSR-14 event <../13.0/Feature-102624-PSR-14EventForModifyingImageSourceCollection>`
to allow greater influence in the functionality.
.. index:: Frontend, PHP-API, FullyScanned, ext:frontend
@@ -0,0 +1,73 @@
.. include:: /Includes.rst.txt
.. _breaking-102627-1704301828:
===============================================================================
Breaking: #102627 - Removed special properties of page arrays in PageRepository
===============================================================================
See :issue:`102627`
Description
===========
When requesting a page with a translation, the following special properties of
an overlaid page have been removed:
:php:`_PAGES_OVERLAY_UID`: The property denounced the UID of the overlaid
database record entry, keeping "uid" as the original uid field.
:php:`_PAGES_OVERLAY`: A boolean flag being set to true if a page was actually
overlaid with a found record.
:php:`_PAGES_OVERLAY_LANGUAGE`: The value of the database record's
"sys_language" field value (the "language ID" of the overlaid record)
:php:`_PAGES_OVERLAY_REQUESTEDLANGUAGE`: A special property used to set the
actual requested language when having multi-level fallbacks while overlaying a
record. When a requested overlay of language=5 is not available, but its
fallback to language=2 is available, this property is set to "5" even though
the page records' "sys_language_uid" field is set to 2.
These special properties have been relevant especially when generating menus,
or when fetching overlays for Extbase domain models, and have been used due
to historical reasons, because translations of pages have been set in
"pages_language_overlay" instead of the database table "pages" until TYPO3 v9.0.
Any other record, where translations have been stored in the database,
received the special property "_LOCALIZED_UID".
Impact
======
When calling :php:`PageRepository->getPage()` or
:php:`PageRepository->getLanguageOverlay()` these special page-related
properties are not set anymore when overlaying a page.
Affected installations
======================
TYPO3 installations with custom extensions working on the low-level API
using these properties.
Migration
=========
The value of the previous :php:`_PAGES_OVERLAY_UID` property is now available
in :php:`_LOCALIZED_UID` making it consistent with all database record overlays
across the system.
The property :php:`_PAGES_OVERLAY` is removed in favor of a
:php:`isset($page['_LOCALIZED_UID')` check instead.
The property :php:`_PAGES_OVERLAY_LANGUAGE` is removed in favor of the property
:php:`$page['sys_language_uid']` which holds the same value.
The property :php:`_PAGES_OVERLAY_REQUESTEDLANGUAGE` is moved to a new property
called :php:`_REQUESTED_OVERLAY_LANGUAGE` which is available now for any kind
of overlaid record, and not just pages.
.. index:: Database, PHP-API, NotScanned, ext:core
@@ -0,0 +1,103 @@
.. include:: /Includes.rst.txt
.. _breaking-102632-1702043797:
===============================================
Breaking: #102632 - Use strict types in Extbase
===============================================
See :issue:`102632`, :issue:`102878`, :issue:`102879`, :issue:`102885`,
:issue:`102954`, :issue:`102956`, :issue:`102966`, :issue:`102969`
Description
===========
All properties, except the :php:`$view` property, in
:php:`\TYPO3\CMS\Extbase\Mvc\Controller\ActionController` are now strictly typed.
In addition, all function arguments and function return types are now strictly
typed.
Also, the properties in the :php:`\TYPO3\CMS\Extbase\Annotation\Annotation`
namespace now have native PHP types for their properties.
In summary, the following classes have received strict types:
- :php:`\TYPO3\CMS\Extbase\Mvc\Controller\ActionController`
- :php:`\TYPO3\CMS\Extbase\TYPO3\CMS\Extbase\Annotation\IgnoreValidation`
- :php:`\TYPO3\CMS\Extbase\TYPO3\CMS\Extbase\Annotation\ORM\Cascade`
- :php:`\TYPO3\CMS\Extbase\TYPO3\CMS\Extbase\Annotation\Required\Validate`
- :php:`\TYPO3\CMS\Extbase\TYPO3\CMS\Extbase\DomainObject\AbstractDomainObject`
- :php:`\TYPO3\CMS\Extbase\TYPO3\CMS\Extbase\DomainObject\DomainObjectInterface`
- :php:`\TYPO3\CMS\Extbase\TYPO3\CMS\Extbase\Domain\Model\AbstractFileFolder`
- :php:`\TYPO3\CMS\Extbase\TYPO3\CMS\Extbase\Domain\Model\Category`
- :php:`\TYPO3\CMS\Extbase\TYPO3\CMS\Extbase\Domain\Model\FileReference`
- :php:`\TYPO3\CMS\Extbase\TYPO3\CMS\Extbase\Domain\Model\File`
- :php:`\TYPO3\CMS\Extbase\TYPO3\CMS\Extbase\Persistence\Generic\LazyObjectStorage`
- :php:`\TYPO3\CMS\Extbase\TYPO3\CMS\Extbase\Persistence\Generic\PersistenceManager`
- :php:`\TYPO3\CMS\Extbase\TYPO3\CMS\Extbase\Persistence\Generic\QuerySettingsInterface`
- :php:`\TYPO3\CMS\Extbase\TYPO3\CMS\Extbase\Persistence\Generic\Typo3QuerySettings`
- :php:`\TYPO3\CMS\Extbase\TYPO3\CMS\Extbase\Persistence\ObjectStorage`
- :php:`\TYPO3\CMS\Extbase\TYPO3\CMS\Extbase\Persistence\PersistenceManagerInterface`
Impact
======
Classes extending the changed classes must now ensure that overwritten
properties and methods are all are strictly typed.
Affected installations
======================
Custom classes extending the changed classes.
Migration
=========
Ensure classes that extend the changed classes use strict types for overwritten
properties, function arguments and return types.
Extensions supporting multiple TYPO3 versions (for example, v12 and v13) must not
overwrite properties of the changed classes.
Instead, it is recommended to set values of overwritten properties in the
constructor of the extending class.
Before
------
.. code-block:: php
<?php
namespace MyVendor\MyExtension\Controller;
use TYPO3\CMS\Extbase\Mvc\Controller\ActionController;
class MyController extends ActionController
{
public string $errorMethodName = 'myAction';
}
After
-----
.. code-block:: php
<?php
namespace MyVendor\MyExtension\Controller;
use TYPO3\CMS\Extbase\Mvc\Controller\ActionController;
class MyController extends ActionController
{
public function __construct()
{
$this->errorMethodName = 'myAction';
}
}
.. index:: Backend, Frontend, NotScanned, ext:extbase
@@ -0,0 +1,60 @@
.. include:: /Includes.rst.txt
.. _breaking-102645-1702194379:
================================================
Breaking: #102645 - More strict Context handling
================================================
See :issue:`102645`
Description
===========
Class :php:`\TYPO3\CMS\Core\Context\Context` is a stateful singleton class set up
pretty early by the frontend or backend application after the request object has been created.
Its state is then further changed by various frontend and backend middlewares. It can
be retrieved using dependency injection or :php:`GeneralUtility::makeInstance()` in consuming
classes.
To clean up Context-related code a bit, the following changes have been made:
* Method :php:`__construct()` removed from :php:`\TYPO3\CMS\Core\Context\Context`
* Class :php:`\TYPO3\CMS\Core\Context\ContextAwareInterface` removed
* Trait :php:`\TYPO3\CMS\Core\Context\ContextAwareTrait` removed
Impact
======
Handing over manual arguments to the constructor of :php:`__construct()` does not have
an effect anymore, and using the interface or the trait will raise a fatal PHP error.
Affected installations
======================
Most likely, not too many instances are affected: An instance of :php:`Context` is
typically created by Core bootstrap and retrieved using dependency injection, extensions
usually do not need to create own instances.
There are also not many routing aspects with context dependencies that may use the
interface or the trait. If so, they can adapt easily and stay compatible with older
versions.
Migration
=========
The constructor of the Context class was bogus. Since the class is an injectable singleton
that should be available through the container, it must not have manual constructor arguments
since this would shut down the container registration. Extensions typically did not create
own instances of :php:`Context`, using the constructor argument was - if at all - only done
in tests. Unit tests should typically create own instances using :php:`new` and hand them
over to classes that get the context injected.
Adaption to the interface and trait removal is straight forward as well: Get the
context injected into the aspect, or retrieve the instance using :php:`GeneralUtility::makeInstance()`.
.. index:: PHP-API, PartiallyScanned, ext:core
@@ -0,0 +1,60 @@
.. include:: /Includes.rst.txt
.. _breaking-102715-1703254781:
===================================================================
Breaking: #102715 - Frontend "determineId()" related events changed
===================================================================
See :issue:`102715`
Description
===========
With the continued refactoring of :php:`\TYPO3\CMS\Frontend\Controller\TypoScriptFrontendController`,
the following events have been adapted:
* :php:`\TYPO3\CMS\Frontend\Event\BeforePageIsResolvedEvent`
* :php:`\TYPO3\CMS\Frontend\Event\AfterPageWithRootLineIsResolvedEvent`
* :php:`\TYPO3\CMS\Frontend\Event\AfterPageAndLanguageIsResolvedEvent`
The three events no longer retrieve an instance of :php:`TypoScriptFrontendController`, the
getter methods :php:`getController()` have been removed: The controller is instantiated
*after* the events have been dispatched, event listeners can no longer work with this
object.
Instead, the events now contain an instance of the new :abbr:`DTO (Data Transfer Object)`
:php:`\TYPO3\CMS\Frontend\Page\PageInformation`, which can be retrieved and
manipulated by event listeners if necessary.
Impact
======
Calling :php:`getController()` by consumers of above events will raise a fatal
PHP error.
Also note the events may not be dispatched anymore when the middleware
:php:`\TYPO3\CMS\Frontend\Middleware\TypoScriptFrontendInitialization` creates
early responses.
Affected installations
======================
Those events are in place for a couple of special cases during early frontend rendering.
Most instances will not be affected, but some extensions may register event listeners.
Migration
=========
Use method :php:`getPageInformation()` instead to retrieve calculated page state at
this point in the frontend rendering chain. Event listeners that manipulate that
object should set it again within the event using :php:`setPageInformation()`.
In case middleware :php:`TypoScriptFrontendInitialization` no longer dispatches an event
when it created an early response on its own, an own middleware can be added around
that middleware to retrieve and further manipulate a response if needed.
.. index:: Frontend, PHP-API, PartiallyScanned, ext:frontend
@@ -0,0 +1,39 @@
.. include:: /Includes.rst.txt
.. _breaking-102731-1703944154:
====================================================================================
Breaking: #102731 - Removed TypoScript setting showForgotPasswordLink in ext:felogin
====================================================================================
See :issue:`102731`
Description
===========
The :php:`showForgotPasswordLink` setting in ext:felogin has never been used in
default Fluid templates and was only been kept for backward compatibility
reasons. The setting has been deprecated with :issue:`98122`, but it has been forgotten
to be removed in TYPO3 v12.
Impact
======
The :php:`showForgotPasswordLink` setting has been removed from default
TypoScript.
Affected installations
======================
Instances using :php:`showForgotPasswordLink` setting in Fluid templates.
Migration
=========
Use :php:`showForgotPassword` instead of :php:`showForgotPasswordLink`, which is
available since TYPO3 v11.
.. index:: Frontend, TypoScript, NotScanned, ext:felogin
@@ -0,0 +1,44 @@
.. include:: /Includes.rst.txt
.. _breaking-102745-1705054472:
======================================================
Breaking: #102745 - Removed ContentObject stdWrap hook
======================================================
See :issue:`102745`
Description
===========
The ContentObject stdWrap hook :php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['tslib/class.tslib_content.php']['stdWrap']`
has been removed in favor of the more powerful PSR-14 events:
* :php:`\TYPO3\CMS\Frontend\ContentObject\Event\BeforeStdWrapFunctionsInitializedEvent`
* :php:`\TYPO3\CMS\Frontend\ContentObject\Event\AfterStdWrapFunctionsInitializedEvent`
* :php:`\TYPO3\CMS\Frontend\ContentObject\Event\BeforeStdWrapFunctionsExecutedEvent`
* :php:`\TYPO3\CMS\Frontend\ContentObject\Event\AfterStdWrapFunctionsExecutedEvent`
Impact
======
Any hook implementation registered is not executed anymore
in TYPO3 v13.0+. The extension scanner will report usages.
Affected installations
======================
TYPO3 installations with custom extensions using the hook.
Migration
=========
The hook is removed without deprecation in order to allow extensions
to work with TYPO3 v12 (using the hook) and v13+ (using the new events)
when implementing the events as well without any further deprecations.
Use the :doc:`PSR-14 events <../13.0/Feature-102745-PSR-14EventsForModifyingContentObjectStdWrapFunctionality>`
to allow greater influence in the functionality.
.. index:: Frontend, PHP-API, FullyScanned, ext:frontend
@@ -0,0 +1,55 @@
.. include:: /Includes.rst.txt
.. _breaking-102755-1704381963:
===========================================================
Breaking: #102755 - Improved getImageResource functionality
===========================================================
See :issue:`102755`
Description
===========
The hook :php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['tslib/class.tslib_content.php']['getImgResource']`
has been removed in favor of the new PSR-14 event
:php:`\TYPO3\CMS\Frontend\ContentObject\Event\AfterImageResourceResolvedEvent`.
The new event is using the new :php:`\TYPO3\CMS\Core\Imaging\ImageResource` :abbr:`DTO (Data Transfer Object)`,
which allows an improved API as developers do no longer have to deal with
unnamed array keys but benefit from the object-oriented approach, using
corresponding getter and setter. Therefore, the return types of the following
methods have been changed to :php:`?ImageResource`:
* :php:`\TYPO3\CMS\Frontend\Imaging\GifBuilder->gifBuild()`
* :php:`\TYPO3\CMS\Frontend\ContentObject\ContentObjectRenderer->getImgResource()`
Impact
======
Any registered hook implementation is not executed anymore
in TYPO3 v13.0+.
Calling the mentioned methods do now return either :php:`null` or an instance
of the :php:`ImageResource` DTO.
The new Event is also using the new DTO instead of an array.
Affected Installations
======================
TYPO3 installations with custom extensions using this hook or calling
mentioned methods directly.
Migration
=========
The hook is removed without deprecation in order to allow extensions
to work with TYPO3 v12 (using the hook) and v13+ (using the new event)
when implementing the event as well without any further deprecations.
Use the :doc:`PSR-14 event <../13.0/Feature-102755-PSR-14EventForModifyingGetImageResourceResult>`
to allow greater influence in the functionality.
Additionally, adjust your code to handle the new return types appropriately.
.. index:: Frontend, PHP-API, FullyScanned, ext:frontend
@@ -0,0 +1,48 @@
.. include:: /Includes.rst.txt
.. _breaking-102763-1706362598:
============================================================================
Breaking: #102763 - Extbase HashService usage replaced with Core HashService
============================================================================
See :issue:`102763`
Description
===========
All usages of the :php:`@internal` class
:php:`\TYPO3\CMS\Extbase\Security\Cryptography\HashService` in TYPO3 have been
removed and replaced by :php:`\TYPO3\CMS\Core\Crypto\HashService`.
Impact
======
Custom extensions expecting :php:`\TYPO3\CMS\Extbase\Security\Cryptography\HashService`
as type of the property :php:`'$hashService` of various :php:`@internal` classes
will result in a PHP Fatal error.
Affected installations
======================
TYPO3 installations with custom extensions using one of the following:
- Property :php:`$hashService` of :php:`\TYPO3\CMS\Fluid\ViewHelpers\FormViewHelper`
- :php:`@internal` property :php:`$hashService` of class :php:`\TYPO3\CMS\Extbase\Mvc\Controller\ActionController`
- Property :php:`$hashService` of :php:`internal` class :php:`\TYPO3\CMS\Extbase\Mvc\Controller\MvcPropertyMappingConfigurationService`
- Property :php:`$hashService` of :php:`internal` class :php:`\TYPO3\CMS\FrontendLogin\Configuration\RecoveryConfiguration`
- Property :php:`$hashService` of :php:`internal` class :php:`\TYPO3\CMS\FrontendLogin\Configuration\RecoveryConfiguration`
- Property :php:`$hashService` of :php:`internal` class :php:`\TYPO3\CMS\FrontendLogin\Controller\PasswordRecoveryController`
- Property :php:`$hashService` of :php:`internal` class :php:`\TYPO3\CMS\Form\Domain\Runtime\FormRuntime`
- Property :php:`$hashService` of :php:`internal` class :php:`\TYPO3\CMS\Form\Mvc\Property\TypeConverter\UploadedFileReferenceConverter`
Migration
=========
Custom extensions must be adapted to use methods of class
:php:`\TYPO3\CMS\Core\Crypto\HashService`.
.. index:: Fluid, Frontend, PHP-API, FullyScanned, ext:extbase
@@ -0,0 +1,44 @@
.. include:: /Includes.rst.txt
.. _breaking-102763-1706375934:
======================================================================
Breaking: #102763 - Frontend user password recovery hashes invalidated
======================================================================
See :issue:`102763`
Description
===========
The replacement of deprecated class
:php:`\TYPO3\CMS\Extbase\Security\Cryptography\HashService` results in existing
password recovery hashes of frontend users being invalid.
Impact
======
A frontend user with a valid and unexpired password recovery link created with
a TYPO3 version < 13 can not use the password recovery link to reset the
password.
These hashes have a limited lifetime already (12 hours). On large installations
that require hashes to survive a major update, you could write a small CLI task
that re-adds missing hashes created in the maintenance time window of the upgrade.
Affected installations
======================
TYPO3 installations which use the "Display Password Recovery Link" option of
ext:fe_login.
Migration
=========
Frontend users need to request a new password recovery link to reset the
password.
.. index:: Frontend, NotScanned, ext:felogin
@@ -0,0 +1,54 @@
.. include:: /Includes.rst.txt
.. _breaking-102775-1704711591:
================================================================
Breaking: #102775 - PageRepository methods with native PHP types
================================================================
See :issue:`102775`
Description
===========
Various methods in of the main TYPO3 Core classes
:php:`\TYPO3\CMS\Core\Domain\Repository\PageRepository`
now have native PHP types in their method signature, requiring the caller code
to use exactly the required PHP types for the corresponding method arguments.
The following methods are affected:
- :php:`PageRepository->getPage()`
- :php:`PageRepository->getPage_noCheck()`
- :php:`PageRepository->getPageOverlay()`
- :php:`PageRepository->getPagesOverlay()`
- :php:`PageRepository->checkRecord()`
- :php:`PageRepository->getRawRecord()`
- :php:`PageRepository->enableFields()`
- :php:`PageRepository->getMultipleGroupsWhereClause()`
- :php:`PageRepository->versionOL()`
Impact
======
Calling the affected methods now requires the passed arguments to be
of the specified PHP type. Otherwise a PHP TypeError is triggered.
Affected installations
======================
TYPO3 installations with third-party extensions utilizing the
:php:`PageRepository` PHP class.
Migration
=========
Extension authors need to adapt their PHP code to use ensure passed
arguments are of the required PHP type when calling corresponding methods
of the :php:`PageRepository` PHP class. Using proper type casts would is
a possible migration strategy.
.. index:: PHP-API, NotScanned, ext:core
@@ -0,0 +1,46 @@
.. include:: /Includes.rst.txt
.. _breaking-102779-1704721008:
=================================================
Breaking: #102779 - TYPO3 v13 System Requirements
=================================================
See :issue:`102779`
Description
===========
The minimum PHP version required to run TYPO3 version v13 has been defined as 8.2.
TYPO3 v13 supports these database products and versions:
* MySQL 8.0.17 or higher
* MariaDB 10.4.3 or higher
* PostgresSQL 10.0 or higher
* SQLite 3.8.3 or higher
Impact
======
The TYPO3 Core codebase and extensions tailored for v13 and above can use
features implemented with PHP up to and including 8.2. Running TYPO3 v13 with
older PHP versions or database engines will trigger fatal errors.
Affected installations
======================
Hosting a TYPO3 instance based on version 13 may require an update of the
PHP platform and the database engine.
Migration
=========
TYPO3 v11 / v12 supports PHP 8.2 and database engines required by v13. This
allows upgrading the platform in a first step and upgrading to TYPO3 v13 in a
second step.
.. index:: PHP-API, NotScanned, ext:core
@@ -0,0 +1,40 @@
.. include:: /Includes.rst.txt
.. _breaking-102793-1704798752:
=============================================================
Breaking: #102793 - PageRepository->enableFields hook removed
=============================================================
See :issue:`102793`
Description
===========
One of the common PHP APIs used in TYPO3 Core for fetching records is
:php:`\TYPO3\CMS\Core\Domain\Repository\PageRepository`. The method
:php:`enableFields()` is marked as deprecated, and the according hook
:php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['t3lib/class.t3lib_page.php']['addEnableColumns']`
has been removed.
Impact
======
Hook listeners will not be executed anymore.
Affected installations
======================
TYPO3 installations with custom extensions using the mentioned hook.
Migration
=========
The hook :php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['t3lib/class.t3lib_page.php']['addEnableColumns']`
can be replaced by a listener to the newly introduced
:doc:`PSR-14 event <../13.0/Feature-102793-PSR-14EventForModifyingDefaultConstraintsInPageRepository>`.
.. index:: Database, Frontend, PHP-API, NotScanned, ext:core
@@ -0,0 +1,51 @@
.. include:: /Includes.rst.txt
.. _breaking-102806-1704874383:
===================================================
Breaking: #102806 - Hooks in PageRepository removed
===================================================
See :issue:`102806`
Description
===========
The following hooks in TYPO3's Core API class :php:`\TYPO3\CMS\Core\Domain\PageRepository`
have been removed:
* :php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS'][\TYPO3\CMS\Core\Domain\PageRepository::class]['init']`
* :php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['t3lib/class.t3lib_page.php']['getPage']`
Later hook has been replaced by the new PSR-14 event
:php:`\TYPO3\CMS\Core\Domain\Event\BeforePageIsRetrievedEvent`.
Impact
======
Any hook implementation registered is not executed anymore in TYPO3 v13.0+.
Affected installations
======================
TYPO3 installations with custom extensions using these hooks.
Migration
=========
The hook :php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS'][\TYPO3\CMS\Core\Domain\PageRepository::class]['init']`
is removed without substitution. Back in TYPO3 v4.x this hook was useful to modify
public properties after everything was initialized. Nowadays, this is not
necessary anymore, as the properties are not public anymore and calculated
based on the Context API when instantiated.
The hook :php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['t3lib/class.t3lib_page.php']['getPage']`
is removed without deprecation in order to allow extensions to work with TYPO3
v12 (using the hook) and v13+ (using the new Event) when implementing the event
as well without any further deprecations. Use the
:doc:`PSR-14 event <../13.0/Feature-102806-BeforePageIsRetrievedEventInPageRepository>`
to allow greater influence in the functionality.
.. index:: PHP-API, FullyScanned, ext:core
@@ -0,0 +1,48 @@
.. include:: /Includes.rst.txt
.. _breaking-102834-1705491713:
================================================================
Breaking: #102834 - Remove items from New Content Element Wizard
================================================================
See :issue:`102834`
Description
===========
The configuration of the New Content Element Wizard has been
:doc:`improved <../13.0/Feature-102834-Auto-registrationOfNewContentElementWizardViaTCA>`
by automatically registering the groups and elements from the TCA configuration.
The previously used option to show / hide elements
:typoscript:`mod.wizards.newContentElement.wizardItems.<group>.show` is
therefore not evaluated anymore.
All configured groups and elements are automatically shown. Removing these
groups and elements from the New Content Element Wizard has to be done via
the new :typoscript:`mod.wizards.newContentElement.wizardItems.removeItems` and
:typoscript:`mod.wizards.newContentElement.wizardItems.<group>.removeItems`
options.
Impact
======
Using the page TSconfig option :typoscript:`mod.wizards.newContentElement.wizardItems.<group>.show`
to show / hide elements is not evaluated anymore.
Affected installations
======================
TYPO3 installations with custom extensions using the page TSconfig
option :typoscript:`mod.wizards.newContentElement.wizardItems.<group>.show` to
show / hide elements in the New Content Element Wizard.
Migration
=========
To hide elements, migrate your page TSconfig from
:typoscript:`mod.wizards.newContentElement.wizardItems.<group>.show := removeFromList(html)` to
:typoscript:`mod.wizards.newContentElement.wizardItems.<group>.removeItems := addToList(html)`.
.. index:: TCA, TypoScript, NotScanned, ext:backend
@@ -0,0 +1,52 @@
.. include:: /Includes.rst.txt
.. _breaking-102835-1705314374:
===============================================================
Breaking: #102835 - Strict typing in final TypoLinkCodecService
===============================================================
See :issue:`102835`
Description
===========
The :php:`\TYPO3\CMS\Core\LinkHandling\TypoLinkCodecService`, used to encode
and decode TypoLinks, has been declared `readonly` and set `final`.
Additionally, the class does now use strict typing and the :php:`decode()`
method's first parameter :php:`$typoLink` is now a type hinted :php:`string`.
This has been done in combination with the introduction of the two new PSR-14
events :php:`BeforeTypoLinkEncodedEvent` and :php:`AfterTypoLinkDecodedEvent`,
which allow to fully influence the encode and decode functionality, making
any cross classing superfluous.
Impact
======
Extending / cross classing :php:`TypoLinkCodecService` does no longer work
and will lead to PHP errors.
Calling :php:`decode()` with the first parameter :php:`$typolink` being not
a :php:`string` will lead to a PHP TypeError.
Affected installations
======================
All installations extending / cross classing :php:`TypoLinkCodecService` or
calling :php:`decode()` with the first parameter :php:`$typolink` not being
a :php:`string`.
Migration
=========
Instead of extending / cross classing :php:`TypoLinkCodecService` use the
:doc:`new PSR-14 events <../13.0/Feature-102835-AddPSR-14EventsToManipulateTypoLinkCodecService>`
to modify the functionality.
Ensure to always provide a :php:`string` as first parameter :php:`$typolink`,
when calling :php:`decode()` in your extension code.
.. index:: PHP-API, NotScanned, ext:core
@@ -0,0 +1,40 @@
.. include:: /Includes.rst.txt
.. _breaking-102849-1705514231:
=================================================================
Breaking: #102849 - Removed ContentObject stdWrap cacheStore hook
=================================================================
See :issue:`102849`
Description
===========
The hook :php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['tslib/class.tslib_content.php']['stdWrap_cacheStore']`
has been removed in favor of the new PSR-14 event
:php:`\TYPO3\CMS\Frontend\ContentObject\Event\BeforeStdWrapContentStoredInCacheEvent`.
Impact
======
Any hook implementation registered is not executed anymore
in TYPO3 v13.0+.
Affected installations
======================
TYPO3 installations with custom extensions using this hook.
Migration
=========
The hook is removed without deprecation in order to allow extensions
to work with TYPO3 v12 (using the hook) and v13+ (using the new event)
when implementing the event as well without any further deprecations.
Use the :doc:`PSR-14 event <../13.0/Feature-102849-PSR-14EventForManipulatingStoreCacheFunctionalityOfStdWrap>`
to allow greater influence in the functionality.
.. index:: Frontend, PHP-API, FullyScanned, ext:frontend
@@ -0,0 +1,41 @@
.. include:: /Includes.rst.txt
.. _breaking-102855-1705567984:
==========================================================================
Breaking: #102855 - Removed LinkService resolveByStringRepresentation hook
==========================================================================
See :issue:`102855`
Description
===========
The hook :php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['Link']['resolveByStringRepresentation']`
has been removed in favor of the new PSR-14 event
:php:`\TYPO3\CMS\Core\LinkHandling\Event\AfterLinkResolvedByStringRepresentationEvent`
event.
Impact
======
Any hook implementation registered is not executed anymore
in TYPO3 v13.0+.
Affected installations
======================
TYPO3 installations with custom extensions using this hook.
Migration
=========
The hook is removed without deprecation in order to allow extensions
to work with TYPO3 v12 (using the hook) and v13+ (using the new event)
when implementing the event as well without any further deprecations.
Use the :doc:`PSR-14 event <../13.0/Feature-102855-PSR-14EventForModifyingResolvedLinkResultData>`
to allow greater influence in the functionality.
.. index:: PHP-API, FullyScanned, ext:core
@@ -0,0 +1,110 @@
.. include:: /Includes.rst.txt
.. _breaking-102875-1705944556:
======================================================================
Breaking: #102875 - Changed Connection method signatures and behaviour
======================================================================
See :issue:`102875`
Description
===========
Signature and behaviour of following methods has been changed:
* :php:`lastInsertId()` no longer accepts the sequence and field name.
* :php:`quote()` no longer has a type argument and the value must be a string.
Public :php:`Connection::PARAM_*` class constants has been replaced with the
Doctrine DBAL 4 :php:`ParameterType` and :php:`ArrayParameterType` enum definitions.
.. note::
Doctrine DBAL dropped the support for using the :php:`\PDO::PARAM_*` constants in
favour of the enum types on several methods. Be aware of this and use the
:php:`\TYPO3\CMS\Core\Database\Connection::PARAM_*` constants to reduce
required work on upgrading.
Impact
======
Calling :php:`quote()` with a non-string as first argument will result in a
PHP error. Still providing the second argument will not emit an error, but
may be detected by static code analysers.
Calling :php:`lastInsertId()` not directly after the record insert or inserting
records in another table in between will return the incorrect value.
Affected installations
======================
Only installations calling :php:`quote()` with a non-string as first argument
or not using :php:`lastInsertId()` directly after the record insert.
Migration
=========
:php:`lastInsertId()`
---------------------
Returns the last inserted ID (auto-created) on the connection.
.. note::
That means, that the `last inserted id` needs to be retrieved directly before
inserting a record to another table. That should be the usual workflow used
in the wild - but be aware of this.
**BEFORE**
.. code-block:: php
:emphasize-lines: 20
use TYPO3\CMS\Core\Database\Connection as Typo3Connection;
use TYPO3\CMS\Core\Database\ConnectionPool;
use TYPO3\CMS\Core\Utility\GeneralUtility;
/** @var Typo3Connection $connection */
$connection = GeneralUtility::makeInstance(ConnectionPool::class)
->getConnectionForTable('tx_myextension_mytable');
$connection->insert(
'tx_myextension_mytable',
[
'pid' => $pid,
'some_string' => $someString,
],
[
\PDO::PARAM_INT,
\PDO::PARAM_STR,
]
);
$uid = $connection->lastInsertId('tx_myextension_mytable');
**AFTER**
.. code-block:: php
:emphasize-lines: 20
use TYPO3\CMS\Core\Database\Connection as Typo3Connection;
use TYPO3\CMS\Core\Database\ConnectionPool;
use TYPO3\CMS\Core\Utility\GeneralUtility;
/** @var Typo3Connection $connection */
$connection = GeneralUtility::makeInstance(ConnectionPool::class)
->getConnectionForTable('tx_myextension_mytable');
$connection->insert(
'tx_myextension_mytable',
[
'pid' => $pid,
'some_string' => $someString,
],
[
Typo3Connection::PARAM_INT,
Typo3Connection::PARAM_STR,
]
);
$uid = $connection->lastInsertId();
.. index:: Database, PHP-API, NotScanned, ext:core
@@ -0,0 +1,102 @@
.. include:: /Includes.rst.txt
.. _breaking-102875-1706013339:
=============================================
Breaking: #102875 - ExpressionBuilder changes
=============================================
See :issue:`102875`
Description
===========
Signature changes for following methods
---------------------------------------
* :php:`ExpressionBuilder::literal(string $value)`: Value must be a string now.
* :php:`ExpressionBuilder::trim()`: Only :php:`\Doctrine\DBAL\Platforms\TrimMode`
enum for :php:`$position` argument.
Following class constants have been removed
-------------------------------------------
* :php:`QUOTE_NOTHING`: Not used since already TYPO3 v12 and Doctrine DBAL 3.x.
* :php:`QUOTE_IDENTIFIER`: Not used since already TYPO3 v12 and Doctrine DBAL 3.x.
* :php:`QUOTE_PARAMETER`: Not used since already TYPO3 v12 and Doctrine DBAL 3.x.
Impact
======
Calling any of the mentioned methods with invalid type will result in a PHP
error.
Affected installations
======================
Only those installations that uses one of the mentioned methods with invalid type(s).
Migration
=========
:php:`ExpressionBuilder::literal()`
-----------------------------------
Extension author need to ensure that a string is passed to :php:`literal()`.
:php:`ExpressionBuilder::trim()`
--------------------------------
Extension author need to pass the Doctrine DBAL enum :php:`TrimMode` instead of
an integer.
TRIM_LEADING
.. csv-table:: Replacements
:header: "integer", "enum"
0, "TrimMode::UNSPECIFIED"
1, "TrimMode::LEADING"
2, "TrimMode::TRAILING"
3, "TrimMode::BOTH"
.. code-block:: php
:caption: EXT:my_extension/Classes/Domain/Repository/MyTableRepository.php
use Doctrine\DBAL\Platforms\TrimMode;
use TYPO3\CMS\Core\Database\Connection
use TYPO3\CMS\Core\Database\Query\Expression\ExpressionBuilder;
// before
$queryBuilder = $this->connectionPool->getQueryBuilderForTable('tt_content');
$queryBuilder->expr()->comparison(
$queryBuilder->expr()->trim($fieldName, 1),
ExpressionBuilder::EQ,
$queryBuilder->createNamedParameter('', Connection::PARAM_STR)
);
// after
$queryBuilder = $this->connectionPool->getQueryBuilderForTable('tt_content');
$queryBuilder->expr()->comparison(
$queryBuilder->expr()->trim($fieldName, TrimMode::LEADING),
ExpressionBuilder::EQ,
$queryBuilder->createNamedParameter('', Connection::PARAM_STR)
);
// example for dual version compatible code
$queryBuilder = $this->connectionPool->getQueryBuilderForTable('tt_content');
$queryBuilder->expr()->comparison(
$queryBuilder->expr()->trim($fieldName, TrimMode::LEADING),
ExpressionBuilder::EQ,
$queryBuilder->createNamedParameter('', Connection::PARAM_STR)
);
.. tip::
With Doctrine DBAL 3.x the :php:`TrimMode` was a class with class constants. Using
these no code changes are needed for TYPO3 v12 and v13 compatible code. Only
method call type hinting needs to be adjusted to use the enum instead of
int.
.. index:: Database, PHP-API, NotScanned, ext:core
@@ -0,0 +1,264 @@
.. include:: /Includes.rst.txt
.. _breaking-102875-1705944493:
========================================
Breaking: #102875 - QueryBuilder changes
========================================
See :issue:`102875`
Description
===========
Doctrine DBAL 4 removed methods from the :php:`QueryBuilder` which has been
adopted to the extended :php:`\TYPO3\CMS\Core\Database\Query\QueryBuilder`.
Removed methods:
* :php:`QueryBuilder::add()`: Use new reset methods and normal set methods
instead.
* :php:`QueryBuilder::getQueryPart($partName)`: No replacement, internal state.
* :php:`QueryBuilder::getQueryParts()`: No replacement, internal state.
* :php:`QueryBuilder::resetQueryPart($partName)`: Replacement methods has been added,
see list.
* :php:`QueryBuilder::resetQueryParts()`: Replacement methods has been added,
see list.
* :php:`QueryBuilder::execute()`: Use :php:`QueryBuilder::executeQuery()` or
:php:`QueryBuilder::executeStatement()` directly.
* :php:`QueryBuilder::setMaxResults()`: Using `(int)0` as `max result` will
no longer work and retrieve no records. Use `NULL` instead to allow all
results.
Signature changes:
* :php:`QueryBuilder::quote(string $value)`: Second argument has been dropped
and the value must now be of type :php:`string`.
Impact
======
Calling any of the mentioned removed methods will result in a PHP error. Also
signature changes introducing type hint will result in a PHP error if called
with an invalid type.
Affected installations
======================
Only those installations that use the mentioned methods.
Migration
=========
Extension author need to replace the removed methods with the alternatives which
:php:`QueryBuilder::add('query-part-name')`
-------------------------------------------
Use the direct set/select methods instead:
.. csv-table:: Replacements
:header: "before", "after"
":php:`->add('select', $array)`", ":php:`->select(...$array)`"
":php:`->add('where', $wheres)`", ":php:`->where(...$wheres)`"
":php:`->add('having', $havings)`", ":php:`->having(...$havings)`"
":php:`->add('orderBy', $orderBy)`", ":php:`->orderBy($orderByField, $orderByDirection)->addOrderBy($orderByField2)`"
":php:`->add('groupBy', $groupBy)`", ":php:`->groupBy($groupField)->addGroupBy($groupField2)`"
.. note::
This can be done already in TYPO3 v12 with at least Doctrine DBAL 3.8.
:php:`QueryBuilder::resetQueryParts()` and :php:`QueryBuilder::resetQueryPart()`
--------------------------------------------------------------------------------
However, several replacements have been put in place depending on the
:php:`$queryPartName` parameter:
.. csv-table:: Replacements
:header: "before", "after"
"'select'", "Call :php:`->select()` with a new set of columns"
"'distinct'", ":php:`->distinct(false)`"
"'where'", ":php:`->resetWhere()`"
"'having'", ":php:`->resetHaving()`"
"'groupBy'", ":php:`->resetGroupBy()`"
"'orderBy", ":php:`->resetOrderBy()`"
"'values'", "Call :php:`->values()` with a new set of values."
.. note::
This can be done already in TYPO3 v12 with at least Doctrine DBAL 3.8.
:php:`QueryBuilder::execute()`
------------------------------
Doctrine DBAL 4 removed :php:`QueryBuilder::execute()` in favour of the two
methods :php:`QueryBuilder::executeQuery()` for select/count and :php:`QueryBuilder::executeStatement()`
for insert, delete and update queries.
Before
~~~~~~
.. code-block:: php
:emphasize-lines: 9,20
use TYPO3\CMS\Core\Database\ConnectionPool;
// select query
$queryBuilder = GeneralUtility::makeInstance(ConnectionPool::class)
->getQueryBuilderForTable('pages');
$rows = $queryBuilder
->select('*')
->from('pages')
->execute()
->fetchAllAssociative();
// delete query
$queryBuilder = GeneralUtility::makeInstance(ConnectionPool::class)
->getQueryBuilderForTable('pages');
$deletedRows = (int)$queryBuilder
->delete('pages')
->where(
$queryBuilder->expr()->eq('pid', $this->createNamedParameter(123),
)
->execute();
After
~~~~~
.. code-block:: php
:emphasize-lines: 9,20
use TYPO3\CMS\Core\Database\ConnectionPool;
// select query
$queryBuilder = GeneralUtility::makeInstance(ConnectionPool::class)
->getQueryBuilderForTable('pages');
$rows = $queryBuilder
->select('*')
->from('pages')
->executeQuery()
->fetchAllAssociative();
// delete query
$queryBuilder = GeneralUtility::makeInstance(ConnectionPool::class)
->getQueryBuilderForTable('pages');
$deletedRows = (int)$queryBuilder
->delete('pages')
->where(
$queryBuilder->expr()->eq('pid', $this->createNamedParameter(123),
)
->executeStatement();
:php:`QueryBuilder::quote(string $value)`
-----------------------------------------
:php:`quote()` uses :php:`Connection::quote()` and therefore adopts the changed
signature and behaviour.
Before
~~~~~~
.. code-block:: php
:emphasize-lines: 15
use TYPO3\CMS\Core\Database\Connection as Typo3Connection;
use TYPO3\CMS\Core\Database\ConnectionPool;
use TYPO3\CMS\Core\Utility\GeneralUtility;
// select query
$pageId = 123;
$queryBuilder = GeneralUtility::makeInstance(ConnectionPool::class)
->getQueryBuilderForTable('pages');
$rows = $queryBuilder
->select('*')
->from('pages')
->where(
$queryBuilder->expr()->eq(
'uid',
$queryBuilder->quote($pageId, Typo3Connection::PARAM_INT)
),
)
->executeQuery()
->fetchAllAssociative();
After
~~~~~
.. code-block:: php
:emphasize-lines: 14
use TYPO3\CMS\Core\Database\ConnectionPool;
use TYPO3\CMS\Core\Utility\GeneralUtility;
// select query
$pageId = 123;
$queryBuilder = GeneralUtility::makeInstance(ConnectionPool::class)
->getQueryBuilderForTable('pages');
$rows = $queryBuilder
->select('*')
->from('pages')
->where(
$queryBuilder->expr()->eq(
'uid',
$queryBuilder->quote((string)$pageId)
),
)
->executeQuery()
->fetchAllAssociative();
.. tip::
To provide TYPO3 v12 and v13 with one code base, :php:`->quote((string)$value)`
can be used to ensure dual Core compatibility.
:php:`QueryBuilder::setMaxResults()`
------------------------------------
Using `(int)0` as `max result` will no longer work and retrieve no records.
Use `NULL` instead to allow all results.
Before
~~~~~~
.. code-block:: php
:emphasize-lines: 12
use TYPO3\CMS\Core\Database\ConnectionPool;
use TYPO3\CMS\Core\Utility\GeneralUtility;
// select query
$pageId = 123;
$queryBuilder = GeneralUtility::makeInstance(ConnectionPool::class)
->getQueryBuilderForTable('pages');
$rows = $queryBuilder
->select('*')
->from('pages')
->setFirstResult(0)
->setMaxResults(0)
->executeQuery()
->fetchAllAssociative();
After
~~~~~
.. code-block:: php
:emphasize-lines: 12
use TYPO3\CMS\Core\Database\ConnectionPool;
use TYPO3\CMS\Core\Utility\GeneralUtility;
// select query
$pageId = 123;
$queryBuilder = GeneralUtility::makeInstance(ConnectionPool::class)
->getQueryBuilderForTable('pages');
$rows = $queryBuilder
->select('*')
->from('pages')
->setFirstResult(0)
->setMaxResults(null)
->executeQuery()
->fetchAllAssociative();
.. index:: Database, PHP-API, NotScanned, ext:core
@@ -0,0 +1,49 @@
.. include:: /Includes.rst.txt
.. _breaking-102895-1706002517:
=============================================
Breaking: #102895 - PackageInterface modified
=============================================
See :issue:`102895`
Description
===========
The PHP interface :php:`\TYPO3\CMS\Core\Package\PackageInterface` has been
modified.
All methods of the interface now have proper types in the method signature.
In addition, the method :php:`getPackageIcon(): ?string` is added to define
whether the package has an icon which is shipped with the package.
Impact
======
Although the interface exists primarily because of the original implementation
from Flow Framework in TYPO3 v6.0 in order to differentiate between TYPO3
extensions and Flow packages, the interface only has one implementation:
:php:`\TYPO3\CMS\Core\Package\Package`.
Thus, it does not impact any extension or installation directly.
However, projects might be affected if there is a custom implementation
of the :php:`PackageInterface`, which is highly unlikely.
Affected installations
======================
TYPO3 installations in very rare cases where there is a custom implementation
of the interface, which is unknown at the time of writing.
Migration
=========
Extend the custom implementation to reflect the updated :php:`PackageInterface`.
.. index:: PHP-API, NotScanned, ext:core
@@ -0,0 +1,70 @@
.. include:: /Includes.rst.txt
.. _breaking-102900-1706016651:
=================================================================
Breaking: #102900 - Metaphone search removed from indexed\_search
=================================================================
See :issue:`102900`
Description
===========
The indexed_search based frontend functionality had a feature called "metaphone"
to look for matches that "sound similar" to the given search word. This was available
using the "Advanced search" interface, if it has not been disabled by an
integrator. This feature has been removed.
This feature had so many issues that it was deemed unfixable:
* Most importantly, search results were bad. Even during dedicated testing, it
was hard to retrieve any "similar sounding" results.
* The implementation was tailored for English language only, lacking support for
any non-ASCII characters like umlauts. Sites with languages not based on
single byte characters got even worse results.
* The code has been not maintained for about 15 years.
* The feature seems to be used so seldom, there does not seem to be a single
extension that tries to fix at least the most important issues.
* There has been no issues reported about this broken feature over the years,
except when it triggered crashes.
All in all it seems as if that feature was used extremely seldom, most likely
because the results are so bad.
On a code level, the removal affects these areas:
* Class :php:`\TYPO3\CMS\IndexedSearch\Utility\DoubleMetaPhoneUtility` has been
removed.
* The "hook" :php:`$GLOBALS['TYPO3_CONF_VARS']['EXTCONF']['indexed_search']['metaphone']`
to register an own "metaphone" solution has been removed.
* The extension configuration option :php:`enableMetaphoneSearch` has been removed.
* The database columns :sql:`index_fulltext.metaphonedata` and :sql:`index_words.metaphone`
have been removed.
* A couple of methods and properties in the :php:`@internal` marked indexed_search
classes have been removed and simplified.
Impact
======
Frontend users can no longer select the "Sounds like" option when searching the
website. Backend users do not see statistics about this search variant in the
backend module.
Affected installations
======================
Websites with a search solution based on indexed_search with "metaphone" search
being active in the extension configuration, and with users actively using
the "metaphone" search feature.
Migration
=========
No migration available. Sites that really need this feature should switch to
a more sophisticated search solution.
.. index:: Backend, Database, Frontend, PHP-API, FullyScanned, ext:indexed_search
@@ -0,0 +1,52 @@
.. include:: /Includes.rst.txt
.. _breaking-102902-1706022423:
============================================================
Breaking: #102902 - Search rules removed from Indexed Search
============================================================
See :issue:`102902`
Description
===========
The "Rules" section in Indexed Search stems from a time when today's knowledge
how a search works was considered "advanced". By today's standards, it can be
considered common sense and therefore the rules and its related TypoScript
configuration have been removed.
Impact
======
The Indexed Search plugin doesn't show the rules anymore. The Fluid partial file
:file:`Resources/Private/Partials/Rules.html` and the related TypoScript
configuration :typoscript`:`plugin.tx_indexedsearch.settings.displayRules`
have been removed.
Affected installations
======================
All installations displaying the Indexed Search search rules are affected.
Migration
=========
Fluid
-----
Remove any overrides for the partial file :file:`Resources/Private/Partials/Rules.html`,
as well as the :html:`<f:render partial="Rules" />` invocation from a potentially
overridden :file:`Resources/Private/Partials/Form.html` partial file.
TypoScript
----------
If configured, remove the :typoscript`:`plugin.tx_indexedsearch.settings.displayRules`
configuration.
.. index:: Frontend, TypoScript, NotScanned, ext:indexed_search
@@ -0,0 +1,45 @@
.. include:: /Includes.rst.txt
.. _breaking-102907-1706043066:
==============================================================
Breaking: #102907 - Indexed Search TypoScript settings removed
==============================================================
See :issue:`102907`
Description
===========
Indexed Search previously used a custom link building to generate links and their targets
for linking to search results that are of type "page", instead of the native "typolink" (:php:`LinkFactory`)
system, automatically detecting links to other sites of the same installation and using
the proper :typoscript:`extTarget` setting in TypoScript for creating the target attribute for the link.
For this reason, the two TypoScript settings are removed:
.. code-block:: typoscript
plugin.tx_indexedsearch.settings.detectDomainRecords
plugin.tx_indexedsearch.settings.detectDomainRecords.target
Impact
======
Setting these options have no effect anymore.
Affected installations
======================
TYPO3 installations using indexed search using these options.
Migration
=========
Remove the lines, and adapt config.extTarget accordingly if needed in such cases, as
the links are now generated through TYPO3's native link building APIs.
.. index:: TypoScript, NotScanned, ext:indexed_search
@@ -0,0 +1,60 @@
.. include:: /Includes.rst.txt
.. _breaking-102921-1706170368:
===================================================================
Breaking: #102921 - Remove several outdated indexed search features
===================================================================
See :issue:`102921`
Description
===========
The internal search of TYPO3, Indexed Search exists since over 20 years. Some
functionality that is shipped with the search form is not considered up-to-date
anymore, in regard to templating, as Indexed Search has an Extbase and
Fluid-based plugin since TYPO3 v6.2 (10 years).
Some functionality was never removed, which is now the case:
* The ability to customize the styling of a specific page via
:typoscript:`plugin.tx_indexedsearch.settings.specialConfiguration`
* The ability to customize a result icon (used as Gif images) based on the type
via :typoscript:`plugin.tx_indexedsearch.settings.iconRendering`
* The ability to customize a result language symbol icon (used as Gif images)
based on the page language via :typoscript:`plugin.tx_indexedsearch.settings.flagRendering`
In addition, the possibility for visitors to change only search for results in
a language other than the current language is removed. It proved little sense
to search for e.g. Japanese content on a French websites.
Impact
======
All of the TypoScript settings are not evaluated anymore. The Fluid variables
:html:`{allLanguageUids}`, :html:`{row.language}` and :html:`{row.icon}` are not
filled anymore.
Search only shows results in the language of the currently active language
of the website.
Affected installations
======================
TYPO3 installations using these options or features with Indexed Search.
Migration
=========
Adapt your TypoScript settings, and remove the TypoScript settings and Fluid
variables.
If you still need specific rendering of icons for pages, or customized CSS for
result pages, it is recommended to use Fluid conditions adapted in your custom
template, which is usually not necessary.
.. index:: Frontend, TypoScript, NotScanned, ext:indexed_search
@@ -0,0 +1,59 @@
.. include:: /Includes.rst.txt
.. _breaking-102924-1706178654:
===================================================================
Breaking: #102924 - Single Table Inheritance from fe_groups removed
===================================================================
See :issue:`102924`
Description
===========
Extbase ships with a feature called "Single Table Inheritance", to allow
multiple Extbase domain models reflecting one database table depending on a
specific value of a database field.
TYPO3 has the functionality enabled for the database tables :sql:`fe_users` and
:sql:`fe_groups`.
The respective default models, which do not make a lot of sense as models
depend on a specific domain, have been removed in previous TYPO3 versions.
For frontend user groups, the usage and the usefulness for TYPO3 to ship this out
of the box, has shown little impact. For this reason, the functionality has been
removed. Along with that, the database field :sql:`fe_groups.tx_extbase_type` and its
TCA definition as well as the Extbase configuration as a single table inheritance
option, has been removed.
The functionality for Single Table Inheritance in Extbase and also for frontend
users is working as before without any changes.
.. _Single Table Inheritance: https://en.wikipedia.org/wiki/Single_Table_Inheritance
Impact
======
Using the database field in custom code, or using Single Table Inheritance in
Extbase for frontend user groups will result in SQL and PHP errors.
Affected installations
======================
TYPO3 installations with custom extensions using Single Table Inheritance in
Extbase with frontend usergroups.
Migration
=========
If necessary, extension authors can add Single Table Inheritance in their own
extension for `fe_groups` by themselves.
* Add a database field :sql:`fe_groups.tx_extbase_type` in :file:`ext_tables.sql`
* Add TCA information in :file:`Configuration/TCA/Overrides/fe_groups.php` for the database field
.. index:: Database, TCA, NotScanned, ext:extbase
@@ -0,0 +1,97 @@
.. include:: /Includes.rst.txt
.. _breaking-102925-1706182267:
======================================================
Breaking: #102925 - Template changes in Indexed Search
======================================================
See :issue:`102925`
Description
===========
Due to some major refactorings within EXT:indexed_search, Fluid templates in the
frontend plugins were adapted.
Impact
======
In case Fluid templates of EXT:indexed_search are overridden, the rendered output
may look different and behave unpleasant.
Affected installations
======================
All installations overriding Fluid templates of EXT:indexed_search are affected.
Migration
=========
Pagination
----------
The pagination ViewHelpers have been removed in favor of native pagination API
shipped with TYPO3. Usages of the ViewHelpers `is:pageBrowsingResults` and
`is:pageBrowsing` have been removed.
The Fluid template file `Private/Templates/Search/Search.html` loads a new
JavaScript via :html:`<f:asset.script>`:
.. code-block:: html
<f:asset.script useNonce="true" identifier="indexed_search_pagination" src="EXT:indexed_search/Resources/Public/JavaScript/pagination.js" />
`is:pageBrowsingResults` has been replaced with a short HTML snippet:
.. code-block:: html
<f:sanitize.html>
<f:translate key="displayResults" arguments="{0: result.pagination.startRecordNumber, 1: result.pagination.endRecordNumber, 2: result.count}" />
</f:sanitize.html>
`is:pageBrowsing` has been replaced with a new Fluid partial file:
.. code-block:: html
<f:render partial="Pagination" arguments="{pagination: result.pagination, searchParams: searchParams, freeIndexUid: freeIndexUid}" />
Search result items
-------------------
The following options are now passed to the `Searchresult` partial:
* `row: row`
* `searchParams: searchParams`
* `firstRow: firstRow`
The `Searchresult` partial now registers the `is` namespace for Fluid ViewHelpers:
.. code-block:: html
<html
xmlns:f="http://typo3.org/ns/TYPO3/CMS/Fluid/ViewHelpers"
xmlns:is="http://typo3.org/ns/TYPO3/CMS/IndexedSearch/ViewHelpers"
data-namespace-typo3-fluid="true">
Within the `Searchresult` partial, `{row.rating}` has been replaced with a
ViewHelper invocation:
.. code-block:: html
{is:searchResult.rating(firstRow: firstRow, sortOrder: searchParams.sortOrder, row: row)}
Rules
-----
Remove any overrides for the partial file :file:`Resources/Private/Partials/Rules.html`,
as well as the :html:`<f:render partial="Rules" />` invocation from a potentially
overridden :file:`Resources/Private/Partials/Form.html` partial file.
.. index:: Fluid, Frontend, NotScanned, ext:indexed_search
@@ -0,0 +1,43 @@
.. include:: /Includes.rst.txt
.. _breaking-102931-1706198332:
==============================================
Breaking: #102931 - Removed hook in GifBuilder
==============================================
See :issue:`102931`
Description
===========
The hook :php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['tslib/class.tslib_gifbuilder.php']['gifbuilder-ConfPreProcess']`
has been removed.
This hook was solely introduced in TYPO3 v3.8.0 for a specific use case which
isn't needed anymore, and thus removed.
At the same time the whole :php:`GifBuilder` class is now strictly typed.
Impact
======
PHP code utilizing this hook will not be executed anymore.
Affected installations
======================
TYPO3 installations with extensions utilizing this hook, which is highly unlikely.
Any usages can be found with the Extension Scanner in the Install Tool.
Migration
=========
It is recommended to hand in custom configuration already into GifBuilder
directly, and remove any usages to the hook in custom extension code.
.. index:: PHP-API, FullyScanned, ext:frontend
@@ -0,0 +1,47 @@
.. include:: /Includes.rst.txt
.. _breaking-102932-1706202449:
==============================================================
Breaking: #102932 - Removed TypoScriptFrontendController hooks
==============================================================
See :issue:`102932`
Description
===========
The following frontend TypoScript and page rendering related hooks
have been removed:
* :php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['tslib/class.tslib_fe.php']['configArrayPostProc']`,
substituted by event :php:`ModifyTypoScriptConfigEvent`.
* :php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['tslib/class.tslib_fe.php']['pageLoadedFromCache']`,
no direct substitution, use event :php:`AfterTypoScriptDeterminedEvent` or an own middleware
after :php:`typo3/cms-frontend/prepare-tsfe-rendering` instead.
* :php:`$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['tslib/class.tslib_fe.php']['createHashBase']',
substituted by event :php:`BeforePageCacheIdentifierIsHashedEvent`.
Impact
======
Any such hook implementation registered is not executed anymore
with TYPO3 v13.0+.
Affected installations
======================
TYPO3 installations with custom extensions using above listed hooks.
Migration
=========
See :doc:`PSR-14 event <../13.0/Feature-102932-NewTypoScriptRelatedFrontendEvents>`
for substitutions. The new events are tailored for more restricted use cases and can
be used when existing hook usages have not been "side" usages. Any "off label" hook
usages should be converted to custom middlewares instead.
.. index:: Frontend, PHP-API, FullyScanned, ext:frontend
@@ -0,0 +1,97 @@
.. include:: /Includes.rst.txt
.. _breaking-102935-1706258423:
==========================================================================
Breaking: #102935 - Overhauled extension installation in Extension Manager
==========================================================================
See :issue:`102935`
Description
===========
Installing extensions via the extension manager is only used for non-Composer-based
installations. However, there have been a couple of dependencies to
the `EXT:extensionmanager`, which required even Composer-based installations
to have this extension installed. This has now been resolved. The
`EXT:extensionmanager` extension is now optional.
The public :php:`\TYPO3\CMS\Extensionmanager\Utility\InstallUtility->processExtensionSetup()`
method has therefore been removed. It has previously been used to execute a
couple of "import" tasks, such as import site configurations or media assets to
the :file:`fileadmin/`. However those tasks had dependencies to other optional core
extensions, such as `EXT:impexp`. Therefore the new PSR-14 event
:php:`PackageInitializationEvent` has been introduced and the functionality
has been split into corresponding event listeners, which are added to their
associated Core extensions.
The PSR-14 events, dispatched by those "tasks" have been removed:
* :php:`\TYPO3\CMS\Extensionmanager\Event\AfterExtensionDatabaseContentHasBeenImportedEvent`
* :php:`\TYPO3\CMS\Extensionmanager\Event\AfterExtensionFilesHaveBeenImportedEvent`
* :php:`\TYPO3\CMS\Extensionmanager\Event\AfterExtensionSiteFilesHaveBeenImportedEvent`
* :php:`\TYPO3\CMS\Extensionmanager\Event\AfterExtensionStaticDatabaseContentHasBeenImportedEvent`
The information, provided by those events can now be accessed by fetching the
corresponding storage entry from the new
:php:`\TYPO3\CMS\Core\Package\Event\PackageInitializationEvent`.
Using :php:`before` and :php:`after` keywords in the listener registration,
custom extensions can ensure to be executed, once the corresponding information
is available.
It's even possible to manually execute those "tasks" by dispatching the
:php:`PackageInitializationEvent` in custom extension code. This can be
used as replacement for the :php:`InstallUtility->processExtensionSetup()` call.
Impact
======
Using one of the removed PSR-14 events or calling the removed method will
lead to a PHP error. The extension scanner will report any usages.
Affected installations
======================
TYPO3 installations with extensions registering listeners to the removed events
or calling the removed method in their extension code.
Migration
=========
Instead of registering listeners for the removed events, developers can now
just register a listener to the new :php:`PackageInitializationEvent`, which
contains the listeners result as storage entry:
.. code-block:: php
// Before
#[AsEventListener]
public function __invoke(AfterExtensionSiteFilesHaveBeenImportedEvent $event): void
{
foreach ($event->getSiteIdentifierList() as $siteIdentifier) {
$configuration = $this->siteConfiguration->load($siteIdentifier);
$configuration = $this->extendSiteConfiguration($configuration);
$this->siteConfiguration->write($siteIdentifier, $configuration);
}
}
// After
#[AsEventListener(after: ImportSiteConfigurationsOnPackageInitialization::class)]
public function __invoke(PackageInitializationEvent $event): void
{
foreach ($event->getStorageEntry(ImportSiteConfigurationsOnPackageInitialization::class)->getResult() as $siteIdentifier) {
$configuration = $this->siteConfiguration->load($siteIdentifier);
$configuration = $this->extendSiteConfiguration($configuration);
$this->siteConfiguration->write($siteIdentifier, $configuration);
}
}
Instead of calling :php:`InstallUtility->processExtensionSetup()`, extensions
can just dispatch the :php:`PackageInitializationEvent` on their own.
.. index:: Backend, PHP-API, PartiallyScanned, ext:extensionmanager
@@ -0,0 +1,40 @@
.. include:: /Includes.rst.txt
.. _breaking-102937-1706261180:
================================================================
Breaking: #102937 - `pi1_hooks` hook removed from Indexed Search
================================================================
See :issue:`102937`
Description
===========
Indexed Search provided the possibility to manipulate the search behavior via
hooks with :php:`$GLOBALS['TYPO3_CONF_VARS']['EXTCONF']['indexed_search']['pi1_hooks']`.
There are no public extensions supporting TYPO3 v12 using this hooking mechanism,
therefore it has been removed without replacement. In case there are private consumers
of these hooks, we will allow to add a dedicated event at appropriate places later.
Impact
======
If implemented, hooks in :php:`$GLOBALS['TYPO3_CONF_VARS']['EXTCONF']['indexed_search']['pi1_hooks']`
are not called anymore.
Affected installations
======================
All extensions using this hook are affected.
Migration
=========
No migration available.
.. index:: PHP-API, FullyScanned, ext:indexed_search
@@ -0,0 +1,51 @@
.. include:: /Includes.rst.txt
.. _breaking-102945-1706274593:
=========================================================
Breaking: #102945 - Pagination of Indexed Search replaced
=========================================================
See :issue:`102945`
Description
===========
Indexed Search used a custom crafted pagination, implemented with several
ViewHelpers known as `is:pageBrowsingResults` and `is:pageBrowsing`.
These ViewHelpers have been removed in favor of the existing Pagination API,
leading to template changes.
Impact
======
In case Fluid templates of EXT:indexed_search are overridden, the frontend will
render an exception due to the missing ViewHelpers.
Affected installations
======================
All installations overriding the Fluid template `Templates/Search/Search.html`
of EXT:indexed_search are affected.
Migration
=========
`is:pageBrowsingResults` has been replaced with a short HTML snippet:
.. code-block:: html
<f:sanitize.html>
<f:translate key="displayResults" arguments="{0: result.pagination.startRecordNumber, 1: result.pagination.endRecordNumber, 2: result.count}" />
</f:sanitize.html>
`is:pageBrowsing` has been replaced with a new Fluid partial file:
.. code-block:: html
<f:render partial="Pagination" arguments="{pagination: result.pagination, searchParams: searchParams, freeIndexUid: freeIndexUid}" />
.. index:: Fluid, Frontend, NotScanned, ext:indexed_search
@@ -0,0 +1,62 @@
.. include:: /Includes.rst.txt
.. _breaking-102968-1706440705:
===================================================
Breaking: #102968 - FormEngine itemFormElID removed
===================================================
See :issue:`102968`
Description
===========
When dealing with custom FormEngine elements in the backend record editing
interface, the infrastructure prepares a huge data array and hands it over
to single element classes for rendering.
The specific data key :php:`$this->data['parameterArray']['itemFormElID']`
has been removed. The intention of that key was to prepare some unique id
to be used as :html:`id` attribute. This never made a lot of sense, single
element classes can easily take care of this on their own if needed.
Since the Core can't actively deprecate and log access to members of the main
data array as such, there is no point in declaring a deprecation for it, and
the array entry has been removed directly.
Impact
======
Extensions with custom backend FormEngine elements may raise an
"undefined array key" PHP warning, or may create empty id attributes in
their HTML output if accessing :php:`itemFormElID`.
Affected installations
======================
Instances with extensions that deliver custom FormEngine elements may
be affected.
Migration
=========
A typical use case for a unique :html:`id` attribute on a form element is to
connect it with a :html:`label` element. Accessing :php:`itemFormElID` can
usually be easily avoided by creating a unique string using
:php:`StringUtility::getUniqueId()`, with a custom prefix:
.. code-block:: php
// Before
$attributeId = htmlspecialchars($this->data['parameterArray']['itemFormElID']);
$html[] = '<input id="' . $attributeId . '">';
// After
$attributeId = htmlspecialchars(StringUtility::getUniqueId('formengine-my-custom-element-'));
$html[] = '<input id="' . $attributeId . '">';
.. index:: Backend, PHP-API, NotScanned, ext:backend
@@ -0,0 +1,205 @@
.. include:: /Includes.rst.txt
.. _breaking-102970-1706447911:
========================================================================
Breaking: #102970 - No database relations in FlexForm container sections
========================================================================
See :issue:`102970`
Description
===========
FlexForm handling details can be troublesome in certain scenarios. The Core
suffers from some nasty issues in this area, especially when relations
to other tables are used in FlexForms - the system for instance tends to mix
up things with language and workspace on this level.
The Core strives to get these scenarios sorted out, and a couple of patches to
prepare towards better flex form handling have been done with v13.0 already.
To unblock further development in this area, one detail is restricted a bit more
than with previous versions: FlexForm container section data structures must no
longer contain fields that configure relations to other database tables.
This has already been restricted since TYPO3 v8 for TCA :php:`type="inline"` and
has been partially extended to :php:`type="category"` and others later, if they
configured :php:`MM` relations in FlexForm sections containers. Now, especially
:php:`type="select"` with :php:`foreign_table` will also throw an exception.
In general, anonymous FlexForm container section data can and should not point to
database entities. Their use is tailored for "simple" types like :php:`input`,
:php:`email` and similar, support of those will not be restricted.
Note this does *not* restrict using casual FlexForms without containers sections,
like FlexForm data structures that rely on casual fields in sheets: Those can
continue to work with TCA types like :php:`inline`, :php:`group` and :php:`select`,
and the Core development tries to actively fix existing problematic scenarios
in this area.
Impact
======
When editing records that configure FlexForms with container sections that use
database relation-aware :php:`TCA` types, an exception will be thrown by
FormEngine. The related code may later be relocated to a lower level place
that can be triggered by DataHandler as well.
Affected installations
======================
Instances with extensions that use FlexForm container sections configuring
database relations to tables.
Since previous core versions restricted database relations within FlexForm
container sections already, and since container sections are a relatively rarely
used feature in the first place, we don't expect too many extensions to be
affected by this.
You can easily spot custom usage of FlexForm sections by searching for a :xml:`<section>`
tag within your FlexForm :file:`.xml` files, or within a TCA definition
with :php:`type="flex"`. These will be the instances you need to migrate,
when those sections contain :php:`type="select"` fields (or others mentioned above).
Affected FlexForm XML
---------------------
.. code-block:: xml
:caption: EXT:my_extension/Configuration/FlexForms/Example.xml
:emphasize-lines: 15-38
<?xml version="1.0" encoding="utf-8" standalone="yes" ?>
<T3DataStructure>
<sheets>
<sSection>
<ROOT>
<sheetTitle>section</sheetTitle>
<type>array</type>
<el>
<section_1>
<title>section_1</title>
<type>array</type>
<!-- this is what to look out for: -->
<section>1</section>
<el>
<container_1>
<type>array</type>
<title>container_1</title>
<el>
<select_tree_1>
<label>select_tree_1 pages description</label>
<description>field description</description>
<config>
<type>select</type>
<renderType>selectTree</renderType>
<foreign_table>pages</foreign_table>
<foreign_table_where>ORDER BY pages.sorting</foreign_table_where>
<size>20</size>
<treeConfig>
<parentField>pid</parentField>
<appearance>
<expandAll>true</expandAll>
<showHeader>true</showHeader>
</appearance>
</treeConfig>
</config>
</select_tree_1>
</el>
</container_1>
</el>
</section_1>
</el>
</ROOT>
</sSection>
</sheets>
</T3DataStructure>
Affected FlexForm TCA
---------------------
.. code-block:: php
:caption: EXT:my_extension/Configuration/TCA/tx_myextension_flex.php
:emphasize-lines: 22-45
[
'columns' => [
'flex_2' => [
'label' => 'flex section container',
'config' => [
'type' => 'flex',
'ds' => [
'default' => '
<T3DataStructure>
<sheets>
<sSection>
<ROOT>
<sheetTitle>section</sheetTitle>
<type>array</type>
<el>
<section_1>
<title>section_1</title>
<type>array</type>
<!-- this is what to look out for: -->
<section>1</section>
<el>
<container_1>
<type>array</type>
<title>container_1</title>
<el>
<select_tree_1>
<label>select_tree_1 pages description</label>
<description>field description</description>
<config>
<type>select</type>
<renderType>selectTree</renderType>
<foreign_table>pages</foreign_table>
<foreign_table_where>ORDER BY pages.sorting</foreign_table_where>
<size>20</size>
<treeConfig>
<parentField>pid</parentField>
<appearance>
<expandAll>true</expandAll>
<showHeader>true</showHeader>
</appearance>
</treeConfig>
</config>
</select_tree_1>
</el>
</container_1>
</el>
</section_1>
</el>
</ROOT>
</sSection>
</sheets>
</T3DataStructure>
',
],
],
],
],
]
Migration
=========
Some extensions tried to work around existing restrictions by switching from
:php:`type="inline"` to :php:`type="group"` or :php:`type="select"`, ending
up with the same problematic scenario.
The basic issue is still, that binding database entities to anonymous data
structures is a problematic approach in the first place: A container section
that can be repeated often, combined with the additional built-in feature to
have multiple different sections at the same time, is close to impossible to
manage in a way that does not easily destroy data integrity.
Extensions that rely on this feature need to get rid of this approach: It
typically means rewriting the extension to model relations using :php:`type="inline"`
bound to database columns directly.
.. index:: Backend, FlexForm, TCA, NotScanned, ext:core
@@ -0,0 +1,45 @@
.. include:: /Includes.rst.txt
.. _breaking-102971-1706453204:
====================================================================
Breaking: #102971 - Most classes of EXT:workspaces declared internal
====================================================================
See :issue:`102971`
Description
===========
A few additional classes of extension "workspaces" have been declared :php:`@internal`.
With this, most of the classes are now considered internal handling, except, of
course, dispatched events.
Impact
======
Extensions extending or using workspace classes as PHP API that are now marked
:php:`@internal` may break, when the Core changes such classes. This will not
be considered breaking.
Affected installations
======================
Few extensions extend workspaces as such, and the backend workspaces
application in particular.
Migration
=========
Extension authors who need to extend from classes within EXT:workspaces should
reconsider on why this needs to be done. They should expect these may break
without further notice.
Legit use cases can often be moved towards some additional event instead.
Extension authors are encouraged to come up with specific solutions in those cases.
.. index:: PHP-API, NotScanned, ext:workspaces
@@ -0,0 +1,59 @@
.. include:: /Includes.rst.txt
.. _breaking-102975-1706525161:
===========================================================
Breaking: #102975 - Use full md5 hashes in `indexed_search`
===========================================================
See :issue:`102975`
Description
===========
For historical reasons an integer representation for castrated md5 hashes has
been used in several places for the `ext:indexed_search` provided database schema
and functionality. This led to conflicts that manifested as "duplicate key" errors.
Therefore, the database fields are transformed to varchar fields and the whole
indexed search codebase changed to work with full md5 hashes now.
Due to the database changes it is necessary to truncate the indexed search tables,
which is done within the database analyzer. Reindexing the data is therefore
required.
Field types of following table fields are changed now:
* `index_phash`: `phash`, `phash_grouping`, `contentHash`
* `index_fulltext`: `phash`
* `index_rel`: `phash`, `wid`
* `index_words`: `wid`
* `index_section`: `phash`, `phash_t3`
* `index_grlist`: `phash`, `phash_x`, `hash_gr_list`
* `index_debug`: `phash`
.. note::
Remember to reindex your installation to fill the index again.
Impact
======
Installations using the `ext:indexed_search` need to apply a database schema
change which involves the truncation of the corresponding tables and reindex
the installation.
Affected installations
======================
All installations using `EXT:indexed_search` are affected.
Migration
=========
The database analyzer takes care of updating affected columns and truncates
index related tables to be ready for reindexing.
.. index:: Database, NotScanned, ext:indexed_search
@@ -0,0 +1,53 @@
.. include:: /Includes.rst.txt
.. _breaking-102976-1706528522:
=================================================
Breaking: #102976 - TimeTracker read API internal
=================================================
See :issue:`102976`
Description
===========
Class :php:`\TYPO3\CMS\Core\TimeTracker` is used in the TYPO3 frontend rendering.
It allows tracking time consumed by single code sections. The admin panel uses
gathered data and renders a "time elapsed" overview from it.
All methods and properties that enable or disable tracking details and return
the gathered data have been marked :php:`@internal` and partially moved to
EXT:adminpanel.
Extensions should only write data to :php:`TimeTracker`, methods that are
considered API are these:
* :php:`TimeTracker->push()` (second argument may vanish)
* :php:`TimeTracker->pull()`
* :php:`TimeTracker->setTSlogMessage()`
Impact
======
Extensions using methods other than the ones listed above may raise PHP fatal
errors or different result structures when the underlying code is further
refactored.
Affected installations
======================
Most extensions in the wild use only the above listed methods. There is little
reason to use other methods, except for extension that mimic or extend
functionality of EXT:adminpanel. Instances with such extensions need to follow
changes of class :php:`TimeTracker`.
Migration
=========
No direct migration possible.
.. index:: Frontend, PHP-API, NotScanned, ext:frontend
@@ -0,0 +1,44 @@
.. include:: /Includes.rst.txt
.. _breaking-102980-1706534274:
==============================================================
Breaking: #102980 - getAllPageNumbers() in PaginationInterface
==============================================================
See :issue:`102980`
Description
===========
A method has been added to :php:`\TYPO3\CMS\Core\Pagination\PaginationInterface`
with this signature: :php:`public function getAllPageNumbers(): array;`. It should
return a list of all available page numbers.
The method has already been implemented in
:php:`\TYPO3\CMS\Core\Pagination\SimplePagination` and
:php:`\TYPO3\CMS\Core\Pagination\SlidingWindowPagination`.
Impact
======
Custom implementations of :php:`PaginationInterface` must implement the method.
Affected installations
======================
Instances with extensions that provide own pagination classes that implement
:php:`PaginationInterface` may be affected.
Migration
=========
See the two Core classes :php:`SimplePagination` and :php:`SlidingWindowPagination`
for examples on how the method is implemented.
.. index:: PHP-API, NotScanned, ext:core
@@ -0,0 +1,68 @@
.. include:: /Includes.rst.txt
.. _breaking-102985-1706549304:
==========================================================
Breaking: #102985 - Declare Indexed Search as Content Type
==========================================================
See :issue:`102985`
Description
===========
The plugin configuration of the "Indexed Search" plugin has been changed. The
plugin is now configured as a proper "content element" using the `CType` plugin
type. This allows to further shrink down the `CType=list` and
`list_type=<plugin_name>` combination, like it has already been done with other
plugins, e.g. the "Frontend Login" plugin.
Impact
======
The "Indexed Search" plugin is now configured as a content element, using
`CType=indexedsearch_pi2` instead of the `CType=list` and
`list_type=indexedsearch_pi2` combination.
An upgrade wizard is in place, migrating existing content elements as well
as corresponding backend user group permissions.
Affected installations
======================
All installations with extensions, relying on the "Indexed Search" plugin
using the `CType=list` and `list_type=indexedsearch_pi2` combination. This
might be done in custom database queries, frontend data providers or in
TSconfig. Also in cases where the corresponding backend user group permissions
(:sql:`be_groups.explicit_allowdeny`) are manually evaluated.
Migration
=========
Execute the `Migrate "Indexed Search" plugins to content elements.` upgrade
wizard to automatically migrate existing records. Make sure to have the
`Migrate backend groups "explicit_allowdeny" field to simplified format.`
upgrade wizard executed beforehand.
Additionally, adjust any place relying on the plugin using the
`CType=list` and `list_type=indexedsearch_pi2` combination.
Example SQL migrations:
.. code-block:: sql
-- Before
SELECT * FROM tt_content WHERE CType = 'list' AND list_type = 'indexedsearch_pi2';
-- After
SELECT * FROM tt_content WHERE CType = 'indexedsearch_pi2';
.. code-block:: sql
-- Before
SELECT * FROM be_groups WHERE explicit_allowdeny LIKE '%tt_content:list_type:indexedsearch_pi2%';
-- After
SELECT * FROM be_groups WHERE explicit_allowdeny LIKE '%tt_content:CType:indexedsearch_pi2%';
.. index:: TCA, NotScanned, ext:indexed_search
@@ -0,0 +1,104 @@
.. include:: /Includes.rst.txt
.. _breaking-97330-1687870738:
=========================================================================
Breaking: #97330 - FormEngine element classes must create label or legend
=========================================================================
See :issue:`97330`
Description
===========
When editing records in the backend, the :php:`FormEngine` class structure located
within :file:`EXT:backend/Classes/Form/` handles the generation of the editing view.
A change has been applied related to the rendering of single field labels, which
is no longer done automatically by "container" classes: Single elements have to
create the label themselves.
Extension that add own elements to FormEngine must be adapted, otherwise the
element label is no longer rendered.
Impact
======
When the required changes are not applied to custom FormEngine element classes,
the value of the TCA "label" property is not rendered.
Affected installations
======================
Instances with custom FormEngine elements are affected. Custom elements need to be
registered to the FormEngine's :php:`NodeFactory`, candidates are found by looking at
the :php:`$GLOBALS['TYPO3_CONF_VARS']['SYS']['formEngine']` array (for instance
using the :guilabel:`System > Configuration` backend module provided by
EXT:lowlevel). Classes registered using the sub keys :php:`nodeRegistry` and
:php:`nodeResolver` may be affected. The extension scanner does not find
affected classes.
Migration
=========
Custom elements must take care of creating a :html:`<label>` or :html:`<legend>`
tag on their own: If the element creates an :html:`<input>`, or :html:`<select>` tag,
the :html:`<label>` should have a :html:`for` attribute that points to a field having
an :html:`id` attribute. This is important especially for accessibility. When no such
target element exists, a :html:`<legend>` embedded in a :html:`<fieldset>` can be used.
There are two helper methods in
:php:`\TYPO3\CMS\Backend\Form\Element\AbstractFormElement` to help with this:
:php:`renderLabel()` and :php:`wrapWithFieldsetAndLegend()`.
In practice, an element having an :html:`<input>`, or :html:`<select>` field should
essentially look like this:
.. code-block:: php
$resultArray = $this->initializeResultArray();
// Next line is only needed for extensions that need to keep TYPO3 v12 compatibility
$resultArray['labelHasBeenHandled'] = true;
$fieldId = StringUtility::getUniqueId('formengine-input-');
$html = [];
$html[] = $this->renderLabel($fieldId);
$html[] = '<div class="formengine-field-item t3js-formengine-field-item">';
$html[] = '<div class="form-wizards-wrap">';
$html[] = '<div class="form-wizards-element">';
$html[] = '<div class="form-control-wrap">';
$html[] = '<input class="form-control" id="' . htmlspecialchars($fieldId) . '" value="..." type="text">';
$html[] = '</div>';
$html[] = '</div>';
$html[] = '</div>';
$html[] = '</div>';
$resultArray['html'] = implode(LF, $html);
return $resultArray;
The :php:`renderLabel()` is a helper method to generate a :html:`<label>` tag with a
:html:`for` attribute, and the same fieldId is used as :html:`id` attribute in the
:html:`<input>` field to connect :html:`<label>` and :html:`<input>` with each other.
If there is no such field, a :html:`<legend>` tag should be used:
.. code-block:: php
$resultArray = $this->initializeResultArray();
// Next line is only needed for extensions that need to keep TYPO3 v12 compatibility
$resultArray['labelHasBeenHandled'] = true;
$html = [];
$html[] = '<div class="formengine-field-item t3js-formengine-field-item">';
$html[] = '<div class="form-wizards-wrap">';
$html[] = '<div class="form-wizards-element">';
$html[] = '<div class="form-control-wrap">';
$html[] = Some custom element html
$html[] = '</div>';
$html[] = '</div>';
$html[] = '</div>';
$html[] = '</div>';
$resultArray['html'] = $this->wrapWithFieldsetAndLegend(implode(LF, $html));
return $resultArray;
.. index:: Backend, NotScanned, ext:backend

Some files were not shown because too many files have changed in this diff Show More