Skip to content
Snippets Groups Projects
Select Git revision
  • 12.4
  • main default
  • 11.5
  • 13.3
  • l10n_main
  • 13.1
  • 13.0
  • l10n_12.4
  • 10.4
  • 12.1
  • 9.5
  • 11.3
  • master
  • 11.1
  • TYPO3_8-7
  • 10.2
  • 9.3
  • 9.2
  • TYPO3_7-6
  • TYPO3_7-0
  • v13.3.1
  • v12.4.21
  • v11.5.40
  • v13.3.0
  • v12.4.20
  • v12.4.19
  • v12.4.18
  • v11.5.39
  • v12.4.17
  • v13.2.1
  • v13.2.0
  • v12.4.16
  • v11.5.38
  • v13.1.1
  • v12.4.15
  • v11.5.37
  • v13.1.0
  • v12.4.14
  • v12.4.13
  • v12.4.12
40 results
Search by author
  • Any Author
  • Daniel Hürtgen Daniel Hürtgen higidi
  • Jenkins Jenkins jenkins
  • **** **** project_53_bot
3 authors
  1. Mar 15, 2023
  3. Feb 10, 2023
  5. Feb 06, 2023
    • Benni Mack's avatar
      [BUGFIX] Enforce validation when no cHash is given · 434c4fde
      Benni Mack authored 
      When no cHash is given but GET parameters are handed in
which _would_ require cHash parameters, these are now
properly evaluated during the frontend request.

As this has a security impact,
a new option called
$GLOBALS['TYPO3_CONF_VARS']['FE']['cacheHash']['enforceValidation']
is introduced, which then skips
the "requireCacheHashPresenceParameters" option.
The latter is an include list, but cache Hash
calculation should rather be based on
the exclude list such as "excludedParameters" and
"cachedParametersWhiteList".

If the new option is set, but some properties such
as tx_solr[q] should be allowed, then this needs
to be added to the excludedList ("excludedParameters")
by extension authors.

A new test "SlugSiteWithoutRequiredCHashRequestTest"
is added which works with a disabled feature
flag compared to "SlugSiteRequestTest" which
has the feature flag enabled.

Resolves: #95297
Releases: main, 11.5, 10.4
Change-Id: Ib72c6a34602e77d8c2044ad2e826c0474ebd2326
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/77206


Reviewed-by: default avatarOliver Hader <oliver.hader@typo3.org>
Tested-by: default avatarOliver Hader <oliver.hader@typo3.org>
Tested-by: default avatarOliver Bartsch <bo@cedev.de>
Reviewed-by: default avatarOliver Bartsch <bo@cedev.de>
Tested-by: default avatarcore-ci <typo3@b13.com>
      434c4fde
  7. Jan 23, 2023
  9. Jan 20, 2023
  11. Jan 19, 2023
    • Benni Mack's avatar
      [FEATURE] Add all countries and their localized names · 8ff02008
      Benni Mack authored 
      TYPO3 now supports loading a list of all
countries of the world in all supported
translations that TYPO3 has to offer - out of the box.

For this, a dev-dependency "sokil/php-isocodes-db-i18n"
package is used, which contains a list of
all countries (ISO 3166-1), their short names,
their official names in english, and optional
translations.

This package fetches the data from debian
repositories and is updated automatically
on the second day of each month.

A new Build script then transfers the information
and the translations (originally in PO files)
via symfony/translation into a PHP class
and XLF translations for country names ("France") and
official country names ("French Republic").

The Build script is already prepared
to also fetch language script codes in the future,
along with languages and/or currencies as well.

A new API (CountryProvider) is available
which returns the countries, and prepared
label strings to be used with TYPO3's language
me...
      8ff02008
  13. Dec 12, 2022
  15. Nov 30, 2022
  17. Nov 20, 2022
  19. Nov 10, 2022
    • Christian Kuhn's avatar
      [TASK] Deprecate TypoScript setup "constants" TLO · a3074ab9
      Christian Kuhn authored 
      This is not about TypoScript constants/settings
that are accessed using {$myConstant} in TypoScript
setup.

This is about the TypoScript setup "constants"
top-level-object: It is used in TypoScript
"parseFunc" and allows referencing string literals
by name in "parseFunc" strings, which are substituted
by using ###theName###, when property "constants = 1" is
set in "parseFunc".

This feature dates back to Kasper's "Initial revision"
and is obsolete ever since: The feature exists next
to well-known TypoScript constants, existing
usages can be easily substituted. The confusion with
TypoScript "constants" alone justifies a deprecation
of this detail.

The patch deprecates both the TypoScript setup
"constants" top-level-object, plus the "constants"
property in "parseFunc".

Resolves: #99040
Releases: main
Change-Id: I91546067db8a7eb72661087780e39f320db2cbeb
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/76532


Tested-by: default avatarcore-ci <typo3@b13.com>
Tested-by: default avatarSusanne Moog <look@susi.dev>
Tested-by: default avatarBenni Mack <benni@typo3.org>
Reviewed-by: default avatarSusanne Moog <look@susi.dev>
Reviewed-by: default avatarBenni Mack <benni@typo3.org>
      a3074ab9
  21. Nov 07, 2022
  23. Nov 03, 2022
  25. Oct 31, 2022
  27. Oct 29, 2022
  29. Oct 12, 2022
  31. Oct 02, 2022
  33. Oct 01, 2022
  35. Sep 29, 2022
  37. Sep 21, 2022
  39. Sep 13, 2022
  41. Sep 07, 2022
  43. Jul 27, 2022
  45. Jul 14, 2022
  47. Jul 13, 2022
    • Christian Kuhn's avatar
      [TASK] Avoid setUpBackendUserFromFixture() in functionals · f96a47c4
      Christian Kuhn authored 
      The testing-framework method setUpBackendUserFromFixture()
