Éventuelles anomalies de rétro-compatibilité dans Joomla! 4

From Joomla! Documentation

This page is a translated version of the page Potential backward compatibility issues in Joomla 4 and the translation is 75% complete.

Other languages:
Deutsch • ‎English • ‎español • ‎français • ‎Nederlands • ‎português • ‎Türkçe
Quill icon.png
Content is Incomplete

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

Contents

Ce document suit les problèmes potentiels de rétrocompatibilité pour Joomla! 4. Sont listés des problèmes qui peuvent potentiellement briser des extensions.

La base de cette comparaison est Joomla! 3.8.

Évolution des configurations minimales du système

Les configurations minimales du système doivent être mises à jour ainsi :

  • PHP 7
  • MySQL 5.5.3
  • PostgreSQL 9.2
  • le support de SQL Server ne fait plus partie de la configuration.

Extension PHP MySQL

  • Joomla! ne supporte plus l'utilisation des pilotes PHP ext/mysql (qui ont été retirés de la version PHP 7.0). Joomla! va automatiquement essayer d'utiliser l'extension mysqli (disponible depuis PHP 5.3) ou le pilote mysql PDO (disponible depuis PHP 5.3 également) sinon Joomla! échouera à créer la connexion à la base de données.

Extension PHP Postgres

  • Joomla! ne supporte plus l'utilisation des pilotes PHP ext/pgsql. Joomla! va automatiquement essayer d'utiliser le pilote PostgreSQL PDO (disponible depuis PHP 5.3 et Joomla! 3.9) sinon Joomla! échouera à créer la connexion à la base de données.

Librairies du CMS

Les changements suivant ont été faits dans les librairies CMS de Joomla! (ceci est essentiellement du code qui a été trouvé dans le répertoire `libraries/cms` de Joomla! 3.7 et antérieur).

