Skip to content
Snippets Groups Projects
  1. Jan 16, 2018
  2. Jan 15, 2018
  3. Jan 13, 2018
  4. Jan 03, 2018
  5. Dec 27, 2017
  6. Dec 13, 2017
  7. Dec 12, 2017
  8. Dec 11, 2017
  9. Dec 08, 2017
    • Markus Hoelzle's avatar
      [!!!][FEATURE] Move extension configuration to install tool · ebf0f1a7
      Markus Hoelzle authored
      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: default avatarAndreas Fernandez <typo3@scripting-base.de>
      Reviewed-by: default avatarBenni Mack <benni@typo3.org>
      Tested-by: default avatarBenni Mack <benni@typo3.org>
      ebf0f1a7
  10. Nov 27, 2017
  11. Nov 02, 2017
  12. Oct 06, 2017
  13. Oct 04, 2017
  14. Sep 23, 2017
  15. Jul 30, 2017
  16. Jul 28, 2017
  17. Jul 26, 2017
  18. Jul 11, 2017
  19. Jul 06, 2017
  20. Jun 29, 2017
  21. Jun 28, 2017
  22. Jun 15, 2017
  23. Jun 02, 2017
  24. May 12, 2017
  25. May 05, 2017
  26. Apr 27, 2017
  27. Apr 20, 2017
  28. Apr 18, 2017
  29. Mar 28, 2017
    • Wouter Wolters's avatar
      [TASK] Streamline return tags in phpdocs · eb049dba
      Wouter Wolters authored
      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: default avatarNicole Cordes <typo3@cordes.co>
      Tested-by: default avatarNicole Cordes <typo3@cordes.co>
      Reviewed-by: default avatarBenni Mack <benni@typo3.org>
      Tested-by: default avatarBenni Mack <benni@typo3.org>
      eb049dba
  30. Feb 25, 2017
  31. Feb 16, 2017
  32. Feb 14, 2017
  33. Feb 11, 2017
  34. Feb 04, 2017
  35. Feb 03, 2017
  36. Feb 02, 2017
  37. Jan 26, 2017
    • Christian Kuhn's avatar
      [!!!][FEATURE] FormEngine element level refactoring · 84be5e61
      Christian Kuhn authored
      The patch introduces a new API on FormEngine element level
      that substitutes the old "wizards" / renderWizard() API
      with a more powerful system.
      
      Single wizards are now split into one of three categories:
      * An informational wizard
      * A control button / icon
      * A true wizard with additonal functionality
      
      Method renderWizards() is still called in elements for compatibility
      reasons if people added own scrip/popup/userFunc wizards, but all
      core wizards are migrated.
      
      The patch significantly cleans the HTML of single elements, especially
      HTML stuff that was added by the SingleFieldContainer is now put down
      to single elements, while main HTML wraps formerly done by renderWizards()
      is fetched "up" to single elements. This gives single elements full
      control about the main HTML it is producing, which is a must have
      preparation in order to further advance in this area and to switch
      single elements to fluid rendering in one of the next steps.
      
      The patch brings a pretty huge list of TCA changes and
      simplifications, all TCA changes are supported by TCA migration,
      so existing extensions should benefit out of the box and just
      get deprecations logged.
      
      Change-Id: I45083e14e45bbf40c06267b51c9d0b7c15e2f7ab
      Resolves: #79440
      Resolves: #70032
      Releases: master
      Reviewed-on: https://review.typo3.org/51151
      
      
      Tested-by: default avatarTYPO3com <no-reply@typo3.com>
      Reviewed-by: default avatarWouter Wolters <typo3@wouterwolters.nl>
      Tested-by: default avatarMona Muzaffar <mona.muzaffar@gmx.de>
      Reviewed-by: default avatarBenni Mack <benni@typo3.org>
      Tested-by: default avatarBenni Mack <benni@typo3.org>
      Reviewed-by: default avatarChristian Kuhn <lolli@schwarzbu.ch>
      Tested-by: default avatarChristian Kuhn <lolli@schwarzbu.ch>
      84be5e61
  38. Jan 07, 2017