Skip to content
GitLab
This project is mirrored from https://git.typo3.org/typo3/typo3.git. Pull mirroring failed .
Repository mirroring has been paused due to too many failed attempts. It can be resumed by a project maintainer or owner.
Last successful update .
  1. 29 Jul, 2021 6 commits
  3. 27 Jul, 2021 1 commit
  5. 26 Jul, 2021 1 commit
  7. 23 Jul, 2021 1 commit
  9. 22 Jul, 2021 2 commits
  11. 16 Jul, 2021 1 commit
    • Oliver Bartsch's avatar
      [FEATURE] Allow overriding fileFolder config with TSconfig · 2f0c2656
      Oliver Bartsch authored and Benni Mack's avatar Benni Mack committed 
      The "fileFolder" configuration options, available for TCA
columns of type "select" are used to fill the select field
with predefined files (images / icons). Nowadays this is
frequently used to make a corporate icon set available for
editors. In multi site installations however, those icon sets
usually differ from site to site.

Therefore, the AbstractItemProvider is now extended to allow
overriding those settings with TSconfig (TCEFORM).

Furthermore, to streamline the TCA configuration and to be
in line with the corresponding overrides, the "fileFolder"
TCA configuration options are moved into a dedicated sub array
"fileFolderConfiguration" and the properties are renamed
to be consistent with other TCA options.

* fileFolder => folder
* fileFolder_extList => allowedExtensions
* fileFolder_recursions => depth

A TCA migration is in place.

Resolves: #94406
Releases: master
Change-Id: I621198523edfd328ad68d692d9194017c445406f
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/69832


Tested-by: core-ci's avatarcore-ci <typo3@b13.com>
Tested-by: Jochen's avatarJochen <rothjochen@gmail.com>
Tested-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
Reviewed-by: Jochen's avatarJochen <rothjochen@gmail.com>
Reviewed-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      2f0c2656
  13. 14 Jul, 2021 1 commit
  15. 13 Jul, 2021 1 commit
  17. 12 Jul, 2021 2 commits
  19. 10 Jul, 2021 1 commit
  21. 09 Jul, 2021 1 commit
  23. 06 Jul, 2021 2 commits
  25. 05 Jul, 2021 1 commit
    • Oliver Bartsch's avatar
      [FEATURE] Improve show columns selection functionality · 16c5cae9
      Oliver Bartsch authored and Benni Mack's avatar Benni Mack committed 
      In #94218, the show columns selection was already improved
by relocating it to each tables' header, making it always
available (not only in single-table view).

Since the used dropdown leads to confusion and visibility
drawbacks for records, having long labels, the selector
now lives in a modal. Besides the columns to select,
the new modal contains some selector options, such as
"select all" or "toggle selection". Those options are
fixed at the top, making them always visible, even for
records with a lot of columns.

Furthermore the checkboxes now use a more suitable
"check" icon, the columns are sorted lexically and
also management fields (e.g. `sorting`) are now
displayed with a human-readable label. This label
is now also used in the table header.

Besides the UX, this patch also brings some technical
improvements. The whole column selection logic is moved
into a dedicated controller, which may allows reuse in
the future (e.g. for the filelist module). Also the
JavaScript part is extracted from the Recordlist JS-module
into a dedicated web component.

Finally some cleanup of the existing code is done, making
it more readable and more efficient.

Resolves: #94474
Releases: master
Change-Id: I0f2f8711ee4b40c9e29e633b9fe790dcacae8bb5
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/69691


Tested-by: core-ci's avatarcore-ci <typo3@b13.com>
Tested-by: Jochen's avatarJochen <rothjochen@gmail.com>
Tested-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
Reviewed-by: Jochen's avatarJochen <rothjochen@gmail.com>
Reviewed-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      16c5cae9
  27. 01 Jul, 2021 3 commits
  29. 30 Jun, 2021 2 commits
    • Oliver Bartsch's avatar
      [TASK] Add convenience method for extbase JSON responses · 0943a9c5
      Oliver Bartsch authored 
      Since #92784 extbase actions require to return a PSR-7 Response.
To ease the migration path, the convenience method htmlResponse()
was added. This method creates a new PSR-7 Response with the correct
header and status code. Furthermore, in case no $html content is
given explicitly, the current view is rendered and the result
passed as response body.

Extbase however also features the JsonView, which is widely
used in third-party extensions as well as in multiple core
controllers itself. Also TSFE has to be respected when adding
the content-type header with the correct charset. Therefore,
a new method jsonResponse(), with similar functionality to
htmlResponse(), is now added along with adaptations of all
places in core controllers.

Resolves: #94440
Related: #92784
Releases: master
Change-Id: Ic591a8788f586050578db8b4187e29325d180f49
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/69664


Tested-by: core-ci's avatarcore-ci <typo3@b13.com>
Tested-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
Tested-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
Tested-by: Oliver Bartsch's avatarOliver Bartsch <bo@cedev.de>
Reviewed-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
Reviewed-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
Reviewed-by: Oliver Bartsch's avatarOliver Bartsch <bo@cedev.de>
      0943a9c5
    • Christian Kuhn's avatar
      [FEATURE] Extbase Request implements ServerRequestInterface · 8fde6812
      Christian Kuhn authored and Benni Mack's avatar Benni Mack committed 
      The patch changes the extbase Mvc/Request to implement
