1. 13 May, 2022 1 commit
  2. 10 May, 2022 1 commit
  3. 25 Apr, 2022 1 commit
  4. 17 Apr, 2022 1 commit
  5. 14 Apr, 2022 1 commit
  6. 14 Mar, 2022 1 commit
  7. 09 Mar, 2022 1 commit
  8. 20 Feb, 2022 1 commit
  9. 16 Feb, 2022 1 commit
    • Christian Kuhn's avatar
      [!!!][FEATURE] Avoid BackendTemplateView · 25773e86
      Christian Kuhn authored
      Class BackendTemplateView has been a temporary solution
      to simplify the implementation of the "TsConfig template
      override" feature into smaller patches.
      With ModuleTemplate and general view works being mostly
      done in the backend, BackendTemplateView should be
      removed again.
      The patch removes all usages switching nearly all views
      to BackendViewFactory, which removes the explicit
      dependency to Typo3Fluid ViewInterface since the
      EXT:core ViewInterface is not directly bound to Fluid
      Using BackendViewFactory has the additional advantage
      that templates which don't use ModuleTemplate because
      they're hook usages or some other "sub-view", can now
      be overridden with TsConfig, too.
      Using BackendViewFactory also makes the dependency to
      ServerRequestInterface explicit. The patch thus hands
      $request around at some more places where $request was
      only an indirect dependency before.
      One special @todo area is FormEngine, which is unable
      to have dependency injection (for BackendViewFactory)
      due to its manual constructor arguments. The patch
      falls back to Typo3Fluid TemplateView in those cases.
      The FormEngine API should be adapted with another patch.
      Change-Id: Ie8959dada4dc6fd30e04d87fea6004e74cbe5990
      Resolves: #96904
      Related: #96730
      Related: #96513
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/73518
      Tested-by: core-ci's avatarcore-ci <typo3@b13.com>
      Tested-by: Stefan Bürk's avatarStefan Bürk <stefan@buerk.tech>
      Tested-by: Benjamin Franzke's avatarBenjamin Franzke <bfr@qbus.de>
      Tested-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      Reviewed-by: Stefan Bürk's avatarStefan Bürk <stefan@buerk.tech>
      Reviewed-by: Benjamin Franzke's avatarBenjamin Franzke <bfr@qbus.de>
      Reviewed-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
  10. 12 Feb, 2022 1 commit
  11. 11 Feb, 2022 1 commit
  12. 05 Feb, 2022 1 commit
  13. 02 Feb, 2022 1 commit
  14. 18 Jan, 2022 1 commit
    • Stefan Bürk's avatar
      [TASK] Use proper QueryBuilder execute() replacement methods · 597a92fd
      Stefan Bürk authored and Benni Mack's avatar Benni Mack committed
      doctrine/dbal implemented single purpose method to replace the
      compound 'execute()' in QueryBuilder to avoid the incompatible
      return typehint tuple of 'Doctrine\DBAL\Result|int' in favour
      of 'executeQuery()' and 'executeStatement()' which was added
      forward-compatible with #96247 marking the old one internal
      but not deprecated for now to keep a eventually longer grace
      period to mitigate for extensions developers.
      This patch however goes through the core and replace these
      methods to be clean as possible and is a first preparation
      to remove the 'checkThisOnly' option from phpstan which are
      swallowed by this option.
      * replace 'execute' with 'executeQuery()' for select and
        count queries generating results ('Doctrine\DBAL\Result').
      * use 'executeStatement()' for insert, update and delete
        queries return affected rows as return value (int)
      * adjust return typehints to match the single return type
        signature on really minor places to match the return type
        of the wrapped replaced execute method.
      * replace one really old 'exec()' from connection with
        corresponding replacement method along the way.
      * add several todos on two places which are weird and do
        not make any sense for further investigation and fixing,
        as declared as out-of-the-scope for this wide-area patch.
      Resolves: #96551
      Related: #96247
      Related: #96521
      Releases: main, 11.5
      Change-Id: Ie8d40f3882f1694ab7f7e5053729fa1c798a9c5f
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/73032
      Tested-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      Tested-by: core-ci's avatarcore-ci <typo3@b13.com>
      Tested-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Reviewed-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      Reviewed-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
  15. 16 Jan, 2022 1 commit
  16. 24 Oct, 2021 1 commit
  17. 24 Sep, 2021 1 commit
  18. 30 Aug, 2021 1 commit
  19. 25 Aug, 2021 1 commit
  20. 24 Aug, 2021 1 commit
  21. 12 Aug, 2021 1 commit
    • Benni Mack's avatar
      [FEATURE] Improve Usability in Workspaces module · cc0c62e8
      Benni Mack authored and Christian Kuhn's avatar Christian Kuhn committed
      The workspaces module has a better style and some
      improvements for editors and administrators:
      * Editors now get feedback if an AJAX call shows no results
      * Editors + Administrators now switch workspace via a selector,
        very helpful when having more than a couple of workspaces
      * Administrators can now edit a workspace record
        directly from the module
      The change cleans up a lot of unused code in the main workspaces
      module and brings a few UX improvements within the module.
      * Dropdowns instead of tabs (good when having a lot of workspaces)
      * Language + Depth + Action selection is now rendered via
        Controller+Action instead of waiting for a first AJAX round trip
      * Properly using "moduleData" from "uc" to store information
      * Solved issues related to language icon rendering
      * Removed unused inline settings
      * Consistent usage of Persistent JS module accessing BE_Users' UC
      * nProgress for showing progress of loading AJAX requests
      Next steps in this area:
      * Hand in the first payload as JSON to avoid AJAX call on
        initial page load
      * Remove leftover inline JavaScript
      Resolves: #94819
      Releases: master
      Change-Id: Ie533656a14af56dad4a4039fcbc9b08bde693500
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/70452
      Tested-by: core-ci's avatarcore-ci <typo3@b13.com>
      Tested-by: Wouter Wolters's avatarWouter Wolters <typo3@wouterwolters.nl>
      Tested-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      Reviewed-by: Wouter Wolters's avatarWouter Wolters <typo3@wouterwolters.nl>
      Reviewed-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
  22. 29 Jul, 2021 1 commit
  23. 21 Jun, 2021 1 commit
  24. 27 Apr, 2021 1 commit
  25. 12 Apr, 2021 1 commit
  26. 11 Mar, 2021 1 commit
  27. 08 Mar, 2021 1 commit
    • Benni Mack's avatar
      [FEATURE] Use database field be_users.lang for UI language · 650d5d7b
      Benni Mack authored and Christian Kuhn's avatar Christian Kuhn committed
      Historically (even before TYPO3 3.3.0), the UI language (the language of
      the TYPO3 Backend of a user) is stored in ->uc['lang'], which is only
      filled from the database field be_users.lang when a user logs in the
      first time.
      be_user.lang is/was used for admins when creating users to set a default
      language when the user first logs in for the first time, but is never
      used afterwards.
      However, using "uc[lang]" in various places does not make life easier
      because uc always needs to be unpacked (e.g. for sending bulk mails
      to users, or changing languages for users as admins, listing
      users' preferred languages in list module).
      For this reason, be_users.lang now defines the users' UI language,
      however uc[lang] is synced on each login of a user now, if the language
      has changed.
      In addition, the TCA for be_users.lang is now handled via an
      itemsProcFunc, making uncached requests a tiny bit faster as Locales are
      not populated during TCA creation, and allows for more features such as
      dynamically showing available/downloaded languages in a be_users
      FormEngine field.
      The Setup module now updates be_users.lang instead of uc[lang],
      which makes it easier in the future to use native TCA for rendering
      the setup module fields.
      An upgrade wizard migrates all "uc[lang]" values into "be_users.lang"
      and ensures that empty values are never used, instead
      "default" (= English) is added to all user records to have an explicit
      value (also for new users).
      Resolves: #93663
      Releases: master
      Change-Id: Icb8e07f3fabb1f3022f3adcbdce6dc9efd790302
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/68192
      Tested-by: core-ci's avatarcore-ci <typo3@b13.com>
      Tested-by: default avatarTYPO3com <noreply@typo3.com>
      Tested-by: Oliver Bartsch's avatarOliver Bartsch <bo@cedev.de>
      Tested-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      Reviewed-by: Oliver Bartsch's avatarOliver Bartsch <bo@cedev.de>
      Reviewed-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
  28. 03 Mar, 2021 1 commit
  29. 02 Mar, 2021 1 commit
  30. 01 Feb, 2021 1 commit
  31. 19 Jan, 2021 1 commit
  32. 19 Dec, 2020 1 commit
  33. 05 Sep, 2020 2 commits
  34. 04 Sep, 2020 1 commit
  35. 02 Sep, 2020 1 commit
  36. 14 Aug, 2020 1 commit
    • Christian Kuhn's avatar
      [BUGFIX] Drop "All workspaces" tab from workspace module · 9c4aecd2
      Christian Kuhn authored and Andreas Fernandez's avatar Andreas Fernandez committed
      When "All workspaces" has been integrated somewhere before v6,
      it was advertised as a view to see changes from all workspaces.
      This however never worked: When calling the workspace module,
      "All workspaces" is empty. If switching to a workspace and then
      selecting "All workspaces", the tab shows only the changes of
      the selected workspace - identical to the normal workspace tab.
      Tracing this back in time, this behavior exists at least since v7.
      There is not a single bug report in forge about this.
      Since this tab is broken for such a long time without any
      report, we assume the functionality is barely needed.
      A better solution would be to show the number of existing
      changes next to the workspace name in the tab list, so editors
      can quickly see which specific workspace needs attention, and
      then switch to the workspace in question. This should be done with
      another patch since non-admins currently see only one workspace tab
      at a time, which needs another preparation patch to fix.
      This patch drops the broken "All workspaces" tab for now, preparing
      further bugfixes to finally end up with a working solution.
      Resolves: #91999
      Releases: master, 10.4
      Change-Id: I33f3cdba117b68927eb10447b0541d8975ed0a63
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/65322
      Tested-by: default avatarTYPO3com <noreply@typo3.com>
      Tested-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Tested-by: Andreas Fernandez's avatarAndreas Fernandez <a.fernandez@scripting-base.de>
      Reviewed-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Reviewed-by: Andreas Fernandez's avatarAndreas Fernandez <a.fernandez@scripting-base.de>
  37. 03 Aug, 2020 1 commit
    • Benni Mack's avatar
      [!!!][TASK] Remove t3ver_count and t3ver_tstamp db fields · 80a38d73
      Benni Mack authored and Anja Leichsenring's avatar Anja Leichsenring committed
      The patch drops handling and existence of two further
      workspaces related db fields:
      * t3ver_tstamp has been occassionally set to 'now' when
      records in a workspaces were edited. However, the field
      was never displayed in the backend and is of little use
      since it only holds only a 'last' value. A change
      history on workspace records is available through the
      'info' button in the workspace module. This is powered
      by sys_history and shows modifications with date/time.
      * t3ver_count is also never rendered in the backend. It
      has been used in the (non-default) 'swap' workspace actions
      where live records become the new workspace records. The
      field was then incremented by one. The loose wording around
      that is, it's an 'archived' record. However, if swapping a
      second time, the workspace record does not count two as one
      would expect, but still one. Only after another swap, the
      workspace record would have the value two in this field.
      Together with the fact this field has never been shown/used,
      the weird behavior, and that swapping is an uncommon case
      that needs to be explicitely enabled and used, the field
      is dropped now.
      Resolves: #89137
      Releases: master
      Change-Id: I7cdfe6e867c14462395d7398123b14464835c1bf
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/65145
      Tested-by: default avatarTYPO3com <noreply@typo3.com>
      Tested-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      Tested-by: Anja Leichsenring's avatarAnja Leichsenring <aleichsenring@ab-softlab.de>
      Reviewed-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      Reviewed-by: Anja Leichsenring's avatarAnja Leichsenring <aleichsenring@ab-softlab.de>
  38. 12 May, 2020 1 commit
  39. 15 Apr, 2020 1 commit