- 22 May, 2020 1 commit
-
-
Resolves: #91457 Releases: master Change-Id: I29009a9498b050942e34a27815acdf996e6f0539 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/64558 Tested-by:
TYPO3com <noreply@typo3.com> Tested-by:
Daniel Goerz <daniel.goerz@posteo.de> Tested-by:
Andreas Fernandez <a.fernandez@scripting-base.de> Reviewed-by:
-
- 15 Apr, 2020 1 commit
-
-
With this patch, the header comment of php files is automatically added by the php-cs-fixer, which guarantees that its format and place of occurrence remain the same in all files. Files that are copied over from other projects are excluded. Furthermore, files that are kind of inspired by other projects also get the same header comment but may have a second, additional comment explaining its origin. Used command: bin/php-cs-fixer fix --config=Build/php-cs-fixer/header-comment.php Releases: master Resolves: #91024 Change-Id: I5a040517e0fbde6e5a27d589bf2f222078326dc8 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/64159 Tested-by:Benni Mack <benni@typo3.org> Reviewed-by:
-
- 14 Apr, 2020 1 commit
-
-
This change adds two changes 'blank_line_after_opening_tag' => true, 'single_trait_insert_per_statement' => true, to our PHP-CS Fixer configuration, adopting more rules related to PSR-12. Resolves: #91020 Releases: master Change-Id: I180b2cbceb077911bddeb42d9f131e5b32244ed2 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/64158 Tested-by:Josef Glatz <josefglatz@gmail.com> Tested-by:
Oliver Bartsch <bo@cedev.de>
Tested-by: Alexander Schnitzler <git@alexanderschnitzler.de> Tested-by:
Oliver Bartsch <bo@cedev.de>
Reviewed-by:
-
- 13 Apr, 2020 1 commit
-
-
As a preparation to be compatible with PSR-12, all spaces in strict type declerations are removed. Releases: master Resolves: #91009 Change-Id: I2b7c2fda42b44168b5c4c6b21711eede2eadaf2e Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/62104 Tested-by:
Oliver Bartsch <bo@cedev.de>
Tested-by: Oliver Bartsch <bo@cedev.de>
Reviewed-by:
-
- 16 Jul, 2019 1 commit
-
-
HTML5 defines that <script tags do not need "type=text/javascript" as additional attribute. TYPO3 Backend is fully HTML5, so all parts can be removed there. For Frontend, when having config.doctype = html5 (or empty), then the attributes do not get added anymore as well. If necessary, for Frontend rendering the attribute can be added in HTML5 by specifying includeJS.myfile.type = text/javascript in TypoScript. As this modifies Frontend output, it is considered breaking. Also see W3C specification: https://www.w3.org/TR/html52/semantics-scripting.html#element-attrdef-script-type Resolves: #88772 Releases: master Change-Id: I26ca4361e84cae680eedbf6855e209a6311c33da Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/61300 Reviewed-by:
Markus Klein <markus.klein@typo3.org> Reviewed-by:
Georg Ringer <georg.ringer@gmail.com> Reviewed-by:
Oliver Klee <typo3-coding@oliverklee.de> Reviewed-by:
Oliver Hader <oliver.hader@typo3.org> Tested-by:
-
- 30 Aug, 2018 1 commit
-
-
Enabling future enhancements for the adminpanel without having to make breaking changes for existing module providers is a key ingredient for providing a future proof extensible solution. Using single big interfaces that need to change on updates break backwards compatibility and do not provide sufficient feature encapsulation. The adminpanel APIs have been refactored to use a composition pattern to allow modules more flexibility. Modules can now only implement the interfaces they need instead of implementing all functionality. For example an adminpanel module that only provides page related settings does no longer have to implement the getContent method. Small interfaces have been provided as building blocks for modules with rich functionality. Easy addition of new interfaces that _can_ (not must) be implemented allow future improvements. Additionally the API has been modified to allow a more object-oriented approach using simple DTOs instead of associative arrays for better type-hinting and a better developer experience. Storing and rendering data have been separated in two steps allowing to completely disconnect the rendered adminpanel from the current page. This is a preparation for a standalone adminpanel that can be implemented separately. Resolves: #86003 Releases: master Change-Id: I88236a86e612dee9085b9f6ad7da34f90770d5ed Reviewed-on: https://review.typo3.org/57987 Tested-by:
TYPO3com <no-reply@typo3.com> Reviewed-by:
Benjamin Kott <benjamin.kott@outlook.com> Tested-by:
-