PSR-7 ServerRequestInterface: The former extbase request
details like 'controllerAction' are changed to an
PSR-7 attribute and the Request class is now a
decorator - it receives the original PSR-7 request
as constructor argument, then implements both the
extbase RequestInterface plus PSR-7 ServerRequestInterface.

This way, the Request object itself does not hold
state (except the original request), but channels
all get* and with* calls to the PSR-7 request object.
This avoids creating a new standalone object and moving
all data from the PSR-7 object into the new object.

The patch is relatively conservative. The extbase
related set* methods are kept even though they're
all @internal and violate immutability, and various
method signatures are not adapted towards strict
typing, yet. The reason for that are various
chain- and loop dependencies especially in fluid view
that should be solved with single patches before extbase
Request can be streamlined further. Current usages also
rely on fallback layers within __construct(), which can
be solved when consuming places are adapted - The patch
would have become much bigger if that would be mixed in.

Change-Id: I218de0ee30d16245e7d562d0aba2795ccc439901
Resolves: #94428
Releases: master
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/69545


Tested-by: core-ci's avatarcore-ci <typo3@b13.com>
Tested-by: Oliver Bartsch's avatarOliver Bartsch <bo@cedev.de>
Tested-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
Reviewed-by: Oliver Bartsch's avatarOliver Bartsch <bo@cedev.de>
Reviewed-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      8fde6812
  31. 29 Jun, 2021 2 commits
  33. 28 Jun, 2021 1 commit
  35. 27 Jun, 2021 1 commit
  37. 26 Jun, 2021 1 commit
  39. 22 Jun, 2021 1 commit
  41. 21 Jun, 2021 2 commits
  43. 19 Jun, 2021 1 commit
  45. 18 Jun, 2021 2 commits
    • Christian Kuhn's avatar
      [TASK] Deprecate extbase ReferringRequest · 8eb528d0
      Christian Kuhn authored 
      When extbase has been changed to PSR-7 responses,
class ReferringRequest has been nearly obsoleted:
It is only used to be immediately turned into a
ForwardResponse.
To further prepare towards PSR-7 requests, usage of
ReferringRequest which extends extbase Request is
dropped and the class marked as deprecated.

Change-Id: If16c09b0601792f6702fbacee064cd4d514c70c6
Resolves: #94367
Related: #92502
Releases: master
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/69513


Tested-by: core-ci's avatarcore-ci <typo3@b13.com>
Tested-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
Tested-by: Jochen's avatarJochen <rothjochen@gmail.com>
Tested-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
Reviewed-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
Reviewed-by: Jochen's avatarJochen <rothjochen@gmail.com>
Reviewed-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      8eb528d0
    • Christian Kuhn's avatar
      [TASK] Deprecate extbase ObjectManager->getEmptyObject() · 14805bdf
      Christian Kuhn authored 
      ObjectManager->getEmptyObject() is only used in extbase
persistence DataMapper when domain objects are "thawed":
An existing DB row is fetched and a model object is
created from it.

From extbase PoV, a domain object lifecycle is "creation"
("own a new car"), then eventually "freezing" it in DB,
"thawing" it from DB to update it's state ("washed today,
it's now clean"), and eventually deletion ("brought to
scrapyard, don't own it anymore").

Extbase now says that "thawing" and "creation" are two
different things and thus decided that programmatically,
__construct() on thawed objects should NOT be called,
because, well, it's not new, just thawed! Don't assume
__wakeup() is called instead, though: It's not.

Extbase of course has to hop through quite some loops
to violate this PHP language construct. It even needs
the 3rd party dependency doctrine/instantiator to achieve
suppressing __construct() call, since the previous
'unserialize hack' broke somewhere during PHP 5 times.

Additionally, even though extbase Domain Model objects
*should* be plain old PHP objects, they still allow
inject* methods and are dependency injection aware.

This is a problem when moving away from ObjectManager
towards symfony DI, because symfony does not support
this creative extbase view of supressing __construct()
when instantiating objects.

We can't get rid of this easily in extbase, though.
There is no good way to deprecation-log this behavior. A
feature toggle seems to be overkill - probably not too
many extbase devs are aware of this implementation detail
in the first place, and the impact if __construct() is
properly called when an object is thawed should be relatively
small: First, models are usually relatively stupid in extbase
(which is good, they should be), and if they have a
__construct() method at all, chances are, everything that is
done there is overriden during the following mapping process
anyways.

We thus decided against a feature toggle for this. Instead,
we *keep* the current instantiation logic in v11, just
mark the code places as deprecated, configure the extension
scanner to look for additional getEmptyObject() calls in
extensions, and add a depreation reST file pointing out the
situation and stating __construct() will be called in v12
for thawed objects.

Resolves: #94377
Related: #90803
Releases: master
Change-Id: Ied3da8b9d885be2f635b9bc6c66b37fc9825decc
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/69520


Tested-by: Jochen's avatarJochen <rothjochen@gmail.com>
Tested-by: core-ci's avatarcore-ci <typo3@b13.com>
Tested-by: Daniel Goerz's avatarDaniel Goerz <daniel.goerz@posteo.de>
Tested-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
Reviewed-by: Jochen's avatarJochen <rothjochen@gmail.com>
Reviewed-by: Daniel Goerz's avatarDaniel Goerz <daniel.goerz@posteo.de>
Reviewed-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      14805bdf
  47. 17 Jun, 2021 1 commit
  49. 16 Jun, 2021 2 commits