[TYPO3-german] Eigene php-Scripts in v 8.7

[Stephan Schuler]

Hallo zusammen.

Soweit ich informiert bin ist das in der Tat weggefallen, das zugehörige Forge-Issue dürfte das hier sein:
https://forge.typo3.org/issues/73514

Ich finde das aber überhaupt nicht unglücklich gelöst in TYPO3.
Und nur zur Untermauerung dieser einen Aussage dient der nachfolgende Block. Inhaltlich wurde bereits alles gesagt (.

Eine Datei einzubinden die direkt etwas tut will ja ohnehin niemand. Ein „include“ oder „require“ lässt vielleicht eine Variable im globalen Kontext zurück, vielleicht sogar eine Konstante oder eine Klasse, und wenn man an zwei unterschiedlichen Stellen die gleiche Datei einbindet geht die Welt unter. Ein „require_once“ dagegen wird nur einmal ausgeführt, auch wenn ich den Code-Schnipsel vielleicht an mehreren Stellen haben will.

Dass der Weg also über ein „require_once“ gehen muss, das eine Klasse registriert die dann wiederum mehrfach instanziiert werden kann, darüber sind wir uns ja vermutlich einig. Das hast Du, Peter, ja auch gar nicht anders vor.

Wenn aber der Weg ohnehin eine Klasse ist, dann ist sinnvollste Integration doch der Autoloader.
http://php.net/autoload

Composer nimmt einem das ab, weil er PSR-0 und PSR-4 unterstützt, und zur Not noch eine Classmap. Dass Composer auch Einzeldateien unterstützt verscheige ich hier einfach mal.
https://getcomposer.org/doc/04-schema.md#autoload

Das ist jetzt natürlich nur nochmal wiedergekaut was Helmut Hummel im bereits von Dir, Alex, verlinkten Blogpost erzählt hat. Allerdings möchte ich herausheben, dass es eben nicht ein Weg ist den TYPO3 hier entgegen der sonstigen PHP-Welt einschlägt, sondern dass es nur ein kleines Bisschen TYPO3 um das ansonsten in der PHP-welt etablierte Standardverfahren ist.

Eine gänzlich von TYPO3 losgelöste Variante wäre natürlich, eine komplett eigene Autload-Funktion zu schreiben die mittels spl_autoload_register() registriert wird. Das kann ich auch ohne Extension, wenn ich will direkt in der LocalConfiguration.php oder der AdditionalConfiguration.php.

Der aus meiner Sicht relevante Aspekt dabei ist, dass niemand der nicht ohnehin Schreibrecht auf die PHP-Files oder composer.json hat neuen PHP-Code einbringen kann (sprich: Das gilt natürlich nur für den Composer-Mode, nicht für den Legacy-Mode). Mit der bisherigen Variante war es möglich, dass Administratoren im Backend eine PHP-Datei in einen Storage gelegt haben, die via IncludeLibs eingebunden und den zugehörigen PHP-Code dann ausgeführt. Das aktuelle Setup sollte das unterbinden.

Ganz grundlegend ist es zum Teil auch eine Philosophiefrage. PHP-Code gehört nicht in den Fileadmin (wo ihn ggf. entsprechend privilegierte Redakteure sehen und bearbeiten können) sondern in ein Programmcodeverzeichnis. Und wenn er schon da liegt darf das auch eine Extension sein, dann ist es wenigstens einheitlich.

Beste Grüße,


Stephan Schuler
Web-Entwickler | netlogix Web Solutions

Telefon: +49 (911) 539909 - 0
E-Mail: Stephan.Schuler at netlogix.de
Web: websolutions.netlogix.de



----------------------------
Neu: Wir sind Amazon Web Services Partner. Mehr erfahren:
https://websolutions.netlogix.de/technologie/amazon-web-services-aws
----------------------------




netlogix GmbH & Co. KG
IT-Services | IT-Training | Web Solutions
Neuwieder Straße 10 | 90411 Nürnberg
Telefon: +49 (911) 539909 - 0 | Fax: +49 (911) 539909 - 99
E-Mail: info at netlogix.de | Web: http://www.netlogix.de

netlogix GmbH & Co. KG ist eingetragen am Amtsgericht Nürnberg (HRA 13338)
Persönlich haftende Gesellschafterin: netlogix Verwaltungs GmbH (HRB 20634)
Umsatzsteuer-Identifikationsnummer: DE 233472254
Geschäftsführer: Matthias Schmidt