is kinda flawed since it does two things at once: It
creates db records and creates global state. This is
unfortunate in various cases, especially when  db
snapshoting is used. Additionally, it relies on a
class property which defaults to a fixture file
delivered by testing-framework in XML format. We
want to get rid of the .xml fixtures, and we don't
want that the testing-framework delivers default
fixtures.

The patch adapts all usages of the property and
of method setUpBackendUserFromFixture() by splitting
it into two calls to first insert a local extension
fixture .csv file and to then call the backend user
init helper method.

This finishes the removal of .xml fixture uses
in the core.

$ composer req --dev typo3/testing-framework:dev-main

Change-Id: I32a5c43a6c8176a9e9182d08e08b42b5ff279634
Resolves: #97928
Related: #96856
Releases: main
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/75168


Tested-by: default avatarBenni Mack <benni@typo3.org>
Tested-by: default avatarcore-ci <typo3@b13.com>
Tested-by: default avatarStefan Bürk <stefan@buerk.tech>
Reviewed-by: default avatarBenni Mack <benni@typo3.org>
Reviewed-by: default avatarStefan Bürk <stefan@buerk.tech>
      f96a47c4
  49. Jun 21, 2022
  51. May 25, 2022
  53. Apr 22, 2022
    • Benni Mack's avatar
      [!!!][FEATURE] Introduce dedicated class to create typolinks with unified Event · 4f7c4d1c
      Benni Mack authored 
      This change moves all "typolink" functionality
from cObj->typolink into a custom "LinkFactory"
class which then calls custom LinkBuilders (as before)
to do their work.

The main benefit is separation of concerns, thinning
out functionality from the monster ContentObjectRenderer
functionality.

Instead of the global hook
$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['tslib/class.tslib_content.php']['typoLink_PostProc']
a new PSR-14 Event "AfterLinkIsGeneratedEvent" is introduced,
which in turn uses the LinkResult to operate on.

This new Event also makes the hook
$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['urlProcessing']['urlProcessors']
obsolete, which was used for non-page links + URLs. As
all functionality for frontend links are now running
through this event, which contains all information.

In addition, typolink.userFunc now receives
a LinkResult object instead of a <a> string with arguments,
and needs to return a LinkResult object again.

Also, the ATagParams hook vanished as well, since the
new Event can be used easily (and in a much better way!)

Both parts are breaking, all other parts are expected
to work as before.

A new HtmlLinkResult is added, which allows for building
a HSC'ed <a> tag properly in typolink().

Architectural Details:

* LinkFactory (new class) is now handling the "typolink" logic
  for creating any kind of links or URLs (page/mails/files).
  For the actual logic of e.g, pages the "PageLinkBuilder" is used
  in this place.
* Internally, LinkFactory follows the same generation as
  cObj->typolink() before, but uses methods to make the code
  more readable.
* In the end, LinkFactory will return a "LinkResultInterface"
  which contains everything to build a <a> tag, however it
  cannot return a "UriInterface" from PSR-7, as a
  link to mailto: is not a URL, thus, not supported by PSR-7.
* The main "cObj->typolink()" method then takes the LinkResultInterface
  and wraps it into a HtmlLinkResult which does a htmlspecialchars()
  around all the attributes and the $linkText. So this is still
  the way to go to use from a public API point of view.
* As typolink() heavily depends on stdWrap() and thus on cObject
  this information needs to be injected properly of course, and
  has the hard dependency when creating links in the Frontend.
* new methods $cObj->createUrl() and $cObj->createLink() are added
  to make use of the LinkInterface functionality programmatically,
  so people can choose to get a hsc'ed result via typolink(),
  or typolink_URL(), or a pure data via createUrl() and createLink().

Next steps / further patches:
* Deprecate "lastTypoLink_LD" etc.
* Move LinkResultFactory into LinkFactory with ClassAlias
* Maybe add another method to just generate an URL to the LinkFactory
* Create JsonLinkResult object and clean up original LinkResult object

Resolves: #96641
Resolves: #92029
Releases: main
Change-Id: Ic9ce01153a0cfdcbacb15e1e3f3e382f95400192
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/72999


Tested-by: default avatarcore-ci <typo3@b13.com>
Tested-by: default avatarOliver Hader <oliver.hader@typo3.org>
Tested-by: default avatarStefan Bürk <stefan@buerk.tech>
Tested-by: default avatarOliver Bartsch <bo@cedev.de>
Reviewed-by: default avatarOliver Hader <oliver.hader@typo3.org>
Reviewed-by: default avatarStefan Bürk <stefan@buerk.tech>
Reviewed-by: default avatarOliver Bartsch <bo@cedev.de>
      4f7c4d1c
  55. Apr 07, 2022
  57. Mar 28, 2022
  59. Mar 07, 2022
  61. Mar 02, 2022
  63. Feb 27, 2022
  65. Feb 24, 2022
  67. Feb 18, 2022
  69. Feb 14, 2022
  71. Jan 30, 2022
  73. Jan 29, 2022
  75. Jan 25, 2022