Skip to content
Snippets Groups Projects
Select Git revision
0 result
Search by author
  • Any Author
0 authors
  1. Apr 04, 2024
  3. Mar 07, 2024
  5. Mar 05, 2024
  7. Mar 04, 2024
  9. Mar 01, 2024
  11. Jan 14, 2024
  13. Dec 26, 2023
  15. Dec 08, 2023
  17. Nov 29, 2023
  19. Nov 18, 2023
  21. Oct 15, 2023
  23. Sep 21, 2023
  25. Aug 31, 2023
  27. Aug 08, 2023
  29. Aug 03, 2023
  31. Aug 02, 2023
  33. Jul 17, 2023
  35. Jul 05, 2023
  37. Jun 15, 2023
  39. Jun 14, 2023
  41. Jun 13, 2023
  43. Jun 12, 2023
  45. Apr 21, 2023
  47. Apr 14, 2023
  49. Apr 11, 2023
  51. Apr 05, 2023
  53. Apr 02, 2023
  55. Mar 27, 2023
  57. Mar 21, 2023
  59. Mar 06, 2023
  61. Mar 01, 2023
    • Christian Kuhn's avatar
      [TASK] Modernize condition matching · 41e3abe8
      Christian Kuhn authored 
      The TypoScript condition matching and our symfony
expression language handling is a heavily convoluted
mess: The entire API tends to fetch lots of global
state, the classes are complex, hard to understand and
handle, over-abstracted and full of anti-patterns.

The patch aims to mitigate this. The main strategy is
to provide relevant data from within callers directly
instead of fetching globals TYPO3_REQUEST, calling
GeneralUtility::_GP() and GeneralUtility::getIndpEnv().

* For TypoScript 'condition' expression handler usages,
  the frontend/backend related ConditionMatcher classes
  are obsoleted. The IncludeTreeConditionMatcherVisitor
  class within the new TypoScript parser is now the
  construct that prepares TypoScript relevant variables
  to initialize the symfony expression language construct,
  and gets variables actively hand over.

* The default provider now prepares variables from state
  that can be injected, the entire ProviderInterface no
  longer relies on runtime state from globals.

* Access to runtime Request object is streamlined:
  Especially PageTsConfig and UserTsConfig can not rely
  on a given request object since the DataHandler uses
  this a well, which denies systematic usage of request
  related data. This is deprecated.

* The ProviderInterface config handling should still be
  streamlined towards a symfony service provider approach.
  The current solution is kept for now, an @todo is added
  to briefly outline on how this should be changed in v13
  as a breaking change.

* Note this patch avoids the last core usage of
  GeneralUtility::_GP() which will be deprecated with
  another patch. Additionally, a hard to fix call to
  GeneralUtility::getIndpEnv() is avoided.

Change-Id: I476b69776e950a5a7e5ed937d2e2c58fe00f133f
Resolves: #100047
Related: #97816
Releases: main
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/77981


Tested-by: default avatarcore-ci <typo3@b13.com>
Reviewed-by: default avatarStefan Bürk <stefan@buerk.tech>
Reviewed-by: default avatarBenni Mack <benni@typo3.org>
Tested-by: default avatarBenni Mack <benni@typo3.org>
Tested-by: default avatarStefan Bürk <stefan@buerk.tech>
Tested-by: default avatarChristian Kuhn <lolli@schwarzbu.ch>
Reviewed-by: default avatarChristian Kuhn <lolli@schwarzbu.ch>
      41e3abe8
  63. Feb 04, 2023
    • Christian Kuhn's avatar
      [TASK] Prefer browser tooltips over bootstrap tooltips · 1c77c838
      Christian Kuhn authored 
      The entire bootstrap tooltips plugin and Backend
handling is problemetic. The patch removes usages
throughout the Backend to rely solely on native
browser title attributes on hover for now.

Reasons:
* Usage within the Backend is very inconsistent: Some
  modules use 'bs-toggle="tooltip"', some do, but then
  don't initialze JS accordingly, many don't take care
  at all.
* The placement of tooltips is inconsistent: Some modules
  rely on auto placement, some don't take care, some
  get it right.
* The plugin is fiddly: There are various hacks to for
  instance toggle-off on scroll, or toggle-off when a
  modal is overlayed to not stay on-top-of modals, these
  sort of things. Browser title hovers always get this right.
* Usages are buggy: The page tree sometimes still fails
  to remove tooltips, which then tend to stay until browser
  reload. The list module shows both a browser hover plus
  the tooltip at the same time on icons, ext:form shows funny
  placement in preview-mode. There are more modules that get
  details wrong than those that work flawlessly.
* Tooltips that add a lot of valuable information are
  problematic from an accessibility point of view. It's
  better to refactor UI to not rely on them too much. By
  avoiding bootstrap tooltips for now, we encourage to
  think more about properly accessible solutions instead
  of putting things into a "nice" overlay. With the patch,
  various places now fall back to the title attribute, which
  is also problematic, see [1] for more information. The
  core will continue to improve the situation with
  further patches and will document better best practices.
* Tooltips with a lot of additional information are a
  no-go on touch devices.
* The plugin is slow with many elements. This is easily
  reproducible with the "List" module, which is noticeable
  quicker when relying on title tags alone on weaker clients.

[1] https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/title#accessibility_concerns

Resolves: #99811
Resolves: #99428
Resolves: #99089
Resolves: #98061
Resolves: #97047
Resolves: #93022
Related: #89872
Releases: main
Change-Id: I3cb8f0ca5e65a2c4b74d023935e1bef26c592ffd
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/77664


Tested-by: default avatarMichael Telgkamp <michael.telgkamp@mindscreen.de>
Tested-by: default avatarChristian Kuhn <lolli@schwarzbu.ch>
Tested-by: default avatarcore-ci <typo3@b13.com>
Reviewed-by: default avatarStefan Bürk <stefan@buerk.tech>
Tested-by: default avatarStefan Bürk <stefan@buerk.tech>
Tested-by: default avatarJasmina Ließmann <minapokhalo+typo3@gmail.com>
Reviewed-by: default avatarJasmina Ließmann <minapokhalo+typo3@gmail.com>
Reviewed-by: default avatarChristian Kuhn <lolli@schwarzbu.ch>
      1c77c838
  65. Feb 01, 2023
  67. Jan 30, 2023
  69. Jan 26, 2023