This project is mirrored from 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. 23 Apr, 2021 1 commit
    • Benjamin Franzke's avatar
      [TASK] Update to Lit v2-rc1 · d0da616d
      Benjamin Franzke authored
      Lit is the umbrella term for the next major
      lit-html (v2) and lit-element (v3) versions.
      Therefore we will refer to these components as
      *Lit* in TYPO3 from now on as well.
      These two libraries also have been migrated into
      a single entry point module named `lit`.
      It is officially described as:
      > The main module exports the core pieces needed for component
      > development: LitElement, html, css, and the most
      lit-html v2 and lit-element v3 are mostly compatible
      to the previous major versions. Main changes are
       * Deprecation of the `lit-element` entry point in
         favor of the new `lit` module
       * @internalProperty changed to @state
       * shadow css declaration via static property
         instead of static getter method
       * The CSSResult type declaration is gone
       * Directive (currently unused in TYPO3) API has changed
      Related testing framework change is:
      Commands used:
        rm -rf typo3/sysext/core/Resources/Public/JavaScript/Contrib/{@lit,lit-element,lit-html,lit}/
        yarn add lit@^2.0.0-rc.1 lit-html@^2.0.0-rc.2 lit-element@^3.0.0-rc.1
        yarn add --dev rollup@^2.32.0 @rollup/plugin-replace
        grunt build
        git add typo3/sysext/core/Resources/Public/JavaScript/Contrib/{@lit,lit-element,lit-html,lit}/
        composer require --dev typo3/testing-framework:^6.8.1
        composer require --dev typo3/testing-framework:^6.8.1 \
          --no-update --working-dir=typo3/sysext/core
      Resolves: #93965
      Releases: master
      Change-Id: I9b659d851e6ad9dc3cc649bd40aab886b86fb0f8
      Tested-by: Oliver Hader's avatarOliver Hader <>
      Tested-by: default avatarTYPO3com <>
      Tested-by: core-ci's avatarcore-ci <>
      Tested-by: Benni Mack's avatarBenni Mack <>
      Tested-by: Benjamin Franzke's avatarBenjamin Franzke <>
      Reviewed-by: Oliver Hader's avatarOliver Hader <>
      Reviewed-by: Benni Mack's avatarBenni Mack <>
      Reviewed-by: Benjamin Franzke's avatarBenjamin Franzke <>
  2. 01 Mar, 2021 1 commit
  3. 08 Feb, 2021 2 commits
    • Benjamin Franzke's avatar
      [TASK] Drop unneeded renderElement from lit-helper · 8cbd504f
      Benjamin Franzke authored and Christian Kuhn's avatar Christian Kuhn committed
      renderElement() was added in patchset 2 of #93446.
      The code was then refactored to use renderHTML, but the method was
      forgotten to be removed in the final patchset.
      Now, the intention of the mentioned patchset 2 was to render nodes
      directly to the DOM in PageTreeDragHandler, instead of rendering to
      a temporary element, just to export and re-import as HTML string
      with jQuery/innerHTML.
      Therefore PageTreeDragHandler is now refactored to a new,
      (internal) method renderNodes() which allows the returned
      nodes to be directly attached to the document.
      Also, while at it, all other lit-helper methods are marked as
      internal as well, as they are still subject to change:
       * `renderHTML()` is only needed when mixing traditional jQuery
         rendering and lit-html (same as for the new `renderNodes()`.)
       * The `icon()` method could likely be replaced by a custom
         <typo3-backend-icon> component
       * `lll()` is only of use for globally available language identifiers
         (which are added via inline JS)  So this is also likely to change
         when more backend modules start to use lit-html/LitElement.
      Resolves: #93464
      Related: #93446
      Releases: master
      Change-Id: I61ab778e28e32b75b6e7965b75259beedbb10ae3
      Tested-by: default avatarTYPO3com <>
      Tested-by: core-ci's avatarcore-ci <>
      Tested-by: Benni Mack's avatarBenni Mack <>
      Tested-by: Christian Kuhn's avatarChristian Kuhn <>
      Reviewed-by: Benni Mack's avatarBenni Mack <>
      Reviewed-by: Christian Kuhn's avatarChristian Kuhn <>
    • Benni Mack's avatar
      [TASK] Clean up Drag&Drop Handling in PageTree · 85c7264b
      Benni Mack authored and Georg Ringer's avatar Georg Ringer committed
      The PageTree components for the navigation area consists of:
      * PageTreeElement (container for rendering the navigation area w. toolbar + dragdrop + tree)
      * PageTreeToolbar (uses DnD for creating new items)
      * PageTree (JS, subclass of SvgTree)
      * PageTreeDragDrop
      This patch aims to rework the "PageTreeDragDrop" javascript file
      by moving separate logic into separate classes (as much as possible)
      and into a more stable API, being a first part.
      PageTreeDragDrop is a mixed code class currently,
      and is now split up in various separate classes:
      * DragDropHandler (interface)
      * ToolbarDragHandler -> used as the Toolbar Draggable Handler for new pages
      * PageTreeNodeDragHandler => used for moving/copying and deleting existing pages/nodes
      * PageTreeDragDrop now acts as a simple wrapper for d3-drag but still has some shared state
      For Future Reference:
      It is still up to decide on how to further decouple the code.
      Idea 1: Putting the d3-drag initialization into the right
      place and avoiding cross-dependencies. In general "initializeDragForNode"
      would also be handled via events, and all options / settings would be
      moved into the PageTreeDragDrop class.
      Ideally the PageTreeDragDrop contains the status of the
      current drag+drop action (position, node etc), so the PageTree
      would not know of anything itself.
      Idea 2: Another possibility is to use the current "PageTreeDragDrop"
      as a generic "TreeDragDropManager" because it does not
      contain any Page-Tree specific code anymore, but could be carried
      on later-on.
      The current change is already a good step as it moves all code
      to TypeScript and minimizes injection via constructors (except
      for the Tree itself).
      Resolves: #93446
      Releases: master
      Change-Id: Ibd7a067c1e6a821b138a8cc2971ec8133392b600
      Tested-by: default avatarTYPO3com <>
      Tested-by: Andreas Fernandez's avatarAndreas Fernandez <>
      Tested-by: Georg Ringer's avatarGeorg Ringer <>
      Reviewed-by: Andreas Fernandez's avatarAndreas Fernandez <>
      Reviewed-by: Georg Ringer's avatarGeorg Ringer <>
  4. 18 Dec, 2020 2 commits
  5. 05 Apr, 2019 1 commit
  6. 16 Mar, 2018 1 commit
  7. 20 Nov, 2015 1 commit
  8. 08 Oct, 2015 1 commit
  9. 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 <>
  10. 17 Jul, 2015 1 commit
  11. 13 Dec, 2014 1 commit
  12. 22 Jun, 2014 1 commit
    • Michael Schams's avatar
      [TASK] Re-work/simplify copyright header in PHP files - Part 2 · 02670b20
      Michael Schams authored
      This patch replaces the copyright/license header in PHP files with a
      new, simplified one. The new header does not show the year figure, nor
      an author name, and refers to the LICENSE.txt file for the full
      copyright information. License is: GPL2 or any later version.
      This is a multi-part commit due to the huge number of changed files.
      See issue #59778 for further details.
      Resolves: #59778
      Releases: 6.3, 6.2
      Change-Id: I155df27e66ec103a4f83356adef7dc441585b54a
      Reviewed-by: Krzysztof Adamczyk
      Tested-by: Krzysztof Adamczyk
      Reviewed-by: Markus Klein
      Tested-by: Markus Klein
  13. 04 May, 2014 1 commit
    • Helmut Hummel's avatar
      [BUGFIX] Flush caches in group should throw exception · b3c932f2
      Helmut Hummel authored
      If a not existent cache group is specified
      to the flushCachesInGroup methods, there is no
      indication that actually nothing happened.
      Throw an exception instead, so that calling code
      can easily be fixed.
      Resolves: #58465
      Releases: 6.2
      Change-Id: I9617fcee9abfa27a9cb76a3fd12543c62420e719
      Reviewed-by: Anja Leichsenring
      Tested-by: Anja Leichsenring
      Reviewed-by: Felix Oertel
      Tested-by: Felix Oertel
  14. 01 Oct, 2013 1 commit
  15. 19 Mar, 2013 1 commit
    • Wouter Wolters's avatar
      [TASK] Update copyright year to 2013 · 4d463976
      Wouter Wolters authored and Christian Kuhn's avatar Christian Kuhn committed
      In this patch are also some fixes for files containing
      a interface. Due the namespace change all interfaces
      have the curly bracket not on the same line as the
      interface name.
      Change-Id: I64ba45de73693452d681ce7f018965968b11d2af
      Resolves: #46370
      Releases: 6.1
      Reviewed-by: Christian Kuhn
      Tested-by: Christian Kuhn
  16. 16 Nov, 2012 1 commit
  17. 23 Aug, 2012 1 commit
  18. 15 Jul, 2011 1 commit
    • Christian Kuhn's avatar
      [TASK] Remove XCLASS definitions from cache classes · 0957fe4e
      Christian Kuhn authored
      With #28063 many core cache classes are required directly during bootstrap.
      This makes XCLASS impossible since those base classes are not instantiated
      with t3lib_div::makeInstance() anymore. t3lib_cache is static and can not be
      XCLASSED. The caching framework has a built-in feature to register and use own
      implementations. The patch removes all XCLASS definitions of cache classes.
      Change-Id: I1e624bb769b899a14491aa3ee1cca9da480ebfb6
      Resolves: #28221
      Related: #28063
      Reviewed-by: Stefan Neufeind
      Reviewed-by: Xavier Perseguers
      Tested-by: Xavier Perseguers
      Reviewed-by: Philipp Gampe
      Tested-by: Philipp Gampe
      Reviewed-by: Christian Kuhn
      Tested-by: Christian Kuhn
  19. 25 Mar, 2011 1 commit
  20. 18 Jan, 2011 1 commit
  21. 05 Dec, 2010 1 commit
  22. 24 Nov, 2010 1 commit
  23. 13 Jun, 2010 1 commit
  24. 07 Jun, 2010 1 commit
  25. 09 Mar, 2009 1 commit
  26. 15 Sep, 2008 1 commit
  27. 15 Nov, 2007 1 commit
  28. 10 Apr, 2006 1 commit
  29. 01 Apr, 2005 1 commit
  30. 13 Sep, 2004 1 commit
    • Kasper Skårhøj's avatar
      · 40cddcec
      Kasper Skårhøj authored
      * Updated my email address from "" (which is closed and will stay that way) to "" which programmers should be able to figure out...
      * Updated all JavaDoc comments and function/class indexes in files, preparing for 3.7.0RC
      git-svn-id: 709f56b5-9817-0410-a4d7-c38de5d9e867
  31. 14 Apr, 2004 1 commit
  32. 31 Jan, 2004 1 commit
  33. 27 Oct, 2003 1 commit
  34. 26 Oct, 2003 1 commit
  35. 03 Oct, 2003 1 commit