Installeur

  • La recherche d'installations de plugins ne se fera plus pour les fichiers xml dans le répertoire des plugins de mises en page de Joomla! 1.5 ;
  • Dans la version 3.x, seuls les scripts des plugins avaient la méthode avant lancement de la désinstallation appelée et aucun ne mettaient à disposition une méthode après désinstallation. Tous ces branchements sont disponibles en version 4.0 lors de la désinstallation d'une extension. Si actuellement vous pensiez que les méthodes pré et post étaient uniquement appelées dans le contexte de l'installation ou de la mise à jour, cette logique est maintenant incorrecte et vous devez utiliser le chemin d'installation (transmis en tant que paramètre de la méthode).
  • Lors de la désinstallation du plugin, la fonction de désinstallation dans le script de l'extension et maintenant activé avant l'activation des requêtes SQL (ce qui est maintenant cohérent avec les autres types d'extensions).

Classes supprimées

Les classes suivantes ont été retirées de Joomla! 4.0 :

  • JInstallerComponent (utilisez plutôt JInstallerAdapterComponent)
  • JInstallerFile (utilisez plutôt JInstallerAdapterFile)
  • JInstallerLanguage (utilisez plutôt JInstallerAdapterLanguage)
  • JInstallerLibrary (utilisez plutôt JInstallerAdapterLibrary)
  • JInstallerModule (utilisez plutôt JInstallerAdapterModule)
  • JInstallerPackage (utilisez plutôt JInstallerAdapterPackage)
  • JInstallerPlugin (utilisez plutôt JInstallerAdapterPlugin)
  • JInstallerTemplate (utilisez plutôt JInstallerAdapterTemplate)
  • JSubMenuHelper (utilisez plutôt JHtmlSidebar ; à noter que contrairement à JSubMenuHelper, ceci demande l'ajout d'un emplacement dans le modèle de votre vue)

Héritage de JInstallerAdapter

JInstallerAdapter n'hérite plus de JAdapterInstance et par conséquent plus de JObject.

Les adaptateurs d'installeur personnalisés doivent maintenant être auto chargeables.

Menu

JMenu devient une classe abstraite

JMenu devient une classe abstraite. Les sous-classes de JMenu doivent maintenant implémenter une méthode de chargement.

Suppression de la possibilité d'une inclusion manuelle

La possibilité dans JMenu::getInstance() d'inclure manuellement un fichier depuis le chemin de l'application includes/menu.php a été supprimée. La sous-classe JMenu doit maintenant s'auto-charger.

Chemin

Suppression de la possibilité d'une inclusion manuelle

La possibilité dans JPathway::getInstance() d'inclure manuellement un fichier depuis le chemin de l'application includes/pathway.php a été supprimée. La sous-classe JPathway doit maintenant s'auto-charger.

Routeur

Suppression de la possibilité d'une inclusion manuelle

La possibilité dans JRouter::getInstance() d'inclure manuellement un fichier depuis le chemin de l'application includes/router.php a été supprimée. La sous-classe JRouter doit maintenant s'auto-charger.

Modification des méthodes de signature

attachBuildRule et attachParseRule sont maintenant typés (typehint) pour être appelables.

JVersion

L'accès aux constantes de classe de JVersion en tant que propriétés de classe n'est plus supporté. Les constantes avaient été introduites avec Joomla! 3.5 pour éviter l'édition des paramètres des anciennes classes.

Les constantes obsolètes suivantes ont été supprimées :

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

JHtml

  • La fonction de déclaration dans JHtml est maintenant typée (typehint) pour être appelable. Les sous-classes de JHtml vont devoir maintenant correspondre à cette signature (à noter que ceci était déjà requis au niveau du code des fonctions).
  • JHtml::_ n'autorise plus l'appel de méthodes non publiques de JHtml ;
  • JHtml::_ est maintenant une méthode finale (il n'est plus possible de la surcharger en faisant une sous-classe de JHtml) et sa signature a évolué pour bénéficier des avantages des fonctionnalités modernes de PHP (éléments typés scalaires et variadiques) ;

Plateforme

Les changements suivant ont été effectués sur les librairies de la plateforme Joomla! (ceci concerne essentiellement du code des répertoires `libraries/joomla` ou `libraries/legacy` de Joomla! 3).

Application

Classes supprimées

Les classes suivantes ont été supprimées de Joomla! 4.0 :

  • JApplicationWebRouter (utilisez plutôt le paquet `joomla/router`)
  • JApplicationWebRouterBase (utilisez plutôt le paquet `joomla/router`)
  • JApplicationWebRouterRest (utilisez plutôt le paquet `joomla/router`)

Classes obsolètes

Les classes suivantes ont été dépréciées et seront retirées dans la version Joomla! 5.0 :

  • JApplicationBase (utilisez plutôt Joomla\Application\AbstractApplication)

Modifications des classes CLI/Web

Les classes JApplicationCli et JApplicationWeb ont été recomposées pour être étendues depuis le paquet de la structure de l'application. Ceci casse les vérifications de types pour un objet JApplicationBase. Pour la compatibilité future, il est recommandé de vérifier si les classes de l'application sont une instance de Joomla\Application\AbstractApplication (JApplicationBase a étendu cette classe depuis Joomla! 3.4).

De plus, ces deux classes sont maintenant abstraites. Les développeurs implémentant ces classes doivent fournir une méthode `doExecute` avec leur logique d'application.

La méthode registerEvent est maintenant typée (typehint) pour être appelable pour le paramètre $handler.

Les applications qui veulent à la fois supporter les applications Web et CLI doivent maintenant être typées (typehint) avec \Joomla\CMS\Application\ CMSApplicationInterface - ceci inclut les méthodes communes (certaines d'entre elles dans Joomla 3.x étaient seulement présentes dans la classe JApplicationCms) qui peuvent être utilisées pour tout code. Il est fortement recommandé dans les applications personnalisées (en particulier les applications CLI) d'implémenter cette interface pour faciliter les vérifications de compatibilité ; simultanément, tout typehint doit utiliser l'interface plutôt qu'une classe réelle.

JApplicationCli
  • Ancien : JApplicationCli    JApplicationBase    Joomla\Application\AbstractApplication
  • Nouveau : JApplicationCli    Joomla\Application\AbstractCliApplication    Joomla\Application\AbstractApplication
JApplicationWeb
  • Ancien : JApplicationWeb    JApplicationBase    Joomla\Application\AbstractApplication
  • Nouveau : JApplicationWeb    Joomla\Application\AbstractWebApplication    Joomla\Application\AbstractApplication
  • Les manières obsolètes d'appeler JApplicationWeb::redirect ont été supprimées :
    • avec un message et des paramètres messageType (appel de enqueueMessage séparément) ;
    • passer une valeur true/false en tant que 2ème/3ème paramètres au lieu du code de redirection va générer un InvalidArgumentException au lieu de l'état par défaut 303 ;
  • JApplicationWeb::$singleValueResponseHeaders a été supprimé parce que le Framework de l'application va utiliser en interne les objets PSR-7 Response et la version 2.0. Ceci modifie la manière dont les données headers sont stockées bien que ce soit toujours un tableau multi-dimensionnel avec chaque clé de niveau supérieur comme noms de header et la valeur étant un tableau contenant toutes les valeurs de ce header.
CMSApplication
  • Les propriétés de classe $_clientId, $_messageQueue et $_name ont été renommées pour supprimer le tiret bas.
  • Implémente dorénavant CMSApplicationInterface ;
  • Si il y a une erreur en récupérant l'objet de chemin, routage ou menu en utilisant les méthodes respectives, l'exception va dorénavant se manifester plutôt que la méthode génère l'exception en silence et retourne null ;
  • CMSApplication::getInstance va de plus dorénavant essayer de charger l'objet utilisateur (en utilisant la fonction loadidentity) ;
JApplicationSite

Les propriétés de classe $_language_filter et $_detect_browser ont été renommées pour supprimer le tiret bas.

La méthode obsolète JApplicationSite::getPageParameters a été supprimée au profit de son alias JApplicationSite::getParams.

JApplicationHelper

JApplicationHelper::parseXMLLangMetaFile a été supprimée sans remplacement.

Archive

  • Le paquet d'archive à été supprimé au profit de paquet d'archive du framework. A noter que l'API devrait rester inchangée ;
  • Le gestion des erreurs utilise dorénavant les Exceptions plutôt que JError ;

Crypt

Classes supprimées

Les chiffrages suivants ont été retirés de Joomla! 4.0 ;:

  • JCryptCipher3Des
  • JCryptCipherBlowfish
  • JCryptCipherMcrypt
  • JCryptCipherRijndael256
  • JCryptCipherSimple

Ils ont été retirés sans remplaçant. Utilisez JCryptCipherCrypto.

Méthodes supprimées

  • JCrypt::hasStrongPasswordSupport a été retiré sans remplaçant (ceci tentait de détecter les 'bcrypt polyfills' de l'hôte linux mais retournait toujours true depuis l'utilisation de PHP 5.3.10 dans Joomla! 3.3) ;

Cache

  • JCacheController::get requiert maintenant un call. De ce fait, JCacheControllerCallback::call a été supprimé.
  • JCacheStorage::test a été supprimé. Utilisez JCacheStorage::isSupported dorénavant
  • Les moteurs de stockage ne sont plus chargés manuellement et sont maintenant chargés automatiquement
  • JCacheControllerOutput::start et JCacheControllerOutput::end ont été retirés sans remplaçant
  • Suppression du stockage CacheLite étant donné qu'il n'est pas compatible avec PHP7 (qui est la version minimale requise)
  • Le gestion des erreurs utilise dorénavant les Exceptions plutôt que JError ;

Composant

  • \Joomla\CMS\Component\ComponentRecord n'est plus une extension de JObject

Document

Changement d'héritage

Les classes suivantes ont changé d'héritage :

  • JDocumentError (qui hérite maintenant de \Joomla\Cms\Document\HtmlDocument au lieu de \Joomla\Cms\Document\Document)

A noter que, comme résultat de ce changement, le rendu d'une page d'erreur réinitialise l'objet document Joomla\CMS\Factory::$document, la raison étant que nous voulons partir d'un rendu vierge du document pour travailler; si la page d'erreur est déclenchée, nous ne sommes par intéressés par les métadonnées que votre document a initialisées, ou les médias ajouté par un module défaillant, ou n'importe quel plugin s'affichant à l'écran. Nous voulons un environnement propre pour afficher la page d'erreur en affichant uniquement les données chargées par la page d'erreur.

Rendus

  • Afin d'être conforme avec les spécifications des fils RSS, JDocumentRendererFeedRss autorise maintenant l'élément lastBuildDate à être configuré en utilisant la propriété de classe JDocumentFeed::$lastBuildDate lorsqu'un fil d'actualité est affiché. La valeur par défaut est l'heure courante, comme c'est le cas avec Joomla! 3.x et antérieur, cependant l'heure peut être modifiée en changeant la propriété de classe avec un objet JDate configuré avec le timestamp souhaité.
  • Il y a dorénavant un RendererInterface que tous les Renderers doivent implémenter.
  • JDocumentRenderer est dorénavant une classe abstraite qui implémente RendererInterface.
  • En alternative à <jdoc:include type="head" />, vous pouvez dorénavant charger individuellement <jdoc:include type="metas" /> pour les metadata, <jdoc:include type="styles" /> pour le CSS et <jdoc:include type="scripts" /> pour le javascript. Le but de cela est de permettre optionnellement aux utilisateurs de placer tous les javascript en fin du document HTML dans leur modèle de site.

JDocumentFeed

Le type de propriété de JDocumentFeed::$lastBuildDate a été modifié d'un format de string à un objet JDate. La propriété était par le passé inutilisée dans le noyau API Joomla mais des extensions peuvent l'avoir utilisée.

Base de données

Ce paquet à été remplacé par le paquet Joomla Framework Database.

Factory

  • Factory::getApplication ne prend plus d'arguments. Ceci était trompeur vu qu'elle retournait systématiquement l'application active après le premier appel dans le bootstrap, quels que soient les arguments qui étaient passés à la fonction.
  • Factory::getXml a été retiré avec JXMLElement. Utilisez dorénavant SimpleXMLElement directement.
  • Factory::getEditor a été retiré. Utilisez dorénavant JEditor::getInstance.

Form

  • Les répertoires libraries/joomla/form/fields et libraries/joomla/form/rules ne sont plus enregistrés pour trouver les formulaires de classes ; Les formulaires de classes doivent dorénavant être auto-chargés.
  • Two new properties added addfieldprefix which registers a namespace prefix for extensions (intended to be used as a replacement for addfieldpath). For example usage please see this Github PR

HTTP

Classes et Interfaces obsolètes

Les classes et interfaces suivantes sont obsolètes et planifiées pour suppression dans la version Joomla! 5.0 :

  • JHttpResponse (utilisez dorénavant Joomla\Http\Response)
  • JHttpTransport (implémentez dorénavant Joomla\Http\TransportInterface)

Modifications de classe

Le paquet HTTP du Framework est dorénavant inclus dans Joomla! 4.0 et JHttp et les sous-classes JHttpTransport ont été remaniées pour utiliser le paquet en amont.

JHttp

Le constructeur de classe JHttp a été allégé avec les changements suivant :

  • Le paramètre d'options n'est plus typehinted en tant qu'objet Joomla\Registry\Registry, un tableau ou un objet implémentant l'interface ArrayAccess peut être utilisée en lieu et place ;
  • Le paramètre de transport &accepte dorénavant tout objet Joomla\Http\TransportInterface ;
JHttpTransport

L'interface dorénavant obsolète JHttpTransport étend maintenant Joomla\Http\TransportInterface et a provoqué des changements dans l'interface qui causent des problèmes de compatibilité aval. Le constructeur ne fait plus partie de l'interface, et la méthode `request()` de l'interface a changé de signature. Plus spécifiquement, le second paramètre qui typait (typehint) la classe JUri, type (typehint) dorénavant Joomla\Uri\UriInterface.

JHttpResponse

En remaniant l'objet de réponse pour hériter du paquet HTTP du Framework, qui utilise maintenant l'API ResponseInterface PSR-7, la compatibilité a été cassée dans la structure des entêtes de réponses. A partir de 4.0, ceci sera dorénavant un tableau multi-dimensionnel où la clé est nom de l'entête et la valeur est un tableau de valeurs pour cet entête (par le passé, c'était une chaîne de caractères).

Image

Classes et Interfaces obsolètes

Les classes et interfaces suivantes sont obsolètes et seront retirées dans la version Joomla! 5.0 :

  • JImageFilter (utilisez dorénavant Joomla\Image\ImageFilter)
  • JImageFilterBackgroundfill (utilisez dorénavant Joomla\Image\Filter\Backgroundfill)
  • JImageFilterBrightness (utilisez dorénavant Joomla\Image\Filter\Brightness)
  • JImageFilterContrast (utilisez dorénavant Joomla\Image\Filter\Contrast)
  • JImageFilterEdgedetect (utilisez dorénavant Joomla\Image\Filter\Edgedetect)
  • JImageFilterEmboss (utilisez dorénavant Joomla\Image\Filter\Emboss)
  • JImageFilterGrayscale (utilisez dorénavant Joomla\Image\Filter\Grayscale)
  • JImageFilterNegate (utilisez dorénavant Joomla\Image\Filter\Negate)
  • JImageFilterSketchy (utilisez dorénavant Joomla\Image\Filter\Sketchy)
  • JImageFilterSmooth (utilisez dorénavant Joomla\Image\Filter\Smooth)

Modifications de classe

Le paquet d'Image du Framework est maintenant inclus dans Joomla! 4.0 et les sous-classes JImage et JImageFilter ont été réécrites pour utiliser le paquet amont.

Menu

  • Le tiret bas de JMenu::$_items, JMenu::$_default et JMenu::$_active a été retiré (notez que ces propriétés étaient protégées et donc cela n'impacte que les sous-classes personnalisées de JMenu) ;

Keychain

Retirer le keychain de la version 4.0 implique la suppression des classes suivantes :

  • JKeychain

Pathway

  • Le tiret bas de JPathway::$_pathway et JPathway::$_count a été supprimé (notez que ces propriétés étaient protégées et donc cela n'impacte que les sous-classes personnalisées de JPathway) ;
  • JPathway::_makeItem a été retiré à la faveur de JPathway::makeItem (notez que cette méthode était protégée et donc cela n'impacte que les sous-classes personnalisées de JPathway) ;

Table

  • l'objet de base de données JTable::__construct est dorénavant typé (typehint) pour être un JDatabaseDriver ;
    • Les sous-classes de JTable devront s'assurer qu'elles passent un objet JDatabaseDriver au constructeur parent ;
    • Les sous-classes de JTable devront changer la signature de la méthode de setDbo() si elles veulent avoir une version étendue de cette méthode pour inclure le typehint ;
  • Il existe une nouvelle méthode JTable::hasField - toutes les instances de property_exists sur les instances de JTable devront dorénavant de préférence utiliser cette méthode de proxy afin de permettre une meilleure interopérabilité des instances de Table  ;
  • Le modèle JTableObserver (et des classes correspondantes) a été retiré de JTable. Dorénavant les déclenchements d'événements, les Tags et Content History de JTable (et toute autre utilisation personnalisée de ce modèle) doivent être déplacées vers les plugins standards ;

E-mail

Les méthodes suivantes ont été retirées de Joomla! 4.0 :

  • JMail::sendAdminMail a été supprimée ;

Langues

Les fonctions setTransliterator, setPluralSuffixesCallback, setIgnoredSearchWordsCallback, setLowerLimitSearchWordCallback, setUpperLimitSearchWordCallback et setSearchDisplayedCharactersNumberCallback sont maintenant typées (typehint) pour être appelables.

Compatibilité des couches MVC

JControllerLegacy

  • JControllerLegacy a été retiré de la couche de compatibilité, et nous n'avons plus l'intention de la retirer (ni ses sous-classes) dans le futur proche.
  • JControllerLegacy n'étend plus JObject. Les contrôleurs ne devraient appeler aucune méthode contenues dans la classe JObject.
  • JControllerLegacy implémente une interface pour les contrôleurs multi-tâches.
  • JControllerLegacy::_construct prend dorénavant des arguments supplémentaires. Si par le passé vous obteniez un objet de type Controller en utilisant JControllerLegacy::getInstance, vous devrez modifier votre code.
    • Paramètre 2: Une instance facultative de MVCFactoryInterface
    • Paramètre 3: Une instance facultative de CMSApplicationInterface
    • Paramètre 4: Une instance facultative de Input
    • Paramètre 5: Une instance facultative de FormFactoryInterface
  • JControllerForm utilise dorénavant le paquet StringInflector pour déterminer la vue en liste. Ceci devrait améliorer sa capacité à déterminer la vue en liste avec plus de noms de vues. Si les développeurs d'extensions trouvent que la vue en liste n'est plus trouvée, ils devront mettre à la main la propriété de classe `view_list` dans leur contrôleur.

Legacy View

  • JViewLegacy has been removed from the legacy layer, and we no longer intend to remove it or it's subclasses in the near future.
  • JViewHtml has been split into two classes - AbstractView and HtmlView. Abstract view contains the logic for accessing models and getting the name of the view and is intended to be a base class for non-Html views. Html view contains the same logic as before.
  • There are now two subclasses of JViewHtml - \Joomla\CMS\MVC\View\ListView and \Joomla\CMS\MVC\View\FormView designed to speed up the development of list and form views and reduce code duplication.

Session

The session package has undergone a major refactoring to use the Framework's Session package. This change primarily effects the internals of the package; changes to the primary public API through the JSession class are minimal.

Removed Classes and Interfaces

The following classes and interfaces have been removed in Joomla! 5.0:

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

JSession

JSession now extends from the Framework's Joomla\Session\Session class. Many of the methods have a modified signature and a compatibility layer exists to help with the transition.

Namespace Parameter Deprecated

The get, set, has, and clear methods previously supported a namespace parameter. This parameter is now deprecated, the namespace should be prepended to the name before calling these methods.

JSession::clear() Repurposed

In the Joomla\Session\Session class, the clear method is used to clear all data from the session store. In JSession, this method is used to remove a single key. When this method is called with parameters, it will call the new Joomla\Session\Session::remove() method.

JSession::getInstance() Deprecated

The singleton getInstance() method has been deprecated. The session object should be retrieved from the active application or the dependency injection container instead.

Social Media Libraries

The facebook, github, google, linkedin, openstreetmap, mediawiki and twitter packages have all been removed from the CMS.

Session Handlers

In Joomla! 3.x and earlier, session handlers were represented by the JSessionStorage class and its subclasses. In Joomla! 4.0, session handlers are now implementations of Joomla\Session\HandlerInterface (which is an extension of PHP's SessionHandlerInterface. All handlers which were supported in Joomla! 3.x are still available in 4.0 in addition to two additional handlers; a handler natively implementing the APCu extension and a handler supporting Redis.

Classes supprimées sans remplaçant

  • JNode
  • JTree
  • JGrid
  • JError (utilisez des exceptions natives lorsque la gestion d'erreur est requise)

Utilities

Removed Classes and Interfaces

The following classes and interfaces have been removed in Joomla! 4.0:

  • JArrayHelper

use Joomla\Utilities\ArrayHelper; instead.

Librairies externes

The following changes have been made to the external libraries that Joomla! packages and ships.

PHPMailer

Joomla! 4.0 ships with PHPMailer 6.0. Please review 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 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: [1]. For more information about Bootstrap 2.3.2: [2]

Autre

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.

Plugins

  • The gmail authentication plugin has been removed. For more information please read 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
  • 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 has been removed without replacement (use JHtmlSidebar instead - available since 3.0)
  • JToolbarHelper has been moved to the main libraries directory

Modules

  • Le module du site d'administration "submenu" a été supprimé.

Error Handling

  • Joomla will now handle PHP's E_USER_DEPRECATED errors and pipes it into JLog - this is useful for handling deprecations in many 3rd party PHP Libraries (note it will block the page load if debug mode is enabled)
  • Joomla\CMS\Exception\ExceptionHandler now only operates on Exceptions thrown in JApplication::execute. We now use Symfony's ErrorHandler when this fails or exceptions are thrown outside of this. We expect this to have minimal effect on most users and should give a more helpful message in many cases than the traditional "Error displaying the error page" error for users when things go very wrong.
  • Joomla\CMS\Exception\ExceptionHandler is now format aware and will render errors in html, json, xml, feed or cli aware formats
  • The Joomla\CMS\Exception\ExceptionHandler::render() signature is changed to include the Throwable typehint. Before 3.5 when PHP 7 support was added this was typehinted as Exception, and since 3.5 has been typechecked in the code itself.