1. 11 Dec, 2020 2 commits
  2. 22 Oct, 2020 1 commit
  3. 12 Oct, 2020 1 commit
  4. 07 Sep, 2020 1 commit
  5. 11 May, 2020 1 commit
    • Helmut Hummel's avatar
      [BUGFIX] Consistently fetch SiteConfiguration from DI · cd8a613c
      Helmut Hummel authored
      SiteConfiguration is available from the DI container (both in failsafe and
      symfony DI), therefore no constructor arguments MUST be passed to
      GeneralUtility::makeInstance when fetching the SiteConfiguration singleton
      instance, or a new instance will be created.
      
      There are however multiple places where this object is still created
      by passing constructor arguments to GeneralUtility::makeInstance
      (this bypasses proxying to the container).
      This leads to the situation that two different objects are created and
      retrieved, depending on how it is fetched.
      
      This is now fixed by changing each remaining retrieval via makeInstance
      to NOT provide constructor arguments, which in turn results in a call to
      the container to fetch the SiteConfiguration object.
      
      Additionally the ServiceProvider introduced in #89892 is changed to allow
      providing an alternative implementation using XCLASS. Although XCLASSES
      are generally discouraged in favor of Services.yaml overwrites, there is
      no other way to provide an alternative for this class, as it is registered
      in an internal service provider.
      
      Resolves: #91260
      Releases: master
      Change-Id: I8af1cafd737feccff9e06eacb23d6991105238d0
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/64386
      
      
      Tested-by: Benjamin Franzke's avatarBenjamin Franzke <bfr@qbus.de>
      Tested-by: default avatarTYPO3com <noreply@typo3.com>
      Tested-by: Helmut Hummel's avatarHelmut Hummel <typo3@helhum.io>
      Reviewed-by: Benjamin Franzke's avatarBenjamin Franzke <bfr@qbus.de>
      Reviewed-by: Daniel Goerz's avatarDaniel Goerz <daniel.goerz@posteo.de>
      Reviewed-by: Helmut Hummel's avatarHelmut Hummel <typo3@helhum.io>
      cd8a613c
  6. 27 Apr, 2020 1 commit
  7. 17 Apr, 2020 1 commit
  8. 15 Apr, 2020 1 commit
  9. 19 Mar, 2020 1 commit
  10. 08 Mar, 2020 1 commit
  11. 31 Jan, 2020 1 commit
    • Benni Mack's avatar
      [FEATURE] Migrate Extension-related signals to PSR-14 events · c53161ca
      Benni Mack authored and Andreas Fernandez's avatar Andreas Fernandez committed
      This change migrates all left-over signals in TYPO3 Core to PSR-14-compatible
      events.
      
      Package manager - related events have been moved to EXT:core to decouple
      ExtensionManager functionality from PackageManager.
      
      The following signals have been moved to events:
      PackageManagement::packagesMayHaveChanged => PackagesMayHaveChangedEvent
      InstallUtility::afterExtensionInstall => AfterPackageActivationEvent
      InstallUtility::afterExtensionUninstall => AfterPackageDeactivationEvent
      InstallUtility::afterExtensionT3DImport => AfterExtensionStaticDatabaseContentHasBeenImportedEvent
      InstallUtility::afterExtensionStaticSqlImport => AfterExtensionStaticDatabaseContentHasBeenImportedEvent
      InstallUtility::afterExtensionFileImport => AfterExtensionFilesHaveBeenImportedEvent
      ExtensionManagementService::willInstallExtensions => BeforePackageActivationEvent
      ProcessAvailableActionsViewHelper::processActions => AvailableActionsForExtensionEvent
      
      Next up: Deprecate signal slot dispatcher.
      
      Resolves: #90249
      Releases: master
      Change-Id: If688265c50c4200983c34f408b1cfd063f72546b
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/63045
      
      
      Tested-by: default avatarTYPO3com <noreply@typo3.com>
      Tested-by: Susanne Moog's avatarSusanne Moog <look@susi.dev>
      Tested-by: Andreas Fernandez's avatarAndreas Fernandez <a.fernandez@scripting-base.de>
      Reviewed-by: Susanne Moog's avatarSusanne Moog <look@susi.dev>
      Reviewed-by: Andreas Fernandez's avatarAndreas Fernandez <a.fernandez@scripting-base.de>
      c53161ca
  12. 23 Nov, 2019 1 commit
  13. 07 Oct, 2019 1 commit
  14. 30 Sep, 2019 1 commit
  15. 26 Sep, 2019 1 commit
  16. 25 Sep, 2019 1 commit
  17. 24 Sep, 2019 1 commit
  18. 30 Aug, 2019 1 commit
  19. 12 Jun, 2019 1 commit
  20. 18 Jan, 2019 1 commit
  21. 01 Oct, 2018 1 commit
  22. 30 Sep, 2018 1 commit
  23. 29 Sep, 2018 1 commit
  24. 19 Aug, 2018 1 commit
  25. 25 Jul, 2018 1 commit
  26. 11 Jul, 2018 1 commit
  27. 04 Jul, 2018 1 commit
  28. 15 Jun, 2018 1 commit
  29. 11 Jun, 2018 1 commit
  30. 07 Jun, 2018 1 commit
    • Christian Kuhn's avatar
      [FEATURE] Auto create management DB fields from TCA ctrl · 7b2319ff
      Christian Kuhn authored and Benni Mack's avatar Benni Mack committed
      Adds a class that auto creates TYPO3 "management" related database
      columns and indexes based on TCA 'ctrl' information without having
      them specified in ext_tables.sql. The feature .rst file outlines
      field details.
      
      Goals:
      * Save extension developers time.
      * Less copy+paste issues and different general fields definitions.
      * Reduce number of boilerplate fields in ext_tables.sql.
      * Bring schema of management fields under core control.
      
      Non goals:
      * No full substitution of ext_tables.sql by TCA: "Business"
        fields from 'columns' are NOT created automatically. This
        would require further thoughts and code disentangling.
      * No new extension API.
      * No "migration" approach or similar.
      
      Notable patch details:
      * The patch is a revamped version of issue #81234 that has been
        abandoned. As requested in the review of #81234, the code now
        hooks in after ext_tables.sql has been parsed into the doctrine
        schema.
      * Field defintions of ext_tables.sql take precedence, auto fields
        are only added if ext_tables.sql does not define a column or index.
        This makes the patch fully backwards compatible.
      * No deprecation for obsolete field definitions in ext_tables.sql
        is logged.
      * Many core fields are aligned to a central definition and slightly
        change. For instance "uid" is now always an unsigned int.
      * Reduce all core's ext_tables.sql files as well as the functional
        testing related ext_tables.sql files down to the business fields
      * A relatively huge series of test adaptions: Especially the
        ext:impexp related functionals now create dumps with differently
        sorted fields - This is no problem during import.
      * Field t3_origuid of sys_file_reference has never been registered
        in TCA as ['ctrl']['origUid'], is thus unused and removed as obsolete.
      * The extension manager no longer applies possible destructive changes,
        it only adds missing columns and tables when loading / updating
        extensions. It however considers *all* ext_tables.sql files, not only
        the one the extension in question provides. See the important .rst
        file for details.
      
      Change-Id: I640a7c7da3b63bac21a71102f253aa2d1bef4391
      Resolves: #85160
      Related: #81234
      Releases: master
      Reviewed-on: https://review.typo3.org/57121
      
      
      Tested-by: default avatarTYPO3com <no-reply@typo3.com>
      Reviewed-by: Anja Leichsenring's avatarAnja Leichsenring <aleichsenring@ab-softlab.de>
      Tested-by: Anja Leichsenring's avatarAnja Leichsenring <aleichsenring@ab-softlab.de>
      Reviewed-by: Wouter Wolters's avatarWouter Wolters <typo3@wouterwolters.nl>
      Reviewed-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Tested-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      7b2319ff
  31. 16 Mar, 2018 1 commit
  32. 01 Mar, 2018 1 commit
  33. 29 Jan, 2018 1 commit
  34. 12 Dec, 2017 1 commit
  35. 08 Dec, 2017 1 commit
    • Markus Hoelzle's avatar
      [!!!][FEATURE] Move extension configuration to install tool · ebf0f1a7
      Markus Hoelzle authored and Benni Mack's avatar Benni Mack committed
      With #82254 LocalConfiguration serialized array EXT/extConf has been
      changed to a not serialized array in EXTENSIONS. This patch follows
      up on this task an finishes various tasks:
      
      * An install tool silent upgrader upmerges given EXT/extConf settings
        to EXTENSIONS array. The resulting EXTENSIONS array does not contain
        dots for sub paths in its array key anymore and is accessible with a
        new ExtensionConfiguration->get() API to fetch values and whole
        extension config.
      * A new API is introduced to get() and set() extension specific
        configuration, is documented and used throughout the core to not
        unserialize old EXT/extConf anymore. Setting values updates legacy
        EXT/extConf to new values including compatible 'dot' ending on
        nested array configurations.
      * If extensions come with new configuration items in ext_conf_template.txt
        a silent upgrader of the install tool synchronizes these to the
        EXTENSIONS and old extConf array. Extension authors can rely on that
        and always fetch new keys from the new ExtensionConfiguration->get()
        API right away. The synchronization is also triggered when new
        extensions are loaded or extensions are updated via the extension
        manager.
      * Core usages are adapted to the new API.
      * Next to the main get() / set() API, the extension configuration
        form is extracted from the extension manager and put into the install
        tool as a new card in "Settings". The code below is streamlined
        and encapsulated with just a couple of public methods in class
        'ExtensionConfigurationService' as internal class for use in install
        tool and extension manager.
      
      Resolves: #82368
      Related: #82254
      Releases: master
      Change-Id: I88568fa355f8f6fd5acc9850dcdd718fdd9a1b2e
      Reviewed-on: https://review.typo3.org/54034
      
      
      Tested-by: default avatarTYPO3com <no-reply@typo3.com>
      Reviewed-by: default avatarDaniel Gorges <daniel.gorges@b13.de>
      Tested-by: default avatarDaniel Gorges <daniel.gorges@b13.de>
      Reviewed-by: Andreas Fernandez's avatarAndreas Fernandez <typo3@scripting-base.de>
      Reviewed-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Tested-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      ebf0f1a7
  36. 23 Aug, 2017 1 commit
  37. 22 Aug, 2017 1 commit
    • Christian Kuhn's avatar
      [!!!][TASK] Extension manager: Drop "Download SQL Dump" · 15819601
      Christian Kuhn authored and Benni Mack's avatar Benni Mack committed
      The em in "Installed Extensions" has a button "Download SQL Dump"
      for all extensions that provide ext_tables.sql. On click, an sql
      dump file is sent.
      
      This feature is severely flawed:
      * Dumps of extensions that add fields to existing tables contain
        a 'drop table' of these tables, the 'import into' statements are
        broken and only (try to) add these fields again. This easily
        leads to hazard in DB if importing such a dump.
      * There are no charset specs and other meta data whatsoever in the dump.
      * The dump is not dbal compatible, field definitions and imports
        are incomplete.
      
      We assume nobody really used this feature in a sane way, even at
      this prominent position in em. The lack of bug reports to this
      broken feature and the fact there have been zero changes in this
      area since main em refactoring years ago support this view.
      
      There are way better options to retrieve proper data specifications:
      * The list module has a csv export
      * Ext:impexp supports export and import in a much better way
        including proper relation handling and other options.
      * Low level db exports and backups should be done on cli or
        with more powerful guis like phpmyadmin or other db engine
        specific tools.
      
      The feature is dropped without substitution.
      
      The v8 backport of this patch will just remove the button from
      the em list view, but keep all code.
      
      Change-Id: Ia027e7498c5464af04c49675987a696ee3a06070
      Resolves: #82148
      Releases: master, 8.7
      Reviewed-on: https://review.typo3.org/53764
      
      
      Tested-by: default avatarTYPO3com <no-reply@typo3.com>
      Reviewed-by: Georg Ringer's avatarGeorg Ringer <georg.ringer@gmail.com>
      Tested-by: Georg Ringer's avatarGeorg Ringer <georg.ringer@gmail.com>
      Reviewed-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Tested-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      15819601
  38. 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
  39. 01 Mar, 2017 1 commit