Difference between revisions of "Potential backward compatibility issues in Joomla 4/de"

Revision as of 03:43, 23 February 2021

Content is Incomplete

This article or section is incomplete, which means it may be lacking information. You are welcome to assist in its completion by editing it as well. If this article or section has not been edited in several days, please consider helping complete the content.
This article was last edited by Max123kl (talk| contribs) 6 hours ago. (Purge)

In diesem Dokument werden mögliche Probleme mit der Abwärtskompatibilität für Joomla! 4 behandelt. Es werden Probleme aufgelistet, die möglicherweise zu Problemen mit Erweiterungen führen.

Die Vergleichsbasis ist Joomla! 3.10.

Aktualisierte Systemanforderungen

Die Systemanforderungen wurden wie folgt aktualisiert:

• PHP 7.2.5
• MySQL 5.6
• PostgreSQL 11.0
• SQL-Server Support wurde eingestellt.

PHP MySQL Erweiterung

• Joomla unterstützt die Verwendung des PHP-Treibers ext/mysql (der in PHP 7.0 entfernt wurde) nicht mehr. Joomla wird automatisch versuchen, die mysqli-Erweiterung (verfügbar seit PHP 5.3) oder den mysql-PDO-Treiber (verfügbar seit PHP 5.3) zu verwenden. Andernfalls wird keine Datenbankverbindung hergestellt.
• Der Strict-Modus wurde aktiviert. Die folgenden Flags sind jetzt standardmäßig in Joomla 4 aktiv und möglicherweise müssen die Datenbankabfragen entsprechend aktualisiert werden. Das wird uns bei zukünftigen Upgrades der MySQL-Version helfen und wird auch enger an Postgres ausgerichtet, um eine einfachere Kompatibilität mit Abfragen in beiden Sprachen zu ermöglichen.

'STRICT_TRANS_TABLES',
'ERROR_FOR_DIVISION_BY_ZERO',
'NO_AUTO_CREATE_USER',
'NO_ENGINE_SUBSTITUTION',

Folglich wird Joomla 4 nur NULL-Datumsvorgaben verwenden. Die Verwendung des invalid default date von 0000-00-00 00:00:00 in Joomla 4 ist veraltet.

PHP Postgres Erweiterung

• Joomla unterstützt die Verwendung des PHP-Treibers ext/pgsql nicht mehr. Joomla wird automatisch versuchen, den PostgreSQL PDO-Treiber (verfügbar seit PHP 5.3 und Joomla 3.9) zu verwenden, andernfalls wird keine Verbindung mit der Postgres-Datenbank hergestellt.

PHP GMP Erweiterung

Das ist für die Verwendung der Funktion WebAuthn Passwordless Login erforderlich. Hinweis: Die PHP-GMP-Erweiterung ist standardmäßig auf den meisten Hosting-Sites installiert. Das WebAuthn Passwordless Login System-Plugin ist in Joomla 4 auf https-Seiten standardmäßig aktiviert.

PHP mcrypt Erweiterung

Diese Erweiterung ist für die Verwendung der Klasse Joomla\CMS\Crypt\Cipher\CrytoCipher und ihres Alias JCryptCipherCrypto erforderlich.

CMS Libraries

Die folgenden Änderungen wurden in den Joomla! CMS-Bibliotheken gemacht, das ist hauptsächlich der Code, der in Joomla! 3.7 und früheren Versionen im Verzeichnis „libraries/cms“ gefunden wurde.

Installer

• Plugin Discover-Installationen suchen nicht mehr nach Xml-Dateien in den Joomla! 1.5 Plugin-Ordner-Layouts.
• In 3.x haben nur Plugin-Skripte die Preflight-Methode aufgerufen und keine macht Postflight während des Deinstallationsprozesses verfügbar. Bei allen Erweiterungstypen werden diese Hooks (Programm-Schnittstellen) in 4.0 verfügbar sein, wenn sie deinstalliert werden. Wenn Sie derzeit ein Preflight und ein Postflight durchführen und davon ausgehen, dass sie nur in einem Installations-/Aktualisierungskontext angewendet werden, ist diese Logik jetzt falsch und Sie sollten die Installationsroute verwenden (die als einer der Methodenparameter angegeben wird).
• Bei der Deinstallation eines Plugins wird jetzt die Deinstallationsfunktion im Erweiterungs-Skript ausgelöst, bevor SQL-Abfragen ausgelöst werden (dies ist jetzt mit allen anderen Erweiterungstypen konsistent).

aus Joomla! entfernte Klassen

Die folgenden Klassen wurden in Joomla! 4.0 entfernt:

• JInstallerComponent (ersatzweise JInstallerAdapterComponent benutzen)
• JInstallerFile (ersatzweise JInstallerAdapterFile benutzen)
• JInstallerLanguage (ersatzweise JInstallerAdapterLanguage benutzen)
• JInstallerLibrary (ersatzweise JInstallerAdapterLibrary benutzen)
• JInstallerModule (ersatzweise JInstallerAdapterModule benutzen)
• JInstallerPackage (ersatzweise JInstallerAdapterPackage benutzen)
• JInstallerPlugin (ersatzweise JInstallerAdapterPlugin benutzen)
• JInstallerTemplate (ersatzweise JInstallerAdapterTemplate benutzen)
• JSubMenuHelper (ersatzweise JHtmlSidebar benutzen. Bitte beachten: im Gegensatz zu JSubMenuHelper muss jetzt ein Platzhalter in der Ansichtsvorlage hinzugefügt werden)

JInstallerAdapter Vererbung

JInstallerAdapter ist nicht mehr von JAdapterInstance abhängig und von Natur aus JObject.

Benutzerdefinierte Installer-Adapter müssen jetzt automatisch geladen werden.

Menü

JMenu ist jetzt eine abstrakte Klasse

JMenu ist jetzt eine abstrakte Klasse. Unterklassen von JMenu müssen jetzt auch eine Lademethode implementieren.

Manuelles Include-Verhalten entfernt

Die Logik in JMenu::getInstance(), eine Datei manuell aus dem Pfad includes/menu.php der Anwendung einzubinden, wurde entfernt. Die Unterklasse JMenu sollte stattdessen automatisch geladen werden.

