1. 04 Jan, 2021 1 commit
  2. 20 Dec, 2020 1 commit
    • Matthias Stegmann's avatar
      [FEATURE] Introduce Bootstrap v5 for TYPO3 Backend · 793fc121
      Matthias Stegmann authored and Benni Mack's avatar Benni Mack committed
      This changes removes the frontend framework
      Bootstrap 3, and adds Bootstrap 5 beta 1 (we
      expect Bootstrap 5 final by the time we release TYPO3 v11 LTS).
      Bootstrap v3 is not supported by the Bootstrap
      team any longer, so an update is critical for TYPO3 Core.
      Bootstrap v5 adds a few accessibility improvements
      as well as flexbox for rendering
      containers and grids throughout TYPO3 Backend.
      All JS components are not bound to jQuery anymore,
      and have been reworked.
      A lot of HTML/CSS changes happened, which we
      slowly migrate (and not in a huge change)
      to TYPO3's templates, in order to keep
      this change managable.
      A legacy CSS/SCSS file is added to
      keep some backwards-compatibility classes
      to ease the migration for extension developers
      who have built their own backend modules.
      Key features of Bootstrap 5:
      * "rem" instead of "px" is used by default
      * CSS variables are introduced
      * Improved bootstrap focus outline styling (buttons / inputs / links)
      * Simplified grid functionality
      * use new button color mixin to increase contrast:
        Primary, Success and Warning Button color is now dark instead of white
      EXT:styleguide was used as a basis for
      upgrading to keep compatibility as much
      as possible, but more changes will be coming
      in the next few minor releases.
      Resolves: #92616
      Releases: master
      Change-Id: Iec989f39649b5460b055ec879199faf38e424f2b
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/66247
      Tested-by: default avatarTYPO3com <noreply@typo3.com>
      Tested-by: Benjamin Franzke's avatarBenjamin Franzke <bfr@qbus.de>
      Tested-by: Oliver Hader's avatarOliver Hader <oliver.hader@typo3.org>
      Tested-by: Oliver Bartsch's avatarOliver Bartsch <bo@cedev.de>
      Tested-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Reviewed-by: Benjamin Franzke's avatarBenjamin Franzke <bfr@qbus.de>
      Reviewed-by: Oliver Hader's avatarOliver Hader <oliver.hader@typo3.org>
      Reviewed-by: Oliver Bartsch's avatarOliver Bartsch <bo@cedev.de>
      Reviewed-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
  3. 14 Dec, 2020 1 commit
  4. 26 Sep, 2020 1 commit
  5. 08 Sep, 2020 1 commit
  6. 28 Aug, 2020 1 commit
    • Christian Kuhn's avatar
      [BUGFIX] Workspace delete placeholder handling in list module · 0a201b5e
      Christian Kuhn authored and Andreas Fernandez's avatar Andreas Fernandez committed
      When a record that exists in live is deleted in a workspace, a
      new 'delete placeholder' record is created in the workspace. This
      record is used to mark the live workspace record as 'to be deleted'
      when the workspace is published.
      Those delete placeholder are not shown in the page tree and not
      in the page module. The page / element is simply gone. Only the
      list module renders those records.
      This is confusing usability wise: A user clicks on 'delete' in
      list module, reloads the module, and the record is back again.
      Additionally, there is an even more confusing mechanism: The 'waste'
      icon is substituted by a different icon called 'restore'. 'restore'
      however does not actually restore changes that may have been done
      to the record in the workspace before, instead it simply sets the
      delete placeholder record to deleted, which makes the underlying
      live record 'shine through' in the workspace again.
      Interacting with delete placeholder records is also useless,
      for instance edited content of delete placeholder records is
      always gone in the end. So most action icons don't make sense.
      Looking at the lifecycle of workspace records, there are only
      two final results: A change is either discarded, or is published
      to live. This is managed exclusively in the workspace module.
      Having the third option 'restore' in the list module - that is
      basically the same as discarding a delete placeholder in workspace
      module - is very confusing.
      The best option would be to not render delete placeholder rows
      in the list module at all. Unfortunately this can't be done due
      to the workspace overlay mechanics: Especially the count and
      limit / pagination handling in list module is done on db level before
      the module knows that certain rows shouldn't be rendered. We need to
      have some serious refactoring before this can be solved.
      For now, the solution is to still render delete placeholder records
      in list module, to 'strike through' their title (similar to workspace
      module) and to disable all control icons and the click menu on them.
      This way the final fate of a delete placeholder can be decided only
      in the workspace module - just like all other workspace records.
      Change-Id: Id8a95c41f2bbe90ea68f40e376a4d36d3a2019b8
      Resolves: #90679
      Resolves: #52700
      Releases: master, 10.4
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/65495
      Tested-by: default avatarTYPO3com <noreply@typo3.com>
      Tested-by: Daniel Windloff
      Tested-by: Riccardo De Contardi's avatarRiccardo De Contardi <erredeco@gmail.com>
      Tested-by: Andreas Fernandez's avatarAndreas Fernandez <a.fernandez@scripting-base.de>
      Reviewed-by: Daniel Windloff
      Reviewed-by: Björn Jacob's avatarBjörn Jacob <bjoern.jacob@tritum.de>
      Reviewed-by: Andreas Fernandez's avatarAndreas Fernandez <a.fernandez@scripting-base.de>
  7. 04 May, 2020 1 commit
  8. 04 Mar, 2020 1 commit
  9. 14 Jan, 2020 1 commit
  10. 12 Jan, 2020 1 commit
  11. 04 Oct, 2019 2 commits
  12. 12 Jul, 2019 1 commit
  13. 23 Apr, 2019 1 commit
  14. 05 Apr, 2019 1 commit
  15. 15 Mar, 2019 1 commit
  16. 01 Mar, 2019 1 commit
  17. 11 Jan, 2019 1 commit
  18. 03 Dec, 2018 1 commit
  19. 03 Aug, 2018 1 commit
  20. 25 Apr, 2018 1 commit
  21. 31 Mar, 2017 1 commit
  22. 29 Mar, 2017 1 commit
  23. 07 Feb, 2017 1 commit
  24. 06 Feb, 2017 1 commit
  25. 01 Dec, 2016 1 commit
  26. 15 Oct, 2016 1 commit
  27. 10 Aug, 2016 1 commit
  28. 23 Jun, 2016 1 commit
  29. 20 Jun, 2016 1 commit
  30. 12 Oct, 2015 1 commit
  31. 03 Sep, 2015 1 commit
  32. 29 Sep, 2014 1 commit
  33. 01 May, 2013 1 commit
    • Felix Kopp's avatar
      [TASK] Move backend templates to extension contexts · 61dfb8f2
      Felix Kopp authored and Christian Kuhn's avatar Christian Kuhn committed
      Most html templates in backend are used in one extension only.
      Those templates should be held in extension context to reduce
      Creates extbase/flow directory structures.
      Change-Id: I7638092b695d36c4cea2a2755d8285bf92114bb0
      Fixes: #47786
      Releases: 6.2
      Reviewed-on: https://review.typo3.org/20374
      Reviewed-by: Wouter Wolters
      Tested-by: Wouter Wolters
      Reviewed-by: Christian Kuhn
      Tested-by: Christian Kuhn