Skip to content
Snippets Groups Projects
Select Git revision
  • 12.4
  • main default
  • 11.5
  • 13.3
  • l10n_main
  • 13.1
  • 13.0
  • l10n_12.4
  • 10.4
  • 12.1
  • 9.5
  • 11.3
  • master
  • 11.1
  • TYPO3_8-7
  • 10.2
  • 9.3
  • 9.2
  • TYPO3_7-6
  • TYPO3_7-0
  • v13.3.1
  • v12.4.21
  • v11.5.40
  • v13.3.0
  • v12.4.20
  • v12.4.19
  • v12.4.18
  • v11.5.39
  • v12.4.17
  • v13.2.1
  • v13.2.0
  • v12.4.16
  • v11.5.38
  • v13.1.1
  • v12.4.15
  • v11.5.37
  • v13.1.0
  • v12.4.14
  • v12.4.13
  • v12.4.12
40 results
Search by author
  • Any Author
  • Daniel Hürtgen Daniel Hürtgen higidi
  • Jenkins Jenkins jenkins
  • **** **** project_53_bot
3 authors
  1. Dec 10, 2019
  3. Dec 03, 2019
  5. Dec 02, 2019
  7. Nov 29, 2019
  9. Nov 28, 2019
  11. Nov 27, 2019
  13. Nov 26, 2019
  15. Nov 25, 2019
  17. Nov 22, 2019
  19. Nov 21, 2019
    • Benni Mack's avatar
      [TASK] Raise testing framework to version 5.0.16 · 5cf5eeb8
      Benni Mack authored 
      The next version has PHP 7.4 support and was
cleaned up a lot.

Used composer command:
    composer req typo3/testing-framework:~5.0.16 \
        --update-with-all-dependencies --dev

Resolves: #89725
Releases: master
Change-Id: Iba181feb693c9ee61b8792cd0d0197c1e3b1f59a
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/62359


Tested-by: default avatarTYPO3com <noreply@typo3.com>
Tested-by: default avatarBenni Mack <benni@typo3.org>
Reviewed-by: default avatarBenni Mack <benni@typo3.org>
      5cf5eeb8
    • 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
  21. Nov 19, 2019
  23. Nov 09, 2019
  25. Oct 30, 2019
  27. Oct 23, 2019
  29. Oct 18, 2019
  31. Oct 01, 2019
  33. Sep 24, 2019
  35. Sep 23, 2019
  37. Sep 20, 2019
    • Benjamin Franzke's avatar
      [FEATURE] Provide implementation for PSR-17 HTTP Message Factories · 7b5612f5
      Benjamin Franzke authored 
      Support for PSR-17 HTTP Message Factories has been added.

PSR-17 HTTP Factories are intended to be used by PSR-15 request handlers
in order to create PSR-7 compatible message objects.

Classes may use dependency injection to use any of the available PSR-17
HTTP Factory interfaces.

The Request/Response base class (Message) is adapted to be able to lazily
initialize a stream when getBody() is called.
This is done as the PSR (Stream)RequestFactoryInterface does not allow
to control Stream properties. Therefore it is a performance
optimization to defer initialization. It is likely, that a new
Stream will be added to a Request with withStream() anyway.
(Which would mean resources for the intermediate stream would have
been wasted)

Furthermore some DocBlocks are adapted to reflect the variadic
UriInterface/StreamInterface parameters that are already handled in
code but were not documented. These cases are needed/required
by the PSR-17 factory implementation now.

composer require psr/http-factory:^1.0

Releases: master
Resolves: #89018
Change-Id: Ie6b9d865679bbf6f5d3d030b0ed1a3f277c47a3d
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/61558


Tested-by: default avatarTYPO3com <noreply@typo3.com>
Tested-by: default avatarBenni Mack <benni@typo3.org>
Tested-by: default avatarFrank Nägler <frank.naegler@typo3.org>
Reviewed-by: default avatarBenni Mack <benni@typo3.org>
Reviewed-by: default avatarFrank Nägler <frank.naegler@typo3.org>
      7b5612f5
  39. Sep 13, 2019
  41. Sep 11, 2019
  43. Sep 04, 2019
  45. Aug 28, 2019
  47. Aug 13, 2019
  49. Aug 05, 2019
  51. Jul 23, 2019
  53. Jul 17, 2019
  55. Jul 16, 2019
    • Benni Mack's avatar
      [FEATURE] Introduce PSR-14-based EventDispatcher as alternative for hooks · 0b0f5f1e
      Benni Mack authored 
      