JMenuItem

• Die Eigenschaft params kann nicht mehr direkt aus JMenuItem abgerufen werden. Stattdessen sollte die Methode getParams() verwendet werden (verfügbar seit Joomla 3.7)
• JMenuItem::set und JMenuItem::get wurden entfernt. Die Eigenschaften müssen eindeutig benannt werden
• Es gibt jetzt die Klasse AdministratorMenuItem, die von MenuItem abhängt und zusätzliche öffentliche Eigenschaften enthält, die im Administrator Menü-Eintrag verwendet werden.

Pagination

• Die beiden magischen Funktionen für die Paginierung pagination_item_active und pagination_item_inactive wurden entfernt. Stattdessen sollte jetzt joomla.pagination.link aus JLayouts verwendet werden
• Die magische Funktion für die Paginierung pagination_list_render ist veraltet. Man sollte daher joomla.pagination.list aus JLayout verwenden

Pathway

Manuelles Include-Verhalten entfernt

Die Logik in JPathway::getInstance(), eine Datei aus dem Pfad includes/pathway.php der Anwendung manuell einzubinden, wurde entfernt. Die Unterklasse JPathway sollte stattdessen automatisch geladen werden.

Router

Manuelles Include-Verhalten entfernt

Die Logik in JRouter::getInstance(), eine Datei manuell aus dem Pfad includes/router.php der Anwendung einzubinden, wurde entfernt. Die Unterklasse JRouter sollte stattdessen automatisch geladen werden.

Änderungen der Methodensignatur

Die attachBuildRule und attachParseRule sind nun typisiert, um Callables zu benötigen.

JVersion

Unterstützung für den Zugriff auf die JVersion-Klassenkonstanten als Klasseneigenschaften wird nicht mehr unterstützt. Die Konstanten wurden in Joomla! 3.5 eingeführt, um zu verhindern, dass die alten Klasseneigenschaften bearbeitet werden können.

Die folgenden veralteten Konstanten wurden entfernt:

• JVersion::RELEASE
• JVersion::DEV_LEVEL
• JVersion::BUILD

JHtml

• Die Registerfunktion in JHtml ist nun typisiert, um eine Callable zu benötigen. Unterklassen von JHtml müssen nun mit dieser Signatur übereinstimmen (beachte, dass dies bereits auf Funktionscode-Ebene erforderlich war).
• JHtml::_ erlaubt es nicht mehr, nicht-öffentliche Methoden in JHtml aufzurufen
• JHtml::_ ist nun eine endgültige Methode (Man kann sie nicht mehr überschreiben, wenn mandie Unterklasse JHtml verwendet) und ihre Signatur hat sich geändert, um die Vorteile moderner PHP-Funktionen (skalare und variadische Typisierungspunkte) zu nutzen.
• JHtmlBootstrap::modal wurde entfernt. Verwende JHtmlBootstrap::renderModal
• JHtmlSortablelist::sortable wurde zugunsten von JHtmlDraggablelist::draggable als veraltet eingestuft – die alte Methode dient als Proxy für die neue Methode, um die Entfernung von jQuery UI aus dem Joomla Kern zu erleichtern. Alle Media Assets, die sich auf die ursprüngliche jQuery UI-Implementierung beziehen, wurden entfernt.
• JHtmlBatch wurde entfernt, da der gesamte Code in die Layouts für die Overrides von Templates verschoben wurde. Man sollte JLayouts im Code direkt verwenden.

Updater

• Wir haben die veraltete Handhabung von Ganzzahl-Clients aus der Adapterklasse der Updater-Erweiterung entfernt. Bitte jetzt site und administrator verwenden und nicht mehr die Integer-Werte 0 / 1.

Plattform

Die folgenden Änderungen wurden an den Bibliotheken der Joomla! Plattform vorgenommen (dies ist in erster Linie Code, der sich in den Verzeichnissen `libraries/joomla` oder `libraries/legacy` in Joomla! 3 befindet).

Access

• JAccess::$assetPermissionsById und JAccess::$assetPermissionsByName und JAccess::preloadPermissionsParentIdMapping wurden ersatzlos entfernt. Seit Version 3.6 haben wir andere Methoden und Klasseneigenschaften verwendet, um das Laden von Assets zu optimieren. Siehe den Pull-Request: JAccess Bugfixes und Optimierungen, um die Gründe für diese Maßnahme zu erfahren.
• JAccess::getActions wurde entfernt. Stattdessen sollte JAccess::getActionsFromFile oder JAccess::getActionsFromData verwendet werden.

Application

aus Joomla! entfernte Klassen

Die folgenden Klassen wurden in Joomla! 4.0 entfernt:

• JApplicationWebRouter (verwenden Sie stattdessen das Paket `joomla/router`)
• JApplicationWebRouterBase (verwenden Sie stattdessen das Paket `joomla/router`)
• JApplicationWebRouterRest (verwenden Sie stattdessen das Paket `joomla/router`)

Alle Referenzen auf JSite und JAdministrator wurden entfernt (diese waren seit Joomla 3.2 nur noch sogenannte Alias-Klassen)

= Veraltete Klassen

Die folgenden Klassen sind veraltet und für die Entfernung in Joomla! 5.0 geplant:

• JApplicationBase (verwenden Sie stattdessen Joomla\Application\Application\AbstractApplication)

Änderungen an CLI/Web-Klassen

Die Klassen JApplicationCli und JApplicationWeb wurden neu zusammengesetzt, um stattdessen aus dem Anwendungspaket des Frameworks zu erweitern. Dies bricht die Typprüfung für ein JApplicationBase-Objekt ab. Aus Gründen der Aufwärtskompatibilität wird empfohlen, zu prüfen, ob Anwendungsklassen eine Instanz von Joomla\Application\AbstractApplication sind (JApplicationBase hat diese Klasse seit Joomla! 3.4 erweitert).

