Joomla! Documentation™

Content is Incomplete

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',

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.

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

• You can no longer retrieve the params property from JMenuItem directly. Use the getParams() method instead (available since Joomla 3.7)
• JMenuItem::set and JMenuItem::get have been removed. Properties must be explicitly named
• There is now a AdministratorMenuItem class which extends from MenuItem that contains extra public properties used for the Administrator menu item.

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 has been deprecated in favour of JHtmlDragablelist::dragable - the old method acts as a proxy to the new method currently to facilitate the removal of jQuery UI from Joomla Core. All media assets relating to the original jQuery UI implementation have been removed.
• JHtmlBatch has been removed as all the code had been moved to layouts for template overrides. Use the JLayouts directly in your code.

Updater

• We removed the deprecated integer client handling from the updater extension adapter class. Please use site and administrator and not any more the integer values 0 / 1

Platform

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).

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`)

= 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)

CLI/Web Class Changes

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.

Crypt

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

Removed Methods

• 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

Inheritance Change

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 Rendern einer Fehlerseite setzt das Dokument Objekt in Joomla\CMS\Factory::$document, die Begründung ist, dass wir wollen, dass ein sauberes Dokument von der Arbeit; wenn die Fehlerseite ausgelöst wird, sind wir nicht interessiert an den Metadaten, die Ihre Komponente gesetzt hat, oder die Medien aus einem schlechten Modul hinzugefügt, oder was Plugins hinzufügen, um die Anzeige. Wir wollen eine saubere Umgebung für die Darstellung der Fehlerseite, die nur die geladenen Daten der Fehlerseite enthält.

Renderers

• 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)

Filesystem

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

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.
• wei neue Eigenschaften hinzugefügt addfieldprefix, das ein Namensraumpräfix für Erweiterungen registriert (das als Ersatz für addfieldpath verwendet werden soll). Zum Beispiel für die Nutzung siehedieser 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).
• When rendering a field using the hiddenLabel option in JForm - it now only hides the label from the User Interface - the html is still rendered with the sr-only class for screen-reader accessibility purposes.
• JFormFieldUsergroup wurde entfernt. Verwende stattdessen Joomla\CMS\Form\Field\UsergrouplistField (verfügbar seit Joomla 3.2).

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 has its filter properties renamed to optionsFilter (in order to allow the use of the regular Joomla filter attribute on returned values)
• JFormFieldEditor::save has been removed without replacement

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 (verwende stattdessen Joomla\Image\ImageFilter)
• JImageFilterBackgroundfill (verwende stattdessen Joomla\Image\Filter\Backgroundfill)
• JImageFilterBrightness (verwende stattdessen Joomla\Image\Filter\Brightness)
• JImageFilterContrast (verwende stattdessen Joomla\Image\Filter\Contrast)
• JImageFilterEdgedetect (verwende stattdessen Joomla\Image\Filter\Edgedetect)
• JImageFilterEmboss (verwende stattdessen Joomla\Image\Filter\Emboss)
• JImageFilterGraustufen (verwende stattdessen Joomla\Image\Filter\Graustufen)
• JImageFilterNegate (verwende stattdessen Joomla\Image\Filter\Negate)
• JImageFilterSketchy (verwende stattdessen Joomla\Image\Filter\Sketchy)
• JImageFilterSmooth (verwende stattdessen Joomla\Image\Filter\Smooth)

Klassenwechsel

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

Menu

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

Keychain

Das Entfernen des Schlüsselanhängers mit 4.0 hat zur Entfernung der folgenden Klasse geführt:

• JKeychain

Pathway

• JPathway::$_pfad und JPathway::$_count wurden von ihrem Unterstrich-Präfix befreit (beachte, dass diese Eigenschaften geschützt waren, so dass dies nur benutzerdefinierte Unterklassen von JPathway betrifft).
• JPathway::_makeItem wurde zugunsten von JPathway::makeItem entfernt (beachte, dass diese Methode geschützt wurde, so dass dies nur benutzerdefinierte Unterklassen von JPathway betrifft).

Profiler

• JProfiler::getmicrotime and JProfiler::getMemory have been removed in favour of the native PHP methods they wrapped (microtime(1) and memory_get_usage() respectively

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. \")
• The format for language file names has been changes to ease the work in 3rd party translation tools (such as crowdin). INI language files no longer have to contain the language code (i.e. en-GB.com_contact.ini => com_contact.ini), in this case the special case of en-GB.ini has been renamed to joomla.ini in the core language pack. en-GB.xml has been named langmetadata.xml. There is a b/c layer that will continue to read the old Joomla 3 file names throughout Joomla 4.

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.

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.

Namespace Parameter Deprecated

Die Methoden get, set, has und clear unterstützten zuvor einen Namensraumparameter. Dieser Parameter ist nun 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.

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 4 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.

Sonstiges

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.

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 any type hints for events that require a class - the 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

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 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.

Namespacing

Class usage like $msg = JText::_( 'Hello man!' ); can now use namespacing.
Which would turn into $msg = Text::_( 'Hello man!' );.
To use namespacing you need to add the proper namespace declaration.
I recommend you add it immediately after the define.

To find out the proper namespace you can either follow the instructions
here: https://groups.google.com/forum/#!topic/joomla-dev-general/1ua9zIqlcVc
or use the generated file pdf reference file. File:J! namespace reference.pdf