Joomla! Documentation - User contributions [en]

Potential backward compatibility issues in Joomla 4/de

2019-10-19T18:29:46Z

Jehacgn: Created page with "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."

<noinclude><languages /></noinclude>
{{incomplete}}{{RightTOC}}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.9.

== Aktualisierte Systemanforderungen ==
Die Systemanforderungen wurden wie folgt aktualisiert:
*PHP 7.2
*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.

<pre>
'STRICT_TRANS_TABLES',
'ERROR_FOR_DIVISION_BY_ZERO',
'NO_AUTO_CREATE_USER',
'NO_ENGINE_SUBSTITUTION',
</pre>

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

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

== 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 {{rarr}} JApplicationBase {{rarr}} Joomla\Application\AbstractApplication
*Neu: JApplicationCli {{rarr}} Joomla\Application\AbstractCliApplication {{rarr}} Joomla\Application\AbstractApplication

===== JApplicationWeb =====

*Alt: JApplicationWeb {{rarr}} JApplicationBase {{rarr}} Joomla\Application\AbstractApplication
*Neu: JApplicationWeb {{rarr}} Joomla\Application\AbstractWebApplication {{rarr}} 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 {{JVer | 3.7}}). Weitere Informationen finden Sie unter [[S:MyLanguage/J3.x:Discover_on_which_client_your_extension_code_is_running|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). [https://github.com/joomla-framework/database])

=== 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 ===
* <noinclude>JBrowser::isSSLConnection has been removed. Use JApplicationCms::isSSLConnection (available since Joomla 3.2)</noinclude>

=== 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 siehe[https://github.com/joomla/joomla-cms/pull/16419 dieser 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).
* JFormFieldUsergroup wurde entfernt. Verwende stattdessen Joomla\CMS\Form\Field\UsergrouplistField (verfügbar seit Joomla 3.2).
* JFormFieldFilelist und JFormFieldFolderList wurden ihre Filtereigenschaften umbenannt in <code>fileFilter</code> und <code>folderFilter</code> (um die Verwendung des regulären Joomla-Filterattributs auf zurückgegebene Werte zu ermöglichen).

=== 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 Schnittstelle[https://secure.php.net/manual/en/class.arrayaccess.php ArrayAccess] 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).

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

=== Sprache ====
* Die Funktionen setTransliterator, setPluralSuffixesCallback, setIgnoredSearchWordsCallback, setLowerLimitSearchWordCallback, setUpperLimitSearchWordCallback und setSearchDisplayedCharactersNumberCallback sind nun typisiert, um ein Callable zu benötigen.
* Der <tt>"_QQ_"</tt> 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. <tt>\"</tt>)

=== 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's[https://secure.php.net/manual/en/class.sessionhandlerinterface.php SessionHandlerInterface] 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 [https://github.com/PHPMailer/PHPMailer/blob/6.0/UPGRADING.md 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 [https://jquery.com/upgrade-guide/3.0/ 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.

=== 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: [http://getbootstrap.com/docs/4.0/getting-started/introduction/]. Für weitere Informationen über Bootstrap 2.3.2: (http://getbootstrap.com/2.3.2/)

== 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 <source inline lang="php">ActionlogsHelper::getCsvData()</source> ist nun vom Typ angedeutet, dass er ein <source inline lang="php">Generator</source> Objekt liefert.
* Corekomponenten wurden aus Joomla 3.7 entfernt, da der URL-Routing-Modus'Legacy' entfernt wurde. Man sollte entweder die .htaccess-Datei oder die Umleitungskomponente verwenden, um interne URLs zu korrigieren, die sich ändern. Man kann den'Modern'-Modus in Joomla 3 ausprobieren, indem man den Anweisungen [[S:MyLanguage/J3.x:New_Routing_System|here]]] folgt.

=== Plugins ===
* Das Plugin zur Google Mail-Authentifizierung wurde entfernt. Für weitere Informationen lese bitte[https://developer.joomla.org/news/724-removal-of-the-gmail-authentication-plugin-as-of-joomla-4-0.html diesen 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).

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

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

<noinclude>
[[Category:Compatibility{{#translation:}}]]
[[Category:Development{{#translation:}}]]
[[Category:Platform{{#translation:}}]]
[[Category:Migration{{#translation:}}]]
[[Category:Update Working Group{{#translation:}}]]
[[Category:Joomla! 4.x{{#translation:}}]]
[[Category:Joomla! 4.0{{#translation:}}]]
</noinclude>

Translations:Potential backward compatibility issues in Joomla 4/168/de

2019-10-19T18:29:46Z

Jehacgn: Created page with "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."

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

Potential backward compatibility issues in Joomla 4/de

2019-10-19T18:27:53Z

Jehacgn: Created page with "Das Recaptcha-Plugin verwendet nun Googles offizielle php-Bibliothek für Captcha."

<noinclude><languages /></noinclude>
{{incomplete}}{{RightTOC}}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.9.

== Aktualisierte Systemanforderungen ==
Die Systemanforderungen wurden wie folgt aktualisiert:
*PHP 7.2
*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.

<pre>
'STRICT_TRANS_TABLES',
'ERROR_FOR_DIVISION_BY_ZERO',
'NO_AUTO_CREATE_USER',
'NO_ENGINE_SUBSTITUTION',
</pre>

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

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

== 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 {{rarr}} JApplicationBase {{rarr}} Joomla\Application\AbstractApplication
*Neu: JApplicationCli {{rarr}} Joomla\Application\AbstractCliApplication {{rarr}} Joomla\Application\AbstractApplication

===== JApplicationWeb =====

*Alt: JApplicationWeb {{rarr}} JApplicationBase {{rarr}} Joomla\Application\AbstractApplication
*Neu: JApplicationWeb {{rarr}} Joomla\Application\AbstractWebApplication {{rarr}} 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 {{JVer | 3.7}}). Weitere Informationen finden Sie unter [[S:MyLanguage/J3.x:Discover_on_which_client_your_extension_code_is_running|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). [https://github.com/joomla-framework/database])

=== 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 ===
* <noinclude>JBrowser::isSSLConnection has been removed. Use JApplicationCms::isSSLConnection (available since Joomla 3.2)</noinclude>

=== 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 siehe[https://github.com/joomla/joomla-cms/pull/16419 dieser 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).
* JFormFieldUsergroup wurde entfernt. Verwende stattdessen Joomla\CMS\Form\Field\UsergrouplistField (verfügbar seit Joomla 3.2).
* JFormFieldFilelist und JFormFieldFolderList wurden ihre Filtereigenschaften umbenannt in <code>fileFilter</code> und <code>folderFilter</code> (um die Verwendung des regulären Joomla-Filterattributs auf zurückgegebene Werte zu ermöglichen).

=== 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 Schnittstelle[https://secure.php.net/manual/en/class.arrayaccess.php ArrayAccess] 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).

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

=== Sprache ====
* Die Funktionen setTransliterator, setPluralSuffixesCallback, setIgnoredSearchWordsCallback, setLowerLimitSearchWordCallback, setUpperLimitSearchWordCallback und setSearchDisplayedCharactersNumberCallback sind nun typisiert, um ein Callable zu benötigen.
* Der <tt>"_QQ_"</tt> 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. <tt>\"</tt>)

=== 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's[https://secure.php.net/manual/en/class.sessionhandlerinterface.php SessionHandlerInterface] 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 [https://github.com/PHPMailer/PHPMailer/blob/6.0/UPGRADING.md 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 [https://jquery.com/upgrade-guide/3.0/ 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.

=== 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: [http://getbootstrap.com/docs/4.0/getting-started/introduction/]. Für weitere Informationen über Bootstrap 2.3.2: (http://getbootstrap.com/2.3.2/)

== 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 <source inline lang="php">ActionlogsHelper::getCsvData()</source> ist nun vom Typ angedeutet, dass er ein <source inline lang="php">Generator</source> Objekt liefert.
* Corekomponenten wurden aus Joomla 3.7 entfernt, da der URL-Routing-Modus'Legacy' entfernt wurde. Man sollte entweder die .htaccess-Datei oder die Umleitungskomponente verwenden, um interne URLs zu korrigieren, die sich ändern. Man kann den'Modern'-Modus in Joomla 3 ausprobieren, indem man den Anweisungen [[S:MyLanguage/J3.x:New_Routing_System|here]]] folgt.

=== Plugins ===
* Das Plugin zur Google Mail-Authentifizierung wurde entfernt. Für weitere Informationen lese bitte[https://developer.joomla.org/news/724-removal-of-the-gmail-authentication-plugin-as-of-joomla-4-0.html diesen 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.
* For plugins using the 3.x compatibility layer the name result is a protected property for both input parameters and return values. For information on the new recommended approach to plugins please read [[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).

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

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

<noinclude>
[[Category:Compatibility{{#translation:}}]]
[[Category:Development{{#translation:}}]]
[[Category:Platform{{#translation:}}]]
[[Category:Migration{{#translation:}}]]
[[Category:Update Working Group{{#translation:}}]]
[[Category:Joomla! 4.x{{#translation:}}]]
[[Category:Joomla! 4.0{{#translation:}}]]
</noinclude>

Translations:Potential backward compatibility issues in Joomla 4/164/de

2019-10-19T18:27:52Z

Jehacgn: Created page with "Das Recaptcha-Plugin verwendet nun Googles offizielle php-Bibliothek für Captcha."

Das Recaptcha-Plugin verwendet nun Googles offizielle php-Bibliothek für Captcha.

Potential backward compatibility issues in Joomla 4/de

2019-10-19T18:24:57Z

Jehacgn: Created page with "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..."

<noinclude><languages /></noinclude>
{{incomplete}}{{RightTOC}}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.9.

== Aktualisierte Systemanforderungen ==
Die Systemanforderungen wurden wie folgt aktualisiert:
*PHP 7.2
*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.

<pre>
'STRICT_TRANS_TABLES',
'ERROR_FOR_DIVISION_BY_ZERO',
'NO_AUTO_CREATE_USER',
'NO_ENGINE_SUBSTITUTION',
</pre>

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

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

== 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 {{rarr}} JApplicationBase {{rarr}} Joomla\Application\AbstractApplication
*Neu: JApplicationCli {{rarr}} Joomla\Application\AbstractCliApplication {{rarr}} Joomla\Application\AbstractApplication

===== JApplicationWeb =====

*Alt: JApplicationWeb {{rarr}} JApplicationBase {{rarr}} Joomla\Application\AbstractApplication
*Neu: JApplicationWeb {{rarr}} Joomla\Application\AbstractWebApplication {{rarr}} 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 {{JVer | 3.7}}). Weitere Informationen finden Sie unter [[S:MyLanguage/J3.x:Discover_on_which_client_your_extension_code_is_running|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). [https://github.com/joomla-framework/database])

=== 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 ===
* <noinclude>JBrowser::isSSLConnection has been removed. Use JApplicationCms::isSSLConnection (available since Joomla 3.2)</noinclude>

=== 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 siehe[https://github.com/joomla/joomla-cms/pull/16419 dieser 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).
* JFormFieldUsergroup wurde entfernt. Verwende stattdessen Joomla\CMS\Form\Field\UsergrouplistField (verfügbar seit Joomla 3.2).
* JFormFieldFilelist und JFormFieldFolderList wurden ihre Filtereigenschaften umbenannt in <code>fileFilter</code> und <code>folderFilter</code> (um die Verwendung des regulären Joomla-Filterattributs auf zurückgegebene Werte zu ermöglichen).

=== 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 Schnittstelle[https://secure.php.net/manual/en/class.arrayaccess.php ArrayAccess] 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).

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

=== Sprache ====
* Die Funktionen setTransliterator, setPluralSuffixesCallback, setIgnoredSearchWordsCallback, setLowerLimitSearchWordCallback, setUpperLimitSearchWordCallback und setSearchDisplayedCharactersNumberCallback sind nun typisiert, um ein Callable zu benötigen.
* Der <tt>"_QQ_"</tt> 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. <tt>\"</tt>)

=== 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's[https://secure.php.net/manual/en/class.sessionhandlerinterface.php SessionHandlerInterface] 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 [https://github.com/PHPMailer/PHPMailer/blob/6.0/UPGRADING.md 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 [https://jquery.com/upgrade-guide/3.0/ 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.

=== 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: [http://getbootstrap.com/docs/4.0/getting-started/introduction/]. Für weitere Informationen über Bootstrap 2.3.2: (http://getbootstrap.com/2.3.2/)

== 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 <source inline lang="php">ActionlogsHelper::getCsvData()</source> ist nun vom Typ angedeutet, dass er ein <source inline lang="php">Generator</source> Objekt liefert.
* Corekomponenten wurden aus Joomla 3.7 entfernt, da der URL-Routing-Modus'Legacy' entfernt wurde. Man sollte entweder die .htaccess-Datei oder die Umleitungskomponente verwenden, um interne URLs zu korrigieren, die sich ändern. Man kann den'Modern'-Modus in Joomla 3 ausprobieren, indem man den Anweisungen [[S:MyLanguage/J3.x:New_Routing_System|here]]] folgt.

=== Plugins ===
* Das Plugin zur Google Mail-Authentifizierung wurde entfernt. Für weitere Informationen lese bitte[https://developer.joomla.org/news/724-removal-of-the-gmail-authentication-plugin-as-of-joomla-4-0.html diesen 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.
* The Recaptcha plugin now uses google's official php library for captcha under the hood
* For plugins using the 3.x compatibility layer the name result is a protected property for both input parameters and return values. For information on the new recommended approach to plugins please read [[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).

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

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

<noinclude>
[[Category:Compatibility{{#translation:}}]]
[[Category:Development{{#translation:}}]]
[[Category:Platform{{#translation:}}]]
[[Category:Migration{{#translation:}}]]
[[Category:Update Working Group{{#translation:}}]]
[[Category:Joomla! 4.x{{#translation:}}]]
[[Category:Joomla! 4.0{{#translation:}}]]
</noinclude>

Translations:Potential backward compatibility issues in Joomla 4/163/de

2019-10-19T18:24:56Z

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.

Potential backward compatibility issues in Joomla 4/de

2019-10-19T18:24:16Z

Jehacgn: Created page with "Das Plugin zur Google Mail-Authentifizierung wurde entfernt. Für weitere Informationen lese bitte[https://developer.joomla.org/news/724-removal-of-the-gmail-authentication-pl..."

<noinclude><languages /></noinclude>
{{incomplete}}{{RightTOC}}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.9.

== Aktualisierte Systemanforderungen ==
Die Systemanforderungen wurden wie folgt aktualisiert:
*PHP 7.2
*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.

<pre>
'STRICT_TRANS_TABLES',
'ERROR_FOR_DIVISION_BY_ZERO',
'NO_AUTO_CREATE_USER',
'NO_ENGINE_SUBSTITUTION',
</pre>

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

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

== 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 {{rarr}} JApplicationBase {{rarr}} Joomla\Application\AbstractApplication
*Neu: JApplicationCli {{rarr}} Joomla\Application\AbstractCliApplication {{rarr}} Joomla\Application\AbstractApplication

===== JApplicationWeb =====

*Alt: JApplicationWeb {{rarr}} JApplicationBase {{rarr}} Joomla\Application\AbstractApplication
*Neu: JApplicationWeb {{rarr}} Joomla\Application\AbstractWebApplication {{rarr}} 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 {{JVer | 3.7}}). Weitere Informationen finden Sie unter [[S:MyLanguage/J3.x:Discover_on_which_client_your_extension_code_is_running|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). [https://github.com/joomla-framework/database])

=== 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 ===
* <noinclude>JBrowser::isSSLConnection has been removed. Use JApplicationCms::isSSLConnection (available since Joomla 3.2)</noinclude>

=== 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 siehe[https://github.com/joomla/joomla-cms/pull/16419 dieser 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).
* JFormFieldUsergroup wurde entfernt. Verwende stattdessen Joomla\CMS\Form\Field\UsergrouplistField (verfügbar seit Joomla 3.2).
* JFormFieldFilelist und JFormFieldFolderList wurden ihre Filtereigenschaften umbenannt in <code>fileFilter</code> und <code>folderFilter</code> (um die Verwendung des regulären Joomla-Filterattributs auf zurückgegebene Werte zu ermöglichen).

=== 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 Schnittstelle[https://secure.php.net/manual/en/class.arrayaccess.php ArrayAccess] 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).

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

=== Sprache ====
* Die Funktionen setTransliterator, setPluralSuffixesCallback, setIgnoredSearchWordsCallback, setLowerLimitSearchWordCallback, setUpperLimitSearchWordCallback und setSearchDisplayedCharactersNumberCallback sind nun typisiert, um ein Callable zu benötigen.
* Der <tt>"_QQ_"</tt> 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. <tt>\"</tt>)

=== 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's[https://secure.php.net/manual/en/class.sessionhandlerinterface.php SessionHandlerInterface] 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 [https://github.com/PHPMailer/PHPMailer/blob/6.0/UPGRADING.md 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 [https://jquery.com/upgrade-guide/3.0/ 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.

=== 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: [http://getbootstrap.com/docs/4.0/getting-started/introduction/]. Für weitere Informationen über Bootstrap 2.3.2: (http://getbootstrap.com/2.3.2/)

== 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 <source inline lang="php">ActionlogsHelper::getCsvData()</source> ist nun vom Typ angedeutet, dass er ein <source inline lang="php">Generator</source> Objekt liefert.
* Corekomponenten wurden aus Joomla 3.7 entfernt, da der URL-Routing-Modus'Legacy' entfernt wurde. Man sollte entweder die .htaccess-Datei oder die Umleitungskomponente verwenden, um interne URLs zu korrigieren, die sich ändern. Man kann den'Modern'-Modus in Joomla 3 ausprobieren, indem man den Anweisungen [[S:MyLanguage/J3.x:New_Routing_System|here]]] folgt.

=== Plugins ===
* Das Plugin zur Google Mail-Authentifizierung wurde entfernt. Für weitere Informationen lese bitte[https://developer.joomla.org/news/724-removal-of-the-gmail-authentication-plugin-as-of-joomla-4-0.html diesen Blogbeitrag].
* Recaptcha v1 support has been fully removed from the captcha plugin - this has no longer worked since Q2 2018 due to google dropping support for it.
* The Recaptcha plugin now uses google's official php library for captcha under the hood
* For plugins using the 3.x compatibility layer the name result is a protected property for both input parameters and return values. For information on the new recommended approach to plugins please read [[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).

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

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

<noinclude>
[[Category:Compatibility{{#translation:}}]]
[[Category:Development{{#translation:}}]]
[[Category:Platform{{#translation:}}]]
[[Category:Migration{{#translation:}}]]
[[Category:Update Working Group{{#translation:}}]]
[[Category:Joomla! 4.x{{#translation:}}]]
[[Category:Joomla! 4.0{{#translation:}}]]
</noinclude>

Translations:Potential backward compatibility issues in Joomla 4/162/de

2019-10-19T18:24:15Z

Das Plugin zur Google Mail-Authentifizierung wurde entfernt. Für weitere Informationen lese bitte[https://developer.joomla.org/news/724-removal-of-the-gmail-authentication-plugin-as-of-joomla-4-0.html diesen Blogbeitrag].

Translations:Potential backward compatibility issues in Joomla 4/161/de

2019-10-19T18:23:10Z

Jehacgn: Created page with "=== Plugins ==="

=== Plugins ===

Potential backward compatibility issues in Joomla 4/de

2019-10-19T18:22:58Z

Jehacgn: Created page with "Corekomponenten wurden aus Joomla 3.7 entfernt, da der URL-Routing-Modus'Legacy' entfernt wurde. Man sollte entweder die .htaccess-Datei oder die Umleitungskomponente verwende..."

<noinclude><languages /></noinclude>
{{incomplete}}{{RightTOC}}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.9.

== Aktualisierte Systemanforderungen ==
Die Systemanforderungen wurden wie folgt aktualisiert:
*PHP 7.2
*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.

<pre>
'STRICT_TRANS_TABLES',
'ERROR_FOR_DIVISION_BY_ZERO',
'NO_AUTO_CREATE_USER',
'NO_ENGINE_SUBSTITUTION',
</pre>

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

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

== 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 {{rarr}} JApplicationBase {{rarr}} Joomla\Application\AbstractApplication
*Neu: JApplicationCli {{rarr}} Joomla\Application\AbstractCliApplication {{rarr}} Joomla\Application\AbstractApplication

===== JApplicationWeb =====

*Alt: JApplicationWeb {{rarr}} JApplicationBase {{rarr}} Joomla\Application\AbstractApplication
*Neu: JApplicationWeb {{rarr}} Joomla\Application\AbstractWebApplication {{rarr}} 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 {{JVer | 3.7}}). Weitere Informationen finden Sie unter [[S:MyLanguage/J3.x:Discover_on_which_client_your_extension_code_is_running|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). [https://github.com/joomla-framework/database])

=== 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 ===
* <noinclude>JBrowser::isSSLConnection has been removed. Use JApplicationCms::isSSLConnection (available since Joomla 3.2)</noinclude>

=== 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 siehe[https://github.com/joomla/joomla-cms/pull/16419 dieser 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).
* JFormFieldUsergroup wurde entfernt. Verwende stattdessen Joomla\CMS\Form\Field\UsergrouplistField (verfügbar seit Joomla 3.2).
* JFormFieldFilelist und JFormFieldFolderList wurden ihre Filtereigenschaften umbenannt in <code>fileFilter</code> und <code>folderFilter</code> (um die Verwendung des regulären Joomla-Filterattributs auf zurückgegebene Werte zu ermöglichen).

=== 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 Schnittstelle[https://secure.php.net/manual/en/class.arrayaccess.php ArrayAccess] 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).

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

=== Sprache ====
* Die Funktionen setTransliterator, setPluralSuffixesCallback, setIgnoredSearchWordsCallback, setLowerLimitSearchWordCallback, setUpperLimitSearchWordCallback und setSearchDisplayedCharactersNumberCallback sind nun typisiert, um ein Callable zu benötigen.
* Der <tt>"_QQ_"</tt> 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. <tt>\"</tt>)

=== 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's[https://secure.php.net/manual/en/class.sessionhandlerinterface.php SessionHandlerInterface] 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 [https://github.com/PHPMailer/PHPMailer/blob/6.0/UPGRADING.md 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 [https://jquery.com/upgrade-guide/3.0/ 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.

=== 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: [http://getbootstrap.com/docs/4.0/getting-started/introduction/]. Für weitere Informationen über Bootstrap 2.3.2: (http://getbootstrap.com/2.3.2/)

== 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 <source inline lang="php">ActionlogsHelper::getCsvData()</source> ist nun vom Typ angedeutet, dass er ein <source inline lang="php">Generator</source> Objekt liefert.
* Corekomponenten wurden aus Joomla 3.7 entfernt, da der URL-Routing-Modus'Legacy' entfernt wurde. Man sollte entweder die .htaccess-Datei oder die Umleitungskomponente verwenden, um interne URLs zu korrigieren, die sich ändern. Man kann den'Modern'-Modus in Joomla 3 ausprobieren, indem man den Anweisungen [[S:MyLanguage/J3.x:New_Routing_System|here]]] folgt.

=== Plugins ===
* The gmail authentication plugin has been removed. For more information please read [https://developer.joomla.org/news/724-removal-of-the-gmail-authentication-plugin-as-of-joomla-4-0.html this blog post]
* Recaptcha v1 support has been fully removed from the captcha plugin - this has no longer worked since Q2 2018 due to google dropping support for it.
* The Recaptcha plugin now uses google's official php library for captcha under the hood
* For plugins using the 3.x compatibility layer the name result is a protected property for both input parameters and return values. For information on the new recommended approach to plugins please read [[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).

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

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

<noinclude>
[[Category:Compatibility{{#translation:}}]]
[[Category:Development{{#translation:}}]]
[[Category:Platform{{#translation:}}]]
[[Category:Migration{{#translation:}}]]
[[Category:Update Working Group{{#translation:}}]]
[[Category:Joomla! 4.x{{#translation:}}]]
[[Category:Joomla! 4.0{{#translation:}}]]
</noinclude>

Translations:Potential backward compatibility issues in Joomla 4/204/de

2019-10-19T18:22:57Z

Corekomponenten wurden aus Joomla 3.7 entfernt, da der URL-Routing-Modus'Legacy' entfernt wurde. Man sollte entweder die .htaccess-Datei oder die Umleitungskomponente verwenden, um interne URLs zu korrigieren, die sich ändern. Man kann den'Modern'-Modus in Joomla 3 ausprobieren, indem man den Anweisungen [[S:MyLanguage/J3.x:New_Routing_System|here]]] folgt.

Potential backward compatibility issues in Joomla 4/de

2019-10-19T18:21:08Z

Jehacgn: Created page with "com_actionlogs php 5.5 Backfill-Code wurde entfernt und entsprechend <source inline lang="php">ActionlogsHelper::getCsvData()</source> ist nun vom Typ angedeutet, dass er ein..."

<noinclude><languages /></noinclude>
{{incomplete}}{{RightTOC}}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.9.

== Aktualisierte Systemanforderungen ==
Die Systemanforderungen wurden wie folgt aktualisiert:
*PHP 7.2
*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.

<pre>
'STRICT_TRANS_TABLES',
'ERROR_FOR_DIVISION_BY_ZERO',
'NO_AUTO_CREATE_USER',
'NO_ENGINE_SUBSTITUTION',
</pre>

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

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

== 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 {{rarr}} JApplicationBase {{rarr}} Joomla\Application\AbstractApplication
*Neu: JApplicationCli {{rarr}} Joomla\Application\AbstractCliApplication {{rarr}} Joomla\Application\AbstractApplication

===== JApplicationWeb =====

*Alt: JApplicationWeb {{rarr}} JApplicationBase {{rarr}} Joomla\Application\AbstractApplication
*Neu: JApplicationWeb {{rarr}} Joomla\Application\AbstractWebApplication {{rarr}} 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 {{JVer | 3.7}}). Weitere Informationen finden Sie unter [[S:MyLanguage/J3.x:Discover_on_which_client_your_extension_code_is_running|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). [https://github.com/joomla-framework/database])

=== 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 ===
* <noinclude>JBrowser::isSSLConnection has been removed. Use JApplicationCms::isSSLConnection (available since Joomla 3.2)</noinclude>

=== 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 siehe[https://github.com/joomla/joomla-cms/pull/16419 dieser 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).
* JFormFieldUsergroup wurde entfernt. Verwende stattdessen Joomla\CMS\Form\Field\UsergrouplistField (verfügbar seit Joomla 3.2).
* JFormFieldFilelist und JFormFieldFolderList wurden ihre Filtereigenschaften umbenannt in <code>fileFilter</code> und <code>folderFilter</code> (um die Verwendung des regulären Joomla-Filterattributs auf zurückgegebene Werte zu ermöglichen).

=== 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 Schnittstelle[https://secure.php.net/manual/en/class.arrayaccess.php ArrayAccess] 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).

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

=== Sprache ====
* Die Funktionen setTransliterator, setPluralSuffixesCallback, setIgnoredSearchWordsCallback, setLowerLimitSearchWordCallback, setUpperLimitSearchWordCallback und setSearchDisplayedCharactersNumberCallback sind nun typisiert, um ein Callable zu benötigen.
* Der <tt>"_QQ_"</tt> 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. <tt>\"</tt>)

=== 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's[https://secure.php.net/manual/en/class.sessionhandlerinterface.php SessionHandlerInterface] 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 [https://github.com/PHPMailer/PHPMailer/blob/6.0/UPGRADING.md 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 [https://jquery.com/upgrade-guide/3.0/ 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.

=== 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: [http://getbootstrap.com/docs/4.0/getting-started/introduction/]. Für weitere Informationen über Bootstrap 2.3.2: (http://getbootstrap.com/2.3.2/)

== 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 <source inline lang="php">ActionlogsHelper::getCsvData()</source> ist nun vom Typ angedeutet, dass er ein <source inline lang="php">Generator</source> Objekt liefert.
* Core components have had URL Routing 'Legacy' mode removed from Joomla 3.7. You should either use your .htaccess file or the redirect component to fix any internal URLs that change. You can try the 'Modern' mode in Joomla 3 by following the instructions [[S:MyLanguage/J3.x:New_Routing_System|here]]

=== Plugins ===
* The gmail authentication plugin has been removed. For more information please read [https://developer.joomla.org/news/724-removal-of-the-gmail-authentication-plugin-as-of-joomla-4-0.html this blog post]
* Recaptcha v1 support has been fully removed from the captcha plugin - this has no longer worked since Q2 2018 due to google dropping support for it.
* The Recaptcha plugin now uses google's official php library for captcha under the hood
* For plugins using the 3.x compatibility layer the name result is a protected property for both input parameters and return values. For information on the new recommended approach to plugins please read [[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).

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

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

<noinclude>
[[Category:Compatibility{{#translation:}}]]
[[Category:Development{{#translation:}}]]
[[Category:Platform{{#translation:}}]]
[[Category:Migration{{#translation:}}]]
[[Category:Update Working Group{{#translation:}}]]
[[Category:Joomla! 4.x{{#translation:}}]]
[[Category:Joomla! 4.0{{#translation:}}]]
</noinclude>

Translations:Potential backward compatibility issues in Joomla 4/203/de

2019-10-19T18:21:07Z

com_actionlogs php 5.5 Backfill-Code wurde entfernt und entsprechend <source inline lang="php">ActionlogsHelper::getCsvData()</source> ist nun vom Typ angedeutet, dass er ein <source inline lang="php">Generator</source> Objekt liefert.

Potential backward compatibility issues in Joomla 4/de

2019-10-19T18:20:02Z

Jehacgn: Created page with "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 Co..."

<noinclude><languages /></noinclude>
{{incomplete}}{{RightTOC}}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.9.

== Aktualisierte Systemanforderungen ==
Die Systemanforderungen wurden wie folgt aktualisiert:
*PHP 7.2
*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.

<pre>
'STRICT_TRANS_TABLES',
'ERROR_FOR_DIVISION_BY_ZERO',
'NO_AUTO_CREATE_USER',
'NO_ENGINE_SUBSTITUTION',
</pre>

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

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

== 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 {{rarr}} JApplicationBase {{rarr}} Joomla\Application\AbstractApplication
*Neu: JApplicationCli {{rarr}} Joomla\Application\AbstractCliApplication {{rarr}} Joomla\Application\AbstractApplication

===== JApplicationWeb =====

*Alt: JApplicationWeb {{rarr}} JApplicationBase {{rarr}} Joomla\Application\AbstractApplication
*Neu: JApplicationWeb {{rarr}} Joomla\Application\AbstractWebApplication {{rarr}} 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 {{JVer | 3.7}}). Weitere Informationen finden Sie unter [[S:MyLanguage/J3.x:Discover_on_which_client_your_extension_code_is_running|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). [https://github.com/joomla-framework/database])

=== 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 ===
* <noinclude>JBrowser::isSSLConnection has been removed. Use JApplicationCms::isSSLConnection (available since Joomla 3.2)</noinclude>

=== 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 siehe[https://github.com/joomla/joomla-cms/pull/16419 dieser 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).
* JFormFieldUsergroup wurde entfernt. Verwende stattdessen Joomla\CMS\Form\Field\UsergrouplistField (verfügbar seit Joomla 3.2).
* JFormFieldFilelist und JFormFieldFolderList wurden ihre Filtereigenschaften umbenannt in <code>fileFilter</code> und <code>folderFilter</code> (um die Verwendung des regulären Joomla-Filterattributs auf zurückgegebene Werte zu ermöglichen).

=== 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 Schnittstelle[https://secure.php.net/manual/en/class.arrayaccess.php ArrayAccess] 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).

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

=== Sprache ====
* Die Funktionen setTransliterator, setPluralSuffixesCallback, setIgnoredSearchWordsCallback, setLowerLimitSearchWordCallback, setUpperLimitSearchWordCallback und setSearchDisplayedCharactersNumberCallback sind nun typisiert, um ein Callable zu benötigen.
* Der <tt>"_QQ_"</tt> 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. <tt>\"</tt>)

=== 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's[https://secure.php.net/manual/en/class.sessionhandlerinterface.php SessionHandlerInterface] 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 [https://github.com/PHPMailer/PHPMailer/blob/6.0/UPGRADING.md 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 [https://jquery.com/upgrade-guide/3.0/ 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.

=== 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: [http://getbootstrap.com/docs/4.0/getting-started/introduction/]. Für weitere Informationen über Bootstrap 2.3.2: (http://getbootstrap.com/2.3.2/)

== 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 has been removed and accordingly <source inline lang="php">ActionlogsHelper::getCsvData()</source> is now type hinted to return a <source inline lang="php">Generator</source> object
* Core components have had URL Routing 'Legacy' mode removed from Joomla 3.7. You should either use your .htaccess file or the redirect component to fix any internal URLs that change. You can try the 'Modern' mode in Joomla 3 by following the instructions [[S:MyLanguage/J3.x:New_Routing_System|here]]

=== Plugins ===
* The gmail authentication plugin has been removed. For more information please read [https://developer.joomla.org/news/724-removal-of-the-gmail-authentication-plugin-as-of-joomla-4-0.html this blog post]
* Recaptcha v1 support has been fully removed from the captcha plugin - this has no longer worked since Q2 2018 due to google dropping support for it.
* The Recaptcha plugin now uses google's official php library for captcha under the hood
* For plugins using the 3.x compatibility layer the name result is a protected property for both input parameters and return values. For information on the new recommended approach to plugins please read [[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).

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

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

<noinclude>
[[Category:Compatibility{{#translation:}}]]
[[Category:Development{{#translation:}}]]
[[Category:Platform{{#translation:}}]]
[[Category:Migration{{#translation:}}]]
[[Category:Update Working Group{{#translation:}}]]
[[Category:Joomla! 4.x{{#translation:}}]]
[[Category:Joomla! 4.0{{#translation:}}]]
</noinclude>

Translations:Potential backward compatibility issues in Joomla 4/190/de

2019-10-19T18:20:01Z

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

Potential backward compatibility issues in Joomla 4/de

2019-10-19T18:16:25Z

Jehacgn: Created page with "JAdministratorHelper wurde ersatzlos entfernt (es wurde in JApplicationAdministrator integriert)."

<noinclude><languages /></noinclude>
{{incomplete}}{{RightTOC}}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.9.

== Aktualisierte Systemanforderungen ==
Die Systemanforderungen wurden wie folgt aktualisiert:
*PHP 7.2
*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.

<pre>
'STRICT_TRANS_TABLES',
'ERROR_FOR_DIVISION_BY_ZERO',
'NO_AUTO_CREATE_USER',
'NO_ENGINE_SUBSTITUTION',
</pre>

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

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

== 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 {{rarr}} JApplicationBase {{rarr}} Joomla\Application\AbstractApplication
*Neu: JApplicationCli {{rarr}} Joomla\Application\AbstractCliApplication {{rarr}} Joomla\Application\AbstractApplication

===== JApplicationWeb =====

*Alt: JApplicationWeb {{rarr}} JApplicationBase {{rarr}} Joomla\Application\AbstractApplication
*Neu: JApplicationWeb {{rarr}} Joomla\Application\AbstractWebApplication {{rarr}} 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 {{JVer | 3.7}}). Weitere Informationen finden Sie unter [[S:MyLanguage/J3.x:Discover_on_which_client_your_extension_code_is_running|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). [https://github.com/joomla-framework/database])

=== 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 ===
* <noinclude>JBrowser::isSSLConnection has been removed. Use JApplicationCms::isSSLConnection (available since Joomla 3.2)</noinclude>

=== 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 siehe[https://github.com/joomla/joomla-cms/pull/16419 dieser 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).
* JFormFieldUsergroup wurde entfernt. Verwende stattdessen Joomla\CMS\Form\Field\UsergrouplistField (verfügbar seit Joomla 3.2).
* JFormFieldFilelist und JFormFieldFolderList wurden ihre Filtereigenschaften umbenannt in <code>fileFilter</code> und <code>folderFilter</code> (um die Verwendung des regulären Joomla-Filterattributs auf zurückgegebene Werte zu ermöglichen).

=== 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 Schnittstelle[https://secure.php.net/manual/en/class.arrayaccess.php ArrayAccess] 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).

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

=== Sprache ====
* Die Funktionen setTransliterator, setPluralSuffixesCallback, setIgnoredSearchWordsCallback, setLowerLimitSearchWordCallback, setUpperLimitSearchWordCallback und setSearchDisplayedCharactersNumberCallback sind nun typisiert, um ein Callable zu benötigen.
* Der <tt>"_QQ_"</tt> 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. <tt>\"</tt>)

=== 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's[https://secure.php.net/manual/en/class.sessionhandlerinterface.php SessionHandlerInterface] 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 [https://github.com/PHPMailer/PHPMailer/blob/6.0/UPGRADING.md 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 [https://jquery.com/upgrade-guide/3.0/ 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.

=== 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: [http://getbootstrap.com/docs/4.0/getting-started/introduction/]. Für weitere Informationen über Bootstrap 2.3.2: (http://getbootstrap.com/2.3.2/)

== 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 has been removed and accordingly <source inline lang="php">ActionlogsHelper::getCsvData()</source> is now type hinted to return a <source inline lang="php">Generator</source> object
* Core components have had URL Routing 'Legacy' mode removed from Joomla 3.7. You should either use your .htaccess file or the redirect component to fix any internal URLs that change. You can try the 'Modern' mode in Joomla 3 by following the instructions [[S:MyLanguage/J3.x:New_Routing_System|here]]

=== Plugins ===
* The gmail authentication plugin has been removed. For more information please read [https://developer.joomla.org/news/724-removal-of-the-gmail-authentication-plugin-as-of-joomla-4-0.html this blog post]
* Recaptcha v1 support has been fully removed from the captcha plugin - this has no longer worked since Q2 2018 due to google dropping support for it.
* The Recaptcha plugin now uses google's official php library for captcha under the hood
* For plugins using the 3.x compatibility layer the name result is a protected property for both input parameters and return values. For information on the new recommended approach to plugins please read [[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
* The onContentBeforeSave event now requires the data parameter (this has been passed in \Joomla\CMS\MVC\Model\LegacyModel since 3.7 but is now passed in consistently by core extensions and used by the core Joomla content plugin)

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

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

<noinclude>
[[Category:Compatibility{{#translation:}}]]
[[Category:Development{{#translation:}}]]
[[Category:Platform{{#translation:}}]]
[[Category:Migration{{#translation:}}]]
[[Category:Update Working Group{{#translation:}}]]
[[Category:Joomla! 4.x{{#translation:}}]]
[[Category:Joomla! 4.0{{#translation:}}]]
</noinclude>

Translations:Potential backward compatibility issues in Joomla 4/170/de

2019-10-19T18:16:25Z

Jehacgn: Created page with "JAdministratorHelper wurde ersatzlos entfernt (es wurde in JApplicationAdministrator integriert)."

JAdministratorHelper wurde ersatzlos entfernt (es wurde in JApplicationAdministrator integriert).

Potential backward compatibility issues in Joomla 4/de

2019-10-19T18:15:43Z

Jehacgn: Created page with "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..."

<noinclude><languages /></noinclude>
{{incomplete}}{{RightTOC}}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.9.

== Aktualisierte Systemanforderungen ==
Die Systemanforderungen wurden wie folgt aktualisiert:
*PHP 7.2
*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.

<pre>
'STRICT_TRANS_TABLES',
'ERROR_FOR_DIVISION_BY_ZERO',
'NO_AUTO_CREATE_USER',
'NO_ENGINE_SUBSTITUTION',
</pre>

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

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

== 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 {{rarr}} JApplicationBase {{rarr}} Joomla\Application\AbstractApplication
*Neu: JApplicationCli {{rarr}} Joomla\Application\AbstractCliApplication {{rarr}} Joomla\Application\AbstractApplication

===== JApplicationWeb =====

*Alt: JApplicationWeb {{rarr}} JApplicationBase {{rarr}} Joomla\Application\AbstractApplication
*Neu: JApplicationWeb {{rarr}} Joomla\Application\AbstractWebApplication {{rarr}} 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 {{JVer | 3.7}}). Weitere Informationen finden Sie unter [[S:MyLanguage/J3.x:Discover_on_which_client_your_extension_code_is_running|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). [https://github.com/joomla-framework/database])

=== 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 ===
* <noinclude>JBrowser::isSSLConnection has been removed. Use JApplicationCms::isSSLConnection (available since Joomla 3.2)</noinclude>

=== 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 siehe[https://github.com/joomla/joomla-cms/pull/16419 dieser 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).
* JFormFieldUsergroup wurde entfernt. Verwende stattdessen Joomla\CMS\Form\Field\UsergrouplistField (verfügbar seit Joomla 3.2).
* JFormFieldFilelist und JFormFieldFolderList wurden ihre Filtereigenschaften umbenannt in <code>fileFilter</code> und <code>folderFilter</code> (um die Verwendung des regulären Joomla-Filterattributs auf zurückgegebene Werte zu ermöglichen).

=== 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 Schnittstelle[https://secure.php.net/manual/en/class.arrayaccess.php ArrayAccess] 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).

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

=== Sprache ====
* Die Funktionen setTransliterator, setPluralSuffixesCallback, setIgnoredSearchWordsCallback, setLowerLimitSearchWordCallback, setUpperLimitSearchWordCallback und setSearchDisplayedCharactersNumberCallback sind nun typisiert, um ein Callable zu benötigen.
* Der <tt>"_QQ_"</tt> 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. <tt>\"</tt>)

=== 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's[https://secure.php.net/manual/en/class.sessionhandlerinterface.php SessionHandlerInterface] 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 [https://github.com/PHPMailer/PHPMailer/blob/6.0/UPGRADING.md 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 [https://jquery.com/upgrade-guide/3.0/ 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.

=== 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: [http://getbootstrap.com/docs/4.0/getting-started/introduction/]. Für weitere Informationen über Bootstrap 2.3.2: (http://getbootstrap.com/2.3.2/)

== 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 has been removed and accordingly <source inline lang="php">ActionlogsHelper::getCsvData()</source> is now type hinted to return a <source inline lang="php">Generator</source> object
* Core components have had URL Routing 'Legacy' mode removed from Joomla 3.7. You should either use your .htaccess file or the redirect component to fix any internal URLs that change. You can try the 'Modern' mode in Joomla 3 by following the instructions [[S:MyLanguage/J3.x:New_Routing_System|here]]

=== Plugins ===
* The gmail authentication plugin has been removed. For more information please read [https://developer.joomla.org/news/724-removal-of-the-gmail-authentication-plugin-as-of-joomla-4-0.html this blog post]
* Recaptcha v1 support has been fully removed from the captcha plugin - this has no longer worked since Q2 2018 due to google dropping support for it.
* The Recaptcha plugin now uses google's official php library for captcha under the hood
* For plugins using the 3.x compatibility layer the name result is a protected property for both input parameters and return values. For information on the new recommended approach to plugins please read [[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
* The onContentBeforeSave event now requires the data parameter (this has been passed in \Joomla\CMS\MVC\Model\LegacyModel since 3.7 but is now passed in consistently by core extensions and used by the core Joomla content plugin)

=== Administrator Helpers ===
* JAdministratorHelper has been removed without replacement (it's been merged into JApplicationAdministrator)
* 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.

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

<noinclude>
[[Category:Compatibility{{#translation:}}]]
[[Category:Development{{#translation:}}]]
[[Category:Platform{{#translation:}}]]
[[Category:Migration{{#translation:}}]]
[[Category:Update Working Group{{#translation:}}]]
[[Category:Joomla! 4.x{{#translation:}}]]
[[Category:Joomla! 4.0{{#translation:}}]]
</noinclude>

Translations:Potential backward compatibility issues in Joomla 4/202/de

2019-10-19T18:15:43Z

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

Potential backward compatibility issues in Joomla 4/de

2019-10-19T18:15:07Z

Jehacgn: Created page with "Alle Komponenten wurden im Namensraum angeordnet und die Verzeichnisse entsprechend überarbeitet. Für weitere Informationen dazu lese das Tutorial zum Erstellen einer Kompon..."

<noinclude><languages /></noinclude>
{{incomplete}}{{RightTOC}}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.9.

== Aktualisierte Systemanforderungen ==
Die Systemanforderungen wurden wie folgt aktualisiert:
*PHP 7.2
*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.

<pre>
'STRICT_TRANS_TABLES',
'ERROR_FOR_DIVISION_BY_ZERO',
'NO_AUTO_CREATE_USER',
'NO_ENGINE_SUBSTITUTION',
</pre>

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

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

== 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 {{rarr}} JApplicationBase {{rarr}} Joomla\Application\AbstractApplication
*Neu: JApplicationCli {{rarr}} Joomla\Application\AbstractCliApplication {{rarr}} Joomla\Application\AbstractApplication

===== JApplicationWeb =====

*Alt: JApplicationWeb {{rarr}} JApplicationBase {{rarr}} Joomla\Application\AbstractApplication
*Neu: JApplicationWeb {{rarr}} Joomla\Application\AbstractWebApplication {{rarr}} 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 {{JVer | 3.7}}). Weitere Informationen finden Sie unter [[S:MyLanguage/J3.x:Discover_on_which_client_your_extension_code_is_running|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). [https://github.com/joomla-framework/database])

=== 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 ===
* <noinclude>JBrowser::isSSLConnection has been removed. Use JApplicationCms::isSSLConnection (available since Joomla 3.2)</noinclude>

=== 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 siehe[https://github.com/joomla/joomla-cms/pull/16419 dieser 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).
* JFormFieldUsergroup wurde entfernt. Verwende stattdessen Joomla\CMS\Form\Field\UsergrouplistField (verfügbar seit Joomla 3.2).
* JFormFieldFilelist und JFormFieldFolderList wurden ihre Filtereigenschaften umbenannt in <code>fileFilter</code> und <code>folderFilter</code> (um die Verwendung des regulären Joomla-Filterattributs auf zurückgegebene Werte zu ermöglichen).

=== 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 Schnittstelle[https://secure.php.net/manual/en/class.arrayaccess.php ArrayAccess] 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).

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

=== Sprache ====
* Die Funktionen setTransliterator, setPluralSuffixesCallback, setIgnoredSearchWordsCallback, setLowerLimitSearchWordCallback, setUpperLimitSearchWordCallback und setSearchDisplayedCharactersNumberCallback sind nun typisiert, um ein Callable zu benötigen.
* Der <tt>"_QQ_"</tt> 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. <tt>\"</tt>)

=== 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's[https://secure.php.net/manual/en/class.sessionhandlerinterface.php SessionHandlerInterface] 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 [https://github.com/PHPMailer/PHPMailer/blob/6.0/UPGRADING.md 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 [https://jquery.com/upgrade-guide/3.0/ 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.

=== 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: [http://getbootstrap.com/docs/4.0/getting-started/introduction/]. Für weitere Informationen über Bootstrap 2.3.2: (http://getbootstrap.com/2.3.2/)

== 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.
* com_admin profile view has been removed (this appears to have been created historically due to issues accessing com_users. This is no longer the case so all user edits go through com_users edit user view in the backend)
* com_actionlogs php 5.5 backfill code has been removed and accordingly <source inline lang="php">ActionlogsHelper::getCsvData()</source> is now type hinted to return a <source inline lang="php">Generator</source> object
* Core components have had URL Routing 'Legacy' mode removed from Joomla 3.7. You should either use your .htaccess file or the redirect component to fix any internal URLs that change. You can try the 'Modern' mode in Joomla 3 by following the instructions [[S:MyLanguage/J3.x:New_Routing_System|here]]

=== Plugins ===
* The gmail authentication plugin has been removed. For more information please read [https://developer.joomla.org/news/724-removal-of-the-gmail-authentication-plugin-as-of-joomla-4-0.html this blog post]
* Recaptcha v1 support has been fully removed from the captcha plugin - this has no longer worked since Q2 2018 due to google dropping support for it.
* The Recaptcha plugin now uses google's official php library for captcha under the hood
* For plugins using the 3.x compatibility layer the name result is a protected property for both input parameters and return values. For information on the new recommended approach to plugins please read [[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
* The onContentBeforeSave event now requires the data parameter (this has been passed in \Joomla\CMS\MVC\Model\LegacyModel since 3.7 but is now passed in consistently by core extensions and used by the core Joomla content plugin)

=== Administrator Helpers ===
* JAdministratorHelper has been removed without replacement (it's been merged into JApplicationAdministrator)
* 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.

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

<noinclude>
[[Category:Compatibility{{#translation:}}]]
[[Category:Development{{#translation:}}]]
[[Category:Platform{{#translation:}}]]
[[Category:Migration{{#translation:}}]]
[[Category:Update Working Group{{#translation:}}]]
[[Category:Joomla! 4.x{{#translation:}}]]
[[Category:Joomla! 4.0{{#translation:}}]]
</noinclude>

Translations:Potential backward compatibility issues in Joomla 4/201/de

2019-10-19T18:15:07Z

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.

Potential backward compatibility issues in Joomla 4/de

2019-10-19T18:13:55Z

Jehacgn: Created page with "=== Komponenten ==="

<noinclude><languages /></noinclude>
{{incomplete}}{{RightTOC}}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.9.

== Aktualisierte Systemanforderungen ==
Die Systemanforderungen wurden wie folgt aktualisiert:
*PHP 7.2
*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.

<pre>
'STRICT_TRANS_TABLES',
'ERROR_FOR_DIVISION_BY_ZERO',
'NO_AUTO_CREATE_USER',
'NO_ENGINE_SUBSTITUTION',
</pre>

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

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

== 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 {{rarr}} JApplicationBase {{rarr}} Joomla\Application\AbstractApplication
*Neu: JApplicationCli {{rarr}} Joomla\Application\AbstractCliApplication {{rarr}} Joomla\Application\AbstractApplication

===== JApplicationWeb =====

*Alt: JApplicationWeb {{rarr}} JApplicationBase {{rarr}} Joomla\Application\AbstractApplication
*Neu: JApplicationWeb {{rarr}} Joomla\Application\AbstractWebApplication {{rarr}} 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 {{JVer | 3.7}}). Weitere Informationen finden Sie unter [[S:MyLanguage/J3.x:Discover_on_which_client_your_extension_code_is_running|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). [https://github.com/joomla-framework/database])

=== 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 ===
* <noinclude>JBrowser::isSSLConnection has been removed. Use JApplicationCms::isSSLConnection (available since Joomla 3.2)</noinclude>

=== 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 siehe[https://github.com/joomla/joomla-cms/pull/16419 dieser 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).
* JFormFieldUsergroup wurde entfernt. Verwende stattdessen Joomla\CMS\Form\Field\UsergrouplistField (verfügbar seit Joomla 3.2).
* JFormFieldFilelist und JFormFieldFolderList wurden ihre Filtereigenschaften umbenannt in <code>fileFilter</code> und <code>folderFilter</code> (um die Verwendung des regulären Joomla-Filterattributs auf zurückgegebene Werte zu ermöglichen).

=== 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 Schnittstelle[https://secure.php.net/manual/en/class.arrayaccess.php ArrayAccess] 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).

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

=== Sprache ====
* Die Funktionen setTransliterator, setPluralSuffixesCallback, setIgnoredSearchWordsCallback, setLowerLimitSearchWordCallback, setUpperLimitSearchWordCallback und setSearchDisplayedCharactersNumberCallback sind nun typisiert, um ein Callable zu benötigen.
* Der <tt>"_QQ_"</tt> 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. <tt>\"</tt>)

=== 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's[https://secure.php.net/manual/en/class.sessionhandlerinterface.php SessionHandlerInterface] 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 [https://github.com/PHPMailer/PHPMailer/blob/6.0/UPGRADING.md 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 [https://jquery.com/upgrade-guide/3.0/ 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.

=== 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: [http://getbootstrap.com/docs/4.0/getting-started/introduction/]. Für weitere Informationen über Bootstrap 2.3.2: (http://getbootstrap.com/2.3.2/)

== 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 ===
* All components have been namespaced and directories reworked accordingly. For more information about this read the tutorial on building a component in Joomla 4
* com_admin profile view has been removed (this appears to have been created historically due to issues accessing com_users. This is no longer the case so all user edits go through com_users edit user view in the backend)
* com_actionlogs php 5.5 backfill code has been removed and accordingly <source inline lang="php">ActionlogsHelper::getCsvData()</source> is now type hinted to return a <source inline lang="php">Generator</source> object
* Core components have had URL Routing 'Legacy' mode removed from Joomla 3.7. You should either use your .htaccess file or the redirect component to fix any internal URLs that change. You can try the 'Modern' mode in Joomla 3 by following the instructions [[S:MyLanguage/J3.x:New_Routing_System|here]]

=== Plugins ===
* The gmail authentication plugin has been removed. For more information please read [https://developer.joomla.org/news/724-removal-of-the-gmail-authentication-plugin-as-of-joomla-4-0.html this blog post]
* Recaptcha v1 support has been fully removed from the captcha plugin - this has no longer worked since Q2 2018 due to google dropping support for it.
* The Recaptcha plugin now uses google's official php library for captcha under the hood
* For plugins using the 3.x compatibility layer the name result is a protected property for both input parameters and return values. For information on the new recommended approach to plugins please read [[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
* The onContentBeforeSave event now requires the data parameter (this has been passed in \Joomla\CMS\MVC\Model\LegacyModel since 3.7 but is now passed in consistently by core extensions and used by the core Joomla content plugin)

=== Administrator Helpers ===
* JAdministratorHelper has been removed without replacement (it's been merged into JApplicationAdministrator)
* 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.

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

<noinclude>
[[Category:Compatibility{{#translation:}}]]
[[Category:Development{{#translation:}}]]
[[Category:Platform{{#translation:}}]]
[[Category:Migration{{#translation:}}]]
[[Category:Update Working Group{{#translation:}}]]
[[Category:Joomla! 4.x{{#translation:}}]]
[[Category:Joomla! 4.0{{#translation:}}]]
</noinclude>

Translations:Potential backward compatibility issues in Joomla 4/200/de

2019-10-19T18:13:55Z

Jehacgn: Created page with "=== Komponenten ==="

=== Komponenten ===

Potential backward compatibility issues in Joomla 4/de

2019-10-19T18:13:33Z

Jehacgn: Created page with "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"

<noinclude><languages /></noinclude>
{{incomplete}}{{RightTOC}}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.9.

== Aktualisierte Systemanforderungen ==
Die Systemanforderungen wurden wie folgt aktualisiert:
*PHP 7.2
*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.

<pre>
'STRICT_TRANS_TABLES',
'ERROR_FOR_DIVISION_BY_ZERO',
'NO_AUTO_CREATE_USER',
'NO_ENGINE_SUBSTITUTION',
</pre>

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

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

== 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 {{rarr}} JApplicationBase {{rarr}} Joomla\Application\AbstractApplication
*Neu: JApplicationCli {{rarr}} Joomla\Application\AbstractCliApplication {{rarr}} Joomla\Application\AbstractApplication

===== JApplicationWeb =====

*Alt: JApplicationWeb {{rarr}} JApplicationBase {{rarr}} Joomla\Application\AbstractApplication
*Neu: JApplicationWeb {{rarr}} Joomla\Application\AbstractWebApplication {{rarr}} 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 {{JVer | 3.7}}). Weitere Informationen finden Sie unter [[S:MyLanguage/J3.x:Discover_on_which_client_your_extension_code_is_running|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). [https://github.com/joomla-framework/database])

=== 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 ===
* <noinclude>JBrowser::isSSLConnection has been removed. Use JApplicationCms::isSSLConnection (available since Joomla 3.2)</noinclude>

=== 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 siehe[https://github.com/joomla/joomla-cms/pull/16419 dieser 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).
* JFormFieldUsergroup wurde entfernt. Verwende stattdessen Joomla\CMS\Form\Field\UsergrouplistField (verfügbar seit Joomla 3.2).
* JFormFieldFilelist und JFormFieldFolderList wurden ihre Filtereigenschaften umbenannt in <code>fileFilter</code> und <code>folderFilter</code> (um die Verwendung des regulären Joomla-Filterattributs auf zurückgegebene Werte zu ermöglichen).

=== 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 Schnittstelle[https://secure.php.net/manual/en/class.arrayaccess.php ArrayAccess] 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).

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

=== Sprache ====
* Die Funktionen setTransliterator, setPluralSuffixesCallback, setIgnoredSearchWordsCallback, setLowerLimitSearchWordCallback, setUpperLimitSearchWordCallback und setSearchDisplayedCharactersNumberCallback sind nun typisiert, um ein Callable zu benötigen.
* Der <tt>"_QQ_"</tt> 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. <tt>\"</tt>)

=== 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's[https://secure.php.net/manual/en/class.sessionhandlerinterface.php SessionHandlerInterface] 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 [https://github.com/PHPMailer/PHPMailer/blob/6.0/UPGRADING.md 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 [https://jquery.com/upgrade-guide/3.0/ 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.

=== 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: [http://getbootstrap.com/docs/4.0/getting-started/introduction/]. Für weitere Informationen über Bootstrap 2.3.2: (http://getbootstrap.com/2.3.2/)

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

=== Components ===
* All components have been namespaced and directories reworked accordingly. For more information about this read the tutorial on building a component in Joomla 4
* com_admin profile view has been removed (this appears to have been created historically due to issues accessing com_users. This is no longer the case so all user edits go through com_users edit user view in the backend)
* com_actionlogs php 5.5 backfill code has been removed and accordingly <source inline lang="php">ActionlogsHelper::getCsvData()</source> is now type hinted to return a <source inline lang="php">Generator</source> object
* Core components have had URL Routing 'Legacy' mode removed from Joomla 3.7. You should either use your .htaccess file or the redirect component to fix any internal URLs that change. You can try the 'Modern' mode in Joomla 3 by following the instructions [[S:MyLanguage/J3.x:New_Routing_System|here]]

=== Plugins ===
* The gmail authentication plugin has been removed. For more information please read [https://developer.joomla.org/news/724-removal-of-the-gmail-authentication-plugin-as-of-joomla-4-0.html this blog post]
* Recaptcha v1 support has been fully removed from the captcha plugin - this has no longer worked since Q2 2018 due to google dropping support for it.
* The Recaptcha plugin now uses google's official php library for captcha under the hood
* For plugins using the 3.x compatibility layer the name result is a protected property for both input parameters and return values. For information on the new recommended approach to plugins please read [[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
* The onContentBeforeSave event now requires the data parameter (this has been passed in \Joomla\CMS\MVC\Model\LegacyModel since 3.7 but is now passed in consistently by core extensions and used by the core Joomla content plugin)

=== Administrator Helpers ===
* JAdministratorHelper has been removed without replacement (it's been merged into JApplicationAdministrator)
* 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.

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

<noinclude>
[[Category:Compatibility{{#translation:}}]]
[[Category:Development{{#translation:}}]]
[[Category:Platform{{#translation:}}]]
[[Category:Migration{{#translation:}}]]
[[Category:Update Working Group{{#translation:}}]]
[[Category:Joomla! 4.x{{#translation:}}]]
[[Category:Joomla! 4.0{{#translation:}}]]
</noinclude>

Translations:Potential backward compatibility issues in Joomla 4/97/de

2019-10-19T18:13:32Z

Jehacgn: Created page with "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"

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

Potential backward compatibility issues in Joomla 4/de

2019-10-19T18:12:22Z

Jehacgn: Created page with "Im Bibliotheksstammordner des CMS sind keine Medien erlaubt - alle mit Joomla-Bibliotheken verbundenen Assets sollten gemäß den besten Beispielen in den Medienordner gelegt..."

<noinclude><languages /></noinclude>
{{incomplete}}{{RightTOC}}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.9.

== Aktualisierte Systemanforderungen ==
Die Systemanforderungen wurden wie folgt aktualisiert:
*PHP 7.2
*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.

<pre>
'STRICT_TRANS_TABLES',
'ERROR_FOR_DIVISION_BY_ZERO',
'NO_AUTO_CREATE_USER',
'NO_ENGINE_SUBSTITUTION',
</pre>

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

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

== 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 {{rarr}} JApplicationBase {{rarr}} Joomla\Application\AbstractApplication
*Neu: JApplicationCli {{rarr}} Joomla\Application\AbstractCliApplication {{rarr}} Joomla\Application\AbstractApplication

===== JApplicationWeb =====

*Alt: JApplicationWeb {{rarr}} JApplicationBase {{rarr}} Joomla\Application\AbstractApplication
*Neu: JApplicationWeb {{rarr}} Joomla\Application\AbstractWebApplication {{rarr}} 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 {{JVer | 3.7}}). Weitere Informationen finden Sie unter [[S:MyLanguage/J3.x:Discover_on_which_client_your_extension_code_is_running|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). [https://github.com/joomla-framework/database])

=== 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 ===
* <noinclude>JBrowser::isSSLConnection has been removed. Use JApplicationCms::isSSLConnection (available since Joomla 3.2)</noinclude>

=== 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 siehe[https://github.com/joomla/joomla-cms/pull/16419 dieser 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).
* JFormFieldUsergroup wurde entfernt. Verwende stattdessen Joomla\CMS\Form\Field\UsergrouplistField (verfügbar seit Joomla 3.2).
* JFormFieldFilelist und JFormFieldFolderList wurden ihre Filtereigenschaften umbenannt in <code>fileFilter</code> und <code>folderFilter</code> (um die Verwendung des regulären Joomla-Filterattributs auf zurückgegebene Werte zu ermöglichen).

=== 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 Schnittstelle[https://secure.php.net/manual/en/class.arrayaccess.php ArrayAccess] 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).

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

=== Sprache ====
* Die Funktionen setTransliterator, setPluralSuffixesCallback, setIgnoredSearchWordsCallback, setLowerLimitSearchWordCallback, setUpperLimitSearchWordCallback und setSearchDisplayedCharactersNumberCallback sind nun typisiert, um ein Callable zu benötigen.
* Der <tt>"_QQ_"</tt> 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. <tt>\"</tt>)

=== 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's[https://secure.php.net/manual/en/class.sessionhandlerinterface.php SessionHandlerInterface] 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 [https://github.com/PHPMailer/PHPMailer/blob/6.0/UPGRADING.md 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 [https://jquery.com/upgrade-guide/3.0/ 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.

=== 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: [http://getbootstrap.com/docs/4.0/getting-started/introduction/]. Für weitere Informationen über Bootstrap 2.3.2: (http://getbootstrap.com/2.3.2/)

== 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 ===
Removing the keychain with 4.0 has resulted in the removal of the entire Bin directory as it only contained keychain.

=== Components ===
* All components have been namespaced and directories reworked accordingly. For more information about this read the tutorial on building a component in Joomla 4
* com_admin profile view has been removed (this appears to have been created historically due to issues accessing com_users. This is no longer the case so all user edits go through com_users edit user view in the backend)
* com_actionlogs php 5.5 backfill code has been removed and accordingly <source inline lang="php">ActionlogsHelper::getCsvData()</source> is now type hinted to return a <source inline lang="php">Generator</source> object
* Core components have had URL Routing 'Legacy' mode removed from Joomla 3.7. You should either use your .htaccess file or the redirect component to fix any internal URLs that change. You can try the 'Modern' mode in Joomla 3 by following the instructions [[S:MyLanguage/J3.x:New_Routing_System|here]]

=== Plugins ===
* The gmail authentication plugin has been removed. For more information please read [https://developer.joomla.org/news/724-removal-of-the-gmail-authentication-plugin-as-of-joomla-4-0.html this blog post]
* Recaptcha v1 support has been fully removed from the captcha plugin - this has no longer worked since Q2 2018 due to google dropping support for it.
* The Recaptcha plugin now uses google's official php library for captcha under the hood
* For plugins using the 3.x compatibility layer the name result is a protected property for both input parameters and return values. For information on the new recommended approach to plugins please read [[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
* The onContentBeforeSave event now requires the data parameter (this has been passed in \Joomla\CMS\MVC\Model\LegacyModel since 3.7 but is now passed in consistently by core extensions and used by the core Joomla content plugin)

=== Administrator Helpers ===
* JAdministratorHelper has been removed without replacement (it's been merged into JApplicationAdministrator)
* 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.

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

<noinclude>
[[Category:Compatibility{{#translation:}}]]
[[Category:Development{{#translation:}}]]
[[Category:Platform{{#translation:}}]]
[[Category:Migration{{#translation:}}]]
[[Category:Update Working Group{{#translation:}}]]
[[Category:Joomla! 4.x{{#translation:}}]]
[[Category:Joomla! 4.0{{#translation:}}]]
</noinclude>

Translations:Potential backward compatibility issues in Joomla 4/160/de

2019-10-19T18:12:21Z

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.

Potential backward compatibility issues in Joomla 4/de

2019-10-19T18:09:46Z

Jehacgn: Created page with "=== Medien in Bibliotheken ==="

<noinclude><languages /></noinclude>
{{incomplete}}{{RightTOC}}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.9.

== Aktualisierte Systemanforderungen ==
Die Systemanforderungen wurden wie folgt aktualisiert:
*PHP 7.2
*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.

<pre>
'STRICT_TRANS_TABLES',
'ERROR_FOR_DIVISION_BY_ZERO',
'NO_AUTO_CREATE_USER',
'NO_ENGINE_SUBSTITUTION',
</pre>

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

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

== 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 {{rarr}} JApplicationBase {{rarr}} Joomla\Application\AbstractApplication
*Neu: JApplicationCli {{rarr}} Joomla\Application\AbstractCliApplication {{rarr}} Joomla\Application\AbstractApplication

===== JApplicationWeb =====

*Alt: JApplicationWeb {{rarr}} JApplicationBase {{rarr}} Joomla\Application\AbstractApplication
*Neu: JApplicationWeb {{rarr}} Joomla\Application\AbstractWebApplication {{rarr}} 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 {{JVer | 3.7}}). Weitere Informationen finden Sie unter [[S:MyLanguage/J3.x:Discover_on_which_client_your_extension_code_is_running|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). [https://github.com/joomla-framework/database])

=== 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 ===
* <noinclude>JBrowser::isSSLConnection has been removed. Use JApplicationCms::isSSLConnection (available since Joomla 3.2)</noinclude>

=== 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 siehe[https://github.com/joomla/joomla-cms/pull/16419 dieser 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).
* JFormFieldUsergroup wurde entfernt. Verwende stattdessen Joomla\CMS\Form\Field\UsergrouplistField (verfügbar seit Joomla 3.2).
* JFormFieldFilelist und JFormFieldFolderList wurden ihre Filtereigenschaften umbenannt in <code>fileFilter</code> und <code>folderFilter</code> (um die Verwendung des regulären Joomla-Filterattributs auf zurückgegebene Werte zu ermöglichen).

=== 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 Schnittstelle[https://secure.php.net/manual/en/class.arrayaccess.php ArrayAccess] 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).

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

=== Sprache ====
* Die Funktionen setTransliterator, setPluralSuffixesCallback, setIgnoredSearchWordsCallback, setLowerLimitSearchWordCallback, setUpperLimitSearchWordCallback und setSearchDisplayedCharactersNumberCallback sind nun typisiert, um ein Callable zu benötigen.
* Der <tt>"_QQ_"</tt> 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. <tt>\"</tt>)

=== 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's[https://secure.php.net/manual/en/class.sessionhandlerinterface.php SessionHandlerInterface] 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 [https://github.com/PHPMailer/PHPMailer/blob/6.0/UPGRADING.md 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 [https://jquery.com/upgrade-guide/3.0/ 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.

=== 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: [http://getbootstrap.com/docs/4.0/getting-started/introduction/]. Für weitere Informationen über Bootstrap 2.3.2: (http://getbootstrap.com/2.3.2/)

== Sonstiges ==

=== Medien in Bibliotheken ===
No media is allowed in the libraries root folder in the CMS - all assets associated with Joomla libraries should be put in the media folder as per best practices. Direct access is blocked with a .htaccess and web.config file in the root of the libraries directory.

=== Bin ===
Removing the keychain with 4.0 has resulted in the removal of the entire Bin directory as it only contained keychain.

=== Components ===
* All components have been namespaced and directories reworked accordingly. For more information about this read the tutorial on building a component in Joomla 4
* com_admin profile view has been removed (this appears to have been created historically due to issues accessing com_users. This is no longer the case so all user edits go through com_users edit user view in the backend)
* com_actionlogs php 5.5 backfill code has been removed and accordingly <source inline lang="php">ActionlogsHelper::getCsvData()</source> is now type hinted to return a <source inline lang="php">Generator</source> object
* Core components have had URL Routing 'Legacy' mode removed from Joomla 3.7. You should either use your .htaccess file or the redirect component to fix any internal URLs that change. You can try the 'Modern' mode in Joomla 3 by following the instructions [[S:MyLanguage/J3.x:New_Routing_System|here]]

=== Plugins ===
* The gmail authentication plugin has been removed. For more information please read [https://developer.joomla.org/news/724-removal-of-the-gmail-authentication-plugin-as-of-joomla-4-0.html this blog post]
* Recaptcha v1 support has been fully removed from the captcha plugin - this has no longer worked since Q2 2018 due to google dropping support for it.
* The Recaptcha plugin now uses google's official php library for captcha under the hood
* For plugins using the 3.x compatibility layer the name result is a protected property for both input parameters and return values. For information on the new recommended approach to plugins please read [[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
* The onContentBeforeSave event now requires the data parameter (this has been passed in \Joomla\CMS\MVC\Model\LegacyModel since 3.7 but is now passed in consistently by core extensions and used by the core Joomla content plugin)

=== Administrator Helpers ===
* JAdministratorHelper has been removed without replacement (it's been merged into JApplicationAdministrator)
* 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.

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

<noinclude>
[[Category:Compatibility{{#translation:}}]]
[[Category:Development{{#translation:}}]]
[[Category:Platform{{#translation:}}]]
[[Category:Migration{{#translation:}}]]
[[Category:Update Working Group{{#translation:}}]]
[[Category:Joomla! 4.x{{#translation:}}]]
[[Category:Joomla! 4.0{{#translation:}}]]
</noinclude>

Translations:Potential backward compatibility issues in Joomla 4/159/de

2019-10-19T18:09:45Z

Jehacgn: Created page with "=== Medien in Bibliotheken ==="

=== Medien in Bibliotheken ===

Potential backward compatibility issues in Joomla 4/de

2019-10-19T18:09:08Z

Jehacgn: Created page with "== Sonstiges =="

<noinclude><languages /></noinclude>
{{incomplete}}{{RightTOC}}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.9.

== Aktualisierte Systemanforderungen ==
Die Systemanforderungen wurden wie folgt aktualisiert:
*PHP 7.2
*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.

<pre>
'STRICT_TRANS_TABLES',
'ERROR_FOR_DIVISION_BY_ZERO',
'NO_AUTO_CREATE_USER',
'NO_ENGINE_SUBSTITUTION',
</pre>

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

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

== 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 {{rarr}} JApplicationBase {{rarr}} Joomla\Application\AbstractApplication
*Neu: JApplicationCli {{rarr}} Joomla\Application\AbstractCliApplication {{rarr}} Joomla\Application\AbstractApplication

===== JApplicationWeb =====

*Alt: JApplicationWeb {{rarr}} JApplicationBase {{rarr}} Joomla\Application\AbstractApplication
*Neu: JApplicationWeb {{rarr}} Joomla\Application\AbstractWebApplication {{rarr}} 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 {{JVer | 3.7}}). Weitere Informationen finden Sie unter [[S:MyLanguage/J3.x:Discover_on_which_client_your_extension_code_is_running|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). [https://github.com/joomla-framework/database])

=== 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 ===
* <noinclude>JBrowser::isSSLConnection has been removed. Use JApplicationCms::isSSLConnection (available since Joomla 3.2)</noinclude>

=== 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 siehe[https://github.com/joomla/joomla-cms/pull/16419 dieser 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).
* JFormFieldUsergroup wurde entfernt. Verwende stattdessen Joomla\CMS\Form\Field\UsergrouplistField (verfügbar seit Joomla 3.2).
* JFormFieldFilelist und JFormFieldFolderList wurden ihre Filtereigenschaften umbenannt in <code>fileFilter</code> und <code>folderFilter</code> (um die Verwendung des regulären Joomla-Filterattributs auf zurückgegebene Werte zu ermöglichen).

=== 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 Schnittstelle[https://secure.php.net/manual/en/class.arrayaccess.php ArrayAccess] 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).

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

=== Sprache ====
* Die Funktionen setTransliterator, setPluralSuffixesCallback, setIgnoredSearchWordsCallback, setLowerLimitSearchWordCallback, setUpperLimitSearchWordCallback und setSearchDisplayedCharactersNumberCallback sind nun typisiert, um ein Callable zu benötigen.
* Der <tt>"_QQ_"</tt> 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. <tt>\"</tt>)

=== 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's[https://secure.php.net/manual/en/class.sessionhandlerinterface.php SessionHandlerInterface] 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 [https://github.com/PHPMailer/PHPMailer/blob/6.0/UPGRADING.md 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 [https://jquery.com/upgrade-guide/3.0/ 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.

=== 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: [http://getbootstrap.com/docs/4.0/getting-started/introduction/]. Für weitere Informationen über Bootstrap 2.3.2: (http://getbootstrap.com/2.3.2/)

== Sonstiges ==

=== Media in Libraries ===
No media is allowed in the libraries root folder in the CMS - all assets associated with Joomla libraries should be put in the media folder as per best practices. Direct access is blocked with a .htaccess and web.config file in the root of the libraries directory.

=== Bin ===
Removing the keychain with 4.0 has resulted in the removal of the entire Bin directory as it only contained keychain.

=== Components ===
* All components have been namespaced and directories reworked accordingly. For more information about this read the tutorial on building a component in Joomla 4
* com_admin profile view has been removed (this appears to have been created historically due to issues accessing com_users. This is no longer the case so all user edits go through com_users edit user view in the backend)
* com_actionlogs php 5.5 backfill code has been removed and accordingly <source inline lang="php">ActionlogsHelper::getCsvData()</source> is now type hinted to return a <source inline lang="php">Generator</source> object
* Core components have had URL Routing 'Legacy' mode removed from Joomla 3.7. You should either use your .htaccess file or the redirect component to fix any internal URLs that change. You can try the 'Modern' mode in Joomla 3 by following the instructions [[S:MyLanguage/J3.x:New_Routing_System|here]]

=== Plugins ===
* The gmail authentication plugin has been removed. For more information please read [https://developer.joomla.org/news/724-removal-of-the-gmail-authentication-plugin-as-of-joomla-4-0.html this blog post]
* Recaptcha v1 support has been fully removed from the captcha plugin - this has no longer worked since Q2 2018 due to google dropping support for it.
* The Recaptcha plugin now uses google's official php library for captcha under the hood
* For plugins using the 3.x compatibility layer the name result is a protected property for both input parameters and return values. For information on the new recommended approach to plugins please read [[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
* The onContentBeforeSave event now requires the data parameter (this has been passed in \Joomla\CMS\MVC\Model\LegacyModel since 3.7 but is now passed in consistently by core extensions and used by the core Joomla content plugin)

=== Administrator Helpers ===
* JAdministratorHelper has been removed without replacement (it's been merged into JApplicationAdministrator)
* 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.

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

<noinclude>
[[Category:Compatibility{{#translation:}}]]
[[Category:Development{{#translation:}}]]
[[Category:Platform{{#translation:}}]]
[[Category:Migration{{#translation:}}]]
[[Category:Update Working Group{{#translation:}}]]
[[Category:Joomla! 4.x{{#translation:}}]]
[[Category:Joomla! 4.0{{#translation:}}]]
</noinclude>

Translations:Potential backward compatibility issues in Joomla 4/95/de

2019-10-19T18:09:07Z

Jehacgn: Created page with "== Sonstiges =="

== Sonstiges ==

Potential backward compatibility issues in Joomla 4/de

2019-10-19T18:08:41Z

Jehacgn: Created page with "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 übe..."

<noinclude><languages /></noinclude>
{{incomplete}}{{RightTOC}}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.9.

== Aktualisierte Systemanforderungen ==
Die Systemanforderungen wurden wie folgt aktualisiert:
*PHP 7.2
*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.

<pre>
'STRICT_TRANS_TABLES',
'ERROR_FOR_DIVISION_BY_ZERO',
'NO_AUTO_CREATE_USER',
'NO_ENGINE_SUBSTITUTION',
</pre>

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

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

== 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 {{rarr}} JApplicationBase {{rarr}} Joomla\Application\AbstractApplication
*Neu: JApplicationCli {{rarr}} Joomla\Application\AbstractCliApplication {{rarr}} Joomla\Application\AbstractApplication

===== JApplicationWeb =====

*Alt: JApplicationWeb {{rarr}} JApplicationBase {{rarr}} Joomla\Application\AbstractApplication
*Neu: JApplicationWeb {{rarr}} Joomla\Application\AbstractWebApplication {{rarr}} 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 {{JVer | 3.7}}). Weitere Informationen finden Sie unter [[S:MyLanguage/J3.x:Discover_on_which_client_your_extension_code_is_running|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). [https://github.com/joomla-framework/database])

=== 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 ===
* <noinclude>JBrowser::isSSLConnection has been removed. Use JApplicationCms::isSSLConnection (available since Joomla 3.2)</noinclude>

=== 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 siehe[https://github.com/joomla/joomla-cms/pull/16419 dieser 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).
* JFormFieldUsergroup wurde entfernt. Verwende stattdessen Joomla\CMS\Form\Field\UsergrouplistField (verfügbar seit Joomla 3.2).
* JFormFieldFilelist und JFormFieldFolderList wurden ihre Filtereigenschaften umbenannt in <code>fileFilter</code> und <code>folderFilter</code> (um die Verwendung des regulären Joomla-Filterattributs auf zurückgegebene Werte zu ermöglichen).

=== 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 Schnittstelle[https://secure.php.net/manual/en/class.arrayaccess.php ArrayAccess] 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).

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

=== Sprache ====
* Die Funktionen setTransliterator, setPluralSuffixesCallback, setIgnoredSearchWordsCallback, setLowerLimitSearchWordCallback, setUpperLimitSearchWordCallback und setSearchDisplayedCharactersNumberCallback sind nun typisiert, um ein Callable zu benötigen.
* Der <tt>"_QQ_"</tt> 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. <tt>\"</tt>)

=== 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's[https://secure.php.net/manual/en/class.sessionhandlerinterface.php SessionHandlerInterface] 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 [https://github.com/PHPMailer/PHPMailer/blob/6.0/UPGRADING.md 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 [https://jquery.com/upgrade-guide/3.0/ 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.

=== 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: [http://getbootstrap.com/docs/4.0/getting-started/introduction/]. Für weitere Informationen über Bootstrap 2.3.2: (http://getbootstrap.com/2.3.2/)

== Other ==

=== Media in Libraries ===
No media is allowed in the libraries root folder in the CMS - all assets associated with Joomla libraries should be put in the media folder as per best practices. Direct access is blocked with a .htaccess and web.config file in the root of the libraries directory.

=== Bin ===
Removing the keychain with 4.0 has resulted in the removal of the entire Bin directory as it only contained keychain.

=== Components ===
* All components have been namespaced and directories reworked accordingly. For more information about this read the tutorial on building a component in Joomla 4
* com_admin profile view has been removed (this appears to have been created historically due to issues accessing com_users. This is no longer the case so all user edits go through com_users edit user view in the backend)
* com_actionlogs php 5.5 backfill code has been removed and accordingly <source inline lang="php">ActionlogsHelper::getCsvData()</source> is now type hinted to return a <source inline lang="php">Generator</source> object
* Core components have had URL Routing 'Legacy' mode removed from Joomla 3.7. You should either use your .htaccess file or the redirect component to fix any internal URLs that change. You can try the 'Modern' mode in Joomla 3 by following the instructions [[S:MyLanguage/J3.x:New_Routing_System|here]]

=== Plugins ===
* The gmail authentication plugin has been removed. For more information please read [https://developer.joomla.org/news/724-removal-of-the-gmail-authentication-plugin-as-of-joomla-4-0.html this blog post]
* Recaptcha v1 support has been fully removed from the captcha plugin - this has no longer worked since Q2 2018 due to google dropping support for it.
* The Recaptcha plugin now uses google's official php library for captcha under the hood
* For plugins using the 3.x compatibility layer the name result is a protected property for both input parameters and return values. For information on the new recommended approach to plugins please read [[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
* The onContentBeforeSave event now requires the data parameter (this has been passed in \Joomla\CMS\MVC\Model\LegacyModel since 3.7 but is now passed in consistently by core extensions and used by the core Joomla content plugin)

=== Administrator Helpers ===
* JAdministratorHelper has been removed without replacement (it's been merged into JApplicationAdministrator)
* 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.

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

<noinclude>
[[Category:Compatibility{{#translation:}}]]
[[Category:Development{{#translation:}}]]
[[Category:Platform{{#translation:}}]]
[[Category:Migration{{#translation:}}]]
[[Category:Update Working Group{{#translation:}}]]
[[Category:Joomla! 4.x{{#translation:}}]]
[[Category:Joomla! 4.0{{#translation:}}]]
</noinclude>

Translations:Potential backward compatibility issues in Joomla 4/158/de

2019-10-19T18:08:41Z

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: [http://getbootstrap.com/docs/4.0/getting-started/introduction/]. Für weitere Informationen über Bootstrap 2.3.2: (http://getbootstrap.com/2.3.2/)

Translations:Potential backward compatibility issues in Joomla 4/90/de

2019-10-19T18:07:39Z

Jehacgn: Created page with "== Templates =="

== Templates ==

Potential backward compatibility issues in Joomla 4/de

2019-10-19T18:07:17Z

Jehacgn: Created page with "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 wur..."

<noinclude><languages /></noinclude>
{{incomplete}}{{RightTOC}}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.9.

== Aktualisierte Systemanforderungen ==
Die Systemanforderungen wurden wie folgt aktualisiert:
*PHP 7.2
*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.

<pre>
'STRICT_TRANS_TABLES',
'ERROR_FOR_DIVISION_BY_ZERO',
'NO_AUTO_CREATE_USER',
'NO_ENGINE_SUBSTITUTION',
</pre>

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

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

== 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 {{rarr}} JApplicationBase {{rarr}} Joomla\Application\AbstractApplication
*Neu: JApplicationCli {{rarr}} Joomla\Application\AbstractCliApplication {{rarr}} Joomla\Application\AbstractApplication

===== JApplicationWeb =====

*Alt: JApplicationWeb {{rarr}} JApplicationBase {{rarr}} Joomla\Application\AbstractApplication
*Neu: JApplicationWeb {{rarr}} Joomla\Application\AbstractWebApplication {{rarr}} 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 {{JVer | 3.7}}). Weitere Informationen finden Sie unter [[S:MyLanguage/J3.x:Discover_on_which_client_your_extension_code_is_running|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). [https://github.com/joomla-framework/database])

=== 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 ===
* <noinclude>JBrowser::isSSLConnection has been removed. Use JApplicationCms::isSSLConnection (available since Joomla 3.2)</noinclude>

=== 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 siehe[https://github.com/joomla/joomla-cms/pull/16419 dieser 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).
* JFormFieldUsergroup wurde entfernt. Verwende stattdessen Joomla\CMS\Form\Field\UsergrouplistField (verfügbar seit Joomla 3.2).
* JFormFieldFilelist und JFormFieldFolderList wurden ihre Filtereigenschaften umbenannt in <code>fileFilter</code> und <code>folderFilter</code> (um die Verwendung des regulären Joomla-Filterattributs auf zurückgegebene Werte zu ermöglichen).

=== 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 Schnittstelle[https://secure.php.net/manual/en/class.arrayaccess.php ArrayAccess] 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).

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

=== Sprache ====
* Die Funktionen setTransliterator, setPluralSuffixesCallback, setIgnoredSearchWordsCallback, setLowerLimitSearchWordCallback, setUpperLimitSearchWordCallback und setSearchDisplayedCharactersNumberCallback sind nun typisiert, um ein Callable zu benötigen.
* Der <tt>"_QQ_"</tt> 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. <tt>\"</tt>)

=== 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's[https://secure.php.net/manual/en/class.sessionhandlerinterface.php SessionHandlerInterface] 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 [https://github.com/PHPMailer/PHPMailer/blob/6.0/UPGRADING.md 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 [https://jquery.com/upgrade-guide/3.0/ 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.

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

As a consequence, all extensions must migrate to the new Bootstrap 4 style, away from the current Bootstrap 2.3.2 implementation. For more information about Bootstrap 4: [http://getbootstrap.com/docs/4.0/getting-started/introduction/]. For more information about Bootstrap 2.3.2: [http://getbootstrap.com/2.3.2/]

== Other ==

=== Media in Libraries ===
No media is allowed in the libraries root folder in the CMS - all assets associated with Joomla libraries should be put in the media folder as per best practices. Direct access is blocked with a .htaccess and web.config file in the root of the libraries directory.

=== Bin ===
Removing the keychain with 4.0 has resulted in the removal of the entire Bin directory as it only contained keychain.

=== Components ===
* All components have been namespaced and directories reworked accordingly. For more information about this read the tutorial on building a component in Joomla 4
* com_admin profile view has been removed (this appears to have been created historically due to issues accessing com_users. This is no longer the case so all user edits go through com_users edit user view in the backend)
* com_actionlogs php 5.5 backfill code has been removed and accordingly <source inline lang="php">ActionlogsHelper::getCsvData()</source> is now type hinted to return a <source inline lang="php">Generator</source> object
* Core components have had URL Routing 'Legacy' mode removed from Joomla 3.7. You should either use your .htaccess file or the redirect component to fix any internal URLs that change. You can try the 'Modern' mode in Joomla 3 by following the instructions [[S:MyLanguage/J3.x:New_Routing_System|here]]

=== Plugins ===
* The gmail authentication plugin has been removed. For more information please read [https://developer.joomla.org/news/724-removal-of-the-gmail-authentication-plugin-as-of-joomla-4-0.html this blog post]
* Recaptcha v1 support has been fully removed from the captcha plugin - this has no longer worked since Q2 2018 due to google dropping support for it.
* The Recaptcha plugin now uses google's official php library for captcha under the hood
* For plugins using the 3.x compatibility layer the name result is a protected property for both input parameters and return values. For information on the new recommended approach to plugins please read [[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
* The onContentBeforeSave event now requires the data parameter (this has been passed in \Joomla\CMS\MVC\Model\LegacyModel since 3.7 but is now passed in consistently by core extensions and used by the core Joomla content plugin)

=== Administrator Helpers ===
* JAdministratorHelper has been removed without replacement (it's been merged into JApplicationAdministrator)
* 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.

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

<noinclude>
[[Category:Compatibility{{#translation:}}]]
[[Category:Development{{#translation:}}]]
[[Category:Platform{{#translation:}}]]
[[Category:Migration{{#translation:}}]]
[[Category:Update Working Group{{#translation:}}]]
[[Category:Joomla! 4.x{{#translation:}}]]
[[Category:Joomla! 4.0{{#translation:}}]]
</noinclude>

Translations:Potential backward compatibility issues in Joomla 4/86/de

2019-10-19T18:07:17Z

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.

Potential backward compatibility issues in Joomla 4/de

2019-10-19T17:21:41Z

Jehacgn: Created page with "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 F..."

<noinclude><languages /></noinclude>
{{incomplete}}{{RightTOC}}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.9.

== Aktualisierte Systemanforderungen ==
Die Systemanforderungen wurden wie folgt aktualisiert:
*PHP 7.2
*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.

<pre>
'STRICT_TRANS_TABLES',
'ERROR_FOR_DIVISION_BY_ZERO',
'NO_AUTO_CREATE_USER',
'NO_ENGINE_SUBSTITUTION',
</pre>

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

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

== 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 {{rarr}} JApplicationBase {{rarr}} Joomla\Application\AbstractApplication
*Neu: JApplicationCli {{rarr}} Joomla\Application\AbstractCliApplication {{rarr}} Joomla\Application\AbstractApplication

===== JApplicationWeb =====

*Alt: JApplicationWeb {{rarr}} JApplicationBase {{rarr}} Joomla\Application\AbstractApplication
*Neu: JApplicationWeb {{rarr}} Joomla\Application\AbstractWebApplication {{rarr}} 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 {{JVer | 3.7}}). Weitere Informationen finden Sie unter [[S:MyLanguage/J3.x:Discover_on_which_client_your_extension_code_is_running|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). [https://github.com/joomla-framework/database])

=== 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 ===
* <noinclude>JBrowser::isSSLConnection has been removed. Use JApplicationCms::isSSLConnection (available since Joomla 3.2)</noinclude>

=== 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 siehe[https://github.com/joomla/joomla-cms/pull/16419 dieser 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).
* JFormFieldUsergroup wurde entfernt. Verwende stattdessen Joomla\CMS\Form\Field\UsergrouplistField (verfügbar seit Joomla 3.2).
* JFormFieldFilelist und JFormFieldFolderList wurden ihre Filtereigenschaften umbenannt in <code>fileFilter</code> und <code>folderFilter</code> (um die Verwendung des regulären Joomla-Filterattributs auf zurückgegebene Werte zu ermöglichen).

=== 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 Schnittstelle[https://secure.php.net/manual/en/class.arrayaccess.php ArrayAccess] 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).

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

=== Sprache ====
* Die Funktionen setTransliterator, setPluralSuffixesCallback, setIgnoredSearchWordsCallback, setLowerLimitSearchWordCallback, setUpperLimitSearchWordCallback und setSearchDisplayedCharactersNumberCallback sind nun typisiert, um ein Callable zu benötigen.
* Der <tt>"_QQ_"</tt> 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. <tt>\"</tt>)

=== 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's[https://secure.php.net/manual/en/class.sessionhandlerinterface.php SessionHandlerInterface] 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 [https://github.com/PHPMailer/PHPMailer/blob/6.0/UPGRADING.md den Upgrade-Leitfaden]. für relevante Änderungen.

=== PHPUTF8 ===
At Joomla! 3.4, the PHPUTF8 library lived in two locations in the Joomla! package; `libraries/phputf8` and `libraries/vendor/joomla/string/src/phputf8`. In Joomla! 4.0, the copy of the library in `libraries/phputf8` has been removed. The Joomla\String\StringHelper class exposes many of the library's functions and the Composer autoloader definition imports much of the library as well, however, if you need a feature that is not already included then you should import the required functions from the `libraries/vendor/joomla/string/src/phputf8` path.

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

=== jQuery ===
Joomla! 4.0 wird mit jQuery 3 ausgeliefert. Bitte lese [https://jquery.com/upgrade-guide/3.0/ 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.

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

As a consequence, all extensions must migrate to the new Bootstrap 4 style, away from the current Bootstrap 2.3.2 implementation. For more information about Bootstrap 4: [http://getbootstrap.com/docs/4.0/getting-started/introduction/]. For more information about Bootstrap 2.3.2: [http://getbootstrap.com/2.3.2/]

== Other ==

=== Media in Libraries ===
No media is allowed in the libraries root folder in the CMS - all assets associated with Joomla libraries should be put in the media folder as per best practices. Direct access is blocked with a .htaccess and web.config file in the root of the libraries directory.

=== Bin ===
Removing the keychain with 4.0 has resulted in the removal of the entire Bin directory as it only contained keychain.

=== Components ===
* All components have been namespaced and directories reworked accordingly. For more information about this read the tutorial on building a component in Joomla 4
* com_admin profile view has been removed (this appears to have been created historically due to issues accessing com_users. This is no longer the case so all user edits go through com_users edit user view in the backend)
* com_actionlogs php 5.5 backfill code has been removed and accordingly <source inline lang="php">ActionlogsHelper::getCsvData()</source> is now type hinted to return a <source inline lang="php">Generator</source> object
* Core components have had URL Routing 'Legacy' mode removed from Joomla 3.7. You should either use your .htaccess file or the redirect component to fix any internal URLs that change. You can try the 'Modern' mode in Joomla 3 by following the instructions [[S:MyLanguage/J3.x:New_Routing_System|here]]

=== Plugins ===
* The gmail authentication plugin has been removed. For more information please read [https://developer.joomla.org/news/724-removal-of-the-gmail-authentication-plugin-as-of-joomla-4-0.html this blog post]
* Recaptcha v1 support has been fully removed from the captcha plugin - this has no longer worked since Q2 2018 due to google dropping support for it.
* The Recaptcha plugin now uses google's official php library for captcha under the hood
* For plugins using the 3.x compatibility layer the name result is a protected property for both input parameters and return values. For information on the new recommended approach to plugins please read [[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
* The onContentBeforeSave event now requires the data parameter (this has been passed in \Joomla\CMS\MVC\Model\LegacyModel since 3.7 but is now passed in consistently by core extensions and used by the core Joomla content plugin)

=== Administrator Helpers ===
* JAdministratorHelper has been removed without replacement (it's been merged into JApplicationAdministrator)
* 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.

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

<noinclude>
[[Category:Compatibility{{#translation:}}]]
[[Category:Development{{#translation:}}]]
[[Category:Platform{{#translation:}}]]
[[Category:Migration{{#translation:}}]]
[[Category:Update Working Group{{#translation:}}]]
[[Category:Joomla! 4.x{{#translation:}}]]
[[Category:Joomla! 4.0{{#translation:}}]]
</noinclude>

Translations:Potential backward compatibility issues in Joomla 4/91/de

2019-10-19T17:21:40Z

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.

Potential backward compatibility issues in Joomla 4/de

2019-10-19T17:20:20Z

Jehacgn: Created page with "FOF 2.x wurde entfernt."

<noinclude><languages /></noinclude>
{{incomplete}}{{RightTOC}}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.9.

== Aktualisierte Systemanforderungen ==
Die Systemanforderungen wurden wie folgt aktualisiert:
*PHP 7.2
*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.

<pre>
'STRICT_TRANS_TABLES',
'ERROR_FOR_DIVISION_BY_ZERO',
'NO_AUTO_CREATE_USER',
'NO_ENGINE_SUBSTITUTION',
</pre>

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

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

== 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 {{rarr}} JApplicationBase {{rarr}} Joomla\Application\AbstractApplication
*Neu: JApplicationCli {{rarr}} Joomla\Application\AbstractCliApplication {{rarr}} Joomla\Application\AbstractApplication

===== JApplicationWeb =====

*Alt: JApplicationWeb {{rarr}} JApplicationBase {{rarr}} Joomla\Application\AbstractApplication
*Neu: JApplicationWeb {{rarr}} Joomla\Application\AbstractWebApplication {{rarr}} 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 {{JVer | 3.7}}). Weitere Informationen finden Sie unter [[S:MyLanguage/J3.x:Discover_on_which_client_your_extension_code_is_running|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). [https://github.com/joomla-framework/database])

=== 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 ===
* <noinclude>JBrowser::isSSLConnection has been removed. Use JApplicationCms::isSSLConnection (available since Joomla 3.2)</noinclude>

=== 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 siehe[https://github.com/joomla/joomla-cms/pull/16419 dieser 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).
* JFormFieldUsergroup wurde entfernt. Verwende stattdessen Joomla\CMS\Form\Field\UsergrouplistField (verfügbar seit Joomla 3.2).
* JFormFieldFilelist und JFormFieldFolderList wurden ihre Filtereigenschaften umbenannt in <code>fileFilter</code> und <code>folderFilter</code> (um die Verwendung des regulären Joomla-Filterattributs auf zurückgegebene Werte zu ermöglichen).

=== 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 Schnittstelle[https://secure.php.net/manual/en/class.arrayaccess.php ArrayAccess] 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).

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

=== Sprache ====
* Die Funktionen setTransliterator, setPluralSuffixesCallback, setIgnoredSearchWordsCallback, setLowerLimitSearchWordCallback, setUpperLimitSearchWordCallback und setSearchDisplayedCharactersNumberCallback sind nun typisiert, um ein Callable zu benötigen.
* Der <tt>"_QQ_"</tt> 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. <tt>\"</tt>)

=== 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's[https://secure.php.net/manual/en/class.sessionhandlerinterface.php SessionHandlerInterface] 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 [https://github.com/PHPMailer/PHPMailer/blob/6.0/UPGRADING.md den Upgrade-Leitfaden]. für relevante Änderungen.

=== PHPUTF8 ===
At Joomla! 3.4, the PHPUTF8 library lived in two locations in the Joomla! package; `libraries/phputf8` and `libraries/vendor/joomla/string/src/phputf8`. In Joomla! 4.0, the copy of the library in `libraries/phputf8` has been removed. The Joomla\String\StringHelper class exposes many of the library's functions and the Composer autoloader definition imports much of the library as well, however, if you need a feature that is not already included then you should import the required functions from the `libraries/vendor/joomla/string/src/phputf8` path.

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

=== jQuery ===
Joomla! 4.0 wird mit jQuery 3 ausgeliefert. Bitte lese [https://jquery.com/upgrade-guide/3.0/ 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.

=== 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 ==
All the Joomla! 3 templates - ISIS and Hathor in the backend, and protostar and Beeze in the frontend are no longer supported. The new 4.0 backend template is called Atum and the frontend template is called Cassiopeia.

As a consequence, all extensions must migrate to the new Bootstrap 4 style, away from the current Bootstrap 2.3.2 implementation. For more information about Bootstrap 4: [http://getbootstrap.com/docs/4.0/getting-started/introduction/]. For more information about Bootstrap 2.3.2: [http://getbootstrap.com/2.3.2/]

== Other ==

=== Media in Libraries ===
No media is allowed in the libraries root folder in the CMS - all assets associated with Joomla libraries should be put in the media folder as per best practices. Direct access is blocked with a .htaccess and web.config file in the root of the libraries directory.

=== Bin ===
Removing the keychain with 4.0 has resulted in the removal of the entire Bin directory as it only contained keychain.

=== Components ===
* All components have been namespaced and directories reworked accordingly. For more information about this read the tutorial on building a component in Joomla 4
* com_admin profile view has been removed (this appears to have been created historically due to issues accessing com_users. This is no longer the case so all user edits go through com_users edit user view in the backend)
* com_actionlogs php 5.5 backfill code has been removed and accordingly <source inline lang="php">ActionlogsHelper::getCsvData()</source> is now type hinted to return a <source inline lang="php">Generator</source> object
* Core components have had URL Routing 'Legacy' mode removed from Joomla 3.7. You should either use your .htaccess file or the redirect component to fix any internal URLs that change. You can try the 'Modern' mode in Joomla 3 by following the instructions [[S:MyLanguage/J3.x:New_Routing_System|here]]

=== Plugins ===
* The gmail authentication plugin has been removed. For more information please read [https://developer.joomla.org/news/724-removal-of-the-gmail-authentication-plugin-as-of-joomla-4-0.html this blog post]
* Recaptcha v1 support has been fully removed from the captcha plugin - this has no longer worked since Q2 2018 due to google dropping support for it.
* The Recaptcha plugin now uses google's official php library for captcha under the hood
* For plugins using the 3.x compatibility layer the name result is a protected property for both input parameters and return values. For information on the new recommended approach to plugins please read [[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
* The onContentBeforeSave event now requires the data parameter (this has been passed in \Joomla\CMS\MVC\Model\LegacyModel since 3.7 but is now passed in consistently by core extensions and used by the core Joomla content plugin)

=== Administrator Helpers ===
* JAdministratorHelper has been removed without replacement (it's been merged into JApplicationAdministrator)
* 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.

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

<noinclude>
[[Category:Compatibility{{#translation:}}]]
[[Category:Development{{#translation:}}]]
[[Category:Platform{{#translation:}}]]
[[Category:Migration{{#translation:}}]]
[[Category:Update Working Group{{#translation:}}]]
[[Category:Joomla! 4.x{{#translation:}}]]
[[Category:Joomla! 4.0{{#translation:}}]]
</noinclude>

Translations:Potential backward compatibility issues in Joomla 4/157/de

2019-10-19T17:20:19Z

Jehacgn: Created page with "FOF 2.x wurde entfernt."

FOF 2.x wurde entfernt.

Potential backward compatibility issues in Joomla 4/de

2019-10-19T17:19:53Z

Jehacgn: Created page with "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 BS..."

<noinclude><languages /></noinclude>
{{incomplete}}{{RightTOC}}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.9.

== Aktualisierte Systemanforderungen ==
Die Systemanforderungen wurden wie folgt aktualisiert:
*PHP 7.2
*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.

<pre>
'STRICT_TRANS_TABLES',
'ERROR_FOR_DIVISION_BY_ZERO',
'NO_AUTO_CREATE_USER',
'NO_ENGINE_SUBSTITUTION',
</pre>

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

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

== 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 {{rarr}} JApplicationBase {{rarr}} Joomla\Application\AbstractApplication
*Neu: JApplicationCli {{rarr}} Joomla\Application\AbstractCliApplication {{rarr}} Joomla\Application\AbstractApplication

===== JApplicationWeb =====

*Alt: JApplicationWeb {{rarr}} JApplicationBase {{rarr}} Joomla\Application\AbstractApplication
*Neu: JApplicationWeb {{rarr}} Joomla\Application\AbstractWebApplication {{rarr}} 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 {{JVer | 3.7}}). Weitere Informationen finden Sie unter [[S:MyLanguage/J3.x:Discover_on_which_client_your_extension_code_is_running|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). [https://github.com/joomla-framework/database])

=== 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 ===
* <noinclude>JBrowser::isSSLConnection has been removed. Use JApplicationCms::isSSLConnection (available since Joomla 3.2)</noinclude>

=== 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 siehe[https://github.com/joomla/joomla-cms/pull/16419 dieser 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).
* JFormFieldUsergroup wurde entfernt. Verwende stattdessen Joomla\CMS\Form\Field\UsergrouplistField (verfügbar seit Joomla 3.2).
* JFormFieldFilelist und JFormFieldFolderList wurden ihre Filtereigenschaften umbenannt in <code>fileFilter</code> und <code>folderFilter</code> (um die Verwendung des regulären Joomla-Filterattributs auf zurückgegebene Werte zu ermöglichen).

=== 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 Schnittstelle[https://secure.php.net/manual/en/class.arrayaccess.php ArrayAccess] 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).

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

=== Sprache ====
* Die Funktionen setTransliterator, setPluralSuffixesCallback, setIgnoredSearchWordsCallback, setLowerLimitSearchWordCallback, setUpperLimitSearchWordCallback und setSearchDisplayedCharactersNumberCallback sind nun typisiert, um ein Callable zu benötigen.
* Der <tt>"_QQ_"</tt> 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. <tt>\"</tt>)

=== 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's[https://secure.php.net/manual/en/class.sessionhandlerinterface.php SessionHandlerInterface] 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 [https://github.com/PHPMailer/PHPMailer/blob/6.0/UPGRADING.md den Upgrade-Leitfaden]. für relevante Änderungen.

=== PHPUTF8 ===
At Joomla! 3.4, the PHPUTF8 library lived in two locations in the Joomla! package; `libraries/phputf8` and `libraries/vendor/joomla/string/src/phputf8`. In Joomla! 4.0, the copy of the library in `libraries/phputf8` has been removed. The Joomla\String\StringHelper class exposes many of the library's functions and the Composer autoloader definition imports much of the library as well, however, if you need a feature that is not already included then you should import the required functions from the `libraries/vendor/joomla/string/src/phputf8` path.

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

=== jQuery ===
Joomla! 4.0 wird mit jQuery 3 ausgeliefert. Bitte lese [https://jquery.com/upgrade-guide/3.0/ 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.

=== 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 has been removed.

== Templates ==
All the Joomla! 3 templates - ISIS and Hathor in the backend, and protostar and Beeze in the frontend are no longer supported. The new 4.0 backend template is called Atum and the frontend template is called Cassiopeia.

As a consequence, all extensions must migrate to the new Bootstrap 4 style, away from the current Bootstrap 2.3.2 implementation. For more information about Bootstrap 4: [http://getbootstrap.com/docs/4.0/getting-started/introduction/]. For more information about Bootstrap 2.3.2: [http://getbootstrap.com/2.3.2/]

== Other ==

=== Media in Libraries ===
No media is allowed in the libraries root folder in the CMS - all assets associated with Joomla libraries should be put in the media folder as per best practices. Direct access is blocked with a .htaccess and web.config file in the root of the libraries directory.

=== Bin ===
Removing the keychain with 4.0 has resulted in the removal of the entire Bin directory as it only contained keychain.

=== Components ===
* All components have been namespaced and directories reworked accordingly. For more information about this read the tutorial on building a component in Joomla 4
* com_admin profile view has been removed (this appears to have been created historically due to issues accessing com_users. This is no longer the case so all user edits go through com_users edit user view in the backend)
* com_actionlogs php 5.5 backfill code has been removed and accordingly <source inline lang="php">ActionlogsHelper::getCsvData()</source> is now type hinted to return a <source inline lang="php">Generator</source> object
* Core components have had URL Routing 'Legacy' mode removed from Joomla 3.7. You should either use your .htaccess file or the redirect component to fix any internal URLs that change. You can try the 'Modern' mode in Joomla 3 by following the instructions [[S:MyLanguage/J3.x:New_Routing_System|here]]

=== Plugins ===
* The gmail authentication plugin has been removed. For more information please read [https://developer.joomla.org/news/724-removal-of-the-gmail-authentication-plugin-as-of-joomla-4-0.html this blog post]
* Recaptcha v1 support has been fully removed from the captcha plugin - this has no longer worked since Q2 2018 due to google dropping support for it.
* The Recaptcha plugin now uses google's official php library for captcha under the hood
* For plugins using the 3.x compatibility layer the name result is a protected property for both input parameters and return values. For information on the new recommended approach to plugins please read [[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
* The onContentBeforeSave event now requires the data parameter (this has been passed in \Joomla\CMS\MVC\Model\LegacyModel since 3.7 but is now passed in consistently by core extensions and used by the core Joomla content plugin)

=== Administrator Helpers ===
* JAdministratorHelper has been removed without replacement (it's been merged into JApplicationAdministrator)
* 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.

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

<noinclude>
[[Category:Compatibility{{#translation:}}]]
[[Category:Development{{#translation:}}]]
[[Category:Platform{{#translation:}}]]
[[Category:Migration{{#translation:}}]]
[[Category:Update Working Group{{#translation:}}]]
[[Category:Joomla! 4.x{{#translation:}}]]
[[Category:Joomla! 4.0{{#translation:}}]]
</noinclude>

Translations:Potential backward compatibility issues in Joomla 4/89/de

2019-10-19T17:19:53Z

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)

Potential backward compatibility issues in Joomla 4/de

2019-10-19T17:19:14Z

Jehacgn: Created page with "Joomla! 4.0 wird mit jQuery 3 ausgeliefert. Bitte lese [https://jquery.com/upgrade-guide/3.0/ den Upgrade-Leitfaden] für relevante Änderungen. Beachte dass wir jQuery Migra..."

<noinclude><languages /></noinclude>
{{incomplete}}{{RightTOC}}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.9.

== Aktualisierte Systemanforderungen ==
Die Systemanforderungen wurden wie folgt aktualisiert:
*PHP 7.2
*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.

<pre>
'STRICT_TRANS_TABLES',
'ERROR_FOR_DIVISION_BY_ZERO',
'NO_AUTO_CREATE_USER',
'NO_ENGINE_SUBSTITUTION',
</pre>

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

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

== 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 {{rarr}} JApplicationBase {{rarr}} Joomla\Application\AbstractApplication
*Neu: JApplicationCli {{rarr}} Joomla\Application\AbstractCliApplication {{rarr}} Joomla\Application\AbstractApplication

===== JApplicationWeb =====

*Alt: JApplicationWeb {{rarr}} JApplicationBase {{rarr}} Joomla\Application\AbstractApplication
*Neu: JApplicationWeb {{rarr}} Joomla\Application\AbstractWebApplication {{rarr}} 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 {{JVer | 3.7}}). Weitere Informationen finden Sie unter [[S:MyLanguage/J3.x:Discover_on_which_client_your_extension_code_is_running|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). [https://github.com/joomla-framework/database])

=== 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 ===
* <noinclude>JBrowser::isSSLConnection has been removed. Use JApplicationCms::isSSLConnection (available since Joomla 3.2)</noinclude>

=== 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 siehe[https://github.com/joomla/joomla-cms/pull/16419 dieser 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).
* JFormFieldUsergroup wurde entfernt. Verwende stattdessen Joomla\CMS\Form\Field\UsergrouplistField (verfügbar seit Joomla 3.2).
* JFormFieldFilelist und JFormFieldFolderList wurden ihre Filtereigenschaften umbenannt in <code>fileFilter</code> und <code>folderFilter</code> (um die Verwendung des regulären Joomla-Filterattributs auf zurückgegebene Werte zu ermöglichen).

=== 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 Schnittstelle[https://secure.php.net/manual/en/class.arrayaccess.php ArrayAccess] 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).

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

=== Sprache ====
* Die Funktionen setTransliterator, setPluralSuffixesCallback, setIgnoredSearchWordsCallback, setLowerLimitSearchWordCallback, setUpperLimitSearchWordCallback und setSearchDisplayedCharactersNumberCallback sind nun typisiert, um ein Callable zu benötigen.
* Der <tt>"_QQ_"</tt> 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. <tt>\"</tt>)

=== 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's[https://secure.php.net/manual/en/class.sessionhandlerinterface.php SessionHandlerInterface] 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 [https://github.com/PHPMailer/PHPMailer/blob/6.0/UPGRADING.md den Upgrade-Leitfaden]. für relevante Änderungen.

=== PHPUTF8 ===
At Joomla! 3.4, the PHPUTF8 library lived in two locations in the Joomla! package; `libraries/phputf8` and `libraries/vendor/joomla/string/src/phputf8`. In Joomla! 4.0, the copy of the library in `libraries/phputf8` has been removed. The Joomla\String\StringHelper class exposes many of the library's functions and the Composer autoloader definition imports much of the library as well, however, if you need a feature that is not already included then you should import the required functions from the `libraries/vendor/joomla/string/src/phputf8` path.

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

=== jQuery ===
Joomla! 4.0 wird mit jQuery 3 ausgeliefert. Bitte lese [https://jquery.com/upgrade-guide/3.0/ 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.

=== Bootstrap ===
Joomla! 4.0 ships with Bootstrap 4. Bootstrap 2.3.2 has been removed, however we have left some BS2 classes in to ease the migration (e.g. The old BS2 element-invisible still exists for screenreaders)

=== FOF ===
FOF 2.x has been removed.

== Templates ==
All the Joomla! 3 templates - ISIS and Hathor in the backend, and protostar and Beeze in the frontend are no longer supported. The new 4.0 backend template is called Atum and the frontend template is called Cassiopeia.

As a consequence, all extensions must migrate to the new Bootstrap 4 style, away from the current Bootstrap 2.3.2 implementation. For more information about Bootstrap 4: [http://getbootstrap.com/docs/4.0/getting-started/introduction/]. For more information about Bootstrap 2.3.2: [http://getbootstrap.com/2.3.2/]

== Other ==

=== Media in Libraries ===
No media is allowed in the libraries root folder in the CMS - all assets associated with Joomla libraries should be put in the media folder as per best practices. Direct access is blocked with a .htaccess and web.config file in the root of the libraries directory.

=== Bin ===
Removing the keychain with 4.0 has resulted in the removal of the entire Bin directory as it only contained keychain.

=== Components ===
* All components have been namespaced and directories reworked accordingly. For more information about this read the tutorial on building a component in Joomla 4
* com_admin profile view has been removed (this appears to have been created historically due to issues accessing com_users. This is no longer the case so all user edits go through com_users edit user view in the backend)
* com_actionlogs php 5.5 backfill code has been removed and accordingly <source inline lang="php">ActionlogsHelper::getCsvData()</source> is now type hinted to return a <source inline lang="php">Generator</source> object
* Core components have had URL Routing 'Legacy' mode removed from Joomla 3.7. You should either use your .htaccess file or the redirect component to fix any internal URLs that change. You can try the 'Modern' mode in Joomla 3 by following the instructions [[S:MyLanguage/J3.x:New_Routing_System|here]]

=== Plugins ===
* The gmail authentication plugin has been removed. For more information please read [https://developer.joomla.org/news/724-removal-of-the-gmail-authentication-plugin-as-of-joomla-4-0.html this blog post]
* Recaptcha v1 support has been fully removed from the captcha plugin - this has no longer worked since Q2 2018 due to google dropping support for it.
* The Recaptcha plugin now uses google's official php library for captcha under the hood
* For plugins using the 3.x compatibility layer the name result is a protected property for both input parameters and return values. For information on the new recommended approach to plugins please read [[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
* The onContentBeforeSave event now requires the data parameter (this has been passed in \Joomla\CMS\MVC\Model\LegacyModel since 3.7 but is now passed in consistently by core extensions and used by the core Joomla content plugin)

=== Administrator Helpers ===
* JAdministratorHelper has been removed without replacement (it's been merged into JApplicationAdministrator)
* 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.

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

<noinclude>
[[Category:Compatibility{{#translation:}}]]
[[Category:Development{{#translation:}}]]
[[Category:Platform{{#translation:}}]]
[[Category:Migration{{#translation:}}]]
[[Category:Update Working Group{{#translation:}}]]
[[Category:Joomla! 4.x{{#translation:}}]]
[[Category:Joomla! 4.0{{#translation:}}]]
</noinclude>

Translations:Potential backward compatibility issues in Joomla 4/88/de

2019-10-19T17:19:13Z

Joomla! 4.0 wird mit jQuery 3 ausgeliefert. Bitte lese [https://jquery.com/upgrade-guide/3.0/ 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.

Potential backward compatibility issues in Joomla 4/de

2019-10-19T17:17:55Z

Jehacgn: Created page with "Die SimplePie-Bibliothek ist nicht mehr in Joomla! 4.0 enthalten."

<noinclude><languages /></noinclude>
{{incomplete}}{{RightTOC}}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.9.

== Aktualisierte Systemanforderungen ==
Die Systemanforderungen wurden wie folgt aktualisiert:
*PHP 7.2
*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.

<pre>
'STRICT_TRANS_TABLES',
'ERROR_FOR_DIVISION_BY_ZERO',
'NO_AUTO_CREATE_USER',
'NO_ENGINE_SUBSTITUTION',
</pre>

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

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

== 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 {{rarr}} JApplicationBase {{rarr}} Joomla\Application\AbstractApplication
*Neu: JApplicationCli {{rarr}} Joomla\Application\AbstractCliApplication {{rarr}} Joomla\Application\AbstractApplication

===== JApplicationWeb =====

*Alt: JApplicationWeb {{rarr}} JApplicationBase {{rarr}} Joomla\Application\AbstractApplication
*Neu: JApplicationWeb {{rarr}} Joomla\Application\AbstractWebApplication {{rarr}} 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 {{JVer | 3.7}}). Weitere Informationen finden Sie unter [[S:MyLanguage/J3.x:Discover_on_which_client_your_extension_code_is_running|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). [https://github.com/joomla-framework/database])

=== 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 ===
* <noinclude>JBrowser::isSSLConnection has been removed. Use JApplicationCms::isSSLConnection (available since Joomla 3.2)</noinclude>

=== 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 siehe[https://github.com/joomla/joomla-cms/pull/16419 dieser 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).
* JFormFieldUsergroup wurde entfernt. Verwende stattdessen Joomla\CMS\Form\Field\UsergrouplistField (verfügbar seit Joomla 3.2).
* JFormFieldFilelist und JFormFieldFolderList wurden ihre Filtereigenschaften umbenannt in <code>fileFilter</code> und <code>folderFilter</code> (um die Verwendung des regulären Joomla-Filterattributs auf zurückgegebene Werte zu ermöglichen).

=== 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 Schnittstelle[https://secure.php.net/manual/en/class.arrayaccess.php ArrayAccess] 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).

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

=== Sprache ====
* Die Funktionen setTransliterator, setPluralSuffixesCallback, setIgnoredSearchWordsCallback, setLowerLimitSearchWordCallback, setUpperLimitSearchWordCallback und setSearchDisplayedCharactersNumberCallback sind nun typisiert, um ein Callable zu benötigen.
* Der <tt>"_QQ_"</tt> 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. <tt>\"</tt>)

=== 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's[https://secure.php.net/manual/en/class.sessionhandlerinterface.php SessionHandlerInterface] 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 [https://github.com/PHPMailer/PHPMailer/blob/6.0/UPGRADING.md den Upgrade-Leitfaden]. für relevante Änderungen.

=== PHPUTF8 ===
At Joomla! 3.4, the PHPUTF8 library lived in two locations in the Joomla! package; `libraries/phputf8` and `libraries/vendor/joomla/string/src/phputf8`. In Joomla! 4.0, the copy of the library in `libraries/phputf8` has been removed. The Joomla\String\StringHelper class exposes many of the library's functions and the Composer autoloader definition imports much of the library as well, however, if you need a feature that is not already included then you should import the required functions from the `libraries/vendor/joomla/string/src/phputf8` path.

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

=== jQuery ===
Joomla! 4.0 ships with jQuery 3. Please review [https://jquery.com/upgrade-guide/3.0/ the upgrading guide] for relevant changes. Note that we are not including jQuery Migrate anymore either. We recommend using it locally to help debug your code if there are any issues.

=== Bootstrap ===
Joomla! 4.0 ships with Bootstrap 4. Bootstrap 2.3.2 has been removed, however we have left some BS2 classes in to ease the migration (e.g. The old BS2 element-invisible still exists for screenreaders)

=== FOF ===
FOF 2.x has been removed.

== Templates ==
All the Joomla! 3 templates - ISIS and Hathor in the backend, and protostar and Beeze in the frontend are no longer supported. The new 4.0 backend template is called Atum and the frontend template is called Cassiopeia.

As a consequence, all extensions must migrate to the new Bootstrap 4 style, away from the current Bootstrap 2.3.2 implementation. For more information about Bootstrap 4: [http://getbootstrap.com/docs/4.0/getting-started/introduction/]. For more information about Bootstrap 2.3.2: [http://getbootstrap.com/2.3.2/]

== Other ==

=== Media in Libraries ===
No media is allowed in the libraries root folder in the CMS - all assets associated with Joomla libraries should be put in the media folder as per best practices. Direct access is blocked with a .htaccess and web.config file in the root of the libraries directory.

=== Bin ===
Removing the keychain with 4.0 has resulted in the removal of the entire Bin directory as it only contained keychain.

=== Components ===
* All components have been namespaced and directories reworked accordingly. For more information about this read the tutorial on building a component in Joomla 4
* com_admin profile view has been removed (this appears to have been created historically due to issues accessing com_users. This is no longer the case so all user edits go through com_users edit user view in the backend)
* com_actionlogs php 5.5 backfill code has been removed and accordingly <source inline lang="php">ActionlogsHelper::getCsvData()</source> is now type hinted to return a <source inline lang="php">Generator</source> object
* Core components have had URL Routing 'Legacy' mode removed from Joomla 3.7. You should either use your .htaccess file or the redirect component to fix any internal URLs that change. You can try the 'Modern' mode in Joomla 3 by following the instructions [[S:MyLanguage/J3.x:New_Routing_System|here]]

=== Plugins ===
* The gmail authentication plugin has been removed. For more information please read [https://developer.joomla.org/news/724-removal-of-the-gmail-authentication-plugin-as-of-joomla-4-0.html this blog post]
* Recaptcha v1 support has been fully removed from the captcha plugin - this has no longer worked since Q2 2018 due to google dropping support for it.
* The Recaptcha plugin now uses google's official php library for captcha under the hood
* For plugins using the 3.x compatibility layer the name result is a protected property for both input parameters and return values. For information on the new recommended approach to plugins please read [[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
* The onContentBeforeSave event now requires the data parameter (this has been passed in \Joomla\CMS\MVC\Model\LegacyModel since 3.7 but is now passed in consistently by core extensions and used by the core Joomla content plugin)

=== Administrator Helpers ===
* JAdministratorHelper has been removed without replacement (it's been merged into JApplicationAdministrator)
* 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.

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

<noinclude>
[[Category:Compatibility{{#translation:}}]]
[[Category:Development{{#translation:}}]]
[[Category:Platform{{#translation:}}]]
[[Category:Migration{{#translation:}}]]
[[Category:Update Working Group{{#translation:}}]]
[[Category:Joomla! 4.x{{#translation:}}]]
[[Category:Joomla! 4.0{{#translation:}}]]
</noinclude>

Translations:Potential backward compatibility issues in Joomla 4/87/de

2019-10-19T17:17:54Z

Jehacgn: Created page with "Die SimplePie-Bibliothek ist nicht mehr in Joomla! 4.0 enthalten."

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

Potential backward compatibility issues in Joomla 4/de

2019-10-19T17:15:28Z

Jehacgn: Created page with "Joomla! 4.0 wird mit PHPMailer 6.0 ausgeliefert. Bitte überprüfe [https://github.com/PHPMailer/PHPMailer/blob/6.0/UPGRADING.md den Upgrade-Leitfaden]. für relevante Änder..."

<noinclude><languages /></noinclude>
{{incomplete}}{{RightTOC}}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.9.

== Aktualisierte Systemanforderungen ==
Die Systemanforderungen wurden wie folgt aktualisiert:
*PHP 7.2
*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.

<pre>
'STRICT_TRANS_TABLES',
'ERROR_FOR_DIVISION_BY_ZERO',
'NO_AUTO_CREATE_USER',
'NO_ENGINE_SUBSTITUTION',
</pre>

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

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

== 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 {{rarr}} JApplicationBase {{rarr}} Joomla\Application\AbstractApplication
*Neu: JApplicationCli {{rarr}} Joomla\Application\AbstractCliApplication {{rarr}} Joomla\Application\AbstractApplication

===== JApplicationWeb =====

*Alt: JApplicationWeb {{rarr}} JApplicationBase {{rarr}} Joomla\Application\AbstractApplication
*Neu: JApplicationWeb {{rarr}} Joomla\Application\AbstractWebApplication {{rarr}} 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 {{JVer | 3.7}}). Weitere Informationen finden Sie unter [[S:MyLanguage/J3.x:Discover_on_which_client_your_extension_code_is_running|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). [https://github.com/joomla-framework/database])

=== 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 ===
* <noinclude>JBrowser::isSSLConnection has been removed. Use JApplicationCms::isSSLConnection (available since Joomla 3.2)</noinclude>

=== 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 siehe[https://github.com/joomla/joomla-cms/pull/16419 dieser 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).
* JFormFieldUsergroup wurde entfernt. Verwende stattdessen Joomla\CMS\Form\Field\UsergrouplistField (verfügbar seit Joomla 3.2).
* JFormFieldFilelist und JFormFieldFolderList wurden ihre Filtereigenschaften umbenannt in <code>fileFilter</code> und <code>folderFilter</code> (um die Verwendung des regulären Joomla-Filterattributs auf zurückgegebene Werte zu ermöglichen).

=== 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 Schnittstelle[https://secure.php.net/manual/en/class.arrayaccess.php ArrayAccess] 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).

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

=== Sprache ====
* Die Funktionen setTransliterator, setPluralSuffixesCallback, setIgnoredSearchWordsCallback, setLowerLimitSearchWordCallback, setUpperLimitSearchWordCallback und setSearchDisplayedCharactersNumberCallback sind nun typisiert, um ein Callable zu benötigen.
* Der <tt>"_QQ_"</tt> 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. <tt>\"</tt>)

=== 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's[https://secure.php.net/manual/en/class.sessionhandlerinterface.php SessionHandlerInterface] 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 [https://github.com/PHPMailer/PHPMailer/blob/6.0/UPGRADING.md den Upgrade-Leitfaden]. für relevante Änderungen.

=== PHPUTF8 ===
At Joomla! 3.4, the PHPUTF8 library lived in two locations in the Joomla! package; `libraries/phputf8` and `libraries/vendor/joomla/string/src/phputf8`. In Joomla! 4.0, the copy of the library in `libraries/phputf8` has been removed. The Joomla\String\StringHelper class exposes many of the library's functions and the Composer autoloader definition imports much of the library as well, however, if you need a feature that is not already included then you should import the required functions from the `libraries/vendor/joomla/string/src/phputf8` path.

=== SimplePie ===
The SimplePie library is no longer included with Joomla! 4.0.

=== jQuery ===
Joomla! 4.0 ships with jQuery 3. Please review [https://jquery.com/upgrade-guide/3.0/ the upgrading guide] for relevant changes. Note that we are not including jQuery Migrate anymore either. We recommend using it locally to help debug your code if there are any issues.

=== Bootstrap ===
Joomla! 4.0 ships with Bootstrap 4. Bootstrap 2.3.2 has been removed, however we have left some BS2 classes in to ease the migration (e.g. The old BS2 element-invisible still exists for screenreaders)

=== FOF ===
FOF 2.x has been removed.

== Templates ==
All the Joomla! 3 templates - ISIS and Hathor in the backend, and protostar and Beeze in the frontend are no longer supported. The new 4.0 backend template is called Atum and the frontend template is called Cassiopeia.

As a consequence, all extensions must migrate to the new Bootstrap 4 style, away from the current Bootstrap 2.3.2 implementation. For more information about Bootstrap 4: [http://getbootstrap.com/docs/4.0/getting-started/introduction/]. For more information about Bootstrap 2.3.2: [http://getbootstrap.com/2.3.2/]

== Other ==

=== Media in Libraries ===
No media is allowed in the libraries root folder in the CMS - all assets associated with Joomla libraries should be put in the media folder as per best practices. Direct access is blocked with a .htaccess and web.config file in the root of the libraries directory.

=== Bin ===
Removing the keychain with 4.0 has resulted in the removal of the entire Bin directory as it only contained keychain.

=== Components ===
* All components have been namespaced and directories reworked accordingly. For more information about this read the tutorial on building a component in Joomla 4
* com_admin profile view has been removed (this appears to have been created historically due to issues accessing com_users. This is no longer the case so all user edits go through com_users edit user view in the backend)
* com_actionlogs php 5.5 backfill code has been removed and accordingly <source inline lang="php">ActionlogsHelper::getCsvData()</source> is now type hinted to return a <source inline lang="php">Generator</source> object
* Core components have had URL Routing 'Legacy' mode removed from Joomla 3.7. You should either use your .htaccess file or the redirect component to fix any internal URLs that change. You can try the 'Modern' mode in Joomla 3 by following the instructions [[S:MyLanguage/J3.x:New_Routing_System|here]]

=== Plugins ===
* The gmail authentication plugin has been removed. For more information please read [https://developer.joomla.org/news/724-removal-of-the-gmail-authentication-plugin-as-of-joomla-4-0.html this blog post]
* Recaptcha v1 support has been fully removed from the captcha plugin - this has no longer worked since Q2 2018 due to google dropping support for it.
* The Recaptcha plugin now uses google's official php library for captcha under the hood
* For plugins using the 3.x compatibility layer the name result is a protected property for both input parameters and return values. For information on the new recommended approach to plugins please read [[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
* The onContentBeforeSave event now requires the data parameter (this has been passed in \Joomla\CMS\MVC\Model\LegacyModel since 3.7 but is now passed in consistently by core extensions and used by the core Joomla content plugin)

=== Administrator Helpers ===
* JAdministratorHelper has been removed without replacement (it's been merged into JApplicationAdministrator)
* 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.

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

<noinclude>
[[Category:Compatibility{{#translation:}}]]
[[Category:Development{{#translation:}}]]
[[Category:Platform{{#translation:}}]]
[[Category:Migration{{#translation:}}]]
[[Category:Update Working Group{{#translation:}}]]
[[Category:Joomla! 4.x{{#translation:}}]]
[[Category:Joomla! 4.0{{#translation:}}]]
</noinclude>

Translations:Potential backward compatibility issues in Joomla 4/85/de

2019-10-19T17:15:28Z

Joomla! 4.0 wird mit PHPMailer 6.0 ausgeliefert. Bitte überprüfe [https://github.com/PHPMailer/PHPMailer/blob/6.0/UPGRADING.md den Upgrade-Leitfaden]. für relevante Änderungen.

Potential backward compatibility issues in Joomla 4/de

2019-10-19T17:14:34Z

Jehacgn: Created page with "Die folgenden Änderungen wurden an den externen Bibliotheken vorgenommen, die Joomla! pakt und versendet."

<noinclude><languages /></noinclude>
{{incomplete}}{{RightTOC}}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.9.

== Aktualisierte Systemanforderungen ==
Die Systemanforderungen wurden wie folgt aktualisiert:
*PHP 7.2
*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.

<pre>
'STRICT_TRANS_TABLES',
'ERROR_FOR_DIVISION_BY_ZERO',
'NO_AUTO_CREATE_USER',
'NO_ENGINE_SUBSTITUTION',
</pre>

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

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

== 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 {{rarr}} JApplicationBase {{rarr}} Joomla\Application\AbstractApplication
*Neu: JApplicationCli {{rarr}} Joomla\Application\AbstractCliApplication {{rarr}} Joomla\Application\AbstractApplication

===== JApplicationWeb =====

*Alt: JApplicationWeb {{rarr}} JApplicationBase {{rarr}} Joomla\Application\AbstractApplication
*Neu: JApplicationWeb {{rarr}} Joomla\Application\AbstractWebApplication {{rarr}} 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 {{JVer | 3.7}}). Weitere Informationen finden Sie unter [[S:MyLanguage/J3.x:Discover_on_which_client_your_extension_code_is_running|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). [https://github.com/joomla-framework/database])

=== 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 ===
* <noinclude>JBrowser::isSSLConnection has been removed. Use JApplicationCms::isSSLConnection (available since Joomla 3.2)</noinclude>

=== 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 siehe[https://github.com/joomla/joomla-cms/pull/16419 dieser 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).
* JFormFieldUsergroup wurde entfernt. Verwende stattdessen Joomla\CMS\Form\Field\UsergrouplistField (verfügbar seit Joomla 3.2).
* JFormFieldFilelist und JFormFieldFolderList wurden ihre Filtereigenschaften umbenannt in <code>fileFilter</code> und <code>folderFilter</code> (um die Verwendung des regulären Joomla-Filterattributs auf zurückgegebene Werte zu ermöglichen).

=== 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 Schnittstelle[https://secure.php.net/manual/en/class.arrayaccess.php ArrayAccess] 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).

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

=== Sprache ====
* Die Funktionen setTransliterator, setPluralSuffixesCallback, setIgnoredSearchWordsCallback, setLowerLimitSearchWordCallback, setUpperLimitSearchWordCallback und setSearchDisplayedCharactersNumberCallback sind nun typisiert, um ein Callable zu benötigen.
* Der <tt>"_QQ_"</tt> 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. <tt>\"</tt>)

=== 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's[https://secure.php.net/manual/en/class.sessionhandlerinterface.php SessionHandlerInterface] 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 ships with PHPMailer 6.0. Please review [https://github.com/PHPMailer/PHPMailer/blob/6.0/UPGRADING.md the upgrading guide] for relevant changes.

=== PHPUTF8 ===
At Joomla! 3.4, the PHPUTF8 library lived in two locations in the Joomla! package; `libraries/phputf8` and `libraries/vendor/joomla/string/src/phputf8`. In Joomla! 4.0, the copy of the library in `libraries/phputf8` has been removed. The Joomla\String\StringHelper class exposes many of the library's functions and the Composer autoloader definition imports much of the library as well, however, if you need a feature that is not already included then you should import the required functions from the `libraries/vendor/joomla/string/src/phputf8` path.

=== SimplePie ===
The SimplePie library is no longer included with Joomla! 4.0.

=== jQuery ===
Joomla! 4.0 ships with jQuery 3. Please review [https://jquery.com/upgrade-guide/3.0/ the upgrading guide] for relevant changes. Note that we are not including jQuery Migrate anymore either. We recommend using it locally to help debug your code if there are any issues.

=== Bootstrap ===
Joomla! 4.0 ships with Bootstrap 4. Bootstrap 2.3.2 has been removed, however we have left some BS2 classes in to ease the migration (e.g. The old BS2 element-invisible still exists for screenreaders)

=== FOF ===
FOF 2.x has been removed.

== Templates ==
All the Joomla! 3 templates - ISIS and Hathor in the backend, and protostar and Beeze in the frontend are no longer supported. The new 4.0 backend template is called Atum and the frontend template is called Cassiopeia.

As a consequence, all extensions must migrate to the new Bootstrap 4 style, away from the current Bootstrap 2.3.2 implementation. For more information about Bootstrap 4: [http://getbootstrap.com/docs/4.0/getting-started/introduction/]. For more information about Bootstrap 2.3.2: [http://getbootstrap.com/2.3.2/]

== Other ==

=== Media in Libraries ===
No media is allowed in the libraries root folder in the CMS - all assets associated with Joomla libraries should be put in the media folder as per best practices. Direct access is blocked with a .htaccess and web.config file in the root of the libraries directory.

=== Bin ===
Removing the keychain with 4.0 has resulted in the removal of the entire Bin directory as it only contained keychain.

=== Components ===
* All components have been namespaced and directories reworked accordingly. For more information about this read the tutorial on building a component in Joomla 4
* com_admin profile view has been removed (this appears to have been created historically due to issues accessing com_users. This is no longer the case so all user edits go through com_users edit user view in the backend)
* com_actionlogs php 5.5 backfill code has been removed and accordingly <source inline lang="php">ActionlogsHelper::getCsvData()</source> is now type hinted to return a <source inline lang="php">Generator</source> object
* Core components have had URL Routing 'Legacy' mode removed from Joomla 3.7. You should either use your .htaccess file or the redirect component to fix any internal URLs that change. You can try the 'Modern' mode in Joomla 3 by following the instructions [[S:MyLanguage/J3.x:New_Routing_System|here]]

=== Plugins ===
* The gmail authentication plugin has been removed. For more information please read [https://developer.joomla.org/news/724-removal-of-the-gmail-authentication-plugin-as-of-joomla-4-0.html this blog post]
* Recaptcha v1 support has been fully removed from the captcha plugin - this has no longer worked since Q2 2018 due to google dropping support for it.
* The Recaptcha plugin now uses google's official php library for captcha under the hood
* For plugins using the 3.x compatibility layer the name result is a protected property for both input parameters and return values. For information on the new recommended approach to plugins please read [[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
* The onContentBeforeSave event now requires the data parameter (this has been passed in \Joomla\CMS\MVC\Model\LegacyModel since 3.7 but is now passed in consistently by core extensions and used by the core Joomla content plugin)

=== Administrator Helpers ===
* JAdministratorHelper has been removed without replacement (it's been merged into JApplicationAdministrator)
* 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.

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

<noinclude>
[[Category:Compatibility{{#translation:}}]]
[[Category:Development{{#translation:}}]]
[[Category:Platform{{#translation:}}]]
[[Category:Migration{{#translation:}}]]
[[Category:Update Working Group{{#translation:}}]]
[[Category:Joomla! 4.x{{#translation:}}]]
[[Category:Joomla! 4.0{{#translation:}}]]
</noinclude>

Translations:Potential backward compatibility issues in Joomla 4/84/de

2019-10-19T17:14:33Z

Jehacgn: Created page with "Die folgenden Änderungen wurden an den externen Bibliotheken vorgenommen, die Joomla! pakt und versendet."

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