- Oct 10, 2024
-
-
Benni Mack authored
Resolves: #104664 Releases: main, 12.4 Change-Id: I9dc840bca30fdc18164c874348b37597dbf3fbbc Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/86451 Tested-by:
Oliver Bartsch <bo@cedev.de> Reviewed-by:
Benjamin Franzke <ben@bnf.dev> Tested-by:
core-ci <typo3@b13.com> Reviewed-by:
-
- Jul 11, 2024
-
-
Simon Schaufelberger authored
Add test coverage for GeneralUtility::getFilesInDir with sorting by mtime. Resolves: #103817 Releases: main Change-Id: I298f63fef0369cf2fefd0876628ca55a152947c9 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/84190 Reviewed-by:
Georg Ringer <georg.ringer@gmail.com> Tested-by:
Benni Mack <benni@typo3.org> Tested-by:
-
- Jul 09, 2024
-
-
Daniel Siepmann authored
The menu generation must not reuse the page record from the current page but must use the data from the linked page. This got already fixed for #101883. But that fix didn't take into account that ->createLink() might throw an exception. This is now considered and the state is properly re- initialized also on exceptions. Resolves: #104335 Related: #103582 Related: #101883 Releases: main, 12.4 Change-Id: Ib4c1f1fba68a83dca32a9ffd7ee14c31cf60bab5 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/85175 Tested-by:
Christian Kuhn <lolli@schwarzbu.ch> Tested-by:
-
- Jun 28, 2024
-
-
Stefan Bürk authored
With PHP 8.4 marking method parameter implicitly nullable is deprecated and will emit a `E_DEPRECATED` warning. One recommended way to resolve this, is making it explicitly nullable using the `?` nullable operator or adding a null tyype to an union type definition. [1] This prepares the way towards PHP 8.4 compatibility. [1] https://php.watch/versions/8.4/implicitly-marking-parameter-type-nullable-deprecated Resolves: #104237 Releases: main, 12.4, 11.5 Change-Id: Ieb8d05b2e44dc448f7a2142c5ad6a91e68cf98c0 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/84973 Tested-by:
Stefan Bürk <stefan@buerk.tech> Tested-by:
-
- Apr 03, 2024
-
-
Georg Ringer authored
The menu generation must not reuse the page record from the current page but must use the data from the linked page. Resolves: #101883 Releases: main, 12.4 Change-Id: I491ed6d2f0d33f9bbe2ef934c4304adfae656808 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/80948 Reviewed-by:
Oliver Klee <typo3-coding@oliverklee.de> Reviewed-by:
Christoph Lehmann <christoph.lehmann@networkteam.com> Tested-by:
Ben Robinson <robinson2.ben@gmail.com> Tested-by:
-
- Jan 26, 2024
-
-
Christian Kuhn authored
Frontend TypoScript has two special details, next to 'configuration' ("constants") and 'setup'. First, there is the determined "PAGE" object that depends on type / typeNum. It allows to render multiple different variants of a pages content. Historically, this has often been a "print" view, nowadays, this is usually a "json" variant, or some XML for sitemaps. A frontend is not rendered without a proper PAGE object. The FE rendering chain determines the given 'type' and maps it to a configured PAGE with this 'typeNum', defaulting to zero '0'. The patch models the determined PAGE object to the Request attribute 'FrontendTypoScript' now, which is used by FE RequestHandler to manage rendering of this PAGE type. Second special thing is 'config' TypoScript as top-level 'config' settings. Those can be overridden by the specific PAGE object (often 'page.config'). A typical use case is 'json.config.disableAllHeaderCode = 1'. This "merged" 'config' array has been available as TSFE->config['config'] before. The patch makes the merged config available in the 'FrontendTypoScript' object as well, available in the Request object as 'frontend.typoscript' attribute. The patch adapts all usages of TSFE->config['config'] to the attribute. There is a special quirk with 'config': This part of TypoScript 'setup' is so important, that it needs to be available in 'fully cached page' scenarios as well, to for instance decide if a content-length header should be added to the response. This has been the reason 'config' has been cached along with page cache content in 'page' cache before. The patch changes this and adds dedicated cache entries for 'merged config' in the (file based) 'typoscript' cache. This reduces page cache size a bit and allows re-using these 'config' cache accross different pages when they are identical, which is determined by the cache identifiers. All these changes are logical follow-ups to the TypoScript parser that has been implemented with v12. They pave the way to extract TypoScript calculation from TypoScriptFrontendController with upcoming patches. Next to this refactoring, the existing hooks in this area had to fall, especially to get rid of their dependency to "pObj" TypoScriptFrontendController. They are mostly substituted by new events, details are documented with the .rst files and class comments. The patch reduces usages of $GLOBALS['TSFE'] and usages of TypoScriptFrontendController in general. $GLOBALS['TSFE']->config['config'] is still available as b/w compat layer (a dedicated deprecation will follow), but core usages have been removed. This became a bit complicated with TimeTrackerInitialization and WorkspacePreview middlewares: Both are run before the final TypoScript 'config' is determined, so they do not have that attribute attached to their incoming Request. But they still need to know TS 'config' details to decide on details *after* calling lower handle() middlewares. They by now accessed $GLOBALS['TSFE'], which is (still) set by a lower middleware. To avoid this indirect state usage, these middlewares now register an event listener that is dispatched after TypoScript 'config' has been determined, and set local state to know if they should add additional Response data. Resolves: #102932 Releases: main Change-Id: I8282f7a93fe9594e78865db63a3e656cc4d5f8da Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/82522 Tested-by:
-
- Jan 24, 2024
-
-
Stefan Bürk authored
TYPO3 v13 requires Doctrine DBAL 4 and will be subsequently updated. Doctrine DBAL 4 is shipping with a few breaking changes, where most breaking stuff is coped and handled by the TYPO3 core and placed in internal API implementation and wrappings. However, minor breaking things on extended and provided API's are included and requires proper adoption by extensions. * [1] `AbstractPlatform::getName()` has been removed and `instance of` checks are required to be used instead. TYPO3 adopted this removal in the extended platform classes and does not provide a b/c for it. * [2] Doctrine DBAL dropped support for older RDBMS version, aligned the Platform class extend chain and removed not-supported version for PostgreSQL and MariaDB. TYPO3 extended platform implementation are aligned and platform replacement in the replacement driver middleware modified. * [3] Doctrine DBAL switched the casing (renaming) of some of the Platform classes, where the new casing has already been used for the extended classes. Due to the fact that aliased `use` import statement has been used, adjusting these casing is minimized to these places. * [4] `Connection::lastInsertId()` no longer accepts a sequence name. TYPO3 core `Connection::getLastInsertId()` implementation is aligned to match this and core usages has been replaced with a pre-patch except one oversight which is done now. * [5] Doctrine DBAL introducing replacement methods for the removed methods `QueryBuilder::resetQueryParam()` and `resetQueryParams()`, which are replaced at required places. Methods are removed on TYPO3 QueryBuilder to be aligned with Doctrine DBAL. * [6] Doctrine DBAL made QueryBuilder's state internal and therefore removed the QueryBuilder methods `getQueryParts()`, `getQueryPart()`, `getType()` and `getState()` along with the public class constants. Methods are removed from the TYPO3 QueryBuilder to align here with Doctrine DBAL. TYPO3 requires access to this internal state, mainly for the Extbase ORM handling and the ContentObjectRenderer. This is solved by introducing a internal `ConcreteQueryBuilder` ensuring a state duplication and adding internal marked public getter to the outer TYPO3 QueryBuilder. * [7] Doctrine DBAL removed schema compare APIs not taking the DB connection into account and suggest to use connection aware comparator instead. `TYPO3\CMS\Install\Database\PermissionsCheck` is modified to respect this change. * [8] Doctrine DBAL removed table renaming by using the `TableDiff` object and not creating corresponding DDL statements anymore. To compensate for this, the already extended `TableDiff` object get the `new name` information reintroduced, and the renaming SQL DDL is directly created at the required place in `ConnectionMigrator`. * [9] Deprecated `SchemaDiff::toSql()` and `toSaveSql()` are replaced with `AbstractPlatform::getAlterSchemaSQL()`. * [10] TYPO3 SchemaMigrator, ConnectionMigrator and Comparator are modified to cope with some modifications in Doctrine DBAL 4. This leads to the requirement that additional normalisation from the MySQL variant (ext_tables.sql) towards the target platform. SQLite autoincrement normalization is moved from SchemaMigrator into the connection migrator and additional MySQL/MariaDB, generic identifier and PostgreSQL normalization is added to cope with this fact. * [11] Due to dropped PostgreSQL 9.6 support Doctrine DBAL switched from `SERIAL` to `GENERATED IDENTITY COLUMN` as virtual autoincrement handling still using sequence tables under the hood. The implemented schema change created by Doctrine DBAL will not migrate the sequence relation correctly and leads to really bad issues. The suggested and documented way is to create and use a procedure to migrate this. This is not suitable for the TYPO3 way of doing the database changes, and the `ConnectionMigrator` is modified to create the update statements taken from the procedure and replacing the normal alter statements. Due to the lack of a good entry point to combine data migration with required DDL changes, this has been implemented as a hackish merged statement for the meanwhile. * \TYPO3\CMS\Core\Database\Platform\PlatformSaveAlterSchemaSQLTrait is removed as "not used anymore" and already mitigated. The required work on the database analyser involved classes revealed badly, that a complete overhaul and restructuring of the code in this area is mandatory but exceeds the scope if this change. Multiple todo comments have been added to make this clear and will be done later. This is possible because the code in this area is considerable internal versus the need to make the breaking change until the dot-zero sprint release. Used command(s): > \ composer req --no-update --no-install \ -d typo3/sysext/redirects \ "doctrine/dbal":"4.0.x-dev@dev" ; \ composer req --no-update --no-install \ -d typo3/sysext/core \ "doctrine/dbal":"4.0.x-dev@dev" ; \ composer req --no-update --no-install \ -d typo3/sysext/install \ "doctrine/dbal":"4.0.x-dev@dev" ; \ composer req -W \ "doctrine/dbal":"4.0.x-dev@dev" ; \ COMPOSER=composer.dist.json composer req --no-update \ -d Build/composer \ "doctrine/dbal":"4.0.x-dev@dev" > Build/Scripts/runTests.sh -s phpstanGenerateBaseline [1] https://github.com/doctrine/dbal/blob/4.0.x/UPGRADE.md#bc-break-doctrinedbaldrivergetname-removed https://github.com/doctrine/dbal/blob/4.0.x/UPGRADE.md#bc-break-removed-support-for-postgresql-93-and-older [2] https://github.com/doctrine/dbal/blob/4.0.x/UPGRADE.md#bc-break-removed-support-for-mariadb-100-and-older https://github.com/doctrine/dbal/blob/4.0.x/UPGRADE.md#bc-break-removed-support-for-mysql-56-and-older [3] https://github.com/doctrine/dbal/blob/4.0.x/UPGRADE.md#bc-break-renamed-sqlite-platform-classes [4] https://github.com/doctrine/dbal/blob/4.0.x/UPGRADE.md#removed-support-for-connectionlastinsertidname [5] https://github.com/doctrine/dbal/blob/4.0.x/UPGRADE.md#deprecated-reset-methods-from-querybuilder [6] https://github.com/doctrine/dbal/blob/4.0.x/UPGRADE.md#deprecated-getting-query-parts-from-querybuilder https://github.com/doctrine/dbal/blob/4.0.x/UPGRADE.md#deprecated-querybuilder-methods-and-constants [7] https://github.com/doctrine/dbal/blob/4.0.x/UPGRADE.md#bc-break-removed-schema-comparison-apis-that-dont-account-for-the-current-database-connection-and-the-database-platform [8] https://github.com/doctrine/dbal/blob/3.7.x/UPGRADE.md#deprecated-renaming-tables-via-tablediff-and-abstractplatformaltertable [9] https://github.com/doctrine/dbal/blob/4.0.x/UPGRADE.md#deprecated-schemadifftosql-and-schemadifftosavesql [10] https://github.com/doctrine/dbal/blob/4.0.x/UPGRADE.md#bc-break-changes-in-handling-string-and-binary-columns [11] https://github.com/doctrine/dbal/blob/4.0.x/UPGRADE.md#bc-break-auto-increment-columns-on-postgresql-are-implemented-as-identity-not-serial https://github.com/doctrine/dbal/blob/4.0.x/docs/en/how-to/postgresql-identity-migration.rst Resolves: #102875 Related: #102589 Related: #102402 Releases: main Change-Id: I547928b5ebba55e574d3a992e864784d8f594653 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/77709 Tested-by:
-
- Jan 19, 2024
-
-
Christian Kuhn authored
FE knows two root lines: TSFE->rootLine, which is the 'full' path to pid 0, and TSFE->config['rootLine'], which is only the 'local' path to the 'root' sys_template record. The full root line is already PageInformation->getRootLine(), created by 'TypoScriptFrontendInitialization' middleware. The very next middleware 'PrepareTypoScriptFrontendRendering' then gets sys_template records and calculates the local root line. The patch relocates sys_template fetching and calculation of the local root line to 'TypoScriptFrontendInitialization', now additionally handled in PageInformationFactory. Both sys_template rows and the local root line are now modeled in PageInformation, which is already attached as 'frontend.page.information' Request attribute. Both root lines are now parellal to each other in the same object, making the entire thing hopefully more easy to understand. Usages are adapted accordingly, further reducing dependencies to TSFE. Note the sys_template row getter is marked @internal since extensions usually don't need to mess around with this. As a side effect, the local root line is no longer cached in page cache: Caching this was duplicate data since sys_template rows need to be fetched for *every* call, and deriving local root line is quick and trivial. This slightly reduces the size of the page cache for a calculation that happens anyway. Resolves: #102873 Releases: main Change-Id: I79c1c138c6ae43fb67dca0d056f67c3c24266f5f Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/82517 Tested-by:
Sascha Nowak <sascha.nowak@netlogix.de> Tested-by:
-
Christian Kuhn authored
Next logical step on the 'get rid of TSFE' path: Avoid the @internal public getters getSite() and getLanguage(), retrieve them from the Request where needed instead. By additionally avoiding already unused PageArguments, TSFE __construct() no longer needs manual arguments. Resolves: #102868 Releases: main Change-Id: I395cc1d628174df657edc1332c703a4aa84666b5 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/82510 Reviewed-by:
Nikita Hovratov <nikita.h@live.de> Tested-by:
-
- Jan 12, 2024
-
-
Christian Kuhn authored
This removes usages of those properties from TSFE that have been modeled as PageInformation object attached to the Request as attribute 'frontend.page.information' with #102715. The patch is relatively intrusive since especially TSFE->page and TSFE->id were frequently consumed properties. It however allows us to reduce dependencies to TSFE quite significantly, the number of calls to $GLOBALS['TSFE'] shrinks. It also shows that we still have a couple of constructs that need to get the Request hand over, in particular the data processors and more importantly the LinkFactory and link builders: Those tend to either get the Request using "parent" ContentObjectRenderer->getRequest() (that method should be declared protected later) or from $GLOBALS['TYPO3_REQUEST']. We accept this for now since using $GLOBALS['TYPO3_REQUEST'] is at least less worse than using $GLOBALS['TSFE']. A dedicated patch will resolve that situation later, though. Note most remaining use TSFE->config, especially TSFE->config['config']. To model this in a good way, we need a preparation within the TypoScript calculation in getFromCache(), which will be a target of one of the next patches. Resolves: #102824 Related: #102715 Releases: main Change-Id: I9336b4215155eb53422016254f8ef2edb0ee86cf Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/82416 Reviewed-by:
-
- Jan 08, 2024
-
-
Benni Mack authored
The following methods now have a strict method signature for all arguments and their return types. - PageRepository->getPage() - PageRepository->getPage_noCheck() - PageRepository->getPageOverlay() - PageRepository->getPagesOverlay() - PageRepository->checkRecord() - PageRepository->getRawRecord() - PageRepository->enableFields() - PageRepository->getMultipleGroupsWhereClause() - PageRepository->versionOL() Calling one of the methods now require proper arguments of the respective types. Resolves: #102775 Releases: main Change-Id: I789453974001113263bc1fdff047adf0eb92c570 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/82364 Reviewed-by:
-
- Jan 06, 2024
-
-
Benni Mack authored
When doing language overlays in PageRepository an overlaid language for a page received special properties: * "_PAGES_OVERLAY_UID" (the UID of the translated page) * "_PAGES_OVERLAY" (a flag indicating that a translation happened) * "_PAGES_OVERLAY_LANGUAGE" (the sys_language_uid record) * "_PAGES_OVERLAY_REQUESTEDLANGUAGE" (info which language was requested) For regular records (non-pages) only one special property was used "_LOCALIZED_UID". This patch unifies the properties, as this was a historical technical debt due to "pages" vs. "pages_language_overlays" and other records. "_PAGES_OVERLAY_UID" is replaced with "_LOCALIZED_UID", "_PAGES_OVERLAY" is removed as a isset check for "_LOCALIZED_UID" can be used "_PAGES_OVERLAY_LANGUAGE" is replaced in favor of the native "sys_language_uid" field "_PAGES_OVERLAY_REQUESTEDLANGUAGE" is replaced with "_REQUESTED_OVERLAY_LANGUAGE" and now also available for non-page records As seen in the changes, some code can now be simplified due to superfluous checks on "_PAGES_OVERLAY_UID" and directly using "_LOCALIZED_UID". Releases: main Resolves: #102627 Change-Id: I7b5c9de66cccc4d2f0907d4d9c51a5b66aa4d4e8 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/82300 Tested-by:
-
- Dec 09, 2023
-
-
Christian Kuhn authored
The context object is injectable singleton state - "Not good but not terrible". There is no need to have a getter in TypoScriptFrontendController for it. Refactor this. A test case mocking can be simplified significantly with this. The "originally requested id" can be retrieved from the 'routing' Request attribute, there is not need to carry a copy as TSFE property around. Resolves: #102640 Releases: main Change-Id: I816570339464ab38bb44b4e8df6773c2ed5c5a8e Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/82158 Reviewed-by:
-
- Dec 01, 2023
-
-
Benni Mack authored
When PHP 8.0 support was added, a lot of places received extra checks with the $conf ?? []. PHPStan complained about this now, as methods already have native PHP types added now, and the check is not needed anymore, so it can be simplified A few other places did not receive proper PHPdoc annotations which has been fixed as well. In addition, some str_ends_with calls are migrated. Resolves: #102528 Releases: main Change-Id: I031d677473d4e9601fbf9d7c90214c311cfea863 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/81975 Tested-by:
Andreas Kienast <a.fernandez@scripting-base.de> Tested-by:
-
- Oct 24, 2023
-
-
Christian Kuhn authored
It's time to update to latest changes of php-cs-fixer to align with current community rules. This brings a rather huge series of changes, main changes due to single_line_empty_body rule which now formats empty class and method body curly braces into a single line, plus changes from function_declaration rule which tends to avoid more whitespaces. The change has a slight impact on phpstan, we regenerate baseline. To reduce backport headaches, this change is backported to v12 and v11. > composer req --dev friendsofphp/php-cs-fixer:^3.35.1 > Build/Scripts/runTests.sh -s cgl > Build/Scripts/runTests.sh -s phpstanGenerateBaseline Resolves: #102236 Releases: main, 12.4, 11.5 Change-Id: Iea45b10667951672b2194033216c49f580799f55 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/81512 Tested-by:
Jasmina Ließmann <minapokhalo+typo3@gmail.com> Reviewed-by:
-
- Oct 15, 2023
-
-
Patrick Schriner authored
The option untrusted is now properly passed to the addQueryString configuration for the menu object. Resolves: #102162 Releases: main, 12.4 Change-Id: Ibdda3dd256d1984f5589c39077f8defc4a4b818a Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/81424 Tested-by:
-
- Sep 25, 2023
-
-
Ramón Schlosser authored
Resolves: #102029 Releases: main, 12.4, 11.5 Change-Id: Idfa299ece1011727da09421ee148a820dc4e0326 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/81234 Reviewed-by:
-
- Jul 04, 2023
-
-
Tim Horstmann authored
Additionally switch $nextActive to boolean Resolves: #100995 Releases: main, 12.4 Change-Id: I0e41835f42753595480afb16182c446991157ec2 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/79258 Tested-by:
Susanne Moog <look@susi.dev> Reviewed-by:
-
Nikita Hovratov authored
Since the swap to LinkResult, the ATagParams and some more attributes are cached independent of different configuration. This is now fixed by adding the following configuration options to the md5 hash: - TMENUITEM: ATagParams - TMENUITEM: additionalParams - TMENU: addParams - TMENU: target Note: Doing this weakens the usefulness of the runtime cache again (especially for old-school TypoScript based menus). Another option would be to add the attributes after the LinkResult generation (how it was done before), but this would bypass possible Event manipulation. Resolves: #100319 Related: #96486 Releases: main, 12.4 Change-Id: I8a0346b5b932f071f9498ddccd7ecceca39deed4 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/79575 Tested-by:
Garvin Hicking <garvinh+typo3@gmail.com> Tested-by:
-
- Jun 12, 2023
-
-
Christian Kuhn authored
Remove old TypoScriptParser, TemplateService and supporting classes. Resolves: #100998 Related: #100963 Related: #99075 Related: #97816 Related: #98503 Related: #99120 Releases: main Change-Id: Ide8a1d7c7a505cd13f9a87149f71d7985ecd1f40 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/79261 Reviewed-by:
-
- Apr 17, 2023
-
-
Christian Kuhn authored
There are two ways of handing over the current request to ContentObjectRenderer after instantiation: By calling setRequest() and by handing the request to start() as third argument. To further streamline request handling, the patch deprecates the second way. Change-Id: I4304e05924ac81a49ce0495bb8de91c70117e804 Resolves: #100637 Resolves: #98632 Related: #92984 Releases: main Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/78684 Tested-by:
-
- Apr 11, 2023
-
-
Christoph Lehmann authored
TSFE->page now holds a copy of the page in default language, so it can be re-used. Resolves: #100371 Releases: main Change-Id: I2f80a9d2e29e9baf3b1747e67d47e3130706205d Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/78344 Tested-by:
-
- Mar 20, 2023
-
-
Benni Mack authored
A new TypoScript option is introduced to allow to set additional tag attributes to links of pages which are access restricted but link to a login page. This works globally for a page, but also for HMENUs. Globally: config.typolinkLinkAccessRestrictedPages.ATagParams = class="restricted" for HMENUs: page.10 = HMENU page.10.showAccessRestrictedPages = 13 page.10.showAccessRestrictedPages.ATagParams = class="access-restricted" Resolves: #19856 Releases: main Change-Id: I21acdb1ef3290491291acb647c164bcfcee1837f Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/78165 Tested-by:
Jochen <rothjochen@gmail.com> Reviewed-by:
-
- Mar 14, 2023
-
-
Christoph Lehmann authored
Hand over the overlayed page record from PageRepository::getSubpagesForPages() to the PageLinkBuilder in order to not fetch and overlay the target page twice. This reduces the amount of SQL queries when building menus. Resolves: #99612 Releases: main Change-Id: Ibb4505f9a5bf95594506730bb988dacdc27046ff Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/77387 Reviewed-by:
-
- Feb 13, 2023
-
-
Thomas Hohn authored
Added Null coalescing operator, when value of $this->mconf['sectionIndex.']['type'] is used. Resolves: #99866 Releases: main, 11.5 Change-Id: I0b6969b353bf7a55b640f71ced64c06c7539cf27 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/77779 Tested-by:
Guido Schmechel <guido.schmechel@brandung.de>
-
- Jan 23, 2023
-
-
Christoph Lehmann authored
When isSubMenu() decides, that the current page has no subpages, then do not try to fetch its subpages. Resolves: #99657 Releases: main Change-Id: I7f3395ad9caf17c3db3aaea7927b7bfb9acb924c Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/77519 Reviewed-by:
Anja Leichsenring <aleichsenring@ab-softlab.de> Reviewed-by:
-
- Jan 20, 2023
-
-
Christoph Lehmann authored
The method now pre-fetches and caches subpages for all pages on the same level in order to reduce the amount of database queries. Have a menu with 50 subpages - WITHOUT this: 50 SQL queries - WITH this: 1 SQL query Resolves: #99622 Releases: main Change-Id: Ia1372c2548a58a090a109b0938b965fe11d5d1ab Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/77484 Tested-by:
-
- Jan 18, 2023
-
-
Benni Mack authored
PageRepository's public properties "where_hid_del" and "where_groupAccess" which are used to modify a SQL query to fetch pages are now marked as protected, thus not accessible anymore for outside usage. Any usage will trigger a PHP deprecation notice. Resolves: #99588 Releases: main Change-Id: Ic8479e05dcaa72b4e9b7d5fbd3e56220dadd8f1e Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/77405 Reviewed-by:
-
- Nov 20, 2022
-
-
Christian Kuhn authored
Method return annotations identical to the return signature are useless and can be omitted. Resolves: #99143 Releases: main Change-Id: I5f268dfd166667df9df23e504575fcd904678b16 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/76740 Tested-by:
-
Christian Kuhn authored
Method parameter annotations identical to the parameter signature are useless and can be omitted. Resolves: #99142 Releases: main Change-Id: I907113b7049d551113c84aadec74c93597252069 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/76734 Tested-by:
-
- Nov 17, 2022
-
-
Ingo Fabbri authored
With `fallbackType` set to strict, only translated content is rendered. In AbstractMenuContentObject->sectionIndex content is fetched and overlayed. Once there is an element untranslated, the record overlay will return a $row = `null`. To mitigate, move all left over access to $row inside the guarded if-block. Resolves: #98043 Releases: main, 11.5 Change-Id: If4baf0fb88292cb8c6814539cf7efa610ae850f3 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/75318 Tested-by:
-
- Nov 04, 2022
-
-
Loek Hilgersom authored
The "hash" cache for (TMENU) menu generation is very ineffective: The cache identifier hash contains the page rootline, so it is single page specific. This leads to quite some pollution of the "hash" cache, often many more entries than page cache entries, without high re-use / cache-hit rate. Looking closer at this, we found the menu generation cache to be so ineffective that it's better to not cache at all. We first thought a runtime cache would be a good solution but even that one is not helpful and there are further runtime caches on lower levels already, for instance to resolve shortcut pages. The patch removes this cache layer, leading to a drastically smaller "hash" cache. Resolves: #98964 Releases: main Change-Id: Iadd3ad77f4d2d4683b91ca7b1f27a779ff899d26 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/76384 Tested-by:
Loek Hilgersom <loek@netcoop.nl> Tested-by:
-
- Oct 29, 2022
-
-
Benni Mack authored
This change allows to use the LinkResult object for custom HMENU generation moving HMENU to be more consistent like typolink() has been aligned in TYPO3 v12 as well. The related code pieces are rather internal and hardly relevant to userland code outside of TYPO3 Core. Resolves: #98464 Releases: main Change-Id: I886db8092b3c81cdf4d8d0fa06dde1b473cc1683 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/75869 Tested-by:
-
- Oct 25, 2022
-
-
Christian Kuhn authored
The patch introduces the new request attribute TypoScriptRequestAttribute as 'frontend.typoscript'. It is set up in the Frontend middleware chain, extensions and content objects can use this attribute to retrieve TypoScript settings and setup. This obsoletes usages of TSFE->tmpl, the patch switches usages to the request attribute. Note we're also establishing a better wording: The old TypoScript 'constants' are now called 'settings'. This matches much better, should avoid confusion for newcomers and is in line with further renaming of a vaguely anticipated new 'constants editor' towards 'settings editing' or similar. Further patches in this naming area will follow. Change-Id: Ib6ffb91db9bf0976f39759b12983d78418d64efa Resolves: #98914 Releases: main Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/76239 Tested-by:
-
- Oct 18, 2022
-
-
Benni Mack authored
This change modifies most of the userland code to use a) Connection::PARAM_* constants instead of \PDO::PARAM_* constants This is due to also another change from Doctrine DBAL 3 https://github.com/doctrine/dbal/blob/3.4.x/UPGRADE.md#bc-break-the-pdo-symbols-are-no-longer-part-of-the-dbal-api which can easily be changed in TYPO3's Source Code to ensure easy upgrade paths and showing best practices for extension authors looking into TYPO3 Source Code b) Avoid using constants from \Doctrine\DBAL\Connection but use our own constants. Even though Doctrine DBAL 3.x introduces "ParameterType" objects, we use our own connection implementation for the time being as we also seek to backport such changes in TYPO3 v11. c) Avoid using the Connection::PARAM_STR for ->createNamedParameter as second argument, as this is the default value. All of these changes will make the upgrade path towards Doctrine DBAL 4.x easier. The initial change was made with Rector - thanks to @schreiberten $rectorConfig->ruleWithConfiguration( \Rector\Renaming\Rector\ClassConstFetch\RenameClassConstFetchRector::class, [ new \Rector\Renaming\ValueObject\RenameClassAndConstFetch( \PDO::class, 'PARAM_INT', \TYPO3\CMS\Core\Database\Connection::class, 'PARAM_INT' ), .... PDO constants are now solely used within our own Database adapter code. Resolves: #98649 Releases: main, 11.5 Change-Id: Ife2569ddeda31e37d4c575d96beb4d41e9affff7 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/76156 Tested-by:
-
- Oct 10, 2022
-
-
Stefan Bürk authored
PostgresSQL seems to get picky with upper case column names, if they are not proper quoted in queries, like `pages.SYS_LASTCHANGED` as example. Executing such database queries will return database error message like ERROR: column "sys_lastchanged" does not exist also it has been provided as upper case variant. Related to system architecture and historical build up sometimes sql parts are build manually instead of using QueryBuilder directly. Thus fields and values are eventually not properly quoted, thus leading to this error message. This can be verified using ext:styleguide frontend pages and open the `/menu-recently-updated` using postgres dbms backend. This change ensures proper quoting for build up of the extraWhere (or additionalWhere) in core content object class `\TYPO3\CMS\Frontend\ContentObject\Menu\AbstractMenuContentObject`. Resolves: #98561 Releases: main, 11.5 Change-Id: I28541eafd1ceee360c78b54d24967286ec66ea9a Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/76035 Tested-by:
-
- Sep 21, 2022
-
-
Oliver Bartsch authored
Resolves: #98248 Releases: main, 11.5 Change-Id: I365236b8aa959db5092a7c8ba1731674b12f053c Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/75811 Tested-by:
-
- Sep 06, 2022
-
-
Benni Mack authored
This change removes all usages of "getRecordOverlay" to slowly phase out "getRecordOverlay" as a legacy method, where new PSR-14 events can be added into getLanguageOverlay() properly. This is a pre-patch to introduce new PSR-14 events and remove the old hooks. Resolves: #98182 Releases: main Change-Id: I55ce26928633f211891fb8a5cbe32755fc96704d Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/75524 Tested-by:
-
- Jul 18, 2022
-
-
Christian Kuhn authored
With the new TypoScript parser, we should start phasing out TemplateService (tsfe->tmpl in FE). One of it's usages in Frontend is tmpl->rootLine. This property looks as if it's identical to tsfe->rootLine, but it isn't, since it's in a different order and stops at sys_template records with root flag. However, tmpl->rootLine is also assigned in Frontend as tsfe->config['rootLine']. The patch changes all usages of tmpl->rootLine to this and sanitizes access along the way. Additional comments now document the subtle differences. We do not add a deprecation at this point, since the entire class will be fully deprecated later. Note the new TypoScript parser construct can not expose this "local" or "partial" rootLine yet. The TypoScript/IncludeTree/TreeBuilder class will be refactored a bit with an additional patch when the new parser is being used in the Frontend. Change-Id: Ic97d0c7344711d07d2ff672ca3b2968ef9383c14 Resolves: #97963 Releases: main Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/75232 Tested-by:
-
- Jul 12, 2022
-
-
Benni Mack authored
This is a precursor for several language-related Extbase bugfixes, allowing to hand over a custom LanguageAspect into PageRepository->getRecordOverlay() instead of the legacy naming conventions. Resolves: #97903 Releases: main, 11.5 Change-Id: I06f6e889bc0e9f052a79fc8f719b090bface0f77 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/75100 Tested-by:
-