Zusätzlich sind diese beiden Klassen nun abstrakt. Entwickler, die diese Klassen implementieren, müssen eine `doExecute'-Methode mit der Logik ihrer Anwendung bereitstellen.

Die registerEvent-Methode ist nun typischerweise so eingestellt, dass für den $handler-Parameter eine Aufrufbarkeit erforderlich ist.

Anwendungen, die sowohl Web- als auch CLI-Anwendungen unterstützen wollen, sollten nun gegen das \Joomla\CMS\Application\ CMSApplicationInterface antreten - dies enthält gängige Methoden (einige davon wurden in Joomla 3.x nur in der Klasse JApplicationCms gefunden), die von allen Codes verwendet werden können. Es wird dringend empfohlen, dass alle benutzerdefinierten Anwendungen (insbesondere CLI-Anwendungen) diese Schnittstelle implementieren, um Kompatibilitätsprüfungen zu erleichtern. Gleichzeitig sollten alle Typ-Hints die Schnittstelle und nicht eine konkrete Klasse verwenden.

JApplicationCli

• Alt: JApplicationCli → JApplicationBase →  Joomla\Application\AbstractApplication
• Neu: JApplicationCli → Joomla\Application\AbstractCliApplication →  Joomla\Application\AbstractApplication

JApplicationWeb

• Alt: JApplicationWeb → JApplicationBase →  Joomla\Application\AbstractApplication
• Neu: JApplicationWeb → Joomla\Application\AbstractWebApplication →  Joomla\Application\AbstractApplication

• Die alten Methoden zum Aufruf von JApplicationWeb::redirect wurden entfernt.
  • Mit einer Nachricht und messageType-Parametern (Aufruf von enqueueMessage separat)
  • Die Übergabe eines True/False-Wertes als 2nd/3rd-Params anstelle eines Redirect-Codes führt zu einer InvalidArgumentException, anstatt auf ein 303 zu setzen.
• JApplicationWeb::$singleValueResponseHeaders wurde entfernt, da die Framework-Anwendung ab dem Release 2.0 intern PSR-7 Response-Objekte verwenden wird. Dies ändert die Art und Weise, wie die Kopfdaten gespeichert werden, so dass es sich immer um ein multidimensionales Array handelt, wobei jeder Top-Level-Schlüssel die Headernamen und der Wert ein Array mit allen Werten für diesen Header ist.

CMSApplication

• Die Klasseneigenschaften $_clientId, $_messageQueue und $_name wurden alle umbenannt, um das Unterstrichpräfix zu entfernen.
• Implementiert nun die CMSApplicationInterface.
• Wenn ein Fehler beim Abrufen eines Pathway-, Router- oder Menüobjekts mit den entsprechenden Methoden auftritt, poppt die Ausnahme nun auf und nicht mehr die Methode, die die Ausnahme stillschweigend abfängt und null zurückgibt
• CMSApplication::getInstance will now additionally try and load the user object (using the loadIdentity function)
• ConsoleApplication und ApiApplication können zu irreführenden Ergebnissen führen. Bitte verwende CMSApplication::isClient (verfügbar ab ). Weitere Informationen finden Sie unter Discover auf welchem Client Ihr Extensionscode läuft.

JApplicationSite

Die Klasseneigenschaften $_language_filter und $_detect_browser wurden umbenannt, um den Unterstrich-Präfix zu entfernen.

Die veraltete Methode JApplicationSite::getPageParameters wurde zugunsten ihres Alias JApplicationSite::getParams entfernt.

JApplicationHelper

JApplicationHelper::parseXMLLangMetaFile wurde ersatzlos entfernt.

Archiv

• Das Archivpaket wurde zugunsten des Frameworks-Archivpakets entfernt. Beachte, dass die API unverändert bleiben sollte.
• Bei der Fehlerbehandlung werden nun Ausnahmen anstelle von JError verwendet.

Client

\Joomla\CMS\Client\ClientWrapper wurde entfernt. Verwendung der statischen Methoden in \Joomla\CMS\Client\ClientHelper

Crypt

• JCrypt::hasStrongPasswordSupport wurde ersatzlos entfernt, da alle PHP-Versionen, die mit Joomla 4 kompatibel sind, ein starkes Passwort-Hashing unterstützen.

aus Joomla! entfernte Klassen

Die folgenden Verschlüsselungen wurden in Joomla! 4.0 entfernt:

• JCryptCipher3Des
• JCryptCipherBlowfish
• JCryptCipherMcrypt
• JCryptCipherRijndael256
• JCryptCipherSimple

diese wurden ersatzlos entfernt. Verwenden Sie JCryptCipherCrypto

aus Joomla! entfernte Methoden

• JCrypt::hasStrongPasswordSupport wurde ersatzlos entfernt (dies versuchte, bcrypt polyfills auf Linux-Hosting zu erkennen, gab aber immer true zurück, da wir PHP 5.3.10 in Joomla 3.3 benötigten).

Cache

• JCacheController::get benötigt jetzt eine aufrufbare. Dadurch wurde JCacheControllerCallback::call entfernt.
• JCacheStorage::test wurde entfernt. Verwende stattdessen JCacheStorage::isSupported.
• Die Standardspeicher-Engines werden nicht mehr manuell geladen, da sie nun automatisch geladen werden.
• JCacheControllerOutput::start und JCacheControllerOutput::end wurden ersatzlos entfernt.
• CacheLite-Speicher wurde entfernt, da er nicht mit PHP7 kompatibel ist (was unsere Minimalversion ist).
• Die Fehlerbehandlung verwendet nun Exceptions anstelle von JError.

Komponente

• \Joomla\CMS\Component\Component\ComponentRecord erweitert JObject nicht mehr.

Document

Änderung bei der Vererbung

Die folgenden Klassen haben ihre Vererbung geändert:

• JDocumentError (reicht jetzt von \Joomla\Cms\Document\HtmlDocument anstelle von \Joomla\Cms\Document\Document)

Hinweis: Als Ergebnis dieser Änderung setzt das Rendern einer Fehlerseite das Dokument-Objekt in Joomla\CMS\Factory::$document zurück. Der Grund dafür ist, dass wir ein sauberes Dokument wollen, mit dem wir arbeiten können. Wenn die Fehlerseite ausgelöst wird, sind wir nicht an den Metadaten interessiert, welche die Komponente gesetzt hat oder an den Medien, die von einem fehlerhaften Modul hinzugefügt wurden oder welches Plugin auch immer der Darstellung hinzugefügt wurde. Wir wollen eine saubere Umgebung zum Rendern der Fehlerseite, die nur die geladenen Daten der Fehlerseite enthält.

Renderer

• Um der RSS-Feed-Spezifikation zu entsprechen, erlaubt JDocumentRendererFeedRss nun die Konfiguration des lastBuildDate Elements über die Klasseneigenschaft JDocumentFeed::$lastBuildDate, wenn ein Feed gerendert wird. Dieser Wert ist standardmäßig auf die aktuelle Zeit voreingestellt, wie es bei Joomla! 3.x und früher der Fall ist, jedoch kann die Zeit korrekt eingestellt werden, indem man diese Klasseneigenschaft in ein JDate-Objekt ändert, das den gewünschten Zeitstempel darstellt.
• hier ist nun ein RendererInterface, das alle Renderer implementieren sollten.
• JDocumentRenderer ist nun eine abstrakte Klasse und implementiert RendererInterface.
• Alternativ zu <jdoc:include type="head" /> kann man nun <jdoc:include type="metas" /> für Metadaten, <jdoc:include type="styles" /> für CSS und <jdoc:include type="scripts" /> für Javascript einzeln laden. Die Absicht ist es, den Benutzern optional zu erlauben, alle Javascripts am unteren Rand des HTML-Dokuments in ihren Vorlagen zu platzieren.

JDocumentFeed

Der Eigenschaftstyp von JDocumentFeed::$lastBuildDate wurde von einer Zeichenkette in ein JDate-Objekt geändert. Die Eigenschaft wurde bisher nicht von der Core Joomla API verwendet, aber Erweiterungen können es verwendet haben.

Datenbank

• Dieses Paket wurde durch das Joomla Framework Database Package ersetzt.
• Der Debug-Modus wurde überarbeitet (siehe die Framework-Dokumente für weitere Informationen). [1])

Factory

• Factory::getApplication nimmt keine Argumente mehr an. Diese waren irreführend, da sie immer die aktive Anwendung nach dem ersten Aufruf im Bootstrap zurückgaben, egal welche Argumente in die Funktion übergeben wurden.
• Factory::getXml wurde zusammen mit dem JXMLElement entfernt. Verwende stattdessen SimpleXMLElement direkt.
• Factory::: getEditor wurde entfernt, verwende stattdessen JEditor::getInstance.

Umgebung

• JBrowser::isSSLConnection has been removed. Use JApplicationCms::isSSLConnection (available since Joomla 3.2)

Dateisystem

• Die Wrapperklassen des Dateisystems wurden entfernt. Verwende weiterhin die ursprünglichen statischen Methoden.

Filter

• JFilterInput::_remove wurde entfernt zugunsten von JFilterInput::remove
• JFilterInput::_cleanTags wurde entfernt zugunsten von JFilterInput::cleanTags
• JFilterInput::_cleanAttributes wurde entfernt zugunsten von JFilterInput::cleanAttributes
• JFilterInput::_decode wurde entfernt zugunsten von JFilterInput::decode
• JFilterInput::_escapeAttributeValues wurde entfernt zugunsten von JFilterInput::escapeAttributeValues
• JFilterInput::_stripCSSExpressions wurde entfernt zugunsten von JFilterInput::stripCSSExpressions

Alle oben genannten Abwertungen und Löschungen sollen es der Klasse ermöglichen sich mit der Elternklasse des Frameworks wieder zu verknüpfen.

Form

• Die Verzeichnisse libraries/joomla/form/fields und libraries/joomla/form/rules sind nicht mehr registriert, um Formularklassen zu finden, sondern alle Formularklassen sollten automatisch geladen werden.
• Zwei neue Eigenschaften wurden addfieldprefix hinzugefügt, das ein Namensraum-Präfix für Erweiterungen registriert (soll als Ersatz für addfieldpath verwendet werden). Ein Beispiel für die Verwendung siehe diesen Github PR.
• JForm::getControlGroup wurde entfernt und verwendet den Alias JForm::renderField (verfügbar seit Joomla 3.2.3).
• JForm::getControlGroups wurde entfernt und verwendet den Alias JForm::renderFieldset (verfügbar seit Joomla 3.2.3).
• Beim Rendern eines Feldes mit der Option hiddenLabel in JForm – sie blendet jetzt nur noch das Label in der Benutzeroberfläche aus – wird das html weiterhin mit der Klasse sr-only für die Barrierefreiheit des Bildschirm-Lesers gerendert.
• JFormFieldUsergroup wurde entfernt. Verwende stattdessen Joomla\CMS\Form\Field\UsergrouplistField (verfügbar seit Joomla 3.2).
• In der Formular-Klasse wurden die geschützten Methoden filterField() und validateField() entfernt. Dadurch werden alle benutzerdefinierten Formular-Klassen, die den Kern von Form erweitern und diese Methoden verwenden, ungültig. Dies wurde zugunsten der Filterung auf Feldebene ersetzt (siehe https://github.com/joomla/joomla-cms/pull/12414 für weitere Informationen).

Fields

• Die Filtereigenschaften von JFormFieldFilelist und JFormFieldFolderList wurden in fileFilter bzw. folderFilter umbenannt (um die Verwendung des regulären Joomla-Filterattributs bei zurückgegebenen Werten zu ermöglichen)
• JFormPredefinedlistField die Filtereigenschaften wurde umbenannt in optionsFilter (in order to allow the use of the regular Joomla filter attribute on returned values)
• JFormFieldEditor::save wurde ersatzlos entfernt.
• JFormFieldText::getSuggestions wurde entfernt zugunsten von JFormFieldText::getOptions

Wrapper

• Die Formular-Wrapper-Klassen wurden entfernt. Bitte die ursprünglichen statischen Methoden beibehalten.

HTTP

Veraltete Klassen und Interfaces

Die folgenden Klassen und Interfaces sind veraltet und wurden für die Entfernung in Joomla! 5.0 geplant:

• JHttpResponse (verwende stattdessen Joomla\Http\Response)
• JHttpTransport (implementiere stattdessen Joomla\Http\TransportInterface)

Klassenwechsel =

Das HTTP-Paket des Frameworks ist nun in Joomla! 4.0 und JHttp enthalten und die Unterklassen JHttpTransport wurden überarbeitet, um das Upstream-Paket zu verwenden.

JHttp

Der JHttp class constructor wurde mit den folgenden Änderungen gelockert:

• Der Optionsparameter ist nicht mehr als Joomla\Registry\Registry-Objekt typisiert, ein Array oder ein beliebiges Objekt, das die SchnittstelleArrayAccess implementiert, kann stattdessen verwendet werden.
• Der Transportparameter erlaubt nun jedes Joomla\Http\TransportInterface-Objekt.

JHttpTransport

Die nun veraltete JHttpTransport-Schnittstelle erweitert Joomla\Http\TransportInterface jetzt und hat zu Rückwärtskompatibilität geführt, die Änderungen in der Schnittstelle brechen. Der Konstruktor ist nicht mehr Teil der Schnittstelle, und die `Request()`Methode der Schnittstelle hat eine Signaturänderung erfahren. Insbesondere der zweite Parameter, der zuvor die JUri-Klasse typisiert hat, typisiert nun Joomla\Uri\Uri\UriInterface.

JHttpResponse

Beim Refactoring des Response-Objekts, das vom HTTP-Paket des Frameworks übernommen werden soll, das nun die PSR-7 ResponseInterface-API verwendet, wurde ein kleiner Kompatibilitätsbruch in der Struktur der Response-Header vorgenommen. Ab 4.0 ist dies nun immer ein multidimensionales Array, wobei der Schlüssel der Headername und der Wert ein Array von Werten für diesen Header ist (früher war dies eine Zeichenkette).

Bilder

Veraltete Klassen und Interfaces

Die folgenden Klassen und Interfaces sind veraltet und wurden für die Entfernung in Joomla! 5.0 geplant:

• JImageFilter (stattdessen Joomla\CMS\Image\ImageFilter verwenden)
• JImageFilterBackgroundfill (stattdessen Joomla\CMS\Image\Filter\Backgroundfill verwenden)
• JImageFilterBrightness (stattdessen Joomla\CMS\Image\Filter\Brightness verwenden)
• JImageFilterContrast (stattdessen Joomla\CMS\Image\Filter\Contrast verwenden)
• JImageFilterEdgedetect (stattdessen Joomla\CMS\Image\Filter\Edgedetect verwenden)
• JImageFilterEmboss (stattdessen Joomla\CMS\Image\Filter\Emboss verwenden)
• JImageFilterGrayscale (stattdessen Joomla\CMS\Image\Filter\Grayscale verwenden)
• JImageFilterNegate (stattdessen Joomla\CMS\Image\Filter\Negate verwenden)
• JImageFilterSketchy (stattdessen Joomla\CMS\Image\Filter\Sketchy verwenden)
• JImageFilterSmooth (stattdessen Joomla\CMS\Image\Filter\Smooth verwenden)

Klassenwechsel

Die Klassen aus dem Image-Paket des Frameworks wurden in das CMS und JImage integriert und die JImageFilter-Unterklassen wurden so umstrukturiert, dass sie nun verwendet werden können. D.h. alle Klassen unter dem Namespace Joomla\Image wurden in den Namespace Joomla\CMS\Image verschoben.

Menü

• JMenu::$_items, JMenu::$_default und JMenu::$_active wurden entfernt (Bitte beachten, dass diese Eigenschaften geschützt waren, sodass dies nur benutzerdefinierte Unterklassen von JMenu betrifft).

New MVC Layer

• Dies wurde in Joomla 4 entfernt. Wir haben entschieden, dass dieser Versuch nicht erfolgreich war und haben daher die Entwicklungsarbeit an dem ursprünglichen MVC-Layer fortgesetzt (siehe den Abschnitt "Legacy MVC"). Auf GitHub gibt es ein Plugin, das mit eigenen Erweiterungen ausgeliefert werden kann. Während dessen kann man zurück auf das Legacy MVC migrieren (bitte beachten, dass dies nicht standardmäßig mit Joomla 4 ausgeliefert wird).

Keychain

Das Entfernen der Keychain in 4.0 hat das Entfernen der folgenden Klasse zur Folge:

• JKeychain

Pathway

• Bei JPathway::$_pathway und JPathway::$_count wurde das Unterstrich-Präfix entfernt (bitte beachten, dass diese Eigenschaften geschützt waren, sodass dies nur benutzerdefinierte Unterklassen von JPathway betrifft)
• JPathway::_makeItem wurde zugunsten von JPathway::makeItem entfernt (bitte beachten, dass diese Methode geschützt war, sodass dies nur benutzerdefinierte Unterklassen von JPathway betrifft).

Profiler

• JProfiler::getmicrotime und JProfiler::getMemory wurden zugunsten der nativen PHP-Methoden entfernt, die sie enthalten haben (microtime(1) bzw. memory_get_usage())

Table

• JTable::__construct Datenbankobjekt ist nun typisiert, um ein JDatabaseDriver zu sein.
  • Unterklassen von JTable müssen sicherstellen, dass sie ein JDatabaseDriver-Objekt an den übergeordneten Konstruktor übergeben.
  • Unterklassen von JTable müssen die Methodensignatur von setDbo() ändern, wenn sie eine erweiterte Version dieser Methode haben, um den typehint aufzunehmen.
• Es gibt eine neue Methode JTable::hasField - alle Instanzen von property_exists auf JTable-Instanzen verwenden nun diese Proxy-Methode, um eine bessere Interoperabilität von Tabelleninstanzen zu ermöglichen.
• Das JTableObserver-Muster (und die entsprechenden Klassen) wurden aus JTable entfernt. JTable löst nun Ereignisse und Tags aus, die Inhaltshistorie (und alle anderen benutzerdefinierten Anwendungen dieses Musters) sollten zu Standard-Plugins wechseln.

Mail

Die folgenden Methoden wurden in Joomla! 4.0 entfernt:

• JMail::sendAdminMail wurde entfernt.

Exceptions

JMail no longer catches exceptions from PHPMailer. It is now the object calling JMail's responsibility to handle these exceptions as appropriate. In addition if mail sending is disabled in global configuration calling \ Joomla\CMS\Mail\Mail::send() will throw a \Joomla\CMS\Mail\Exception\MailDisabledException.

Sprache =

• Die Funktionen setTransliterator, setPluralSuffixesCallback, setIgnoredSearchWordsCallback, setLowerLimitSearchWordCallback, setUpperLimitSearchWordCallback und setSearchDisplayedCharactersNumberCallback sind nun typisiert, um ein Callable zu benötigen.
• Der "_QQ_" Platzhalter für doppelte Anführungszeichen wurde entfernt (dies existierte nur, um einen alten PHP-Bug zu umgehen, der behoben wurde). Escape doppelte Anführungszeichen bei Bedarf (z.B. \")
• Das Format für die Sprachdateinamen wurde geändert, um die Arbeit in Übersetzungstools von Drittanbietern (wie Crowdin) zu erleichtern. INI-Sprachdateien müssen nicht mehr den Sprachcode enthalten (d.h. en-GB.com_contact.ini => com_contact.ini). Im Spezial-Fall von en-GB.ini wurde die Datei im Core-Sprachpaket in joomla.ini und en-GB.xml in langmetadata.xml umbenannt. Es gibt einen b/c Layer, der weiterhin die alten Joomla 3-Dateinamen in Joomla 4 erkennen wird.
• \Joomla\CMS\Language\Multilanguage::getSiteLangs wurde entfernt. Stattdessen bitte \Joomla\CMS\Language\LanguageHelper::getInstalledLanguages(0) benutzen.
• JLanguage::exists wurde entfernt. Stattdessen bitte Joomla\CMS\Language\LanguageHelper::exists benutzen.
• The wrapper classes JTextWrapper, LanguageHelperWrapper and TransliterateWrapper have been removed. Continue to use the static methods they wrapped.
• The pdf_fonts handling/support for language packs (language/pdf_fonts) has been removed from the language installer (see GitHub PR #31288).

Legacy MVC Layer

Legacy Controller

• JControllerLegacy wurde aus der Legacy-Schicht entfernt, und wir beabsichtigen nicht, es oder seine Unterklassen in naher Zukunft zu entfernen.
• JControllerLegacy erweitert JObject nicht mehr. Controller sollten keine der in der Klasse JObject enthaltenen Methoden aufrufen.
• JControllerLegacy implementiert eine Schnittstelle für mehrere Task-Controller.
• JControllerLegacy::_construct nimmt nun zusätzliche Argumente an. Wenn Sie zuvor ein Controller-Objekt über JControllerLegacy::getInstance erhalten haben, müssen Sie Ihren Code nicht ändern.
  • Parameter 2: Eine optionale MVCFactoryInterface-Instanz.
  • Parameter 3: Eine optionale CMSApplicationInterface-Instanz.
  • Parameter 4: Eine optionale Input-Instanz
  • Parameter 5: Eine optionale FormFactoryInterface-Instanz.
• JControllerForm verwendet nun das StringInflector-Paket, um die Listenansicht zu bestimmen. Dies sollte die Möglichkeit verbessern, die Listenansicht von mehr Ansichtsnamen zu erraten. Wenn Extension-Entwickler feststellen, dass ihre Listenansicht nicht mehr gefunden wird, sollte man die Klasseneigenschaft `view_list` manuell in seinem Controller setzen.

Legacy View

• JViewLegacy wurde aus der Legacy-Schicht entfernt, und wir beabsichtigen nicht mehr, es oder seine Unterklassen in naher Zukunft zu entfernen.
• JViewHtml wurde in zwei Klassen unterteilt - AbstractView und HtmlView. Die abstrakte Sicht enthält die Logik für den Zugriff auf Modelle und die Ermittlung des Namens der Sicht und ist als Basisklasse für Nicht-Html-Sichten gedacht. Die Html-Sicht enthält die gleiche Logik wie bisher.
• Es gibt jetzt zwei Unterklassen von JViewHtml - \Joomla\CMS\MVC\View\ListView und \Joomla\CMS\MVC\View\FormView, die entwickelt wurden, um die Entwicklung von Listen- und Formularansichten zu beschleunigen und die Code-Duplizierung zu reduzieren.

Library

• JLibraryHelper::_load has been removed. Use \Joomla\CMS\Helper\LibraryHelper::loadLibrary instead.

Session

Das Session-Paket wurde grundlegend überarbeitet, um das Session-Paket des Frameworks zu nutzen. Diese Änderung betrifft in erster Linie die Interna des Pakets; Änderungen an der primären öffentlichen API über die JSession-Klasse sind minimal.

String

Der alte Alias der JString-Klasse wurde entfernt. Benutze stattdessen \Joomla\String\StringHelper.

Removed Classes and Interfaces

Die folgenden Klassen und Interfaces wurden in Joomla! 5.0 entfernt:

• JSessionExceptionUnsupported
• JSessionHandlerInterface
• JSessionHandlerJoomla
• JSessionHandlerNative
• JSessionStorage
• JSessionStorageApc
• JSessionStorageDatabase
• JSessionStorageMemcache
• JSessionStorageMemcached
• JSessionStorageNone
• JSessionStorageWincache
• JSessionStorageXcache

JSession

Methoden haben eine modifizierte Signatur und es existiert eine Kompatibilitätsschicht, die beim Übergang hilft.

Veraltete Namensraum-Parameter

Die Methoden get, set, has und clear unterstützten bisher einen Namensraum-Parameter. Dieser Parameter ist jetzt veraltet. Der Namensraum sollte dem Namen vorangestellt werden, bevor diese Methoden aufgerufen werden.

JSession::clear() Repurposed

In JSession wird diese Methode verwendet, um einen einzelnen Schlüssel zu entfernen. Wenn diese Methode mit Parametern aufgerufen wird, ruft sie die neue Joomla\Session\Session\Session::remove() Methode auf.

JSession::getInstance() Deprecated

Die Singleton getInstance()-Methode ist veraltet. Das Session-Objekt sollte stattdessen aus der aktiven Anwendung oder dem Dependency Injection Container geholt werden.

Session Handlers

In Joomla! 3.x und früher wurden Session-Handler durch die Klasse JSessionStorage und ihre Unterklassen repräsentiert. In Joomla! 4.0 sind Session-Handler nun Implementierungen von Joomla\Session\HandlerInterface (das eine Erweiterung von PHP'sSessionHandlerInterface ist. Alle Handler, die in Joomla! 3.x unterstützt wurden, sind in 4.0 weiterhin verfügbar, zusätzlich zu zwei weiteren Handlern; ein Handler, der die APCu-Erweiterung nativ implementiert und ein Handler, der Redis unterstützt.

Social Media Libraries

Die Pakete facebook, github, google, linkedin, openstreetmap, mediawiki und twitter wurden alle aus dem CMS entfernt.

User

• JUser::getParameters has been removed. You can no longer retrieve all parameters for a user but instead use JUser::getParam to get individual parameters as required.

Helper

• JUserHelper::getCryptedPassword has been removed. Joomla 4 only supports hashing with the native PHP password_hash function (via JUserHelper::hashPassword (available since Joomla 3.2.1))
• JUserHelper::getSalt has been removed without replacement (it generated the hash's JUserHelper::getCryptedPassword which is now removed as above)
• JUserHelper::invalidateCookie, JUserHelper::clearExpiredTokens and JUserHelper::getRememberCookieData have been removed without replacement. They had been unused in core since Joomla 3.2 when their logic was moved into the Cookie Authentication Plugin
• JUserWrapperHelper has been removed. Continue using the original static methods in JUserHelper.

Klassen ohne Austausch entfernt

• JNode
• JTree
• JGrid
• JError (verwende native Ausnahmen, wenn eine Fehlerbehandlung erforderlich ist)

Utilities

Entfernte Klassen und Interfaces

Die folgenden Klassen und Interfaces wurden in Joomla! 4.0 entfernt:

• JArrayHelper

verwende stattdessen Joomla\Utilities\ArrayHelper;.

External Libraries

Die folgenden Änderungen wurden an den externen Bibliotheken vorgenommen, die Joomla! pakt und versendet.

PHPMailer

Joomla! 4.0 wird mit PHPMailer 6.0 ausgeliefert. Bitte überprüfe den Upgrade-Leitfaden. für relevante Änderungen.

PHPUTF8

Unter Joomla! 3.4 befand sich die PHPUTF8-Bibliothek an zwei Orten im Joomla! Paket; `libraries/phputf8` und `libraries/vendor/joomla/string/src/phputf8``. In Joomla! 4.0 wurde die Kopie der Bibliothek in `libraries/phputf8` entfernt. Die Joomla\String\StringHelper class enthüllt viele der Funktionen der Bibliothek und die Composer-Autoloader-Definition importiert auch einen Großteil der Bibliothek, aber wenn man ein Feature benötigen, das nicht bereits enthalten ist, sollte man die benötigten Funktionen aus dem Pfad `libraries/vendor/joomla/string/src/phputf8` importieren.

