This project is mirrored from git:// Pull mirroring failed .
Repository mirroring has been paused due to too many failed attempts. It can be resumed by a project maintainer.
Last successful update .
  1. 03 Aug, 2021 1 commit
  2. 29 Jul, 2021 2 commits
  3. 21 Jul, 2021 1 commit
  4. 13 Jul, 2021 1 commit
  5. 09 Jul, 2021 2 commits
  6. 05 Jul, 2021 1 commit
    • Oliver Bartsch's avatar
      [FEATURE] Improve show columns selection functionality · 16c5cae9
      Oliver Bartsch authored
      In #94218, the show columns selection was already improved
      by relocating it to each tables' header, making it always
      available (not only in single-table view).
      Since the used dropdown leads to confusion and visibility
      drawbacks for records, having long labels, the selector
      now lives in a modal. Besides the columns to select,
      the new modal contains some selector options, such as
      "select all" or "toggle selection". Those options are
      fixed at the top, making them always visible, even for
      records with a lot of columns.
      Furthermore the checkboxes now use a more suitable
      "check" icon, the columns are sorted lexically and
      also management fields (e.g. `sorting`) are now
      displayed with a human-readable label. This label
      is now also used in the table header.
      Besides the UX, this patch also brings some technical
      improvements. The whole column selection logic is moved
      into a dedicated controller, which may allows reuse in
      the future (e.g. for the filelist module). Also the
      JavaScript part is extracted from the Recordlist JS-module
      into a dedicated web component.
      Finally some cleanup of the existing code is done, making
      it more readable and more efficient.
      Resolves: #94474
      Releases: master
      Change-Id: I0f2f8711ee4b40c9e29e633b9fe790dcacae8bb5
      Tested-by: core-ci's avatarcore-ci <>
      Tested-by: Jochen's avatarJochen <>
      Tested-by: Benni Mack's avatarBenni Mack <>
      Reviewed-by: Jochen's avatarJochen <>
      Reviewed-by: Benni Mack's avatarBenni Mack <>
  7. 29 Jun, 2021 1 commit
  8. 22 Jun, 2021 2 commits
  9. 21 Jun, 2021 1 commit
  10. 18 Jun, 2021 2 commits
  11. 11 Jun, 2021 1 commit
  12. 10 Jun, 2021 1 commit
  13. 01 Jun, 2021 1 commit
  14. 26 May, 2021 2 commits
  15. 25 May, 2021 1 commit
  16. 14 May, 2021 1 commit
  17. 12 May, 2021 1 commit
  18. 09 Apr, 2021 2 commits
  19. 07 Apr, 2021 1 commit
  20. 05 Apr, 2021 1 commit
  21. 01 Apr, 2021 1 commit
  22. 31 Mar, 2021 1 commit
  23. 24 Feb, 2021 1 commit
  24. 19 Jan, 2021 1 commit
  25. 07 Jan, 2021 1 commit
  26. 04 Jan, 2021 2 commits
  27. 27 Sep, 2020 1 commit
  28. 25 Sep, 2020 1 commit
  29. 18 Sep, 2020 1 commit
  30. 08 Sep, 2020 1 commit
    • Daniel Windloff's avatar
      [TASK] DatabaseRecordList: Streamline translation and localization · 21f738cb
      Daniel Windloff authored
      Streamline translation fetching:
      To get a better overview, the fetching of the translations for each
      record has been moved to the `getTable()` method.
      Therewith, the main translation related queries are together, as the
      workspace overlay is already there.
      The translations are now handed over to the methods that render the
      list of records.
      This allows to remove the properties `translations` and `selFieldList`
      as the fields to select are already in the `getTable()` method and
      the translation must no longer be transferred back to the `getTable()`
      from the `makeLocalizationPanel()` method.
      Furthermore, this also avoids a db query for each translated record
      (in strict translation mode). Previously, a query with an always empty
      result set was in place.
      Streamline localization (all records excluding pages):
      The localization of each record (excluding pages) depends on the
      available languages of the site configuration and the already
      translated pages.
      This information is collected in the `getPossibleTranslations()` method,
      which depends on the current page uid and replaces the
      `initializeLanguages()` method.
      It is used to set the possible translations to the `possibleTranslations`
      property in the `start()` method.
      The property `possibleTranslations` replaces the properties
      `pageOverlays` and `systemLanguagesOnPage`.
      Streamline localization for pages:
      The localization of page records does not depend on the translation status
      of the parent page, because otherwise the first translation of one page
      would not be possible.
      The restriction for the page translations is now the same as in the
      Streamline `makeLocalizationPanel()` method:
      This method is now only used to create the possible localization
      Releases: master
      Resolves: #92133
      Change-Id: Iaf5f9f8cee795c4245d8201b20617df5d95570a7
      Tested-by: default avatarTYPO3com <>
      Tested-by: Anja Leichsenring's avatarAnja Leichsenring <>
      Tested-by: Christian Kuhn's avatarChristian Kuhn <>
      Reviewed-by: Anja Leichsenring's avatarAnja Leichsenring <>
      Reviewed-by: Christian Kuhn's avatarChristian Kuhn <>
  31. 05 Sep, 2020 1 commit
    • Christian Kuhn's avatar
      [!!!][TASK] Refactor create bookmark handling · 5be7b805
      Christian Kuhn authored
      The backend shortcut / bookmark handlig API was designed to
      hand over relevant get/post arguments as key only (eg. 'id').
      The underlying code then pulled values from GET/POST or from
      SOBE->MOD_SETTINGS. This is ugly, there shouldn't be such
      magic: Only controllers know relevant keys and values, so
      it should hand them over directly to the shortcut API.
      The patch changes this:
      * Old and unused ViewHelper f:be.buttons.shortcut is deprecated.
      * ViewHelper be:moduleLayout.button.shortcutButton deprecates
        argument 'getVars' and adds new argument 'arguments'.
      * Class ShortcutButton has a new setter 'setArguments' that
        accepts all relevant argument key/value pairs to create a
        shortcut. Existing get/set related methods are deprecated.
      * Helper methods 'makeShortcutIcon' and 'makeShortcutUrl' of
        class ModuleTemplate are deprecated and implemented in class
        ShortcutButton directly.
      * All core usages are adapted to new API.
      * Shortcut handling was the last core usage of SOBE, so last
        $GLOBALS['SOBE'] = $this assignments can be finally removed.
      * Shortcuts to modules not directly reachable via main menu
        do not work due to limits of the module registration API. An
        example is the 'create multiple pages' controller. This issue
        exists before the patch, affected controllers no longer render
        a shortcut button for now.
      * The old code usually added the 'route' argument twice for shortcuts.
        This has been resolved. As a side effect, the comparison if a
        shortcuts exists (yellow shortcut icon) fails currently for existing
        shortcuts when the patch is applied: The comparison relies on
        direct string equality since shortcuts always store the final url in
        the database. This storage strategy should be changed with another
        patch that will solve the 'no yellow icon' issue at the same time.
      Change-Id: I3ccd2b8f6adab8e7780c5f9911fdea013ccfa99b
      Resolves: #92132
      Releases: master
      Tested-by: Andreas Fernandez's avatarAndreas Fernandez <>
      Tested-by: default avatarTYPO3com <>
      Tested-by: Anja Leichsenring's avatarAnja Leichsenring <>
      Reviewed-by: Andreas Fernandez's avatarAndreas Fernandez <>
      Reviewed-by: Anja Leichsenring's avatarAnja Leichsenring <>
  32. 03 Sep, 2020 1 commit
  33. 30 Aug, 2020 1 commit
    • Daniel Windloff's avatar
      [TASK] Migrate RecordListController hooks to an PSR-14 event · ff67726f
      Daniel Windloff authored
      The following hooks in the RecordListController are used to add
      additional content above or below the main controller content:
      As this functionality could be useful, it should be migrated to a
      PSR-14 event. Both hook implementations use a meaningful parameter
      set (the request object) and return the additional content as string.
      As there is no dependency to the parent object (the class instance of
      the class where the hooks are placed), they could be migrated to a
      psr-14 event without a breaking change.
      Therefore, a PSR-14 event has been implemented to replace the hook
      functionality. An event listener has been created to provide a
      compatibility layer for both hooks. This allows a proper deprecation
      without breaking the hooks.
      The event listener (compatibility layer) could be removed in later
      versions without any changes in the controller class.
      Releases: master
      Resolves: #92062
      Change-Id: I50e4897bae256ec165861bccd8356db107c78962
      Tested-by: Christian Kuhn's avatarChristian Kuhn <>
      Tested-by: default avatarTYPO3com <>
      Tested-by: Anja Leichsenring's avatarAnja Leichsenring <>
      Reviewed-by: Christian Kuhn's avatarChristian Kuhn <>
      Reviewed-by: Anja Leichsenring's avatarAnja Leichsenring <>