This project is mirrored from https://git.typo3.org/typo3/typo3.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. 04 Jan, 2021 1 commit
  2. 17 Dec, 2020 1 commit
    • Oliver Bartsch's avatar
      [!!!][TASK] Rework shortcut PHP API functionality · e4833fda
      Oliver Bartsch authored and Christian Kuhn's avatar Christian Kuhn committed
      To be able to introduce URL rewrites for the backend,
      the internal handling and registration of the shortcut
      PHP API is reworked.
      
      The Shortcut PHP API previously has the full URL of
      the shortcut target stored in the database. This lead
      to many problems such as shortcuts got invalid as soon
      as their target module changed its route path. Furthermore,
      this required unnecessary functionality like replacing
      tokens on URL creation.
      
      Therefore, a shortcut record now stores only the route
      identifier of the module to link to and necessary arguments
      in two new database columns. A upgrade wizard is in place
      to migrate existing data.
      
      The rework also required to deprecate some methods in
      the ShortcutButton API and a parameter signature change
      of the JavaScript function `TYPO3.ShortcutMenu.createShortcut()`
      which performs the AJAX call to create new shortcuts.
      
      Side effect, this also deprecated the last remains of
      xMOD_alt_doc.php in the core.
      
      Resolves: #93093
      Releases: master
      Change-Id: I07666a299651e4953b4adf2987fcd3469094c288
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/67143
      
      
      Tested-by: default avatarTYPO3com <noreply@typo3.com>
      Tested-by: Daniel Goerz's avatarDaniel Goerz <daniel.goerz@posteo.de>
      Tested-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      Reviewed-by: Daniel Goerz's avatarDaniel Goerz <daniel.goerz@posteo.de>
      Reviewed-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      e4833fda
  3. 14 Dec, 2020 1 commit
  4. 10 Dec, 2020 1 commit
  5. 12 Nov, 2020 1 commit
    • Benni Mack's avatar
      [!!!][TASK] Do not create new version placeholders in workspaces anymore · 74899ecf
      Benni Mack authored
      Creating a new record in a workspace adds two database rows.
      
      One that is the "placeholder", which - since v10.4 - contains
      the same metadata as the other record:
      
      * t3ver_wsid = workspaceID
      * t3ver_oid = 0 (simulating behavior of an "online pendant record")
      * t3ver_state = 1
      
      And the "versionized" record, identified by:
      
      * t3ver_wsid = workspaceID
      * t3ver_oid = uid of the new placeholder record
      * t3ver_state = -1
      
      As of TYPO3 v10, the first record is not needed anymore,
      the versioned record can be queried directly, however, since
      the relations (except MM) point to the placeholder record,
      this one is kept.
      
      As result, only one record is created from now on:
      
      * t3ver_wsid = workspaceID
      * t3ver_oid = 0 (no online counterpart)
      * t3ver_state = 1
      
      On reading, the record is queried directly (no overlay needed anymore!)
      with the existing Database Doctrine Restrictions. On publishing, the
      record just gets the state/stage/wsid set and is "live".
      
      This brings fundamental benefits:
      
      * No overlays needed when querying
      * Fewer database records (placeholders are not helpful)
      * Conceptual problems with placeholder and shadowed fields are removed
      
      Resolves: #92791
      Releases: master
      Change-Id: I0288cc63fe72d8442d586f309bd4054ac44e829b
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/65587
      
      
      Tested-by: default avatarTYPO3com <noreply@typo3.com>
      Tested-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      Tested-by: Oliver Bartsch's avatarOliver Bartsch <bo@cedev.de>
      Tested-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Reviewed-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      Reviewed-by: Oliver Bartsch's avatarOliver Bartsch <bo@cedev.de>
      Reviewed-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      74899ecf
  6. 11 Nov, 2020 1 commit
  7. 03 Nov, 2020 1 commit
  8. 28 Oct, 2020 1 commit
  9. 20 Oct, 2020 1 commit
  10. 23 Sep, 2020 1 commit
  11. 05 Sep, 2020 1 commit
    • Christian Kuhn's avatar
      [!!!][TASK] Refactor create bookmark handling · 5be7b805
      Christian Kuhn authored and Anja Leichsenring's avatar Anja Leichsenring committed
      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.
      
      Impact:
      * 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
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/65503
      
      
      Tested-by: Andreas Fernandez's avatarAndreas Fernandez <a.fernandez@scripting-base.de>
      Tested-by: default avatarTYPO3com <noreply@typo3.com>
      Tested-by: Anja Leichsenring's avatarAnja Leichsenring <aleichsenring@ab-softlab.de>
      Reviewed-by: Andreas Fernandez's avatarAndreas Fernandez <a.fernandez@scripting-base.de>
      Reviewed-by: Anja Leichsenring's avatarAnja Leichsenring <aleichsenring@ab-softlab.de>
      5be7b805
  12. 04 Sep, 2020 1 commit
  13. 03 Sep, 2020 1 commit
  14. 22 Aug, 2020 1 commit
  15. 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
  16. 31 Jul, 2020 1 commit
  17. 18 Apr, 2020 1 commit
  18. 17 Apr, 2020 1 commit
  19. 15 Apr, 2020 1 commit
  20. 14 Apr, 2020 1 commit
  21. 13 Apr, 2020 1 commit
  22. 06 Apr, 2020 1 commit
  23. 23 Mar, 2020 1 commit
  24. 21 Mar, 2020 1 commit
  25. 19 Mar, 2020 1 commit
  26. 28 Feb, 2020 1 commit
  27. 30 Dec, 2019 1 commit
  28. 18 Dec, 2019 1 commit
  29. 02 Dec, 2019 1 commit
    • Benni Mack's avatar
      [FEATURE] Migrate various Signals to PSR-14 events in system extensions · ca19817b
      Benni Mack authored and Susanne Moog's avatar Susanne Moog committed
      The following new PSR-14 events are added:
      
      TYPO3\CMS\Core\Configuration\Event\ModifyLoadedPageTsConfigEvent
      TYPO3\CMS\Backend\Authentication\Event\SwitchUserEvent
      TYPO3\CMS\Backend\Controller\Event\BeforeFormEnginePageInitializedEvent
      TYPO3\CMS\Backend\Controller\Event\AfterFormEnginePageInitializedEvent
      TYPO3\CMS\Backend\LoginProvider\Event\ModifyPageLayoutOnLoginProviderSelectionEvent
      TYPO3\CMS\Impexp\Event\BeforeImportEvent
      TYPO3\CMS\Install\Service\Event\ModifyLanguagePackRemoteBaseUrlEvent
      TYPO3\CMS\Linkvalidator\Event\BeforeRecordIsAnalyzedEvent
      TYPO3\CMS\Seo\Event\ModifyUrlForCanonicalTagEvent
      TYPO3\CMS\Workspaces\Event\AfterCompiledCacheableDataForWorkspaceEvent
      TYPO3\CMS\Workspaces\Event\AfterDataGeneratedForWorkspaceEvent
      TYPO3\CMS\Workspaces\Event\GetVersionedDataEvent
      TYPO3\CMS\Workspaces\Event\SortVersionedDataEvent
      
      They replace the following "old" signals with a deprecation layer:
      
      TYPO3\CMS\Backend\LoginProvider\UsernamePasswordLoginProvider::getPageRenderer
      TYPO3\CMS\Backend\Controller\EditDocumentController::preInitAfter
      TYPO3\CMS\Backend\Controller\EditDocumentController::initAfter
      TYPO3\CMS\Backend\Utility\BackendUtility::getPagesTSconfigPreInclude
      TYPO3\CMS\Beuser\Controller\BackendUserController::switchUser
      TYPO3\CMS\Impexp\Utility\ImportExportUtility::afterImportExportInitialisation
      TYPO3\CMS\Lang\Service\TranslationService::postProcessMirrorUrl
      TYPO3\CMS\Linkvalidator\LinkAnalyzer::beforeAnalyzeRecord
      TYPO3\CMS\Seo\Canonical\CanonicalGenerator::beforeGeneratingCanonical
      TYPO3\CMS\Workspaces\Service\GridDataService::SIGNAL_GenerateDataArray_BeforeCaching
      TYPO3\CMS\Workspaces\Service\GridDataService::SIGNAL_GenerateDataArray_PostProcesss
      TYPO3\CMS\Workspaces\Service\GridDataService::SIGNAL_GetDataArray_PostProcesss
      TYPO3\CMS\Workspaces\Service\GridDataService::SIGNAL_SortDataArray_PostProcesss
      
      Relates: #89733
      Resolves: #89813
      Releases: master
      Change-Id: I13f2454fd8f4efb5f4c5248d0b839634b77578db
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/62422
      
      
      Tested-by: default avatarTYPO3com <noreply@typo3.com>
      Tested-by: Andreas Fernandez's avatarAndreas Fernandez <a.fernandez@scripting-base.de>
      Tested-by: Susanne Moog's avatarSusanne Moog <look@susi.dev>
      Reviewed-by: Andreas Fernandez's avatarAndreas Fernandez <a.fernandez@scripting-base.de>
      Reviewed-by: Susanne Moog's avatarSusanne Moog <look@susi.dev>
      ca19817b
  30. 29 Nov, 2019 1 commit
  31. 13 Oct, 2019 1 commit
  32. 30 Sep, 2019 1 commit
  33. 11 Sep, 2019 1 commit
    • Benni Mack's avatar
      [BUGFIX] Do not check for pid=-1 when evaluating workspace records · a6363e85
      Benni Mack authored and Susanne Moog's avatar Susanne Moog committed
      TYPO3 Core handles the result of database queries in a lot of different
      ways to filter out workspace records.
      
      With "versioning support v1" (= without workspaces), the identifier was
      usually "pid = -1" to filter out records that should not be displayed in
      live results.
      
      With workspaces, there are other, better ways to identify versioned via
      the following fields:
      - t3ver_state (what kind of versioned record is there)
      - t3ver_oid (if the versioned record points to a live record)
      - t3ver_wsid (the workspace ID)
      
      The "pid" field was kept as misuse, but fine for most of the database
      queries. Since we now have Doctrine DBAL, and Restrictions, the Core
      API can now be unified to actually check for "t3ver_oid>0" instead of
      "pid<>-1" to identify a versioned record.
      
      All places in TYPO3 Core now does not check for "pid<>-1" anymore for
      tables that are workspace-aware.
      
      In the future, it is then possible to get rid of the "pid=-1" value when
      writing versioned records, streamlining the API effectively, to find one
      proper way to query and write records.
      
      This change does not modify any other places in TYPO3 Core where
      Workspace Records are written, but only cleans up the API to only
      consider "t3ver_oid" instead of "pid", avoiding the mis-use of "pid".
      
      Most queries can then be handled by simply checking:
      - t3ver_wsid=0 AND deleted=0 for only fetching live records
      - t3ver_wsid IN (0,12) AND t3ver_oid=0 to find all live records,
        and draft placeholders, to do overlays then
      
      Resolves: #89122
      Releases: master
      Change-Id: I781d1ae440fe944e6c8c99d02884a6eb0c1be0a7
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/61641
      
      
      Tested-by: Oliver Hader's avatarOliver Hader <oliver.hader@typo3.org>
      Tested-by: default avatarTYPO3com <noreply@typo3.com>
      Tested-by: Susanne Moog's avatarSusanne Moog <look@susi.dev>
      Reviewed-by: Oliver Hader's avatarOliver Hader <oliver.hader@typo3.org>
      Reviewed-by: Susanne Moog's avatarSusanne Moog <look@susi.dev>
      a6363e85
  34. 08 Sep, 2019 1 commit
  35. 04 Sep, 2019 1 commit
  36. 28 Aug, 2019 1 commit
  37. 02 Aug, 2019 1 commit
  38. 29 Jul, 2019 1 commit
  39. 22 Jul, 2019 1 commit
  40. 17 Jul, 2019 1 commit