The new PSR-14 standard for dispatching Events (that is: to extend
a Framework without having to modify a frameworks' code) adds
a EventDispatcher object that can dispatch Event objects to
EventListeners.

In PSR-14 every dispatched event is an object. It uses PHP class names as
identifiers for events. Class hierarchies may be used to group events.

A ListenerProvider object collects available listeners from an extension
and allows to listen and/or modify data provided by the Event object.

The current implementation relies on a custom TYPO3-specific
ListenerProvider that is configured using Symfony's Dependency Injection
tags.

As an example the Mailer-postProcInitialization signal/slot is
replaced by an Event.

This first patch introduces the feature, and does not deprecate
anything yet. The most important part is that new Events
can use this API instead of Hooks in TYPO3 v10.

Short-Term goal is to deprecate SignalSlot dispatcher in TYPO3 v10,
and migrate all signals to the EventDispatcher.

Resolves: #88770
Releases: master
Change-Id: I3649ddb9b9340640199279e6af3c040bffc397fe
Signed-off-by: default avatarBenni Mack <benni@typo3.org>
Signed-off-by: default avatarBenjamin Franzke <bfr@qbus.de>
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/61303


Reviewed-by: default avatarGeorg Ringer <georg.ringer@gmail.com>
Reviewed-by: default avatarAndreas Fernandez <a.fernandez@scripting-base.de>
Tested-by: default avatarGeorg Ringer <georg.ringer@gmail.com>
      0b0f5f1e
  57. Jul 13, 2019
    • Benni Mack's avatar
      [!!!][TASK] Remove dependencies of TSFE · e50b1c1a
      Benni Mack authored 
      This patch re-arranges the TYPO3 Core internally used
middlewares for lifting off the weight of $GLOBALS['TSFE']
as Site Handling already introduced a lot of functionality
which can now be utilized further.

For this reason, the Frontend Rendering chain has
been adapted.

* If there is a "Site" + "Language" resolved, this information can
be used directly, as there are no dependencies currently.

* Frontend + Backend User Authentication works regardless
of TSFE, Frontend User is added to the Request object as
attribute to be added to TSFE later-on.

* Resolving the Page ("slug") and mapping them to Page
Arguments (URL parts + GET parameters) as well as validation
against cHash is fully decoupled from TSFE.

After that, TSFE is instantiated, which now gets all resolved
objects injected.

TSFE now only resolves the rootline against the proper permissions
(auth) and validates the final page. Once done, TypoScript is
compiled / cached.

TSFE still contains the rootline, TypoScript, and the information
about which non-cacheables are there.

RequestHandler creates or fetches cached content, but currently piped
through TSFE. This should be simplified further later-on.

Resolves: #88717
Releases: master
Change-Id: I12807455fd8b01493b2da45cf73a5c532b108cbe
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/61155


Tested-by: default avatarTYPO3com <noreply@typo3.com>
Tested-by: default avatarAnja Leichsenring <aleichsenring@ab-softlab.de>
Tested-by: default avatarAndreas Fernandez <a.fernandez@scripting-base.de>
Reviewed-by: default avatarAnja Leichsenring <aleichsenring@ab-softlab.de>
Reviewed-by: default avatarAndreas Fernandez <a.fernandez@scripting-base.de>
      e50b1c1a
  59. Jul 11, 2019
    • Benjamin Franzke's avatar
      [FEATURE] Add symfony dependency injection for core and extbase · 0cf8053e
      Benjamin Franzke authored 
      This feature is a combined approach using two containers/concepts:

1) symfony/dependency-injection (now exposed as official TYPO3 API):
   Supports: autoconfiguration, autowiring using Service.{yaml,php}
   files

2) service providers (fork of the experimental interfaces in
   container-interop/service-provider, sometimes called PSR-11+)
   Supports: factory-style configuration using plain php code
   provided for internal use and possible future public use.

1) Symfony dependency injection is provided to be used by extensions
and throughout the TYPO3 core for (auto)wiring of services (classes).
Extensions can control symfony's dependency injection use a file
located in Configuration/Services.yaml, if they need more flexibility
they may also use Configuration/Services.php which can
use symfony's ContainerConfigurator or ContainerBuilder.

2) Service providers are used (within TYPO3 core) to provide
dependency injection for services used in the install tool which require
failsafe boot. This is based on container-interop/service-provider.
container-interop/service-provider is supposed to become a PSR but is
still marked experimental, therefore this commit adds an implementation
to TYPO3 provided for internal use only – it is not public API.
We do still include it (as @interal fork) right now, to adapt to this
upcoming PSR from the very beginning, in order to actually push the
development of this proposal forward.

Service providers in failsafe mode are consumed by a simplistic,
non-compiled container.
Symfony's container is too slow when running uncached (as the compilation,
recursive directory lookups and autowiring needs to be performed on every
invocation). We do not want caching for recovery maintenance tasks
which would not be able to recover from scenarios with broken caches.

Services that are configured through service providers, are both available
in the non compiled install tool container and in the symfony container.
They do *not* need to be defined twice. The two "worlds" are bridged
using a ServiceProviderCompilerPass which creates symfony DI definitions
from service-provider factories. The code is a derivative of the code from
the (outdated) symfony bundle
thecodingmachine/service-provider-bridge-bundle.

