Skip to content
Snippets Groups Projects
  1. Apr 12, 2024
  2. Oct 24, 2023
  3. Aug 07, 2023
  4. Mar 27, 2023
  5. Mar 10, 2023
  6. Nov 20, 2022
  7. Aug 08, 2022
  8. Apr 22, 2022
  9. Feb 08, 2022
  10. Feb 07, 2022
  11. Jan 08, 2022
  12. Dec 15, 2021
  13. Dec 04, 2021
  14. Sep 24, 2021
  15. Sep 21, 2021
  16. Jun 30, 2021
  17. Jun 14, 2021
  18. May 06, 2021
  19. May 04, 2021
  20. Mar 15, 2021
  21. Mar 01, 2021
  22. Dec 14, 2020
    • Alexander Schnitzler's avatar
      [TASK] Deprecate @Extbase\Inject · 64c8a784
      Alexander Schnitzler authored
      Since core dependency injection is in place and is about to
      replace the extbase dependency injection, marking properties
      with the @Extbase\Inject annotation to invoke property injection is
      deprecated and must be replaced by one of the following di
      methods:
      
      - constructor injection: works both with core and extbase di
        and is well suited to make extensions compatible for multiple
        TYPO3 versions.
      
      - setter injection: Basically the same like constructor injection.
        Both the core and extbase di can handle setter injection and
        both are supported in different TYPO3 versions.
      
      - (core) property injection: This kind of injection can be used
        but it requires the configuration of services via a Services.yaml
        in the Configuration folder of an extension.
      
      The recommended way is constructor injection. Not only is it the
      most compatible version of di, it also brings the advantage of
      clearly showing dependencies of a class. Also, it quickly shows
      if dependencies stack up which i...
      64c8a784
  23. Nov 05, 2020
  24. Jun 03, 2020
  25. Apr 15, 2020
  26. Apr 14, 2020
  27. Apr 13, 2020
  28. Jan 22, 2020
  29. Dec 03, 2019
  30. Nov 22, 2019
  31. Nov 21, 2019
    • Benni Mack's avatar
      [TASK] Update symfony dependencies to 4.4 or 5.0 · f20a7aae
      Benni Mack authored
      TYPO3 Core v10 should rely on Symfony 4.4 (LTS release)
      and add support for 5.0 automatically.
      
      Symfony 4.4 made breaking changes to the Mailer and Mime components
      which now need adaptions.
      
      Used composer command:
      
      composer req "symfony/config":"^4.4 || ^5.0" \
      "symfony/console":"^4.4 || ^5.0" \
      "symfony/dependency-injection":"^4.4 || ^5.0" \
      "symfony/expression-language":"^4.4 || ^5.0" \
      "symfony/finder":"^4.4 || ^5.0" \
      "symfony/mailer":"^4.4 || ^5.0" \
      "symfony/mime":"^4.4 || ^5.0" \
      "symfony/property-access":"^4.4 || ^5.0" \
      "symfony/property-info":"^4.4 || ^5.0" \
      "symfony/routing":"^4.4 || ^5.0" \
      "symfony/yaml":"^4.4 || ^5.0" --update-with-all-dependencies
      
      Loading composer repositories with package information
      Updating dependencies (including require-dev)
      Package operations: 0 installs, 27 updates, 0 removals
        - Updating symfony/polyfill-ctype (v1.11.0 => v1.12.0)
        - Updating symfony/filesystem (v4.3.1 => v4.4.0)
        - Updating symfony/config (v4.3.2 => v4.4.0)
        - Updating symfony/service-contracts (v1.1.2 => v1.1.8)
        - Updating symfony/polyfill-php73 (v1.11.0 => v1.12.0)
        - Updating symfony/polyfill-mbstring (v1.11.0 => v1.12.0)
        - Updating symfony/console (v4.3.1 => v4.4.0)
        - Updating symfony/dependency-injection (v4.3.2 => v4.4.0)
        - Updating symfony/var-exporter (v4.3.1 => v4.4.0)
        - Updating symfony/cache-contracts (v1.1.1 => v1.1.7)
        - Updating psr/log (1.0.2 => 1.1.2)
        - Updating symfony/cache (v4.3.1 => v4.4.0)
        - Updating symfony/expression-language (v4.3.1 => v4.4.0)
        - Updating symfony/finder (v4.3.3 => v4.4.0)
        - Updating symfony/polyfill-php72 (v1.11.0 => v1.12.0)
        - Updating symfony/polyfill-intl-idn (v1.11.0 => v1.12.0)
        - Updating symfony/mime (v4.3.2 => v4.4.0)
        - Updating symfony/event-dispatcher-contracts (v1.1.1 => v1.1.7)
        - Updating symfony/event-dispatcher (v4.3.1 => v4.4.0)
        - Updating doctrine/lexer (v1.0.1 => 1.2.0)
        - Updating egulias/email-validator (2.1.9 => 2.1.11)
        - Updating symfony/mailer (v4.3.2 => v4.4.0)
        - Updating symfony/inflector (v4.3.1 => v4.4.0)
        - Updating symfony/property-access (v4.3.1 => v4.4.0)
        - Updating symfony/property-info (v4.3.1 => v4.4.0)
        - Updating symfony/routing (v4.3.1 => v4.4.0)
        - Updating symfony/yaml (v4.3.1 => v4.4.0)
      
      Resolves: #89721
      Releases: master
      Change-Id: I834a79e3880b3a7a95429c2fe052657e21599ec7
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/62354
      
      
      Tested-by: default avatarTYPO3com <noreply@typo3.com>
      Tested-by: default avatarAnja Leichsenring <aleichsenring@ab-softlab.de>
      Tested-by: default avatarSusanne Moog <look@susi.dev>
      Tested-by: default avatarBenni Mack <benni@typo3.org>
      Reviewed-by: default avatarAnja Leichsenring <aleichsenring@ab-softlab.de>
      Reviewed-by: default avatarSusanne Moog <look@susi.dev>
      Reviewed-by: default avatarBenni Mack <benni@typo3.org>
      f20a7aae
  32. Aug 27, 2019
  33. Jul 05, 2019
    • Alexander Schnitzler's avatar
      [TASK] Streamline ClassSchema property api · 87268b67
      Alexander Schnitzler authored
      This patch tackles three different issues with the current
      ClassSchema property api.
      
      1) Due to the history and the refactoring of the ReflectionService,
         the ClassSchema class cached data redundantly. Information like
         the type of a property has been stored multiple times in different
         cache keys. With this patch, the redundancy has been removed.
      
      2) The information about properties had been roughly grouped by the
         ones gathered by php reflection and the ones gathered from doc
         blocks and/or annotations. This kind of grouping had also been
         exposed to the public by different methods in the Property class.
      
         Said grouping has been removed and the api does no longer allow
         for requesting annotation data. The purpose of the api is to tell
         the status quo of the information about a property, regardless of
         how said information had been gathered in the first place.
      
         Instead of exposing the annotation data itself via method
         `getAnnotationValue('lazy')`, there is a specific method for each
         relevant piece of information like `isLazy()`.
      
      3) A lot of information about properties are boolean values which
         had been stored as separate keys in the cache. All boolean keys
         are now represented by a BitSet, which saves quite a lot of
         bytes during serialization of ClassSchema instances.
      
      Releases: master
      Resolves: #88612
      Change-Id: I838c7b996275341d4ee65e6b6c6a4f7de1b92e28
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/61101
      
      
      Tested-by: default avatarAndreas Fernandez <a.fernandez@scripting-base.de>
      Tested-by: default avatarTYPO3com <noreply@typo3.com>
      Tested-by: default avatarAnja Leichsenring <aleichsenring@ab-softlab.de>
      Reviewed-by: default avatarAndreas Fernandez <a.fernandez@scripting-base.de>
      Reviewed-by: default avatarAnja Leichsenring <aleichsenring@ab-softlab.de>
      87268b67
  34. Jun 28, 2019
  35. Jun 21, 2019
  36. Mar 18, 2019
  37. Mar 15, 2019