SimplePie

Die SimplePie-Bibliothek ist nicht mehr in Joomla! 4.0 enthalten.

jQuery

Joomla! 4.0 wird mit jQuery 3 ausgeliefert. Bitte lese den Upgrade-Leitfaden für relevante Änderungen. Beachte dass wir jQuery Migrate auch nicht mehr berücksichtigen. Wir empfehlen, es lokal zu verwenden, um bei Problemen mit deinem Code zu helfen.

jQuery UI

jQuery UI has been removed from Joomla 4. Whilst it hasn't been officially announced as dead, there hasn't been a release of jQuery UI since 2016.

Bootstrap

Joomla! 4.0 wird mit Bootstrap 5 ausgeliefert. Bootstrap 2.3.2 wurde entfernt, aber wir haben einige BS2-Klassen beibehalten, um die Migration zu erleichtern (z.B. Das alte BS2-Element - unsichtbar existiert noch für Screenreader)

FOF

FOF 2.x wurde entfernt.

Templates

Alle Joomla! 3 Templates - ISIS und Hathor im Backend, sowie protostar und Beeze im Frontend werden nicht mehr unterstützt. Die neue 4.0 Backend-Vorlage heißt Atum und die Frontend-Vorlage Cassiopeia.

Infolgedessen müssen alle Erweiterungen auf den neuen Bootstrap 4-Stil migriert werden, weg von der aktuellen Bootstrap 2.3.2 Implementierung. Für weitere Informationen über Bootstrap 4: [2]. Für weitere Informationen über Bootstrap 2.3.2: (http://getbootstrap.com/2.3.2/)

• Joomla 4 will load the template favicon first rather than the one in the Joomla Root in keeping with the concept the template is the single source of truth.
• Frontend components and module views now use Block Element Modifier (BEM) class markup to make it easier for templates to support frameworks other than bootstrap. See the BEM Website for more information on how to build similar classes.

There where also changes to options of the core components that you should take a look at when your tempalte should support 3.x and 4.x at the same time: https://docs.joomla.org/J4.x:Changed_parameters_for_template_providers

Sonstiges

• The $_PROFILER global variable has been removed. Use \Joomla\CMS\Profiler\Profiler::getInstance instead.

Medien in Bibliotheken

Im Bibliotheksstammordner des CMS sind keine Medien erlaubt - alle mit Joomla-Bibliotheken verbundenen Assets sollten gemäß den besten Beispielen in den Medienordner gelegt werden. Der direkte Zugriff wird mit einer.htaccess und web.config Datei im Stammverzeichnis des Bibliotheksverzeichnisses blockiert.

Bin

Das Entfernen des Schlüsselbundes mit 4.0 hat dazu geführt, dass das gesamte Bin-Verzeichnis entfernt wurde, da es nur den Schlüsselbund enthielt

Komponenten

• Alle Komponenten wurden im Namensraum angeordnet und die Verzeichnisse entsprechend überarbeitet. Für weitere Informationen dazu lese das Tutorial zum Erstellen einer Komponente in Joomla 4.
• Die Profilansicht com_admin wurde entfernt (dies scheint historisch bedingt durch Probleme beim Zugriff auf com_users erstellt worden zu sein. Dies ist nicht mehr der Fall, so dass alle Benutzerbearbeitungen über com_users edit user view im Backend laufen).
• com_actionlogs php 5.5 Backfill-Code wurde entfernt und entsprechend ActionlogsHelper::getCsvData() ist nun vom Typ angedeutet, dass er ein Generator Objekt liefert.
• com_actionlogs CSV export headers have been changed to match the strings shown in the UI.
• Bei den Kernel-Komponenten wurde der URL-Routing-Modus 'Legacy' aus Joomla 3.7 entfernt. Sie sollten entweder Ihre .htaccess-Datei oder die Redirect-Komponente verwenden, um alle internen URLs, die sich ändern, zu reparieren. Sie können den 'Modern'-Modus in Joomla 3 ausprobieren, indem Sie den Anweisungen hier folgen
• The MailTo component has been removed without replacement. If you used this functionality you will need to find an alternative component on JED.
• In com_contact 's frontend contact view - the contact property has been removed as it was a duplicate of the item property. We chose to keep $this->item as it was consistent with that in the article and tag views. Template overrides will need updating to reflect this.
• The repeatable field in com_fields has been removed in favour of the new subform field. Data from repeatable fields is automatically migrated to the new subform field but is stored in a different format.
• The xreference fields have been removed from #__contact_details, #__content and #__newsfeeds as they were unused.

Plugins

• Das Plugin zur Google Mail-Authentifizierung wurde entfernt. Für weitere Informationen lese bittediesen Blogbeitrag.
• Die Recaptcha v1-Unterstützung wurde vollständig aus dem Captcha-Plugin entfernt - dies funktioniert seit Q2 2018 nicht mehr, da Google die Unterstützung dafür eingestellt hat.
• Das Recaptcha-Plugin verwendet nun Googles offizielle php-Bibliothek für Captcha.
• Parameter und Rückgabewerte. Für Informationen über den neuen empfohlenen Ansatz für Plugins lese bitte S:MyLanguage/J4.x:Creating_a_Plugin_for_Joomla.
• For plugins using the 3.x compatibility layer, for any type hints for events that require a class, that class must be autoloaded before the plugin is instantiated.
• Das onContentBeforeSave-Ereignis benötigt nun den Datenparameter (dieser wird seit 3.7 in \Joomla\CMS\MVC\Model\Model\LegacyModel\ übergeben, wird aber nun konsistent von Core-Erweiterungen übergeben und vom Core Joomla Content Plugin verwendet).
• Returning before calling parent::__construct() in the constructor of a plugin is no longer supported to avoid queuing the plugin into the event dispatcher.
• onUserBeforeDataValidation is deprecated as an event in favor of onContentBeforeValidateData (The event was usable by all content types and was not specific to users. Note that both events will be called for the duration of Joomla 4. You should migrate your code to the new event when you no longer need to support Joomla 3.

Administrator Helpers

• JAdministratorHelper wurde ersatzlos entfernt (es wurde in JApplicationAdministrator integriert).
• JSubMenuHelper wurde ersatzlos entfernt (verwende stattdessen die JHtmlSidebar - verfügbar seit 3.0).
• ToolbarHelper wurde in das Hauptbibliotheksverzeichnis verschoben.

Module

• Das Administratormodul "Untermenü" wurde entfernt.
• Logic of Module Chromes (module styles) in template files html/modules.php have been moved to JLayout files. modChrome_x functions in modules.php are no longer supported. See https://github.com/joomla/joomla-cms/pull/23570 for details.
• Module Chromes (module styles) modChrome_horz, modChrome_xhtml, modChrome_rounded have been removed from template system without replacement.
• Module Class Suffixes have been renamed and standardized. These are now called Module Class and are appended to the list of classes in the Module Chrome. (They are no longer rendered in the module output itself.)

Fehlerbehandlung

• Joomla wird nun die PHP-Fehler E_USER_DEPRECATED behandeln und an JLog übergeben - dies ist nützlich für die Behandlung von Verwerfungen in vielen PHP-Bibliotheken von Drittanbietern (beachte, dass es das Laden der Seite blockiert, wenn der Debug-Modus aktiviert ist).
• Joomla\CMS\Exception\Exception\ExceptionHandler arbeitet jetzt nur noch mit Ausnahmen, die in JApplication::execute ausgegeben werden. Wir verwenden nun den ErrorHandler von Symfony, wenn dies fehlschlägt oder Ausnahmen außerhalb davon ausgegeben werden. Wir erwarten, dass dies für die meisten Benutzer minimale Auswirkungen hat und in vielen Fällen eine hilfreichere Meldung geben sollte als der traditionelle Fehler "Fehler beim Anzeigen der Fehlerseite" für Benutzer, wenn die Dinge sehr schlecht laufen.
• Joomla\CMS\Exception\Exception\ExceptionHandler ist jetzt formatbewusst und wird Fehler in html, json, xml, feed oder client-bewussten Formaten anzeigen.
• Die Joomla\CMS\Exception\ExceptionHandler::render() Signatur wurde geändert, um den Throwable Typ-Hinweis aufzunehmen. Vor 3.5, als PHP 7-Unterstützung hinzugefügt wurde, wurde dies als Exception typisiert, und seit 3.5 wurde im Code selbst typgeprüft.

Base Tag

Previous Joomla versions set a <base> header tag of the current URL in the frontend. This has been removed as it served no clear purpose.

JavaScript

The caption.js file has been removed from Joomla. Use the native HTML elements figure and figcaption. (You can look at JLayout in layouts/joomla/content/intro_image.php for an example).

Namespacing

Class usage like $msg = JText::_( 'Hello man!' ); can now use namespacing. That would turn into $msg = Text::_( 'Hello man!' );. To use namespacing, you need to add the proper namespace declaration. This should be added after the defined('_JEXEC') or die;.

To find out the proper namespace you can either follow the instructions here: SO confused about namespace & enquemessage... or use the generated file pdf reference file: File:J! namespace reference.pdf