- 05 Jun, 2020 1 commit
-
-
This patch ensures the linkText is returned and used if the target page is not available in the current language. Resolves: #90182 Releases: master, 10.4 Change-Id: Ifed1921ff42746582dd5abab93fafe7a29c12233 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/64796 Tested-by:
TYPO3com <noreply@typo3.com> Tested-by:
Andreas Fernandez <a.fernandez@scripting-base.de> Reviewed-by:
Andreas Fernandez <a.fernandez@scripting-base.de>
-
- 15 Apr, 2020 2 commits
-
-
Markus Klein authored
Fix the condition whether a page is linkable in the requested language or not. Resolves: #90850 Releases: master, 9.5, 8.7 Change-Id: I720c09cc1f938b5000980bcba20786a5cf41f98d Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/63946 Tested-by:
TYPO3com <noreply@typo3.com> Tested-by:
Oliver Bartsch <bo@cedev.de> Tested-by:
Christian Eßl <indy.essl@gmail.com> Reviewed-by:
Andreas Fernandez <a.fernandez@scripting-base.de> Reviewed-by:
Oliver Bartsch <bo@cedev.de> Reviewed-by:
Josef Glatz <josefglatz@gmail.com> Reviewed-by:
Guido Schmechel <guido.schmechel@brandung.de> Reviewed-by:
Christian Eßl <indy.essl@gmail.com>
-
With this patch, the header comment of php files is automatically added by the php-cs-fixer, which guarantees that its format and place of occurrence remain the same in all files. Files that are copied over from other projects are excluded. Furthermore, files that are kind of inspired by other projects also get the same header comment but may have a second, additional comment explaining its origin. Used command: bin/php-cs-fixer fix --config=Build/php-cs-fixer/header-comment.php Releases: master Resolves: #91024 Change-Id: I5a040517e0fbde6e5a27d589bf2f222078326dc8 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/64159 Tested-by:
TYPO3com <noreply@typo3.com> Tested-by:
Andreas Fernandez <a.fernandez@scripting-base.de> Tested-by:
Benni Mack <benni@typo3.org> Reviewed-by:
Andreas Fernandez <a.fernandez@scripting-base.de> Reviewed-by:
Benni Mack <benni@typo3.org>
-
- 14 Apr, 2020 1 commit
-
-
This change adds two changes 'blank_line_after_opening_tag' => true, 'single_trait_insert_per_statement' => true, to our PHP-CS Fixer configuration, adopting more rules related to PSR-12. Resolves: #91020 Releases: master Change-Id: I180b2cbceb077911bddeb42d9f131e5b32244ed2 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/64158 Tested-by:
Josef Glatz <josefglatz@gmail.com> Tested-by:
Oliver Bartsch <bo@cedev.de> Tested-by:
Alexander Schnitzler <git@alexanderschnitzler.de> Tested-by:
Andreas Fernandez <a.fernandez@scripting-base.de> Tested-by:
TYPO3com <noreply@typo3.com> Reviewed-by:
Josef Glatz <josefglatz@gmail.com> Reviewed-by:
Oliver Bartsch <bo@cedev.de> Reviewed-by:
Alexander Schnitzler <git@alexanderschnitzler.de> Reviewed-by:
Andreas Fernandez <a.fernandez@scripting-base.de>
-
- 13 Apr, 2020 1 commit
-
-
As a preparation to be compatible with PSR-12, all spaces in strict type declerations are removed. Releases: master Resolves: #91009 Change-Id: I2b7c2fda42b44168b5c4c6b21711eede2eadaf2e Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/62104 Tested-by:
TYPO3com <noreply@typo3.com> Tested-by:
Oliver Bartsch <bo@cedev.de> Tested-by:
Andreas Fernandez <a.fernandez@scripting-base.de> Reviewed-by:
Oliver Bartsch <bo@cedev.de> Reviewed-by:
Andreas Fernandez <a.fernandez@scripting-base.de>
-
- 27 Mar, 2020 1 commit
-
-
This adds a similar condition that already existed in the old link generation for the new routing-based link building. The conditions are adjusted accordingly. Change-Id: I467f0ce9695fd33ab1e1545e1ba0728c037d3e93 Resolves: #89068 Releases: master, 9.5 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/61615 Tested-by:
TYPO3com <noreply@typo3.com> Tested-by:
Susanne Moog <look@susi.dev> Tested-by:
Daniel Goerz <daniel.goerz@posteo.de> Reviewed-by:
Susanne Moog <look@susi.dev> Reviewed-by:
Daniel Goerz <daniel.goerz@posteo.de>
-
- 22 Jan, 2020 1 commit
-
-
Benni Mack authored
If a multi-site setup contains a page with slug "/products" as DOKTYPE=7 and "/products" in another site which is the Mounted Page the PageRouter goes in an endless-loop as there is no context in the recursive call. In addition, some other changes that have been adapted in the previous 9.5 backport are addressed now. On top, there is now a MountPointScenario which serves as a basis for adding more functionality in multi-lingual setups. The next step is also to remove the redirect of the MountPoint page with mount_pid_ol=1. Resolves: #90166 Related: #86331 Releases: master, 9.5 Change-Id: If5c67ac813430f54737192341e22b58c9c275cf6 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/63007 Tested-by:
TYPO3com <noreply@typo3.com> Tested-by:
Daniel Goerz <daniel.goerz@posteo.de> Tested-by:
Susanne Moog <look@susi.dev> Tested-by:
Benni Mack <benni@typo3.org> Reviewed-by:
Daniel Goerz <daniel.goerz@posteo.de> Reviewed-by:
Susanne Moog <look@susi.dev> Reviewed-by:
Benni Mack <benni@typo3.org>
-
- 15 Jan, 2020 1 commit
-
-
Benni Mack authored
In order to link to mountpoints with Site Handling, the RootlineUtility needs to receive the MountPoint parameter, to correctly deal with mountpoint-related subpages. Mount Points are based on the assumption that the "context" (the original site environment) is kept. For this to work, the slug of the mount page (doktype=7) is prefixed to the URL, but the common prefix of the subpages is trimmed with the value of the mounted page (= pointer record). The MP parameter is then added to PageArguments within the PageArguments as "routeArgument" (= safe and clean argument) where TYPO3 is dealing with this feature again in the same fashion it as before. Various side-effects when dealing with mount points from other domains still exist (= different language setup, or non-existing sites). Feature Set: * Multi-language setup (= when language setup is the same) with slugs * Recursive mount points * No MP parameter available in URLs anymore (at all) * Multi-site setup (= when language setup is the same) If a subpage of a mount page does not inherit the slug of the mounted page, then the slug of the subpage is added in full afterwards. Resolves: #86331 Resolves: #87473 Resolves: #89039 Releases: master, 9.5 Change-Id: I58f41eb325a07cc0c4a0dfeab1164eb8c58c7314 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/62878 Tested-by:
TYPO3com <noreply@typo3.com> Tested-by:
Susanne Moog <look@susi.dev> Tested-by:
Daniel Siepmann <coding@daniel-siepmann.de> Tested-by:
Benni Mack <benni@typo3.org> Reviewed-by:
Susanne Moog <look@susi.dev> Reviewed-by:
Daniel Goerz <daniel.goerz@posteo.de> Reviewed-by:
Benni Mack <benni@typo3.org>
-
- 13 Jan, 2020 1 commit
-
-
HMENU provides a way to directly create the external link if a page is of type "External URLs" but typolink does not resulting in a) more bandwidth / hits for TYPO3 when using typolink b) different results / expectations. The patch makes typolink handle external URLs like HMENU. Resolves: #90008 Releases: master Change-Id: I712e79f2a399b50d9781bca75f623a419a29f09e Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/62630 Tested-by:
TYPO3com <noreply@typo3.com> Tested-by:
Susanne Moog <look@susi.dev> Tested-by:
Daniel Goerz <daniel.goerz@posteo.de> Reviewed-by:
Jörg Bösche <typo3@joergboesche.de> Reviewed-by:
Susanne Moog <look@susi.dev> Reviewed-by:
Daniel Goerz <daniel.goerz@posteo.de>
-
- 30 Dec, 2019 1 commit
-
-
php bin/rector process A couple of rectors have been disabled due to different reasons: - Rector\Php71\Rector\FuncCall\CountOnNullRector This rector has been disabled as it creates rather long and complex structures to avoid calling count on null. This rector will be enabled as soon as TYPO3 uses at least PHP 7.3 which introduces a "is_countable" method. - Rector\Php71\Rector\Assign\AssignArrayToStringRector This rector has been disabled as it does not work properly. The default types of parameters have been changed although their types could properly be inferred by a doc block or by value assignments. - Rector\Php71\Rector\BinaryOp\BinaryOpBetweenNumberAndStringRector This rector has been disabled as it does not work properly. A bug report is filed and to be found here: https://github.com/rectorphp/rector/issues/2454 - Rector\Php71\Rector\FuncCall\RemoveExtraParametersRector This rector has been disabled as it does not work properly. It removed arguments in tests, especially when using prophecies. Releases: master Resolves: #90002 Change-Id: I6ed14d38cc697a23104286db57535d6a3c0dbf62 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/62751 Tested-by:
TYPO3com <noreply@typo3.com> Tested-by:
Benni Mack <benni@typo3.org> Tested-by:
Anja Leichsenring <aleichsenring@ab-softlab.de> Reviewed-by:
Benni Mack <benni@typo3.org> Reviewed-by:
Anja Leichsenring <aleichsenring@ab-softlab.de>
-
- 07 Oct, 2019 1 commit
-
-
Make spelling in TYPO3 great again. Resolves: #89290 Releases: master Change-Id: I520840dd0774aa5d658ce6a45811aa6282c9e461 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/61845 Tested-by:
TYPO3com <noreply@typo3.com> Tested-by:
Jörg Bösche <typo3@joergboesche.de> Tested-by:
Daniel Goerz <daniel.goerz@posteo.de> Reviewed-by:
Jörg Bösche <typo3@joergboesche.de> Reviewed-by:
Daniel Goerz <daniel.goerz@posteo.de>
-
- 17 Jul, 2019 1 commit
-
-
Since Context API was introduced in TYPO3 v9, PageRepository is highly decoupled from $TSFE->sys_page, and fully works standalone. It is also used in various places where TSFE is not needed, or required, but also in places of EXT:core. Especially parts like RootlineUtility, which depends on PageRepository very much, cannot live without it. I propose to move this highly important PHP class into EXT:core, in order to allow to decouple EXT:frontend even further from EXT:core. The FQCN is moved from - \TYPO3\CMS\Frontend\Page\PageRepository to - TYPO3\CMS\Core\Domain\Repository\PageRepository It can be assumed to use PageRepository for any use-case and actually reduce usages towards BackendUtility::get... by using this API more and more. Further adaptions could be to reduce the logic within PageRepository and move this into QueryBuilder and assimilate especially the "versionOL" behavior. Resolves: #88746 Releases: master Change-Id: Id8225100ac60bd77fc7e1303efb4c46b741d3415 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/61166 Tested-by:
TYPO3com <noreply@typo3.com> Tested-by:
Georg Ringer <georg.ringer@gmail.com> Tested-by:
Benjamin Franzke <bfr@qbus.de> Reviewed-by:
Oliver Klee <typo3-coding@oliverklee.de> Reviewed-by:
Georg Ringer <georg.ringer@gmail.com> Reviewed-by:
Benjamin Franzke <bfr@qbus.de>
-
- 26 Jun, 2019 1 commit
-
-
There are some leftovers where PseudoSite is mentioned. Since TYPO3 v10.0 is built on Site Handling completely, this logic is removed. Resolves: #88625 Releases: master Change-Id: I9f3b3a6c9a4bf29c2b509246c02d64aa5f536b4e Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/61123 Tested-by:
TYPO3com <noreply@typo3.com> Tested-by:
Daniel Gorges <daniel.gorges@b13.de> Tested-by:
Anja Leichsenring <aleichsenring@ab-softlab.de> Reviewed-by:
Daniel Gorges <daniel.gorges@b13.de> Reviewed-by:
Anja Leichsenring <aleichsenring@ab-softlab.de>
-
- 17 Jun, 2019 1 commit
-
-
SiteMatcher is a container around SiteFinder now as PseudoSite handling was removed, so SiteFinder can be used directly. Resolves: #88568 Releases: master Change-Id: Ib0f5a42351ed5c11c25458b74074b80f5c574bbd Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/61043 Tested-by:
TYPO3com <noreply@typo3.com> Tested-by:
Andreas Fernandez <a.fernandez@scripting-base.de> Tested-by:
Benjamin Franzke <bfr@qbus.de> Reviewed-by:
Andreas Fernandez <a.fernandez@scripting-base.de> Reviewed-by:
Benjamin Franzke <bfr@qbus.de>
-
- 22 May, 2019 1 commit
-
-
Having Site Handling in place, the option "useCacheHash" rendered useless as it is added by TYPO3 Core automatically when necessary with SiteHandling. Any Fluid Arguments haven't been deprecated as this was part of the the legacy functionality. Now the options are still available, but trigger a deprecation message that the option is superfluous and should be removed. Calling typolink.useCacheHash will now trigger a deprecation message. Resolves: #88406 Releases: master Change-Id: I2243a335188c3466b8f8f59e8d3e417f13bf854d Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/60774 Tested-by:
TYPO3com <noreply@typo3.com> Tested-by:
Anja Leichsenring <aleichsenring@ab-softlab.de> Tested-by:
Andreas Fernandez <a.fernandez@scripting-base.de> Tested-by:
Georg Ringer <georg.ringer@gmail.com> Reviewed-by:
Anja Leichsenring <aleichsenring@ab-softlab.de> Reviewed-by:
Andreas Fernandez <a.fernandez@scripting-base.de> Reviewed-by:
Georg Ringer <georg.ringer@gmail.com>
-
- 16 May, 2019 1 commit
-
-
Due to some heavy history on the caching framework, all Database caches start with "cf_cache_", which is optimized so they are only called e.g. "cache_pagesection" in the database tables. In addition, the prefix "cache_" (in e.g. "cache_core") is unnecessary, and also there due to legacy reasons, reading $this->getCache('cache_runtime') seems very illogical. The following caches have been renamed: - cache_core => core - cache_hash => hash - cache_pages => pages - cache_pagesection => pagesection - cache_runtime => runtime - cache_rootline => rootline - cache_imagesizes => imagesizes Old identifiers can still be called within PHP, but the caching framework throws a deprecation message on setting up such a cache. A silent upgrade wizard will update one's LocalConfiguration to use the new naming scheme. The result is a cleaner, more readable and more streamlined code base (we have caches like "extbase" or "assets" where there is no prefix) and database structure. The patch is breaking due to the change in the database tables. Resolves: #88366 Releases: master Change-Id: I13dcdb0d1bf78f0899615e850856de081b715358 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/59661 Tested-by:
TYPO3com <noreply@typo3.com> Tested-by:
Andreas Fernandez <a.fernandez@scripting-base.de> Tested-by:
Anja Leichsenring <aleichsenring@ab-softlab.de> Reviewed-by:
Andreas Fernandez <a.fernandez@scripting-base.de> Reviewed-by:
Anja Leichsenring <aleichsenring@ab-softlab.de>
-
- 15 May, 2019 1 commit
-
-
This change removes the compatibility layer of Site Handling, called "PseudoSite" handling. Any TypoScript-related Language properties are removed. - config.sys_language_uid - config.sys_language_mode - config.sys_language_overlay - config.locale_all - config.language - config.typolinkEnableLinksAcrossDomains - typolink.useCacheHash The hook $GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['t3lib/class.t3lib_tstemplate.php']['linkData-PostProc'] is removed. In addition, all tests related to PseudoSite and linking without SiteHandling are removed, linking to pages without a site will not be linked anymore. Adding `useCacheHash` to typolink triggers a "this does not do anything anymore" deprecation message. Further related removals (old "pageNotFound" handling and "useCacheHash" in all viewhelpers), are removed separately. Resolves: #88363 Releases: master Change-Id: I14f2f854e69c98df7fab8b14f92f1ec2440a15a0 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/59366 Tested-by:
TYPO3com <noreply@typo3.com> Tested-by:
Anja Leichsenring <aleichsenring@ab-softlab.de> Tested-by:
Andreas Fernandez <a.fernandez@scripting-base.de> Reviewed-by:
Anja Leichsenring <aleichsenring@ab-softlab.de> Reviewed-by:
Andreas Fernandez <a.fernandez@scripting-base.de>
-
- 08 May, 2019 1 commit
-
-
On old OS with ICU < 4.6, the constant INTL_IDNA_VARIANT_UTS46 is not available, even if php-intl is installed. Therefore, a wrapper is created in HttpUtility to check if the constant is available, then uses INTL_IDNA_VARIANT_UTS46 otherwise the 2003 version of the HttpUtility. Also see the section about INTL_IDNA_VARIANT_UTS46 within https://www.php.net/manual/en/intl.constants.php Resolves: #87953 Releases: master, 9.5 Change-Id: I594c0ffd9afa115de595b0c027bf2474c3abfafb Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/60710 Reviewed-by:
Sven Juergens <typo3@blue-side.de> Reviewed-by:
Kevin Meckl <kevin.meckl@zdrei.com> Reviewed-by:
Timo Poppinga <timo.poppinga@zdrei.com> Reviewed-by:
Andreas Fernandez <a.fernandez@scripting-base.de> Tested-by:
TYPO3com <noreply@typo3.com> Tested-by:
Timo Poppinga <timo.poppinga@zdrei.com> Tested-by:
Andreas Fernandez <a.fernandez@scripting-base.de>
-
- 25 Mar, 2019 1 commit
-
-
When a page (slug) is modified in a preview workspace, links to that page need to be changed to the new slug, as the preview (PageRouter) should evaluate this as well. 1) The PageRouter should include records with "-1" to find them as well, but then fix the "pid" again to find the pid of the online version. 2) The PageLink Builder now uses the SiteFinder nstead of SiteMatcher to detect whether the linked page uid is part of a configured site. We do not need to create/detect a PseudoSite here, only instances of Site are of interest. Resolves: #87871 Releases: master, 9.5 Change-Id: Ifd6add71bec1616049f8c6a50a42bc9f573395e2 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/59955 Tested-by:
Benjamin Franzke <bfr@qbus.de> Tested-by:
TYPO3com <noreply@typo3.com> Tested-by:
Oliver Hader <oliver.hader@typo3.org> Reviewed-by:
Benjamin Franzke <bfr@qbus.de> Reviewed-by:
Oliver Hader <oliver.hader@typo3.org>
-
- 22 Mar, 2019 1 commit
-
-
The new pagelink builder does not set the lastTypoLinkLD options which is used in HMENUs. The patch properly sets the lastTypoLink* properties of ContentObjectRenderer in typolink again, making target overrides in menus work again. Resolves: #87130 Releases: master, 9.5 Change-Id: Ia284e546179dfaec8ec8ecb86a36d38f3b81aad8 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/60292 Tested-by:
TYPO3com <noreply@typo3.com> Tested-by:
Georg Ringer <georg.ringer@gmail.com> Tested-by:
Frank Naegler <frank.naegler@typo3.org> Reviewed-by:
Georg Ringer <georg.ringer@gmail.com> Reviewed-by:
Frank Naegler <frank.naegler@typo3.org>
-
- 16 Mar, 2019 1 commit
-
-
It is safe to use idn_to_ascii() these days due to symfony's polyfill functionality. This allows us to remove the dependency "algo26-matthias/idna-convert". Also, all other places now use the native idn_to_ascii() call, which could speed up performance. The wrapper call GeneralUtility::idnaEncode() can then safely be deprecated. used composer command: composer remove algo26-matthias/idna-convert Resolves: #87894 Releases: master Change-Id: I85aa6f39b8ff5ac171cd73218ed1144a56d9f724 Reviewed-on: https://review.typo3.org/c/60234 Reviewed-by:
Benjamin Franzke <bfr@qbus.de> Reviewed-by:
Stephan Großberndt <stephan.grossberndt@typo3.org> Reviewed-by:
Georg Ringer <georg.ringer@gmail.com> Tested-by:
TYPO3com <noreply@typo3.com> Tested-by:
Benjamin Franzke <bfr@qbus.de> Tested-by:
Georg Ringer <georg.ringer@gmail.com>
-
- 08 Mar, 2019 1 commit
-
-
PageLinkBuilder::populateMountPointMapForPageRecursively() requires the $id parameter to be an integer, so this is cast properly now. In addition, one regression is fixed where "config.MP_mapRootPoints = root" was set, the proper variables are now used. Resolves: #87547 Resolves: #87473 Releases: master, 9.5 Change-Id: I899120d301309d768b9e498ad7f4ec96b9618b9d Reviewed-on: https://review.typo3.org/c/59916 Tested-by:
Markus Klein <markus.klein@typo3.org> Tested-by:
TYPO3com <noreply@typo3.com> Tested-by:
Georg Ringer <georg.ringer@gmail.com> Reviewed-by:
Markus Klein <markus.klein@typo3.org> Reviewed-by:
Oliver Klee <typo3-coding@oliverklee.de> Reviewed-by:
Georg Ringer <georg.ringer@gmail.com>
-
- 04 Mar, 2019 1 commit
-
-
This commit solves some issues regarding language fallback handling: - Resolve correct page for a localized variant respecting fallbacks The Page Router now respects the configured language fallback chain and tries to find a matching page candidate per language. - Metadata of page (e.g. page title) TSFE now respects the reconfigured language content id in case the language fallback is active and resolves the correct data. - Respect existing localizations in menu rendering PageRepository, used by the menu, now respects the language fallback chain and finds suitable localized pages. However, this does not resolve all issues with shortcut pages. Resolves: #81657 Resolves: #86595 Resolves: #19114 Releases: master, 9.5 Change-Id: Ic2b302989449ec14e7e6b5c54819870770655da9 Reviewed-on: https://review.typo3.org/c/59676 Tested-by:
TYPO3com <noreply@typo3.com> Tested-by:
Ralf Merz <mail@merzilla.de> Tested-by:
Anja Leichsenring <aleichsenring@ab-softlab.de> Tested-by:
Benni Mack <benni@typo3.org> Reviewed-by:
Ralf Merz <mail@merzilla.de> Reviewed-by:
Anja Leichsenring <aleichsenring@ab-softlab.de> Reviewed-by:
Benni Mack <benni@typo3.org>
-
- 23 Feb, 2019 1 commit
-
-
If a link is being built with a site configuration, the configuration no_cache must be respected. Resolves: #87728 Releases: master, 9.5 Change-Id: I8d71f11ca953c5744063deec318d9a23c11c1337 Reviewed-on: https://review.typo3.org/c/59715 Tested-by:
TYPO3com <noreply@typo3.com> Tested-by:
Susanne Moog <susanne.moog@typo3.org> Tested-by:
Anja Leichsenring <aleichsenring@ab-softlab.de> Reviewed-by:
Susanne Moog <susanne.moog@typo3.org> Reviewed-by:
Anja Leichsenring <aleichsenring@ab-softlab.de>
-
- 07 Jan, 2019 1 commit
-
-
This is a precursor for removing PseudoSiteHandling in general. The database field "pages.alias" field is dropped, along with the functionality to evalute if a frontend request "?id=acme" is non-integer, as it now always has to be integer. Existing links pointing to page aliases will stop working. Resolves: #87356 Releases: master Change-Id: I19134cc788e633e140b43497f716082ac96744e5 Reviewed-on: https://review.typo3.org/59232 Tested-by:
TYPO3com <no-reply@typo3.com> Reviewed-by:
Georg Ringer <georg.ringer@gmail.com> Tested-by:
Georg Ringer <georg.ringer@gmail.com> Reviewed-by:
Wouter Wolters <typo3@wouterwolters.nl> Tested-by:
Wouter Wolters <typo3@wouterwolters.nl>
-
- 22 Dec, 2018 1 commit
-
-
Removes the legary sys_domain table and handling. Resolves: #87276 Releases: master Change-Id: If2a5eeb1ebcc113c8b00162f4c02ea3a58edcefe Reviewed-on: https://review.typo3.org/59233 Tested-by:
TYPO3com <no-reply@typo3.com> Reviewed-by:
Christian Kuhn <lolli@schwarzbu.ch> Tested-by:
Christian Kuhn <lolli@schwarzbu.ch> Reviewed-by:
Anja Leichsenring <aleichsenring@ab-softlab.de> Tested-by:
Anja Leichsenring <aleichsenring@ab-softlab.de>
-
- 05 Nov, 2018 1 commit
-
-
Adds a new method HttpUtility::buildQueryString() using http_build_query() instead of reimplementing the encoding-process like the old method GeneralUtility::implodeArrayForUrl() did. As the parameter $rawurlencodeParamName of implodeArrayForUrl() was set to "false" by default and used in several places without manually setting it to "true" using that method could lead to potentially unsafe non-encoded parameter names. Some unit-tests had wrong URLs with non-encoded braces [...], which were adapted to be properly escaped as well. Resolves: #83334 Releases: master Change-Id: Ifbaad912f0d658671356dc7bdf1579dacff272df Reviewed-on: https://review.typo3.org/55079 Reviewed-by:
Benni Mack <benni@typo3.org> Tested-by:
Benni Mack <benni@typo3.org> Tested-by:
TYPO3com <no-reply@typo3.com> Reviewed-by:
Anja Leichsenring <aleichsenring@ab-softlab.de> Tested-by:
Anja Leichsenring <aleichsenring@ab-softlab.de>
-
- 01 Oct, 2018 2 commits
-
-
Make sure that in most places any site related exception is handled in a graceful way to avoid negative UX. Resolves: #86522 Releases: master Change-Id: I3b0d7f9ce63351f8dd7bb6b4988704fc8a3d0a9f Reviewed-on: https://review.typo3.org/58537 Reviewed-by:
Benni Mack <benni@typo3.org> Reviewed-by:
Richard Haeser <richard@maxserv.com> Reviewed-by:
Jurian Janssen <jurian.janssen@gmail.com> Reviewed-by:
Andreas Wolf <andreas.wolf@typo3.org> Reviewed-by:
Daniel Goerz <daniel.goerz@posteo.de> Tested-by:
Daniel Goerz <daniel.goerz@posteo.de> Reviewed-by:
Jörg Bösche <typo3@joergboesche.de> Tested-by:
Richard Haeser <richard@maxserv.com> Tested-by:
TYPO3com <no-reply@typo3.com> Tested-by:
Benni Mack <benni@typo3.org>
-
Two new Exceptions are now thrown when routing does not work, one being thrown when a URL is generated but could not be generated, and one when a URL could not be resolved. This is much cleaner than the distinction of a nullable return type, so the new interface is adapted as well. As a drive-by fix, the Backend routing exception now inherits from this new exception. Resolves: #86500 Releases: master Change-Id: Ifaf7b61422dfd49df18399c3bcbdf735bc522cba Reviewed-on: https://review.typo3.org/58519 Tested-by:
TYPO3com <no-reply@typo3.com> Reviewed-by:
Wouter Wolters <typo3@wouterwolters.nl> Reviewed-by:
Oliver Hader <oliver.hader@typo3.org> Tested-by:
Oliver Hader <oliver.hader@typo3.org> Reviewed-by:
Susanne Moog <susanne.moog@typo3.org> Tested-by:
Susanne Moog <susanne.moog@typo3.org>
-
- 27 Sep, 2018 1 commit
-
-
In case no current site exists in a context (for example currently eID or other scripting contexts), the pageLinkBuilder threw an error when linking to a page with a site configuration. The necessity for having a current site config has been removed, the pageLinkBuilder can now be used without a current site object and will then always generate absolute URLs to the target site. Resolves: #86384 Releases: master Change-Id: Id8c984c4ac3837d7b4da37a99d43410c6db34187 Reviewed-on: https://review.typo3.org/58397 Tested-by:
TYPO3com <no-reply@typo3.com> Reviewed-by:
Anja Leichsenring <aleichsenring@ab-softlab.de> Reviewed-by:
Henning Liebe <h.liebe@neusta.de> Tested-by:
Henning Liebe <h.liebe@neusta.de> Reviewed-by:
Frank Naegler <frank.naegler@typo3.org> Tested-by:
Frank Naegler <frank.naegler@typo3.org>
-
- 26 Sep, 2018 1 commit
-
-
The PageUriBuilder is gone, as all is centralized in the PageRouter now, which acts as the centralized place to resolve Requests ("matchRequest") and to create URLs ("generateUri") for pages that have a site configuration. RouterInterface is the abstract interface which is intended to be used within Backend as well in the future, and provides a good basis for both cases (that's why page ID and SiteInterface is not hardcoded in the API). RouteResultInterface is introduced to allow further Result objects like page-specific results, useful for future routing improvements. Since PageUriBuilder was only used in cases where there was a site, the Router is now bound to a site (see constructor). When generating a URL, the PageRouter can receive a special argument called "_language" to hand over a SiteLanguage object. Resolves: #86388 Releases: master Change-Id: Ib090d3373a88cb7c534557ef21b46dce646078b5 Reviewed-on: https://review.typo3.org/58149 Tested-by:
TYPO3com <no-reply@typo3.com> Reviewed-by:
Oliver Hader <oliver.hader@typo3.org> Tested-by:
Oliver Hader <oliver.hader@typo3.org>
-
- 13 Sep, 2018 1 commit
-
-
The check for pages.l18n_cfg is wrong now, as this is always done against pages.sys_language_uid=0 records (as "resolvePage" is called right before). So, these if-statements have to go further south. On top, the getPageOverlay call needs to be done - on top. resolvePage -> get default language of page getPageOverlay -> put the wanted translation on top A fix for pages.alias has to be in place, as DataHandler cannot handle pages.alias yet. Resolves: #86242 Releases: master Change-Id: Ief99e5f934f6e9d31973b9543cb9a6e599d2d33c Reviewed-on: https://review.typo3.org/58267 Tested-by:
TYPO3com <no-reply@typo3.com> Reviewed-by:
Benni Mack <benni@typo3.org> Tested-by:
Benni Mack <benni@typo3.org> Reviewed-by:
Oliver Hader <oliver.hader@typo3.org> Tested-by:
Oliver Hader <oliver.hader@typo3.org>
-
- 03 Sep, 2018 1 commit
-
-
Due to the refactoring process within links to a site, it is still necessary to link to a translated page with a given "&L=" parameter. This parameter is resolved, and a link to a page translation is generated. Fixes menu generation and typolink with the generated page title. Resolves: #86067 Releases: master Change-Id: I3e1208a2cdb438c68d4ed3dac1d0274ce07395dc Reviewed-on: https://review.typo3.org/58108 Reviewed-by:
Christian Kuhn <lolli@schwarzbu.ch> Tested-by:
Christian Kuhn <lolli@schwarzbu.ch> Reviewed-by:
Susanne Moog <susanne.moog@typo3.org> Tested-by:
Susanne Moog <susanne.moog@typo3.org> Tested-by:
TYPO3com <no-reply@typo3.com> Reviewed-by:
Oliver Hader <oliver.hader@typo3.org> Tested-by:
Oliver Hader <oliver.hader@typo3.org>
-
- 02 Sep, 2018 2 commits
-
-
Resolves: #86084 Releases: master Change-Id: I6ebbe0756d799a3c04386c854f6e5e385eeac54f Reviewed-on: https://review.typo3.org/58124 Tested-by:
TYPO3com <no-reply@typo3.com> Reviewed-by:
Christian Kuhn <lolli@schwarzbu.ch> Tested-by:
Christian Kuhn <lolli@schwarzbu.ch>
-
strpos will use only CPU resources, substr also needs memory allocation. Resolves: #85477 Releases: master Change-Id: Ic25c99986f7e2e7237c10acaa75be8d0f6289f13 Reviewed-on: https://review.typo3.org/57466 Reviewed-by:
Jigal van Hemert <jigal.van.hemert@typo3.org> Tested-by:
Jigal van Hemert <jigal.van.hemert@typo3.org> Tested-by:
TYPO3com <no-reply@typo3.com> Reviewed-by:
Christian Kuhn <lolli@schwarzbu.ch> Tested-by:
Christian Kuhn <lolli@schwarzbu.ch>
-
- 01 Sep, 2018 1 commit
-
-
Due to the refactoring yesterday, the TypoScript option config.linkVars was removed, but is still a valid use-case to be added. Resolves: #86054 Releases: master Change-Id: I6d42c82f474668b62143982b8d9f2adf9b735935 Reviewed-on: https://review.typo3.org/58097 Tested-by:
TYPO3com <no-reply@typo3.com> Reviewed-by:
Frans Saris <franssaris@gmail.com> Tested-by:
Frans Saris <franssaris@gmail.com> Reviewed-by:
Wouter Wolters <typo3@wouterwolters.nl> Reviewed-by:
Christian Kuhn <lolli@schwarzbu.ch> Tested-by:
Christian Kuhn <lolli@schwarzbu.ch>
-
- 31 Aug, 2018 1 commit
-
-
When having a Site configuration in order to create a page link for a specific language new property `language` has to be used instead of previous `additionalParams=&L=1`. Since it might not be known in all cases whether the defined TypoScript is used inside or outside a valid Site configuration, `language` settings now take precedence and override legacy L-parameter. Besides that, linking to localized pages was not possible and is resolved to their language parent pages. The new `language` setting will be adjusted at the same time as well. Resolves: #86058 Releases: master Change-Id: I9531a14f8aa5913a03fdac9fcbdaced57312c2af Reviewed-on: https://review.typo3.org/58101 Tested-by:
TYPO3com <no-reply@typo3.com> Reviewed-by:
Benni Mack <benni@typo3.org> Tested-by:
Benni Mack <benni@typo3.org> Reviewed-by:
Wouter Wolters <typo3@wouterwolters.nl> Reviewed-by:
Frans Saris <franssaris@gmail.com> Tested-by:
Frans Saris <franssaris@gmail.com>
-
- 30 Aug, 2018 2 commits
-
-
Benni Mack authored
The PageLinkBuilder now separates out into generating links for pages with site configuration, and without site configuration (= as before). The new link mechanism does not rely on previous hooks and options like config.absRefPrefix which are not necessary for URLs as they are always absolute. A new TypoScript option "typolink.language" is introduced. If not set, it is set to "current", and allows to link across pagetrees to a given site, or render a language menu without having to use "&L=" as additional query parameter. ("current" is the current language and default) is used to also allow to explicitly link to a different language if this language was configured for the site configuration for the site. As for the linking process: - typolink.forceAbsoluteUrl is used to generate the full URL to a target page - typolink.forceAbsoluteUrl.scheme is only applicable if the site base of the target does not explicitly define a scheme - If you link to a different page tree or to a different host/scheme, it is always treated as absolute. On top: If you link across page trees, the link is treated as external (extTarget is used). The next steps are to create tests and incorporate config.linkVars into this process. Resolves: #86048 Releases: master Change-Id: I01b2b43efafa23ce0d256bdcd0feb35756fbe1d5 Reviewed-on: https://review.typo3.org/58063 Reviewed-by:
Oliver Hader <oliver.hader@typo3.org> Tested-by:
Oliver Hader <oliver.hader@typo3.org> Reviewed-by:
Susanne Moog <susanne.moog@typo3.org> Tested-by:
Susanne Moog <susanne.moog@typo3.org> Reviewed-by:
Benni Mack <benni@typo3.org> Tested-by:
Benni Mack <benni@typo3.org> Tested-by:
TYPO3com <no-reply@typo3.com>
-
During the cleanup of https://review.typo3.org/#/c/58022/ a wrong change was done, this actually introduces a regression showing that the scheme part is never evaluated, removing the superfluos check now completely. Resolves: #86042 Related: #85964 Releases: master Change-Id: I0e5a6f5d90141a86e34b4950ace36d620bee813f Reviewed-on: https://review.typo3.org/58089 Tested-by:
TYPO3com <no-reply@typo3.com> Reviewed-by:
Oliver Hader <oliver.hader@typo3.org> Tested-by:
Oliver Hader <oliver.hader@typo3.org>
-
- 27 Aug, 2018 1 commit
-
-
This is a pre-cursor for unifying URL generation with slugs / based on sites, in order to group things that belong together in the mass-method of generating links in the frontend. Tasks done: - $linkText is moved to the very end, as it has no dependency. - $targetDomain/$currentDomain handling is grouped together. - absRefPrefix is now always taken from $tsfe->absRefPrefix, as this is the resolved path (not set to "auto") - minor un-needed calls simplified (unneessary checks etc) Resolves: #85964 Releases: master Change-Id: Iba84cd98fa614ef7131c03a093c9cfa0a0056575 Reviewed-on: https://review.typo3.org/58022 Tested-by:
TYPO3com <no-reply@typo3.com> Reviewed-by:
Wouter Wolters <typo3@wouterwolters.nl> Reviewed-by:
Susanne Moog <susanne.moog@typo3.org> Tested-by:
Susanne Moog <susanne.moog@typo3.org> Reviewed-by:
Christian Kuhn <lolli@schwarzbu.ch> Tested-by:
Christian Kuhn <lolli@schwarzbu.ch>
-