Features
--------
 * inject* methods are now supported for all classes (not just Extbase)
   It is suggested to use constructor based injection, this feature
   is available to provide maximum compatibility to the old Extbase DI.
 * Autoconfiguration based on interface implementation.
   (current) autoconfigured interface are:
     SingletonInterface,  MiddlewareInterface, RequestHandlerInterface,
     LoggerAwareInterface, ControllerInterface, ViewHelperInterface
     (we expect more to follow in subsequent commits)

Included adaptions
------------------
In order to demonstrate and to be able to verify the features of this
patch, some classes are adapted to use or support dependency injection:
 * RedirectHandler/RedirectService autowired/autoconfigured
 * Application classes and their dependencies are manually wired in
   service providers. This is required as the application runs in fail-
   safe mode when there is no configuration available (first install)
 * MiddlewareStack is composed in service providers and injected
   as a RequestHandler into the Http\Application classes (in order to
   prevent injecting the Container, which would be an anti pattern).
 * Middleware configuration is treated as service (like a registry),
   and retrieval is provided through service providers (the service
   providers default to the existing middleware configuration format)
 * The Middleware dispatcher now first tries to retrieve classes from
   the PSR-11 container, falling back to makeInstance if not available
 * Dependency Injection using symfony for all core Extbase Controllers
 * A Services.yaml is added for each core extension which contains
   classes that are used in frontend/backend context
 * A LateBoot service is added for install tool

DI vs ext_localconf – loading order, legacy makeInstance support
----------------------------------------------------------------
Dependency Injection containers solve most of the tasks that
ext_localconf.php and GeneralUtility::makeInstance solve for Singletons:
Service configuration and instance management.

(Symfony) DI could therefore be used to replace both in the long run.
Both are doing similar tasks when talking about Singletons:
They create and configure services that are stored and shared in a
central memory storage (container for DI, GU::$singletonInstances for
our legacy TYPO3 case). That means they both actually conflict right
now – in terms of: Who is responsible for creating a class?

We've made a decision to connect these both: GeneralUtility::makeInstance
will offload instantiation to the Container if the class is a) available
and b) no runtime constructor arguments have been passed to makeInstance
(which symfony DI doesn't support).

The DI container itself does provides backwards compatibility to XCLASSES
and class aliases use a new internal helper method makeInstanceForDi.

ext_localconf's main design flaw is the mixture of initialization
and configuration composition without assurance that all configuration
is available before a configuration-dependent class is instantiated.
Proper DI first reads all configuration and then performs all service
injections on demand and pre calculated using a dependency tree – and
therefore always in proper sequence.

What we *don't* want (+ reasons)
-------------------------------
 * Symfony Bundles
   pro: provide a defined way for container configuration)
   con: Requires the Symfony HTTP kernel which is not compatible with PSR7
 * Usage of Symfony\DependencyInjection\ExtensionInterface
   con: It is not useful as it cannot add new compiler passes
 * Handling of prototypes that need dependency injection *and* a way to
   to get custom constructor arguments passed (individual per class)
   While symfony DI can handle prototypes (called 'shared: false'), it
   does not support passing constructor arguments like the Extbase object
   manager does. We'll advocate to using a factory pattern for those
   prototypes instead.
 * Circular dependencies: This is not supported by symfony DI and isn't
   possible with service providers either

Future changes (left out for brevity)
-------------------------------------

 * (cli) Build tool to warmup DI cache/state during deployment
 * Adaptions to (all) core dispatchers to prefer a PSR-11
   container over GeneralUtility::makeInstance

Dependency changes
------------------
composer require symfony/dependency-injection:^4.1 symfony/config:^4.1

Releases: master
Resolves: #88689
Resolves: #84112
Change-Id: I8efd817066b528a5953c56fdd027cb94b2bb8eb3
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/58255


Tested-by: default avatarTobi Kretschmann <tobi@tobishome.de>
Tested-by: default avatarJörg Bösche <typo3@joergboesche.de>
Tested-by: default avatarAlexander Schnitzler <review.typo3.org@alexanderschnitzler.de>
Tested-by: default avatarTYPO3com <noreply@typo3.com>
Tested-by: default avatarBenjamin Franzke <bfr@qbus.de>
Reviewed-by: default avatarTobi Kretschmann <tobi@tobishome.de>
Reviewed-by: default avatarJörg Bösche <typo3@joergboesche.de>
Reviewed-by: default avatarAlexander Schnitzler <review.typo3.org@alexanderschnitzler.de>
Reviewed-by: default avatarBenjamin Franzke <bfr@qbus.de>
      0cf8053e
  61. Jul 04, 2019
  63. Jun 25, 2019
  65. Jun 18, 2019