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. 28 Jul, 2021 1 commit
  2. 25 May, 2021 1 commit
  3. 14 May, 2021 1 commit
  4. 01 Apr, 2021 1 commit
  5. 23 Sep, 2020 1 commit
  6. 15 Apr, 2020 1 commit
  7. 12 Jan, 2020 1 commit
  8. 05 Jul, 2019 1 commit
  9. 17 Jun, 2019 1 commit
  10. 03 Jun, 2019 1 commit
  11. 29 Mar, 2019 1 commit
  12. 18 Jan, 2019 1 commit
  13. 30 Sep, 2018 1 commit
  14. 16 May, 2018 1 commit
    • Christian Kuhn's avatar
      [TASK] Streamline TSconfig API · 45c582a8
      Christian Kuhn authored
      Final patch to de-mess the user / page TSconfig related API.
      Page TSconfig can be overriden in user TSconfig by prefixing the
      path with 'page.' in user TSconfig. However, method
      BackendUtility::getModTSconfig() violated this principle and
      had a special merge strategy that allowed ommitting the 'page.'
      prefix. This has been marked as deprecated in the TSconfig docs for
      various years and has been lately removed in the docs altogether,
      but the code still existed.
      The patch moves this merge into BackendUtility::getPagesTSconfig()
      and properly deprecates this case. Usages of getModTSconfig() are
      changed to use getPagesTSconfig() directly, dropping the artificial
      'properties' and 'value' sub arrays and omitting some rather expensive
      string operations at the same time.
      This obsoletes getModTSconfig() and a couple of related methods.
      Additionally, BackendUserAuthentication->getTSConfig() has been
      abused frequently to operate on different arrays than it's own userTS.
      Those usages are dropped with the patch. Handing over arguments to
      getTSConfig() is now deprecated, effectively reducing the method a getter.
      This reduces the API down to BackendUtility::getPagesTSconfig($pid)
      and BackendUserAuhtentiction->getTSConfig() both just returning the
      entire array. This simplified API can now be documented in the docs.
      Change-Id: I4bbb066c1d4e2edbc0182f7967897a1558cc3c0d
      Resolves: #85016
      Related: #84982
      Releases: master
      Tested-by: default avatarTYPO3com <>
      Reviewed-by: Jan Helke's avatarJan Helke <>
      Tested-by: Jan Helke's avatarJan Helke <>
      Reviewed-by: Anja Leichsenring's avatarAnja Leichsenring <>
      Tested-by: Anja Leichsenring's avatarAnja Leichsenring <>
      Reviewed-by: Christian Kuhn's avatarChristian Kuhn <>
      Tested-by: Christian Kuhn's avatarChristian Kuhn <>
  15. 25 Apr, 2018 1 commit
  16. 08 Nov, 2017 1 commit
  17. 12 May, 2017 1 commit
  18. 01 Dec, 2016 2 commits
  19. 26 Oct, 2016 1 commit
  20. 01 Sep, 2016 1 commit
  21. 30 Aug, 2016 1 commit
  22. 03 Jun, 2016 1 commit
  23. 05 May, 2016 1 commit
  24. 07 Apr, 2016 1 commit
  25. 23 Dec, 2015 1 commit
  26. 08 Oct, 2015 1 commit
  27. 22 Sep, 2015 1 commit
  28. 20 Sep, 2015 1 commit
  29. 08 Sep, 2015 1 commit
    • Christian Kuhn's avatar
      [!!!][TASK] The FormEngine is dead, long live the FormEngine! · b524fc86
      Christian Kuhn authored
      tl;dr: This patch makes FormEngine insanely flexible, extensions
      however should not rely on structures for now, since class names
      and array content will change.
      The patch applies a separation of concerns to the FormEngine
      class structure by extracting the data processing from rendering.
      As a main goal the render part consisting of container and element
      classes routed through the flexible NodeFactory only works on data
      created by the new FormDataCompiler class construct. This makes the
      FormEngine much more flexible and opens ways to not only use the render
      part in the context of database driven data, but on anything that is
      fed to it.
      This patch creates the main structure for this. The FormDataCompiler
      class returns a defined array container and elements can work on it.
      Data is added by single FormDataProvider, which are combined in
      FormDataGroups. FormDataProvider may depend on each other and a
      FormDataGroup "knows" its providers and calls them in a dedicated order.
      For instance, the "FullDatabaseRecord" FormDataGroup first calls a
      provider that fetches the record defined by uid and table name and
      a later called provider determines the given record type this record
      is assigned to, so another provider can then work on TCA to determine
      the list of record fields to be shown. The FormDataProvider used
      for the main FormDataGroup are defined in TYPO3_CONF_VARS, so
      extensions can add and remove their own providers to add or change
      certain data if needed. This is highly flexible and extensions are
      able to hook in at a specific position within the provider chain for
      the main data groups.
      This construct obsoletes the DataPreprocessor as well as several
      other side classes.
      With this patch the main architecture is created and lots of data
      preparation is transfered already, supported by a high unit test
      The FormEngine class itself is removed: The inline ajax entry point
      is moved to an own controller class, the getMainFields() and friends
      methods are substituted with FormDataCompiler / NodeFactory combinations
      and the data gathering is for now parked in a FormResultCompiler class.
      However, this process is not yet finished and lots of @todo
      statements are added to the code base to document open ends and to
      further separate the data handling from the render engine. Especially
      the IRRE data handling is currently still located within the render
      engine and makes the whole thing much more complicated than it should
      be. Lots of detail patches need to follow to bring this code
      to a level where it belongs to be.
      Warning: While this patch is already insanely huge touching more than
      22 thousands lines of code, lots of loose ends need to be tackled and
      the API is not final yet. The arrays will be reduced and sharpened
      during the next weeks, class names may change and structures will
      Change-Id: Ief1769f478373cc26d1bf6c49114258f0dae8355
      Resolves: #69568
      Releases: master
      Reviewed-by: Anja Leichsenring's avatarAnja Leichsenring <>
      Tested-by: Anja Leichsenring's avatarAnja Leichsenring <>
      Reviewed-by: default avatarFlorian Peters <>
      Reviewed-by: Mathias Schreiber's avatarMathias Schreiber <>
      Tested-by: Mathias Schreiber's avatarMathias Schreiber <>
      Reviewed-by: Alexander Opitz's avatarAlexander Opitz <>
      Tested-by: Alexander Opitz's avatarAlexander Opitz <>
      Reviewed-by: Wouter Wolters's avatarWouter Wolters <>
      Tested-by: Wouter Wolters's avatarWouter Wolters <>
      Reviewed-by: Christian Kuhn's avatarChristian Kuhn <>
      Tested-by: Christian Kuhn's avatarChristian Kuhn <>
  30. 15 Jul, 2015 1 commit
  31. 01 Feb, 2015 1 commit
  32. 18 Jan, 2015 1 commit
  33. 07 Jan, 2015 1 commit
  34. 17 Dec, 2014 1 commit
  35. 13 Dec, 2014 1 commit
  36. 04 Dec, 2014 1 commit
    • Benni Mack's avatar
      [DB][FEATURE] Add ISO 639-1 keys to sys_language · f1e399f3
      Benni Mack authored
      The language handling of records in TYPO3
      is solely based on UIDs of the sys_language DB table,
      but no reference to the real language used.
      The ISO 639-1 defines the language identifiers
      (ISO language code) completely (182 entries).
      If the real language key was needed before in
      TYPO3, one could install static_info_tables
      which takes a field ("static_lang_isocode") in the
      various places of the TYPO3 Core and fetches
      the isocode via separate SQL-Queries.
      The change introduces the ISO language
      two-letter-keys natively in the core in order to
      1. use less SQL queries in FE and BE if
      static_info_tables was installed
      2. remove hard coded dependencies of
      3. and always ensure that the core
      includes the ISO code
      Additionally one can now use the
      $TSFE->sys_language_isocode all the time for
      working with the ISO code instead of the
      UID parameter, meaning that isocode can now be
      set with a TypoScript parameter as well.
      A Migration Wizard moves values put in the old
      DB field (which is a UID reference to
      static_languages) to the new DB field "language_isocode".
      The old field is deprecated to use without the
      new properly filled field "language_isocode".
      In TYPO3 CMS 8 the static_lang_isocode field
      will be removed within the CMS core (but could
      still be included in static_info_tables).
      Releases: master
      Resolves: #61542
      Change-Id: Ia017af52af354ac204ffac11635d99df120b029a
      Reviewed-by: default avatarMarkus Klein <>
      Tested-by: default avatarMarkus Klein <>
      Reviewed-by: Georg Ringer's avatarGeorg Ringer <>
      Tested-by: Georg Ringer's avatarGeorg Ringer <>
  37. 30 Nov, 2014 1 commit
  38. 28 Oct, 2014 1 commit
  39. 25 Oct, 2014 1 commit