1. 13 May, 2022 1 commit
  2. 14 Apr, 2022 1 commit
  3. 20 Feb, 2022 1 commit
  4. 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
      anymore.
      
      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>
      25773e86
  5. 12 Feb, 2022 1 commit
  6. 11 Feb, 2022 1 commit
  7. 16 Jan, 2022 1 commit
  8. 24 Sep, 2021 1 commit
  9. 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>
      cc0c62e8
  10. 21 Jun, 2021 1 commit
  11. 11 Mar, 2021 1 commit
  12. 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>
      650d5d7b
  13. 05 Sep, 2020 2 commits
  14. 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>
      9c4aecd2
  15. 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>
      80a38d73
  16. 12 May, 2020 1 commit
  17. 15 Apr, 2020 1 commit
  18. 14 Apr, 2020 2 commits
  19. 30 Dec, 2019 1 commit
  20. 18 Dec, 2019 1 commit
  21. 07 Oct, 2019 1 commit
  22. 01 Oct, 2018 1 commit
  23. 30 Sep, 2018 1 commit
  24. 23 May, 2018 1 commit
  25. 10 May, 2018 1 commit
  26. 06 May, 2018 1 commit
  27. 05 Mar, 2018 1 commit
  28. 02 Mar, 2018 1 commit
  29. 27 Dec, 2017 1 commit
  30. 23 Aug, 2017 2 commits
  31. 28 Mar, 2017 1 commit
    • Wouter Wolters's avatar
      [TASK] Streamline return tags in phpdocs · eb049dba
      Wouter Wolters authored and Benni Mack's avatar Benni Mack committed
      The TYPO3 Core currently has no guidline how to handle phpdoc
      comments regarding @return annoations related to "void" and "null".
      
      In practice, these annotations have no additional value if no additional
      documentation is given.
      
      With this change, the php-cs-fixer will remove any unnecessary linebreaks
      within the comments above the @return annotation, as well as remove completely
      empty phpdoc comments because the @return annotation is removed.
      
      Please be aware, that once PSR-5 is accepted, this coding standard
      within the TYPO3 Core will change again, where there are currently
      some further proposal details like inheritance information.
      
      Resolves: #80454
      Releases: master
      Change-Id: Ie969d720684c0a75919fe5addd1c36ef5b12eb04
      Reviewed-on: https://review.typo3.org/51686
      
      Reviewed-by: Nicole Cordes's avatarNicole Cordes <typo3@cordes.co>
      Tested-by: Nicole Cordes's avatarNicole Cordes <typo3@cordes.co>
      Reviewed-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Tested-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      eb049dba
  32. 31 Dec, 2016 1 commit
  33. 27 Oct, 2016 1 commit
  34. 10 Oct, 2016 1 commit
  35. 30 Aug, 2016 1 commit
  36. 17 Apr, 2016 1 commit
  37. 20 Nov, 2015 1 commit