Joomla! Documentation - User contributions [en]

J3.x:Adding custom fields/Implement into your component

2020-10-20T08:36:53Z

Sharky: Correct method name

<noinclude><languages /></noinclude><br />
{{section portal heading|icon=plug|title=<translate>
Implementation into your component</translate>}}
{{J3.x:Adding_custom_fields/TOC/<translate>
en</translate>}}
<translate>
== Implement fields into your component == 
</translate>

<translate>
This article describes how to apply a basic implementation of the custom fields feature to your custom component.</translate> <br />
<translate>

Ever wanted to show additional attributes in your items? Through custom fields, you have a seamlessly integrated way to show them in the backend and frontend of your site.</translate> <br />
<translate>
Custom fields offers 15 different types, if you need more you can [[S:MyLanguage/J3.x:Creating_a_Plugin_for_Joomla|create your own plugin]]</translate>.<br />
<translate>
The custom fields extension is placed in core and can be used in a similar way to the categories extension.
Basically there are just 2 files you need to extend with the following code for the basic backend part.</translate><br />
<translate>
'''Note!''' In the example code we will use for your component the name <tt>com_example</tt>.</translate>

<translate>
=== The Backend Part === 
</translate>
<translate>
==== How to add fields to the backend lists ==== 
</translate>

<translate>
Similar to <tt>com_categories</tt> there are just a few lines needed to add the fields in the backend view.
Just add the following lines to the method <code>addSubmenu</code> in your component helper class.</translate><br />
<translate>
The used context needs to match the context you want to implement the fields in. An example of context could be <tt>com_content.article</tt> or <tt>com_weblinks.weblink</tt>. We’re using <tt>com_example.item</tt> here as example. Only the context option needs to be changed.</translate>

<source lang="php">
if (JComponentHelper::isEnabled('com_fields'))
{
JHtmlSidebar::addEntry(
JText::_('JGLOBAL_FIELDS'),
'index.php?option=com_fields&context=com_example.item',
$vName == 'fields.fields'
);

JHtmlSidebar::addEntry(
JText::_('JGLOBAL_FIELD_GROUPS'),
'index.php?option=com_fields&view=groups&context=com_example.item',
$vName == 'fields.groups'
);
}
</source>

<translate>
==== Implement the ACL ==== 
</translate>

<translate>
Now the ACL part needs to be done. You have to add the following lines to your access xml file just before the closing <code></access></code> in that file. Here they are defined and will allow your users to choose the ACL settings in your implementation of <tt>com_fields</tt>.</translate>

<source lang=xml>
<section name="fieldgroup">
<action name="core.create" title="JACTION_CREATE" description="COM_FIELDS_GROUP_PERMISSION_CREATE_DESC" />
<action name="core.delete" title="JACTION_DELETE" description="COM_FIELDS_GROUP_PERMISSION_DELETE_DESC" />
<action name="core.edit" title="JACTION_EDIT" description="COM_FIELDS_GROUP_PERMISSION_EDIT_DESC" />
<action name="core.edit.state" title="JACTION_EDITSTATE" description="COM_FIELDS_GROUP_PERMISSION_EDITSTATE_DESC" />
<action name="core.edit.own" title="JACTION_EDITOWN" description="COM_FIELDS_GROUP_PERMISSION_EDITOWN_DESC" />
<action name="core.edit.value" title="JACTION_EDITVALUE" description="COM_FIELDS_GROUP_PERMISSION_EDITVALUE_DESC" />
</section>
<section name="field">
<action name="core.delete" title="JACTION_DELETE" description="COM_FIELDS_FIELD_PERMISSION_DELETE_DESC" />
<action name="core.edit" title="JACTION_EDIT" description="COM_FIELDS_FIELD_PERMISSION_EDIT_DESC" />
<action name="core.edit.state" title="JACTION_EDITSTATE" description="COM_FIELDS_FIELD_PERMISSION_EDITSTATE_DESC" />
<action name="core.edit.value" title="JACTION_EDITVALUE" description="COM_FIELDS_FIELD_PERMISSION_EDITVALUE_DESC" />
</section>
</source>

<translate>
There is one more entry setting in that file:</translate>
<source lang=xml>
<action name="core.edit.value" title="JACTION_EDITVALUE" description="JACTION_EDITVALUE_COMPONENT_DESC" />
</source>

<translate>
This entry should be made under the normal settings in your component (and also in the access xml file) as it allows users in the group to edit any value of custom fields submitted in your component.</translate>

<translate>
=== Result === 
</translate>

<translate>
If you completed these steps, your backend part for fields implementation is done. The users can now create fields and assign them to an item.</translate>

<translate>
=== The Frontend Part === 
</translate>

<translate>
Now let's go to the frontend part. It is easy as the fields are rendered, through the [[S:MyLanguage/Plugin/Events#Content|Plugin/Events/Content]] events on the frontend.</translate>
<translate>

To display fields on the frontend, you need to implement the content plugin events in your component.</translate> <br />
<translate>
'''Important''' here is where you pass the same context that you used in the backend to the events.</translate>

<translate>
See:</translate>
*[[S:MyLanguage/Plugin/Events/Content#onContentAfterTitle|onContentAfterTitle]]
*[[S:MyLanguage/Plugin/Events/Content#onContentBeforeDisplay|onContentBeforeDisplay]]
*[[S:MyLanguage/Plugin/Events/Content#onContentAfterDisplay|onContentAfterDisplay]]
*[[S:MyLanguage/Plugin/Events/Content#onContentPrepare|onContentPrepare]]
<translate>

After the onContentPrepare event is fired with the context you can find the attached fields in <tt>$item->jcfields</tt> property if you want to render the fields using in your layouts / views.</translate>
<translate>
=== Tips, Tricks & Hidden Features === 
</translate>

<translate>
Here you can find some tips and tricks on what can be gone wrong with your implementation as well as some hidden features of com_fields.</translate>
<translate>
==== The fields tab don’t show up in my component's edit view ==== 
</translate>

<translate>
In some components the edit views in backend and/or frontend are hardcoded and can't be changed / extended using plugins. But as the fields uses a plugin to add the fields to your component you need to support that in order to support fields. You can make sure that fields are rendered e.g. by implementing the following layout in your component edit view:</translate>

<source lang=php>
<?php $this->ignore_fieldsets = array('general', 'info', 'detail', 'jmetadata', 'item_associations'); ?>
<?php echo JLayoutHelper::render('joomla.edit.params', $this); ?>
</source>

<translate>

The first line makes sure we ignore the (eventually hardcoded fieldsets) and than render the dynamic fields tab using the <code>joomla.edit.params</code> layout.</translate>
<translate>
==== Public helper classes and API ==== 
</translate>
<translate>
The class FieldsHelper has some public API functions to work with fields.</translate>

<source lang=php>
JLoader::register('FieldsHelper', JPATH_ADMINISTRATOR . '/components/com_fields/helpers/fields.php');
$fields = FieldsHelper::getFields('com_example.item', $item, true);
</source>

<translate>
The field model itself allows to get and store the value of a field.</translate>

<source lang=php>
JModelLegacy::addIncludePath(JPATH_ADMINISTRATOR . '/components/com_fields/models', 'FieldsModel');
$fieldModel = JModelLegacy::getInstance('Field', 'FieldsModel', array('ignore_request' => true));
$fieldModel->setFieldValue($fieldId, $item->id, 'demo value');
</source>

<translate>
==== ACL support ==== 
</translate>

<translate>

* Every field has an access level
* Every field has a new permission edit.value
</translate>

<tt>JFactory::getUser()->authorise('edit.value', ‘com_example.item.field.' . (int) $field->id);</tt>

<translate>
=== More Information === 
</translate>
* https://www.youtube.com/watch?v=7ikOaOKyo6s | JAB16 - <translate>
Custom Fields in Joomla for developers - English</translate>
* https://www.youtube.com/watch?v=F_Ni15icn1U | JD16AT - <translate>
Custom fields since Joomla 3.7 - English</translate>
* https://joomla.digital-peak.com/images/blog/JDD16%20Custom%20fields%20in%20Joomla%20for%20developers.pdf

<div class="row">
<div class="large-6 columns">{{Basic button|S:MyLanguage/J3.x:Adding_custom_fields/What components are supporting custom fields|
<translate>
Prev: What components are supporting custom fields</translate>|class=expand success}}</div>
<div class="large-6 columns">{{Basic button|S:MyLanguage/J3.x:Adding_custom_fields/Overrides|<translate>
Next: Use custom fields in your overrides</translate>|class=expand success}}</div>
</div>
__NOTOC__
<noinclude>
<translate>

[[Category:Tutorials]]
[[Category:Custom Fields]]
[[Category:Beginners]]
[[Category:Development]]
[[Category:Component_Development]]
[[Category:Joomla! 3.x]]
[[Category:Joomla! 3.7]]
[[Category:Joomla! 3.8]]
</translate>
</noinclude>

Potential backward compatibility issues in Joomla 4

2020-08-04T05:41:55Z

Sharky: Draggable typo

<noinclude><languages /></noinclude>
{{incomplete}}{{RightTOC}}<translate>
This document tracks potential backward compatibility issues for Joomla! 4. Listed are issues which potentially break extensions.


The base of this comparison is Joomla! 3.10.</translate>

<translate>
== Updated System Requirements == 
</translate>
<translate>
The system requirements have been updated as follows:
*PHP 7.2.5
*MySQL 5.6
*PostgreSQL 11.0
*SQL Server support has been dropped.</translate>

<translate>
=== PHP MySQL Extension === 
</translate>
<translate>
*Joomla no longer supports using PHP's ext/mysql driver (which was removed in PHP 7.0). Joomla will automatically try and use the mysqli extension (available since PHP 5.3) or the mysql PDO Driver (available since PHP 5.3) else it will fail to create a database connection.</translate>
<translate> * Strict mode has been enabled. The following flags are now active by default in Joomla 4 and you may have to update your database queries accordingly. This will help us with future MySQL version upgrades and also aligns more closely with Postgres to enable easier compatibility with queries in both languages.</translate>

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

As a consequence, Joomla 4 will only use '''NULL date defaults'''. The use of the "invalid default date" 0000-00-00 00:00:00 in Joomla 4 has been deprecated.

<translate>

=== PHP Postgres Extension === 
</translate>
*<translate> Joomla no longer supports using PHP's ext/pgsql driver. Joomla will automatically try and use the PostgreSQL PDO Driver (available since PHP 5.3 and Joomla 3.9) else it will fail to create a database connection with a Postgres Database.</translate>

<translate>
=== PHP GMP Extension === 
</translate>
<translate> This is required for using the WebAuthn feature. Note it is installed by default on the majority of hosting sites.</translate>
<translate>
=== PHP mcrypt Extension === 
</translate>
<translate> This is required for using the Joomla\CMS\Crypt\Cipher\CrytoCipher class and it's alias JCryptCipherCrypto.</translate>

<translate>

== CMS Libraries == 
</translate>
<translate>
The following changes have been made to Joomla! CMS libraries (this is primarily code that was found in the “libraries/cms” directory in Joomla! 3.7 and earlier).</translate>

<translate>
=== Installer === 
</translate>
* <translate> Plugin discover installs will no longer search for xml files in the Joomla! 1.5 plugin folder layouts</translate>
* <translate> In 3.x, only plugins scripts have the preflight method called and none make postflight available during the uninstall process. All extensions types will have these hooks available in 4.0 when being uninstalled. If you currently preflight and postflight and assume they only apply in an install/update context - this logic is now incorrect and you should use the install route (given as one of the method parameters)</translate>
* <translate> When uninstalling a plugin the uninstall function in the extension script is now triggered before triggering any SQL queries (this is now consistent with all other extension types).</translate>

<translate>
==== Removed Classes ==== 
</translate>
<translate>
The following classes have been removed in Joomla! 4.0:
*JInstallerComponent (use JInstallerAdapterComponent instead)
*JInstallerFile (use JInstallerAdapterFile instead)
*JInstallerLanguage (use JInstallerAdapterLanguage instead)
*JInstallerLibrary (use JInstallerAdapterLibrary instead)
*JInstallerModule (use JInstallerAdapterModule instead)
*JInstallerPackage (use JInstallerAdapterPackage instead)
*JInstallerPlugin (use JInstallerAdapterPlugin instead)
*JInstallerTemplate (use JInstallerAdapterTemplate instead)
*JSubMenuHelper (use JHtmlSidebar instead; note that in contrast to JSubMenuHelper, this requires an addition of a placeholder in your view template)
</translate>

<translate>
==== JInstallerAdapter Inheritance ==== 
</translate>
<translate>
JInstallerAdapter no longer extends from JAdapterInstance and inherently JObject.</translate>

<translate> Custom Installer Adapters must now be autoloaded.</translate>

<translate>
=== Menu === 
</translate>
<translate>
==== JMenu is now an abstract class ==== 
</translate>
<translate>
JMenu is now an abstract class. Subclasses of JMenu must now also implement a load method.</translate>

<translate>
==== Manual Include Behavior Removed ==== 
</translate>
<translate>
The logic in JMenu::getInstance() to manually include a file from the application's includes/menu.php path has been removed. The JMenu subclass should be autoloaded instead.</translate>

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

=== Pagination ===
* The magic pagination functions ''pagination_item_active'', ''pagination_item_inactive'' have been removed. Use the JLayout's joomla.pagination.link instead
* The magic pagination function ''pagination_list_render'' is deprecated. Use the JLayout joomla.pagination.list instead

<translate>

=== Pathway === 
</translate>

<translate>
==== Manual Include Behavior Removed ==== 
</translate>
<translate>
The logic in JPathway::getInstance() to manually include a file from the application's includes/pathway.php path has been removed. The JPathway subclass should be autoloaded instead.</translate>

<translate>
=== Router === 
</translate>

<translate>
==== Manual Include Behavior Removed ==== 
</translate>
<translate>
The logic in JRouter::getInstance() to manually include a file from the application's includes/router.php path has been removed. The JRouter subclass should be autoloaded instead.</translate>

<translate>
==== Method Signature Changes ==== 
</translate>
<translate> The attachBuildRule and attachParseRule are now typehinted to require callables.</translate>

<translate>
=== JVersion === 
</translate>
<translate>
Support for accessing the JVersion class constants as class properties is no longer supported. The constants were introduced in Joomla! 3.5 to prevent the old class properties from being edited.</translate>

<translate> The following deprecated constants have been removed:</translate>
* JVersion::RELEASE
* JVersion::DEV_LEVEL
* JVersion::BUILD

<translate>
=== JHtml === 
</translate>
* <translate> The register function in JHtml is now typehinted to require a callable. Subclasses of JHtml will now need to match this signature (note this was already required at the function code level already).</translate>
* <translate> JHtml::_ no longer allows you to call non-public methods in JHtml</translate>
* <translate> JHtml::_ is now a final method (you can no longer override it if you subclass JHtml) and it's signature has changed to take advantage of modern PHP features (scalar and variadic typehints)</translate>
* <translate> JHtmlBootstrap::modal has been removed. Use JHtmlBootstrap::renderModal</translate>
* JHtmlSortablelist::sortable has been deprecated in favour of JHtmlDraggablelist::draggable - the old method acts as a proxy to the new method currently to facilitate the removal of jQuery UI from Joomla Core. All media assets relating to the original jQuery UI implementation have been removed.
* JHtmlBatch has been removed as all the code had been moved to layouts for template overrides. Use the JLayouts directly in your code.

<translate>

=== Updater === 


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

== Platform == 
</translate>
<translate>
The following changes have been made to Joomla! Platform libraries (this is primarily code found in the `libraries/joomla` or `libraries/legacy` directories in Joomla! 3).</translate>

=== Access ===
* JAccess::$assetPermissionsById and JAccess::$assetPermissionsByName and JAccess::preloadPermissionsParentIdMapping have been removed without replacement. Since 3.6 we've used other methods and class properties to optimize the loading of assets (see [https://github.com/joomla/joomla-cms/pull/12850 this PR] for the reasons why this was deprecated)
* JAccess::getActions has been removed. Use JAccess::getActionsFromFile or JAccess::getActionsFromData instead.

<translate>
=== Application === 
</translate>

<translate>
==== Removed Classes ==== 
</translate>
<translate>
The following classes have been removed in Joomla! 4.0:
*JApplicationWebRouter (use the `joomla/router` package instead)
*JApplicationWebRouterBase (use the `joomla/router` package instead)
*JApplicationWebRouterRest (use the `joomla/router` package instead)</translate>

All references to JSite and JAdministrator have been removed (these were just class alias' since Joomla 3.2)

<translate>

==== Deprecated Classes ==== 
</translate>
<translate>
The following classes have been deprecated and scheduled for removal in Joomla! 5.0:
*JApplicationBase (use Joomla\Application\AbstractApplication instead)</translate>

<translate>
==== CLI/Web Class Changes ==== 
</translate>
<translate>
The JApplicationCli and JApplicationWeb classes have been recomposed to extend from the Framework's Application package instead. This breaks type checks for a JApplicationBase object. For forward compatibility, it is recommended to check if application classes are an instance of Joomla\Application\AbstractApplication (JApplicationBase has extended this class since Joomla! 3.4).</translate>

<translate>
Additionally, both of these classes are now abstract. Developers implementing these classes must provide a `doExecute` method with their application's logic.</translate>

<translate> The registerEvent method is now typehinted to require a callable for the $handler parameter.</translate>

<translate> Applications that want to support both Web and CLI Applications should now typehint against the \Joomla\CMS\Application\ CMSApplicationInterface - this contains common methods (some of which in Joomla 3.x were only found in the JApplicationCms class) that can be used by all code. It's strongly recommended any custom applications (especially CLI applications) implement this interface to make compatibility checks easier, simultaneously any typehints should use the interface rather than a concrete class.</translate>

===== JApplicationCli =====

*<translate>
Old:</translate> JApplicationCli {{rarr}} JApplicationBase {{rarr}} Joomla\Application\AbstractApplication
*<translate>
New:</translate> JApplicationCli {{rarr}} Joomla\Application\AbstractCliApplication {{rarr}} Joomla\Application\AbstractApplication

===== JApplicationWeb =====

*<translate>
Old:</translate> JApplicationWeb {{rarr}} JApplicationBase {{rarr}} Joomla\Application\AbstractApplication
*<translate>
New:</translate> JApplicationWeb {{rarr}} Joomla\Application\AbstractWebApplication {{rarr}} Joomla\Application\AbstractApplication

<translate>
* The legacy ways of calling JApplicationWeb::redirect have been removed
** With a message and messageType parameters (call enqueueMessage separately)
** Passing in a true/false value as the 2nd/3rd params instead of a redirect code will give an InvalidArgumentException instead of defaulting to a 303</translate>
<translate> * JApplicationWeb::$singleValueResponseHeaders has been removed because the Framework Application will be internally using PSR-7 Response objects as of its 2.0 release. This changes how the headers data is stored so it is always a multi-dimensional array with each top level key being the header names and the value being an array holding all of the values for that header.</translate>

===== CMSApplication =====

*<translate> The $_clientId, $_messageQueue and $_name class properties have all been renamed to remove their underscore prefix.</translate>
* <translate> Now implements CMSApplicationInterface</translate>
* <translate> If there is an error retrieving a Pathway, Router or Menu object using the respective methods the exception will now bubble up rather than the method silently catching the exception and returning null</translate>
* <translate> CMSApplication::getInstance will now additionally try and load the user object (using the loadIdentity function)</translate>
* <translate> CMSApplication::isSite and CMSApplication::isAdmin have been removed as with the addition of the ConsoleApplication and ApiApplication can give misleading results. Please use CMSApplication::isClient (available from {{JVer | 3.7}}). For more information please see [[S:MyLanguage/J3.x:Discover_on_which_client_your_extension_code_is_running|Discover on which client your extension code is running]]</translate>

===== JApplicationSite =====
<translate>

The $_language_filter and $_detect_browser class properties have all been renamed to remove their underscore prefix.</translate>

<translate> The deprecated method JApplicationSite::getPageParameters has been removed in favour of it's alias JApplicationSite::getParams</translate>

===== JApplicationHelper =====

<translate> JApplicationHelper::parseXMLLangMetaFile has been removed without replacement.</translate>

<translate>
=== Archive === 
</translate>
*<translate> The archive package has been removed in favour of the frameworks archive package. Note the API should remain unchanged.</translate>
* <translate> Errors handing now uses Exceptions rather than JError</translate>

=== Client ===
\Joomla\CMS\Client\ClientWrapper has been removed. Use the static methods in \Joomla\CMS\Client\ClientHelper

=== Crypt ===
* JCrypt::hasStrongPasswordSupport has been removed without replacement as all PHP versions Joomla 4 matches will support strong password hashing.

<translate>
==== Removed Classes ==== 
</translate>

<translate>
The following ciphers have been removed in Joomla! 4.0:</translate>
*JCryptCipher3Des
*JCryptCipherBlowfish
*JCryptCipherMcrypt
*JCryptCipherRijndael256
*JCryptCipherSimple

<translate>
These have been removed without replacement. Use JCryptCipherCrypto</translate>

<translate>
==== Removed Methods ==== 
</translate>
* <translate> JCrypt::hasStrongPasswordSupport has been removed without replacement (this attempted to detect bcrypt polyfills on linux hosting but has always returned true since we required PHP 5.3.10 in Joomla 3.3)</translate>

<translate>
=== Cache === 
</translate>
* <translate> JCacheController::get now requires a callable. As a result JCacheControllerCallback::call has been removed.</translate>
* <translate> JCacheStorage::test has been removed. Use JCacheStorage::isSupported instead</translate>
* <translate> The default storage engines are no longer manually loaded as they are now autoloaded</translate>
* <translate> JCacheControllerOutput::start and JCacheControllerOutput::end have been removed without replacement</translate>
* <translate> Removed CacheLite storage as it not compatible with PHP7 (which is our minimum version)</translate>
* <translate> Error handling now uses Exceptions instead of JError</translate>

<translate>
=== Component === 
</translate>
* <translate> \Joomla\CMS\Component\ComponentRecord no longer extends JObject</translate>

<translate>
=== Document === 
</translate>

<translate>
==== Inheritance Change ==== 
</translate>
<translate>
The following classes have had their inheritance changed:
*JDocumentError (now extends from \Joomla\Cms\Document\HtmlDocument instead of \Joomla\Cms\Document\Document)</translate>

<translate> Note as a result of this change rendering an error page resets the document object in Joomla\CMS\Factory::$document, the rationale being we want a clean document to work from; if the error page is triggered we aren't interested in the metadata your component has set, or the media added from some bad module, or whatever plugins are adding to the display. We want a clean environment for rendering the error page only containing the error page's loaded data.</translate>

<translate>
==== Renderers ==== 
</translate>
* <translate> In order to comply with the RSS feed specification, JDocumentRendererFeedRss now allows the lastBuildDate element to be configured using the JDocumentFeed::$lastBuildDate class property when a feed is rendered. This value defaults to the current time, as is the case with Joomla! 3.x and earlier, however the time can be correctly set by changing this class property to a JDate object representing the desired timestamp.</translate>
* <translate> There is now a RendererInterface that all Renderers should implement</translate>
* <translate> JDocumentRenderer is now an abstract class and implements RendererInterface</translate>
* <translate> As an alternative to <jdoc:include type="head" /> you can now individually load <jdoc:include type="metas" /> for metadata, <jdoc:include type="styles" /> for CSS and <jdoc:include type="scripts" /> for javascript. The intention of this is to optionally allow users to place all javascript at the bottom of the HTML Document in their templates.</translate>

==== JDocumentFeed ====
<translate>
The property type of JDocumentFeed::$lastBuildDate has changed from a string to a JDate object. The property was previously unused by the core Joomla API but extensions may have used it.</translate>

<translate>
=== Database === 
</translate>
* <translate> This package has been replaced by the Joomla Framework Database Package</translate>
* <translate> Debug mode has been reworked (see the framework docs for more information</translate> [https://github.com/joomla-framework/database])

=== Factory ===
* <translate> Factory::getApplication no longer takes arguments. These were misleading as it always returned the active application after the first call in the bootstrap, whatever arguments were passed into the function.</translate>
* <translate> Factory::getXml has been removed along with JXMLElement. Use SimpleXMLElement directly instead.</translate>
* <translate> Factory:: getEditor has been removed use JEditor::getInstance instead.</translate>

<translate>
=== Environment === 
</translate>
* <noinclude>JBrowser::isSSLConnection has been removed. Use JApplicationCms::isSSLConnection (available since Joomla 3.2)</noinclude>

<translate>
=== Filesystem === 
</translate>
* <translate> The filesystem wrapper classes have been removed. Continue using the original static methods.</translate>

=== Filter ===
* JFilterInput::_remove has been removed in favour of JFilterInput::remove
* JFilterInput::_cleanTags has been removed in favour of JFilterInput::cleanTags
* JFilterInput::_cleanAttributes has been removed in favour of JFilterInput::cleanAttributes
* JFilterInput::_decode has been removed in favour of JFilterInput::decode
* JFilterInput::_escapeAttributeValues has been removed in favour of JFilterInput::escapeAttributeValues
* JFilterInput::_stripCSSExpressions has been removed in favour of JFilterInput::stripCSSExpressions

All of the above deprecations and removals are to allow the class to be reunified with the framework parent class.

=== Form ===
*<translate> The libraries/joomla/form/fields and libraries/joomla/form/rules directories are no longer registered to find form classes, all form classes should be autoloaded instead</translate>
*<translate> 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 [https://github.com/joomla/joomla-cms/pull/16419 this Github PR]</translate>
* <translate> JForm::getControlGroup has been removed use the alias JForm::renderField (available since Joomla 3.2.3)</translate>
* <translate> JForm::getControlGroups has been removed use the alias JForm::renderFieldset (available since Joomla 3.2.3)</translate>
* When rendering a field using the hiddenLabel option in JForm - it now only hides the label from the User Interface - the html is still rendered with the sr-only class for screen-reader accessibility purposes.
* <translate> JFormFieldUsergroup has been removed. Use Joomla\CMS\Form\Field\UsergrouplistField instead (available since Joomla 3.2)</translate>

==== Fields ====
* <translate>
JFormFieldFilelist and JFormFieldFolderList have had their filter properties renamed to <code>fileFilter</code> and <code>folderFilter</code> respectively (in order to allow the use of the regular Joomla filter attribute on returned values)</translate>
* JFormPredefinedlistField has its filter properties renamed to <code>optionsFilter</code> (in order to allow the use of the regular Joomla filter attribute on returned values)
* JFormFieldEditor::save has been removed without replacement
* JFormFieldText::getSuggestions has been removed in favour of JFormFieldText::getOptions

=== Wrapper ===
* The form wrapper classes have been removed. Continue using the original static methods.

=== HTTP ===

<translate>
==== Deprecated Classes and Interfaces ==== 
</translate>
<translate>
The following classes and interfaces have been deprecated and scheduled for removal in Joomla! 5.0:
*JHttpResponse (use Joomla\Http\Response instead)
*JHttpTransport (implement Joomla\Http\TransportInterface instead)</translate>

<translate>
==== Class Changes ==== 
</translate>
<translate>
The Framework's HTTP package is now included in Joomla! 4.0 and JHttp and the JHttpTransport subclasses have been refactored to use the upstream package.</translate>

===== JHttp =====
<translate>
The JHttp class constructor has been loosened with the following changes:</translate>
<translate>
*The options parameter is no longer typehinted as a Joomla\Registry\Registry object, an array or any object implementing the [https://secure.php.net/manual/en/class.arrayaccess.php ArrayAccess] interface can be used instead
*The transport parameter now allows any Joomla\Http\TransportInterface object.</translate>

===== JHttpTransport =====
<translate>
The now deprecated JHttpTransport interface extends Joomla\Http\TransportInterface now and has caused backward compatibility breaking changes in the interface. The constructor is no longer part of the interface, and the interface's `request()` method has had a signature change. Specifically, the second parameter which previously typehinted the JUri class now typehints Joomla\Uri\UriInterface.</translate>

===== JHttpResponse =====
<translate>
In refactoring the response object to inherit from the Framework's HTTP package, which is now using the PSR-7 ResponseInterface API, a minor compatibility break has been made in the structure of the response headers. As of 4.0, this will now always be a multi-dimensional array where the key is the header name and the value is an array of values for that header (previously, this was a string).</translate>

<translate>
=== Image === 
</translate>

<translate>
==== Deprecated Classes and Interfaces ==== 
</translate>
<translate>
The following classes and interfaces have been deprecated and scheduled for removal in Joomla! 5.0:
* JImageFilter (use Joomla\CMS\Image\ImageFilter instead)
* JImageFilterBackgroundfill (use Joomla\CMS\Image\Filter\Backgroundfill instead)
* JImageFilterBrightness (use Joomla\CMS\Image\Filter\Brightness instead)
* JImageFilterContrast (use Joomla\CMS\Image\Filter\Contrast instead)
* JImageFilterEdgedetect (use Joomla\CMS\Image\Filter\Edgedetect instead)
* JImageFilterEmboss (use Joomla\CMS\Image\Filter\Emboss instead)
* JImageFilterGrayscale (use Joomla\CMS\Image\Filter\Grayscale instead)
* JImageFilterNegate (use Joomla\CMS\Image\Filter\Negate instead)
* JImageFilterSketchy (use Joomla\CMS\Image\Filter\Sketchy instead)
* JImageFilterSmooth (use Joomla\CMS\Image\Filter\Smooth instead)</translate>

<translate>
==== Class Changes ==== 
</translate>
<translate>
The classes from Framework's Image package have been inlined into CMS and JImage and the JImageFilter subclasses have been refactored to use them. I.e. all classes under Joomla\Image namespace moved to Joomla\CMS\Image namespace.</translate>

<translate>

=== Menu === 
</translate>
* <translate> JMenu::$_items, JMenu::$_default and JMenu::$_active have been had their underscore prefix's removed (note these properties were protected so this only affects custom subclasses of JMenu)</translate>

=== New MVC Layer ===
* This has been removed in Joomla 4. We have decided that this effort was not successful and as a result have continued development work on the original MVC Layer (see the "Legacy MVC" section). There is a plugin located [https://github.com/joomla-extensions/legacy-mvc on GitHub] you can ship with your extensions whilst you migrate them back to the Legacy MVC (note that this is not shipped by default in Joomla 4).

=== Keychain ===
<translate> Removing the keychain with 4.0 has resulted in the removal of the following class:</translate>
*JKeychain

=== Pathway ===
* <translate> JPathway::$_pathway and JPathway::$_count have been had their underscore prefix's removed (note these properties were protected so this only affects custom subclasses of JPathway)</translate>
* <translate> JPathway::_makeItem has been removed in favour of JPathway::makeItem (note this method was protected so this only affects custom subclasses of JPathway)</translate>

=== Profiler ===
* JProfiler::getmicrotime and JProfiler::getMemory have been removed in favour of the native PHP methods they wrapped (<source lang="php" inline>microtime(1)</source> and <source lang="php" inline>memory_get_usage()</source> respectively

<translate>

=== Table === 
</translate>
<translate>

* JTable::__construct database object is now typehinted to be a JDatabaseDriver.
** Subclasses of JTable will need to ensure they are passing a JDatabaseDriver object to the parent constructor
** Subclasses of JTable will need to change the method signature of setDbo() if they have an extended version of that method to include the typehint
* There is a new method JTable::hasField - all instances of property_exists on JTable instances will now use this proxy method instead to allow better interoperability of Table instances
* The JTableObserver pattern (and corresponding classes) has been removed from JTable. JTable now triggers events and Tags, Content History (and any other custom uses of this pattern) should move to standard plugins.</translate>

<translate>
=== Mail === 
</translate>
<translate>
The following methods have been removed in Joomla! 4.0:</translate>
<translate>
* JMail::sendAdminMail has been removed</translate>

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

<translate>

=== Language === 
</translate>
<translate>
* The functions setTransliterator, setPluralSuffixesCallback, setIgnoredSearchWordsCallback, setLowerLimitSearchWordCallback, setUpperLimitSearchWordCallback and setSearchDisplayedCharactersNumberCallback are now typehinted to require a callable.
* The <tt>"_QQ_"</tt> placeholder for double quotes has been removed (this only existed to work around an old PHP Bug that has been fixed). Escape double quotes if required (i.e. <tt>\"</tt>)
</translate>
* The format for language file names has been changes to ease the work in 3rd party translation tools (such as crowdin). INI language files no longer have to contain the language code (i.e. en-GB.com_contact.ini => com_contact.ini), in this case the special case of en-GB.ini has been renamed to joomla.ini in the core language pack. en-GB.xml has been named langmetadata.xml. There is a b/c layer that will continue to read the old Joomla 3 file names throughout Joomla 4.
* \Joomla\CMS\Language\Multilanguage::getSiteLangs has been removed. Use \Joomla\CMS\Language\LanguageHelper::getInstalledLanguages(0) instead
* JLanguage::exists has been removed. Use Joomla\CMS\Language\LanguageHelper::exists instead.
* The wrapper classes JTextWrapper, LanguageHelperWrapper and TransliterateWrapper have been removed. Continue to use the static methods they wrapped
<translate>

=== Legacy MVC Layer === 
</translate>

<translate>
==== Legacy Controller ==== 
</translate>
<translate>
* JControllerLegacy has been removed from the legacy layer, and we no longer intend to remove it or it's subclasses in the near future.
* JControllerLegacy no longer extends JObject. Controllers should not call any of the methods contained in the JObject class.
* JControllerLegacy implements an interface for multiple task controllers
* JControllerLegacy::_construct now takes additional arguments. If you were previously getting a Controller object through JControllerLegacy::getInstance you do not need to change your code.
** Parameter 2: An optional MVCFactoryInterface instance
** Parameter 3: An optional CMSApplicationInterface instance
** Parameter 4: An optional Input instance
** Parameter 5: An optional FormFactoryInterface instance
* JControllerForm now using the StringInflector package to determine the list view. This should improve it's ability to guess determine the list view of more view names. If extension developers find that their list view is no longer being found they should manually set the `view_list` class property in their controller.</translate>

<translate>
==== Legacy View ==== 
</translate>
<translate>
* 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.</translate>

=== Library ===
* JLibraryHelper::_load has been removed. Use \Joomla\CMS\Helper\LibraryHelper::loadLibrary instead

<translate>
=== Session === 
</translate>
<translate>
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.</translate>

=== String ===
<translate> The old JString class alias has been removed. Use \Joomla\String\StringHelper instead</translate>

<translate>
==== Removed Classes and Interfaces ==== 
</translate>
<translate>
The following classes and interfaces have been removed in Joomla! 5.0:</translate>
*JSessionExceptionUnsupported
*JSessionHandlerInterface
*JSessionHandlerJoomla
*JSessionHandlerNative
*JSessionStorage
*JSessionStorageApc
*JSessionStorageDatabase
*JSessionStorageMemcache
*JSessionStorageMemcached
*JSessionStorageNone
*JSessionStorageWincache
*JSessionStorageXcache

<translate>
==== JSession ==== 
</translate>
<translate>
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.</translate>

<translate>
===== Namespace Parameter Deprecated ===== 
</translate>
<translate>
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.</translate>

<translate>
===== JSession::clear() Repurposed ===== 
</translate>
<translate>
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.</translate>

<translate>
===== JSession::getInstance() Deprecated ===== 
</translate>
<translate>
The singleton getInstance() method has been deprecated. The session object should be retrieved from the active application or the dependency injection container instead.</translate>

<translate>
===== Session Handlers ===== 
</translate>
<translate>
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 [https://secure.php.net/manual/en/class.sessionhandlerinterface.php 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.</translate>

<translate>
=== Social Media Libraries === 
</translate>
<translate> The facebook, github, google, linkedin, openstreetmap, mediawiki and twitter packages have all been removed from the CMS.</translate>

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

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

<translate>

=== Classes Removed Without Replacement === 
</translate>
* JNode
* JTree
* JGrid
* JError <translate> (use native exceptions when error handling is required)</translate>

<translate>
==== Utilities ==== 
</translate>

<translate>
===== Removed Classes and Interfaces ===== 
</translate>
<translate>

The following classes and interfaces have been removed in Joomla! 4.0:
*JArrayHelper
use Joomla\Utilities\ArrayHelper; instead.</translate>

<translate>

== External Libraries == 
</translate>
<translate>
The following changes have been made to the external libraries that Joomla! packages and ships.</translate>

=== PHPMailer ===
<translate>
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.</translate>

=== PHPUTF8 ===
<translate>
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.</translate>

=== SimplePie ===
<translate>
The SimplePie library is no longer included with Joomla! 4.0.</translate>

=== jQuery ===
<translate>
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.</translate>

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

=== Bootstrap ===
<translate>
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)</translate>

=== FOF ===
<translate> FOF 2.x has been removed.</translate>

<translate>
== Templates == 
</translate>
<translate>
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.</translate>

<translate> 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/]</translate>

* Joomla 4 will load the template favicon first rather than the one in the Joomla Root in keeping with the concept the template is the single source of truth.
* Frontend components and module views now use BEM class markup to make it easier for templates to support frameworks other than bootstrap. See [http://getbem.com/ the BEM website] for more information on how to build similar classes.

<translate>

== Other == 
</translate>
* The $_PROFILER global variable has been removed. Use \Joomla\CMS\Profiler\Profiler::getInstance instead

<translate>
=== Media in Libraries === 
</translate>
<translate> 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.</translate>

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

<translate>
=== Components === 
</translate>
* <translate> All components have been namespaced and directories reworked accordingly. For more information about this read the tutorial on building a component in Joomla 4</translate>
* <translate> 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)</translate>
* <translate> 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</translate>
* com_actionlogs CSV export headers have been changed to match the strings shown in the UI.
* <translate> 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]]</translate>
* The MailTo component has been removed without replacement. If you used this functionality you will need to find an alternative component on JED
* In com_contact 's frontend contact view - the contact property has been removed as it was a duplicate of the item property. We chose to keep $this->item as it was consistent with that in the article and tag views. Template overrides will need updating to reflect this.
* The repeatable field in com_fields has been removed in favour of the new subform field. Data from repeatable fields is automatically migrated to the new subform field but is stored in a different format.
* the xreference fields have been removed from ''#__contact_details'', ''#__content'' and ''#__newsfeeds'' as they were unused

<translate>

=== Plugins === 
</translate>
* <translate> 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]</translate>
* <translate> 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.</translate>
* <translate> The Recaptcha plugin now uses google's official php library for captcha under the hood</translate>
* <translate> 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]]</translate>
* 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
* <translate> 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)</translate>
* Returning before calling <source lang="php" inline>parent::__construct()</source> in the constructor of a plugin is no longer supported to avoid queuing the plugin into the event dispatcher
* *onUserBeforeDataValidation* is deprecated as an event in favor of *onContentBeforeValidateData* (as the event was usable by all content types and was not specific to users. Note both events will be called for the duration of Joomla 4 - however you should migrate your code to the new event when you no longer need to support Joomla 3.

<translate>

=== Administrator Helpers === 
</translate>
* <translate> JAdministratorHelper has been removed without replacement (it's been merged into JApplicationAdministrator)</translate>
* <translate> JSubMenuHelper has been removed without replacement (use JHtmlSidebar instead - available since 3.0)</translate>
* <translate> JToolbarHelper has been moved to the main libraries directory</translate>

<translate>
=== Modules === 
</translate>
* <translate> The administrator module "submenu" has been removed</translate>
* Logic of "Module Chromes" (module styles) in template files <code>html/modules.php</code> have been moved to <code>JLayout</code> files. <code>modChrome_x</code> functions in <code>modules.php</code> are no longer supported. See https://github.com/joomla/joomla-cms/pull/23570 for details.
* "Module Chromes" (module styles) <code>modChrome_horz</code>, <code>modChrome_xhtml</code>, <code>modChrome_rounded</code> have been removed from template <code>system</code> without replacement.
* Module Class Suffixes have been renamed and standardized. These now called Module Class and are appended to the list of classes in the Module Chrome (they are no longer rendered in the module output itself)
<translate>

=== Error Handling === 
</translate>
* <translate> 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)</translate>
* <translate> 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.</translate>
* <translate> Joomla\CMS\Exception\ExceptionHandler is now format aware and will render errors in html, json, xml, feed or cli aware formats</translate>
* <translate> 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.</translate>

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

=== Javascript ===
* caption.js has been removed from Joomla. Use the native HTML elements ''figure'' and ''figcaption'' (you can look the JLayout in layouts/joomla/content/intro_image.php for an example).

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

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

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

Potential backward compatibility issues in Joomla 4

2020-08-04T05:41:23Z

Sharky: Draggable typo

<noinclude><languages /></noinclude>
{{incomplete}}{{RightTOC}}<translate>
This document tracks potential backward compatibility issues for Joomla! 4. Listed are issues which potentially break extensions.


The base of this comparison is Joomla! 3.10.</translate>

<translate>
== Updated System Requirements == 
</translate>
<translate>
The system requirements have been updated as follows:
*PHP 7.2.5
*MySQL 5.6
*PostgreSQL 11.0
*SQL Server support has been dropped.</translate>

<translate>
=== PHP MySQL Extension === 
</translate>
<translate>
*Joomla no longer supports using PHP's ext/mysql driver (which was removed in PHP 7.0). Joomla will automatically try and use the mysqli extension (available since PHP 5.3) or the mysql PDO Driver (available since PHP 5.3) else it will fail to create a database connection.</translate>
<translate> * Strict mode has been enabled. The following flags are now active by default in Joomla 4 and you may have to update your database queries accordingly. This will help us with future MySQL version upgrades and also aligns more closely with Postgres to enable easier compatibility with queries in both languages.</translate>

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

As a consequence, Joomla 4 will only use '''NULL date defaults'''. The use of the "invalid default date" 0000-00-00 00:00:00 in Joomla 4 has been deprecated.

<translate>

=== PHP Postgres Extension === 
</translate>
*<translate> Joomla no longer supports using PHP's ext/pgsql driver. Joomla will automatically try and use the PostgreSQL PDO Driver (available since PHP 5.3 and Joomla 3.9) else it will fail to create a database connection with a Postgres Database.</translate>

<translate>
=== PHP GMP Extension === 
</translate>
<translate> This is required for using the WebAuthn feature. Note it is installed by default on the majority of hosting sites.</translate>
<translate>
=== PHP mcrypt Extension === 
</translate>
<translate> This is required for using the Joomla\CMS\Crypt\Cipher\CrytoCipher class and it's alias JCryptCipherCrypto.</translate>

<translate>

== CMS Libraries == 
</translate>
<translate>
The following changes have been made to Joomla! CMS libraries (this is primarily code that was found in the “libraries/cms” directory in Joomla! 3.7 and earlier).</translate>

<translate>
=== Installer === 
</translate>
* <translate> Plugin discover installs will no longer search for xml files in the Joomla! 1.5 plugin folder layouts</translate>
* <translate> In 3.x, only plugins scripts have the preflight method called and none make postflight available during the uninstall process. All extensions types will have these hooks available in 4.0 when being uninstalled. If you currently preflight and postflight and assume they only apply in an install/update context - this logic is now incorrect and you should use the install route (given as one of the method parameters)</translate>
* <translate> When uninstalling a plugin the uninstall function in the extension script is now triggered before triggering any SQL queries (this is now consistent with all other extension types).</translate>

<translate>
==== Removed Classes ==== 
</translate>
<translate>
The following classes have been removed in Joomla! 4.0:
*JInstallerComponent (use JInstallerAdapterComponent instead)
*JInstallerFile (use JInstallerAdapterFile instead)
*JInstallerLanguage (use JInstallerAdapterLanguage instead)
*JInstallerLibrary (use JInstallerAdapterLibrary instead)
*JInstallerModule (use JInstallerAdapterModule instead)
*JInstallerPackage (use JInstallerAdapterPackage instead)
*JInstallerPlugin (use JInstallerAdapterPlugin instead)
*JInstallerTemplate (use JInstallerAdapterTemplate instead)
*JSubMenuHelper (use JHtmlSidebar instead; note that in contrast to JSubMenuHelper, this requires an addition of a placeholder in your view template)
</translate>

<translate>
==== JInstallerAdapter Inheritance ==== 
</translate>
<translate>
JInstallerAdapter no longer extends from JAdapterInstance and inherently JObject.</translate>

<translate> Custom Installer Adapters must now be autoloaded.</translate>

<translate>
=== Menu === 
</translate>
<translate>
==== JMenu is now an abstract class ==== 
</translate>
<translate>
JMenu is now an abstract class. Subclasses of JMenu must now also implement a load method.</translate>

<translate>
==== Manual Include Behavior Removed ==== 
</translate>
<translate>
The logic in JMenu::getInstance() to manually include a file from the application's includes/menu.php path has been removed. The JMenu subclass should be autoloaded instead.</translate>

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

=== Pagination ===
* The magic pagination functions ''pagination_item_active'', ''pagination_item_inactive'' have been removed. Use the JLayout's joomla.pagination.link instead
* The magic pagination function ''pagination_list_render'' is deprecated. Use the JLayout joomla.pagination.list instead

<translate>

=== Pathway === 
</translate>

<translate>
==== Manual Include Behavior Removed ==== 
</translate>
<translate>
The logic in JPathway::getInstance() to manually include a file from the application's includes/pathway.php path has been removed. The JPathway subclass should be autoloaded instead.</translate>

<translate>
=== Router === 
</translate>

<translate>
==== Manual Include Behavior Removed ==== 
</translate>
<translate>
The logic in JRouter::getInstance() to manually include a file from the application's includes/router.php path has been removed. The JRouter subclass should be autoloaded instead.</translate>

<translate>
==== Method Signature Changes ==== 
</translate>
<translate> The attachBuildRule and attachParseRule are now typehinted to require callables.</translate>

<translate>
=== JVersion === 
</translate>
<translate>
Support for accessing the JVersion class constants as class properties is no longer supported. The constants were introduced in Joomla! 3.5 to prevent the old class properties from being edited.</translate>

<translate> The following deprecated constants have been removed:</translate>
* JVersion::RELEASE
* JVersion::DEV_LEVEL
* JVersion::BUILD

<translate>
=== JHtml === 
</translate>
* <translate> The register function in JHtml is now typehinted to require a callable. Subclasses of JHtml will now need to match this signature (note this was already required at the function code level already).</translate>
* <translate> JHtml::_ no longer allows you to call non-public methods in JHtml</translate>
* <translate> JHtml::_ is now a final method (you can no longer override it if you subclass JHtml) and it's signature has changed to take advantage of modern PHP features (scalar and variadic typehints)</translate>
* <translate> JHtmlBootstrap::modal has been removed. Use JHtmlBootstrap::renderModal</translate>
* JHtmlSortablelist::sortable has been deprecated in favour of JHtmlDragdablelist::draggable - the old method acts as a proxy to the new method currently to facilitate the removal of jQuery UI from Joomla Core. All media assets relating to the original jQuery UI implementation have been removed.
* JHtmlBatch has been removed as all the code had been moved to layouts for template overrides. Use the JLayouts directly in your code.

<translate>

=== Updater === 


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

== Platform == 
</translate>
<translate>
The following changes have been made to Joomla! Platform libraries (this is primarily code found in the `libraries/joomla` or `libraries/legacy` directories in Joomla! 3).</translate>

=== Access ===
* JAccess::$assetPermissionsById and JAccess::$assetPermissionsByName and JAccess::preloadPermissionsParentIdMapping have been removed without replacement. Since 3.6 we've used other methods and class properties to optimize the loading of assets (see [https://github.com/joomla/joomla-cms/pull/12850 this PR] for the reasons why this was deprecated)
* JAccess::getActions has been removed. Use JAccess::getActionsFromFile or JAccess::getActionsFromData instead.

<translate>
=== Application === 
</translate>

<translate>
==== Removed Classes ==== 
</translate>
<translate>
The following classes have been removed in Joomla! 4.0:
*JApplicationWebRouter (use the `joomla/router` package instead)
*JApplicationWebRouterBase (use the `joomla/router` package instead)
*JApplicationWebRouterRest (use the `joomla/router` package instead)</translate>

All references to JSite and JAdministrator have been removed (these were just class alias' since Joomla 3.2)

<translate>

==== Deprecated Classes ==== 
</translate>
<translate>
The following classes have been deprecated and scheduled for removal in Joomla! 5.0:
*JApplicationBase (use Joomla\Application\AbstractApplication instead)</translate>

<translate>
==== CLI/Web Class Changes ==== 
</translate>
<translate>
The JApplicationCli and JApplicationWeb classes have been recomposed to extend from the Framework's Application package instead. This breaks type checks for a JApplicationBase object. For forward compatibility, it is recommended to check if application classes are an instance of Joomla\Application\AbstractApplication (JApplicationBase has extended this class since Joomla! 3.4).</translate>

<translate>
Additionally, both of these classes are now abstract. Developers implementing these classes must provide a `doExecute` method with their application's logic.</translate>

<translate> The registerEvent method is now typehinted to require a callable for the $handler parameter.</translate>

<translate> Applications that want to support both Web and CLI Applications should now typehint against the \Joomla\CMS\Application\ CMSApplicationInterface - this contains common methods (some of which in Joomla 3.x were only found in the JApplicationCms class) that can be used by all code. It's strongly recommended any custom applications (especially CLI applications) implement this interface to make compatibility checks easier, simultaneously any typehints should use the interface rather than a concrete class.</translate>

===== JApplicationCli =====

*<translate>
Old:</translate> JApplicationCli {{rarr}} JApplicationBase {{rarr}} Joomla\Application\AbstractApplication
*<translate>
New:</translate> JApplicationCli {{rarr}} Joomla\Application\AbstractCliApplication {{rarr}} Joomla\Application\AbstractApplication

===== JApplicationWeb =====

*<translate>
Old:</translate> JApplicationWeb {{rarr}} JApplicationBase {{rarr}} Joomla\Application\AbstractApplication
*<translate>
New:</translate> JApplicationWeb {{rarr}} Joomla\Application\AbstractWebApplication {{rarr}} Joomla\Application\AbstractApplication

<translate>
* The legacy ways of calling JApplicationWeb::redirect have been removed
** With a message and messageType parameters (call enqueueMessage separately)
** Passing in a true/false value as the 2nd/3rd params instead of a redirect code will give an InvalidArgumentException instead of defaulting to a 303</translate>
<translate> * JApplicationWeb::$singleValueResponseHeaders has been removed because the Framework Application will be internally using PSR-7 Response objects as of its 2.0 release. This changes how the headers data is stored so it is always a multi-dimensional array with each top level key being the header names and the value being an array holding all of the values for that header.</translate>

===== CMSApplication =====

*<translate> The $_clientId, $_messageQueue and $_name class properties have all been renamed to remove their underscore prefix.</translate>
* <translate> Now implements CMSApplicationInterface</translate>
* <translate> If there is an error retrieving a Pathway, Router or Menu object using the respective methods the exception will now bubble up rather than the method silently catching the exception and returning null</translate>
* <translate> CMSApplication::getInstance will now additionally try and load the user object (using the loadIdentity function)</translate>
* <translate> CMSApplication::isSite and CMSApplication::isAdmin have been removed as with the addition of the ConsoleApplication and ApiApplication can give misleading results. Please use CMSApplication::isClient (available from {{JVer | 3.7}}). For more information please see [[S:MyLanguage/J3.x:Discover_on_which_client_your_extension_code_is_running|Discover on which client your extension code is running]]</translate>

===== JApplicationSite =====
<translate>

The $_language_filter and $_detect_browser class properties have all been renamed to remove their underscore prefix.</translate>

<translate> The deprecated method JApplicationSite::getPageParameters has been removed in favour of it's alias JApplicationSite::getParams</translate>

===== JApplicationHelper =====

<translate> JApplicationHelper::parseXMLLangMetaFile has been removed without replacement.</translate>

<translate>
=== Archive === 
</translate>
*<translate> The archive package has been removed in favour of the frameworks archive package. Note the API should remain unchanged.</translate>
* <translate> Errors handing now uses Exceptions rather than JError</translate>

=== Client ===
\Joomla\CMS\Client\ClientWrapper has been removed. Use the static methods in \Joomla\CMS\Client\ClientHelper

=== Crypt ===
* JCrypt::hasStrongPasswordSupport has been removed without replacement as all PHP versions Joomla 4 matches will support strong password hashing.

<translate>
==== Removed Classes ==== 
</translate>

<translate>
The following ciphers have been removed in Joomla! 4.0:</translate>
*JCryptCipher3Des
*JCryptCipherBlowfish
*JCryptCipherMcrypt
*JCryptCipherRijndael256
*JCryptCipherSimple

<translate>
These have been removed without replacement. Use JCryptCipherCrypto</translate>

<translate>
==== Removed Methods ==== 
</translate>
* <translate> JCrypt::hasStrongPasswordSupport has been removed without replacement (this attempted to detect bcrypt polyfills on linux hosting but has always returned true since we required PHP 5.3.10 in Joomla 3.3)</translate>

<translate>
=== Cache === 
</translate>
* <translate> JCacheController::get now requires a callable. As a result JCacheControllerCallback::call has been removed.</translate>
* <translate> JCacheStorage::test has been removed. Use JCacheStorage::isSupported instead</translate>
* <translate> The default storage engines are no longer manually loaded as they are now autoloaded</translate>
* <translate> JCacheControllerOutput::start and JCacheControllerOutput::end have been removed without replacement</translate>
* <translate> Removed CacheLite storage as it not compatible with PHP7 (which is our minimum version)</translate>
* <translate> Error handling now uses Exceptions instead of JError</translate>

<translate>
=== Component === 
</translate>
* <translate> \Joomla\CMS\Component\ComponentRecord no longer extends JObject</translate>

<translate>
=== Document === 
</translate>

<translate>
==== Inheritance Change ==== 
</translate>
<translate>
The following classes have had their inheritance changed:
*JDocumentError (now extends from \Joomla\Cms\Document\HtmlDocument instead of \Joomla\Cms\Document\Document)</translate>

<translate> Note as a result of this change rendering an error page resets the document object in Joomla\CMS\Factory::$document, the rationale being we want a clean document to work from; if the error page is triggered we aren't interested in the metadata your component has set, or the media added from some bad module, or whatever plugins are adding to the display. We want a clean environment for rendering the error page only containing the error page's loaded data.</translate>

<translate>
==== Renderers ==== 
</translate>
* <translate> In order to comply with the RSS feed specification, JDocumentRendererFeedRss now allows the lastBuildDate element to be configured using the JDocumentFeed::$lastBuildDate class property when a feed is rendered. This value defaults to the current time, as is the case with Joomla! 3.x and earlier, however the time can be correctly set by changing this class property to a JDate object representing the desired timestamp.</translate>
* <translate> There is now a RendererInterface that all Renderers should implement</translate>
* <translate> JDocumentRenderer is now an abstract class and implements RendererInterface</translate>
* <translate> As an alternative to <jdoc:include type="head" /> you can now individually load <jdoc:include type="metas" /> for metadata, <jdoc:include type="styles" /> for CSS and <jdoc:include type="scripts" /> for javascript. The intention of this is to optionally allow users to place all javascript at the bottom of the HTML Document in their templates.</translate>

==== JDocumentFeed ====
<translate>
The property type of JDocumentFeed::$lastBuildDate has changed from a string to a JDate object. The property was previously unused by the core Joomla API but extensions may have used it.</translate>

<translate>
=== Database === 
</translate>
* <translate> This package has been replaced by the Joomla Framework Database Package</translate>
* <translate> Debug mode has been reworked (see the framework docs for more information</translate> [https://github.com/joomla-framework/database])

=== Factory ===
* <translate> Factory::getApplication no longer takes arguments. These were misleading as it always returned the active application after the first call in the bootstrap, whatever arguments were passed into the function.</translate>
* <translate> Factory::getXml has been removed along with JXMLElement. Use SimpleXMLElement directly instead.</translate>
* <translate> Factory:: getEditor has been removed use JEditor::getInstance instead.</translate>

<translate>
=== Environment === 
</translate>
* <noinclude>JBrowser::isSSLConnection has been removed. Use JApplicationCms::isSSLConnection (available since Joomla 3.2)</noinclude>

<translate>
=== Filesystem === 
</translate>
* <translate> The filesystem wrapper classes have been removed. Continue using the original static methods.</translate>

=== Filter ===
* JFilterInput::_remove has been removed in favour of JFilterInput::remove
* JFilterInput::_cleanTags has been removed in favour of JFilterInput::cleanTags
* JFilterInput::_cleanAttributes has been removed in favour of JFilterInput::cleanAttributes
* JFilterInput::_decode has been removed in favour of JFilterInput::decode
* JFilterInput::_escapeAttributeValues has been removed in favour of JFilterInput::escapeAttributeValues
* JFilterInput::_stripCSSExpressions has been removed in favour of JFilterInput::stripCSSExpressions

All of the above deprecations and removals are to allow the class to be reunified with the framework parent class.

=== Form ===
*<translate> The libraries/joomla/form/fields and libraries/joomla/form/rules directories are no longer registered to find form classes, all form classes should be autoloaded instead</translate>
*<translate> 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 [https://github.com/joomla/joomla-cms/pull/16419 this Github PR]</translate>
* <translate> JForm::getControlGroup has been removed use the alias JForm::renderField (available since Joomla 3.2.3)</translate>
* <translate> JForm::getControlGroups has been removed use the alias JForm::renderFieldset (available since Joomla 3.2.3)</translate>
* When rendering a field using the hiddenLabel option in JForm - it now only hides the label from the User Interface - the html is still rendered with the sr-only class for screen-reader accessibility purposes.
* <translate> JFormFieldUsergroup has been removed. Use Joomla\CMS\Form\Field\UsergrouplistField instead (available since Joomla 3.2)</translate>

==== Fields ====
* <translate>
JFormFieldFilelist and JFormFieldFolderList have had their filter properties renamed to <code>fileFilter</code> and <code>folderFilter</code> respectively (in order to allow the use of the regular Joomla filter attribute on returned values)</translate>
* JFormPredefinedlistField has its filter properties renamed to <code>optionsFilter</code> (in order to allow the use of the regular Joomla filter attribute on returned values)
* JFormFieldEditor::save has been removed without replacement
* JFormFieldText::getSuggestions has been removed in favour of JFormFieldText::getOptions

=== Wrapper ===
* The form wrapper classes have been removed. Continue using the original static methods.

=== HTTP ===

<translate>
==== Deprecated Classes and Interfaces ==== 
</translate>
<translate>
The following classes and interfaces have been deprecated and scheduled for removal in Joomla! 5.0:
*JHttpResponse (use Joomla\Http\Response instead)
*JHttpTransport (implement Joomla\Http\TransportInterface instead)</translate>

<translate>
==== Class Changes ==== 
</translate>
<translate>
The Framework's HTTP package is now included in Joomla! 4.0 and JHttp and the JHttpTransport subclasses have been refactored to use the upstream package.</translate>

===== JHttp =====
<translate>
The JHttp class constructor has been loosened with the following changes:</translate>
<translate>
*The options parameter is no longer typehinted as a Joomla\Registry\Registry object, an array or any object implementing the [https://secure.php.net/manual/en/class.arrayaccess.php ArrayAccess] interface can be used instead
*The transport parameter now allows any Joomla\Http\TransportInterface object.</translate>

===== JHttpTransport =====
<translate>
The now deprecated JHttpTransport interface extends Joomla\Http\TransportInterface now and has caused backward compatibility breaking changes in the interface. The constructor is no longer part of the interface, and the interface's `request()` method has had a signature change. Specifically, the second parameter which previously typehinted the JUri class now typehints Joomla\Uri\UriInterface.</translate>

===== JHttpResponse =====
<translate>
In refactoring the response object to inherit from the Framework's HTTP package, which is now using the PSR-7 ResponseInterface API, a minor compatibility break has been made in the structure of the response headers. As of 4.0, this will now always be a multi-dimensional array where the key is the header name and the value is an array of values for that header (previously, this was a string).</translate>

<translate>
=== Image === 
</translate>

<translate>
==== Deprecated Classes and Interfaces ==== 
</translate>
<translate>
The following classes and interfaces have been deprecated and scheduled for removal in Joomla! 5.0:
* JImageFilter (use Joomla\CMS\Image\ImageFilter instead)
* JImageFilterBackgroundfill (use Joomla\CMS\Image\Filter\Backgroundfill instead)
* JImageFilterBrightness (use Joomla\CMS\Image\Filter\Brightness instead)
* JImageFilterContrast (use Joomla\CMS\Image\Filter\Contrast instead)
* JImageFilterEdgedetect (use Joomla\CMS\Image\Filter\Edgedetect instead)
* JImageFilterEmboss (use Joomla\CMS\Image\Filter\Emboss instead)
* JImageFilterGrayscale (use Joomla\CMS\Image\Filter\Grayscale instead)
* JImageFilterNegate (use Joomla\CMS\Image\Filter\Negate instead)
* JImageFilterSketchy (use Joomla\CMS\Image\Filter\Sketchy instead)
* JImageFilterSmooth (use Joomla\CMS\Image\Filter\Smooth instead)</translate>

<translate>
==== Class Changes ==== 
</translate>
<translate>
The classes from Framework's Image package have been inlined into CMS and JImage and the JImageFilter subclasses have been refactored to use them. I.e. all classes under Joomla\Image namespace moved to Joomla\CMS\Image namespace.</translate>

<translate>

=== Menu === 
</translate>
* <translate> JMenu::$_items, JMenu::$_default and JMenu::$_active have been had their underscore prefix's removed (note these properties were protected so this only affects custom subclasses of JMenu)</translate>

=== New MVC Layer ===
* This has been removed in Joomla 4. We have decided that this effort was not successful and as a result have continued development work on the original MVC Layer (see the "Legacy MVC" section). There is a plugin located [https://github.com/joomla-extensions/legacy-mvc on GitHub] you can ship with your extensions whilst you migrate them back to the Legacy MVC (note that this is not shipped by default in Joomla 4).

=== Keychain ===
<translate> Removing the keychain with 4.0 has resulted in the removal of the following class:</translate>
*JKeychain

=== Pathway ===
* <translate> JPathway::$_pathway and JPathway::$_count have been had their underscore prefix's removed (note these properties were protected so this only affects custom subclasses of JPathway)</translate>
* <translate> JPathway::_makeItem has been removed in favour of JPathway::makeItem (note this method was protected so this only affects custom subclasses of JPathway)</translate>

=== Profiler ===
* JProfiler::getmicrotime and JProfiler::getMemory have been removed in favour of the native PHP methods they wrapped (<source lang="php" inline>microtime(1)</source> and <source lang="php" inline>memory_get_usage()</source> respectively

<translate>

=== Table === 
</translate>
<translate>

* JTable::__construct database object is now typehinted to be a JDatabaseDriver.
** Subclasses of JTable will need to ensure they are passing a JDatabaseDriver object to the parent constructor
** Subclasses of JTable will need to change the method signature of setDbo() if they have an extended version of that method to include the typehint
* There is a new method JTable::hasField - all instances of property_exists on JTable instances will now use this proxy method instead to allow better interoperability of Table instances
* The JTableObserver pattern (and corresponding classes) has been removed from JTable. JTable now triggers events and Tags, Content History (and any other custom uses of this pattern) should move to standard plugins.</translate>

<translate>
=== Mail === 
</translate>
<translate>
The following methods have been removed in Joomla! 4.0:</translate>
<translate>
* JMail::sendAdminMail has been removed</translate>

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

<translate>

=== Language === 
</translate>
<translate>
* The functions setTransliterator, setPluralSuffixesCallback, setIgnoredSearchWordsCallback, setLowerLimitSearchWordCallback, setUpperLimitSearchWordCallback and setSearchDisplayedCharactersNumberCallback are now typehinted to require a callable.
* The <tt>"_QQ_"</tt> placeholder for double quotes has been removed (this only existed to work around an old PHP Bug that has been fixed). Escape double quotes if required (i.e. <tt>\"</tt>)
</translate>
* The format for language file names has been changes to ease the work in 3rd party translation tools (such as crowdin). INI language files no longer have to contain the language code (i.e. en-GB.com_contact.ini => com_contact.ini), in this case the special case of en-GB.ini has been renamed to joomla.ini in the core language pack. en-GB.xml has been named langmetadata.xml. There is a b/c layer that will continue to read the old Joomla 3 file names throughout Joomla 4.
* \Joomla\CMS\Language\Multilanguage::getSiteLangs has been removed. Use \Joomla\CMS\Language\LanguageHelper::getInstalledLanguages(0) instead
* JLanguage::exists has been removed. Use Joomla\CMS\Language\LanguageHelper::exists instead.
* The wrapper classes JTextWrapper, LanguageHelperWrapper and TransliterateWrapper have been removed. Continue to use the static methods they wrapped
<translate>

=== Legacy MVC Layer === 
</translate>

<translate>
==== Legacy Controller ==== 
</translate>
<translate>
* JControllerLegacy has been removed from the legacy layer, and we no longer intend to remove it or it's subclasses in the near future.
* JControllerLegacy no longer extends JObject. Controllers should not call any of the methods contained in the JObject class.
* JControllerLegacy implements an interface for multiple task controllers
* JControllerLegacy::_construct now takes additional arguments. If you were previously getting a Controller object through JControllerLegacy::getInstance you do not need to change your code.
** Parameter 2: An optional MVCFactoryInterface instance
** Parameter 3: An optional CMSApplicationInterface instance
** Parameter 4: An optional Input instance
** Parameter 5: An optional FormFactoryInterface instance
* JControllerForm now using the StringInflector package to determine the list view. This should improve it's ability to guess determine the list view of more view names. If extension developers find that their list view is no longer being found they should manually set the `view_list` class property in their controller.</translate>

<translate>
==== Legacy View ==== 
</translate>
<translate>
* 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.</translate>

=== Library ===
* JLibraryHelper::_load has been removed. Use \Joomla\CMS\Helper\LibraryHelper::loadLibrary instead

<translate>
=== Session === 
</translate>
<translate>
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.</translate>

=== String ===
<translate> The old JString class alias has been removed. Use \Joomla\String\StringHelper instead</translate>

<translate>
==== Removed Classes and Interfaces ==== 
</translate>
<translate>
The following classes and interfaces have been removed in Joomla! 5.0:</translate>
*JSessionExceptionUnsupported
*JSessionHandlerInterface
*JSessionHandlerJoomla
*JSessionHandlerNative
*JSessionStorage
*JSessionStorageApc
*JSessionStorageDatabase
*JSessionStorageMemcache
*JSessionStorageMemcached
*JSessionStorageNone
*JSessionStorageWincache
*JSessionStorageXcache

<translate>
==== JSession ==== 
</translate>
<translate>
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.</translate>

<translate>
===== Namespace Parameter Deprecated ===== 
</translate>
<translate>
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.</translate>

<translate>
===== JSession::clear() Repurposed ===== 
</translate>
<translate>
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.</translate>

<translate>
===== JSession::getInstance() Deprecated ===== 
</translate>
<translate>
The singleton getInstance() method has been deprecated. The session object should be retrieved from the active application or the dependency injection container instead.</translate>

<translate>
===== Session Handlers ===== 
</translate>
<translate>
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 [https://secure.php.net/manual/en/class.sessionhandlerinterface.php 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.</translate>

<translate>
=== Social Media Libraries === 
</translate>
<translate> The facebook, github, google, linkedin, openstreetmap, mediawiki and twitter packages have all been removed from the CMS.</translate>

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

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

<translate>

=== Classes Removed Without Replacement === 
</translate>
* JNode
* JTree
* JGrid
* JError <translate> (use native exceptions when error handling is required)</translate>

<translate>
==== Utilities ==== 
</translate>

<translate>
===== Removed Classes and Interfaces ===== 
</translate>
<translate>

The following classes and interfaces have been removed in Joomla! 4.0:
*JArrayHelper
use Joomla\Utilities\ArrayHelper; instead.</translate>

<translate>

== External Libraries == 
</translate>
<translate>
The following changes have been made to the external libraries that Joomla! packages and ships.</translate>

=== PHPMailer ===
<translate>
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.</translate>

=== PHPUTF8 ===
<translate>
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.</translate>

=== SimplePie ===
<translate>
The SimplePie library is no longer included with Joomla! 4.0.</translate>

=== jQuery ===
<translate>
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.</translate>

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

=== Bootstrap ===
<translate>
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)</translate>

=== FOF ===
<translate> FOF 2.x has been removed.</translate>

<translate>
== Templates == 
</translate>
<translate>
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.</translate>

<translate> 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/]</translate>

* Joomla 4 will load the template favicon first rather than the one in the Joomla Root in keeping with the concept the template is the single source of truth.
* Frontend components and module views now use BEM class markup to make it easier for templates to support frameworks other than bootstrap. See [http://getbem.com/ the BEM website] for more information on how to build similar classes.

<translate>

== Other == 
</translate>
* The $_PROFILER global variable has been removed. Use \Joomla\CMS\Profiler\Profiler::getInstance instead

<translate>
=== Media in Libraries === 
</translate>
<translate> 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.</translate>

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

<translate>
=== Components === 
</translate>
* <translate> All components have been namespaced and directories reworked accordingly. For more information about this read the tutorial on building a component in Joomla 4</translate>
* <translate> 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)</translate>
* <translate> 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</translate>
* com_actionlogs CSV export headers have been changed to match the strings shown in the UI.
* <translate> 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]]</translate>
* The MailTo component has been removed without replacement. If you used this functionality you will need to find an alternative component on JED
* In com_contact 's frontend contact view - the contact property has been removed as it was a duplicate of the item property. We chose to keep $this->item as it was consistent with that in the article and tag views. Template overrides will need updating to reflect this.
* The repeatable field in com_fields has been removed in favour of the new subform field. Data from repeatable fields is automatically migrated to the new subform field but is stored in a different format.
* the xreference fields have been removed from ''#__contact_details'', ''#__content'' and ''#__newsfeeds'' as they were unused

<translate>

=== Plugins === 
</translate>
* <translate> 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]</translate>
* <translate> 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.</translate>
* <translate> The Recaptcha plugin now uses google's official php library for captcha under the hood</translate>
* <translate> 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]]</translate>
* 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
* <translate> 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)</translate>
* Returning before calling <source lang="php" inline>parent::__construct()</source> in the constructor of a plugin is no longer supported to avoid queuing the plugin into the event dispatcher
* *onUserBeforeDataValidation* is deprecated as an event in favor of *onContentBeforeValidateData* (as the event was usable by all content types and was not specific to users. Note both events will be called for the duration of Joomla 4 - however you should migrate your code to the new event when you no longer need to support Joomla 3.

<translate>

=== Administrator Helpers === 
</translate>
* <translate> JAdministratorHelper has been removed without replacement (it's been merged into JApplicationAdministrator)</translate>
* <translate> JSubMenuHelper has been removed without replacement (use JHtmlSidebar instead - available since 3.0)</translate>
* <translate> JToolbarHelper has been moved to the main libraries directory</translate>

<translate>
=== Modules === 
</translate>
* <translate> The administrator module "submenu" has been removed</translate>
* Logic of "Module Chromes" (module styles) in template files <code>html/modules.php</code> have been moved to <code>JLayout</code> files. <code>modChrome_x</code> functions in <code>modules.php</code> are no longer supported. See https://github.com/joomla/joomla-cms/pull/23570 for details.
* "Module Chromes" (module styles) <code>modChrome_horz</code>, <code>modChrome_xhtml</code>, <code>modChrome_rounded</code> have been removed from template <code>system</code> without replacement.
* Module Class Suffixes have been renamed and standardized. These now called Module Class and are appended to the list of classes in the Module Chrome (they are no longer rendered in the module output itself)
<translate>

=== Error Handling === 
</translate>
* <translate> 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)</translate>
* <translate> 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.</translate>
* <translate> Joomla\CMS\Exception\ExceptionHandler is now format aware and will render errors in html, json, xml, feed or cli aware formats</translate>
* <translate> 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.</translate>

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

=== Javascript ===
* caption.js has been removed from Joomla. Use the native HTML elements ''figure'' and ''figcaption'' (you can look the JLayout in layouts/joomla/content/intro_image.php for an example).

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

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

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

Potential backward compatibility issues in Joomla 4

2020-08-04T05:40:09Z

Sharky: Update Image documentation

<noinclude><languages /></noinclude>
{{incomplete}}{{RightTOC}}<translate>
This document tracks potential backward compatibility issues for Joomla! 4. Listed are issues which potentially break extensions.


The base of this comparison is Joomla! 3.10.</translate>

<translate>
== Updated System Requirements == 
</translate>
<translate>
The system requirements have been updated as follows:
*PHP 7.2.5
*MySQL 5.6
*PostgreSQL 11.0
*SQL Server support has been dropped.</translate>

<translate>
=== PHP MySQL Extension === 
</translate>
<translate>
*Joomla no longer supports using PHP's ext/mysql driver (which was removed in PHP 7.0). Joomla will automatically try and use the mysqli extension (available since PHP 5.3) or the mysql PDO Driver (available since PHP 5.3) else it will fail to create a database connection.</translate>
<translate> * Strict mode has been enabled. The following flags are now active by default in Joomla 4 and you may have to update your database queries accordingly. This will help us with future MySQL version upgrades and also aligns more closely with Postgres to enable easier compatibility with queries in both languages.</translate>

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

As a consequence, Joomla 4 will only use '''NULL date defaults'''. The use of the "invalid default date" 0000-00-00 00:00:00 in Joomla 4 has been deprecated.

<translate>

=== PHP Postgres Extension === 
</translate>
*<translate> Joomla no longer supports using PHP's ext/pgsql driver. Joomla will automatically try and use the PostgreSQL PDO Driver (available since PHP 5.3 and Joomla 3.9) else it will fail to create a database connection with a Postgres Database.</translate>

<translate>
=== PHP GMP Extension === 
</translate>
<translate> This is required for using the WebAuthn feature. Note it is installed by default on the majority of hosting sites.</translate>
<translate>
=== PHP mcrypt Extension === 
</translate>
<translate> This is required for using the Joomla\CMS\Crypt\Cipher\CrytoCipher class and it's alias JCryptCipherCrypto.</translate>

<translate>

== CMS Libraries == 
</translate>
<translate>
The following changes have been made to Joomla! CMS libraries (this is primarily code that was found in the “libraries/cms” directory in Joomla! 3.7 and earlier).</translate>

<translate>
=== Installer === 
</translate>
* <translate> Plugin discover installs will no longer search for xml files in the Joomla! 1.5 plugin folder layouts</translate>
* <translate> In 3.x, only plugins scripts have the preflight method called and none make postflight available during the uninstall process. All extensions types will have these hooks available in 4.0 when being uninstalled. If you currently preflight and postflight and assume they only apply in an install/update context - this logic is now incorrect and you should use the install route (given as one of the method parameters)</translate>
* <translate> When uninstalling a plugin the uninstall function in the extension script is now triggered before triggering any SQL queries (this is now consistent with all other extension types).</translate>

<translate>
==== Removed Classes ==== 
</translate>
<translate>
The following classes have been removed in Joomla! 4.0:
*JInstallerComponent (use JInstallerAdapterComponent instead)
*JInstallerFile (use JInstallerAdapterFile instead)
*JInstallerLanguage (use JInstallerAdapterLanguage instead)
*JInstallerLibrary (use JInstallerAdapterLibrary instead)
*JInstallerModule (use JInstallerAdapterModule instead)
*JInstallerPackage (use JInstallerAdapterPackage instead)
*JInstallerPlugin (use JInstallerAdapterPlugin instead)
*JInstallerTemplate (use JInstallerAdapterTemplate instead)
*JSubMenuHelper (use JHtmlSidebar instead; note that in contrast to JSubMenuHelper, this requires an addition of a placeholder in your view template)
</translate>

<translate>
==== JInstallerAdapter Inheritance ==== 
</translate>
<translate>
JInstallerAdapter no longer extends from JAdapterInstance and inherently JObject.</translate>

<translate> Custom Installer Adapters must now be autoloaded.</translate>

<translate>
=== Menu === 
</translate>
<translate>
==== JMenu is now an abstract class ==== 
</translate>
<translate>
JMenu is now an abstract class. Subclasses of JMenu must now also implement a load method.</translate>

<translate>
==== Manual Include Behavior Removed ==== 
</translate>
<translate>
The logic in JMenu::getInstance() to manually include a file from the application's includes/menu.php path has been removed. The JMenu subclass should be autoloaded instead.</translate>

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

=== Pagination ===
* The magic pagination functions ''pagination_item_active'', ''pagination_item_inactive'' have been removed. Use the JLayout's joomla.pagination.link instead
* The magic pagination function ''pagination_list_render'' is deprecated. Use the JLayout joomla.pagination.list instead

<translate>

=== Pathway === 
</translate>

<translate>
==== Manual Include Behavior Removed ==== 
</translate>
<translate>
The logic in JPathway::getInstance() to manually include a file from the application's includes/pathway.php path has been removed. The JPathway subclass should be autoloaded instead.</translate>

<translate>
=== Router === 
</translate>

<translate>
==== Manual Include Behavior Removed ==== 
</translate>
<translate>
The logic in JRouter::getInstance() to manually include a file from the application's includes/router.php path has been removed. The JRouter subclass should be autoloaded instead.</translate>

<translate>
==== Method Signature Changes ==== 
</translate>
<translate> The attachBuildRule and attachParseRule are now typehinted to require callables.</translate>

<translate>
=== JVersion === 
</translate>
<translate>
Support for accessing the JVersion class constants as class properties is no longer supported. The constants were introduced in Joomla! 3.5 to prevent the old class properties from being edited.</translate>

<translate> The following deprecated constants have been removed:</translate>
* JVersion::RELEASE
* JVersion::DEV_LEVEL
* JVersion::BUILD

<translate>
=== JHtml === 
</translate>
* <translate> The register function in JHtml is now typehinted to require a callable. Subclasses of JHtml will now need to match this signature (note this was already required at the function code level already).</translate>
* <translate> JHtml::_ no longer allows you to call non-public methods in JHtml</translate>
* <translate> JHtml::_ is now a final method (you can no longer override it if you subclass JHtml) and it's signature has changed to take advantage of modern PHP features (scalar and variadic typehints)</translate>
* <translate> JHtmlBootstrap::modal has been removed. Use JHtmlBootstrap::renderModal</translate>
* JHtmlSortablelist::sortable has been deprecated in favour of JHtmlDragablelist::dragable - the old method acts as a proxy to the new method currently to facilitate the removal of jQuery UI from Joomla Core. All media assets relating to the original jQuery UI implementation have been removed.
* JHtmlBatch has been removed as all the code had been moved to layouts for template overrides. Use the JLayouts directly in your code.

<translate>
=== Updater === 


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

== Platform == 
</translate>
<translate>
The following changes have been made to Joomla! Platform libraries (this is primarily code found in the `libraries/joomla` or `libraries/legacy` directories in Joomla! 3).</translate>

=== Access ===
* JAccess::$assetPermissionsById and JAccess::$assetPermissionsByName and JAccess::preloadPermissionsParentIdMapping have been removed without replacement. Since 3.6 we've used other methods and class properties to optimize the loading of assets (see [https://github.com/joomla/joomla-cms/pull/12850 this PR] for the reasons why this was deprecated)
* JAccess::getActions has been removed. Use JAccess::getActionsFromFile or JAccess::getActionsFromData instead.

<translate>
=== Application === 
</translate>

<translate>
==== Removed Classes ==== 
</translate>
<translate>
The following classes have been removed in Joomla! 4.0:
*JApplicationWebRouter (use the `joomla/router` package instead)
*JApplicationWebRouterBase (use the `joomla/router` package instead)
*JApplicationWebRouterRest (use the `joomla/router` package instead)</translate>

All references to JSite and JAdministrator have been removed (these were just class alias' since Joomla 3.2)

<translate>

==== Deprecated Classes ==== 
</translate>
<translate>
The following classes have been deprecated and scheduled for removal in Joomla! 5.0:
*JApplicationBase (use Joomla\Application\AbstractApplication instead)</translate>

<translate>
==== CLI/Web Class Changes ==== 
</translate>
<translate>
The JApplicationCli and JApplicationWeb classes have been recomposed to extend from the Framework's Application package instead. This breaks type checks for a JApplicationBase object. For forward compatibility, it is recommended to check if application classes are an instance of Joomla\Application\AbstractApplication (JApplicationBase has extended this class since Joomla! 3.4).</translate>

<translate>
Additionally, both of these classes are now abstract. Developers implementing these classes must provide a `doExecute` method with their application's logic.</translate>

<translate> The registerEvent method is now typehinted to require a callable for the $handler parameter.</translate>

<translate> Applications that want to support both Web and CLI Applications should now typehint against the \Joomla\CMS\Application\ CMSApplicationInterface - this contains common methods (some of which in Joomla 3.x were only found in the JApplicationCms class) that can be used by all code. It's strongly recommended any custom applications (especially CLI applications) implement this interface to make compatibility checks easier, simultaneously any typehints should use the interface rather than a concrete class.</translate>

===== JApplicationCli =====

*<translate>
Old:</translate> JApplicationCli {{rarr}} JApplicationBase {{rarr}} Joomla\Application\AbstractApplication
*<translate>
New:</translate> JApplicationCli {{rarr}} Joomla\Application\AbstractCliApplication {{rarr}} Joomla\Application\AbstractApplication

===== JApplicationWeb =====

*<translate>
Old:</translate> JApplicationWeb {{rarr}} JApplicationBase {{rarr}} Joomla\Application\AbstractApplication
*<translate>
New:</translate> JApplicationWeb {{rarr}} Joomla\Application\AbstractWebApplication {{rarr}} Joomla\Application\AbstractApplication

<translate>
* The legacy ways of calling JApplicationWeb::redirect have been removed
** With a message and messageType parameters (call enqueueMessage separately)
** Passing in a true/false value as the 2nd/3rd params instead of a redirect code will give an InvalidArgumentException instead of defaulting to a 303</translate>
<translate> * JApplicationWeb::$singleValueResponseHeaders has been removed because the Framework Application will be internally using PSR-7 Response objects as of its 2.0 release. This changes how the headers data is stored so it is always a multi-dimensional array with each top level key being the header names and the value being an array holding all of the values for that header.</translate>

===== CMSApplication =====

*<translate> The $_clientId, $_messageQueue and $_name class properties have all been renamed to remove their underscore prefix.</translate>
* <translate> Now implements CMSApplicationInterface</translate>
* <translate> If there is an error retrieving a Pathway, Router or Menu object using the respective methods the exception will now bubble up rather than the method silently catching the exception and returning null</translate>
* <translate> CMSApplication::getInstance will now additionally try and load the user object (using the loadIdentity function)</translate>
* <translate> CMSApplication::isSite and CMSApplication::isAdmin have been removed as with the addition of the ConsoleApplication and ApiApplication can give misleading results. Please use CMSApplication::isClient (available from {{JVer | 3.7}}). For more information please see [[S:MyLanguage/J3.x:Discover_on_which_client_your_extension_code_is_running|Discover on which client your extension code is running]]</translate>

===== JApplicationSite =====
<translate>

The $_language_filter and $_detect_browser class properties have all been renamed to remove their underscore prefix.</translate>

<translate> The deprecated method JApplicationSite::getPageParameters has been removed in favour of it's alias JApplicationSite::getParams</translate>

===== JApplicationHelper =====

<translate> JApplicationHelper::parseXMLLangMetaFile has been removed without replacement.</translate>

<translate>
=== Archive === 
</translate>
*<translate> The archive package has been removed in favour of the frameworks archive package. Note the API should remain unchanged.</translate>
* <translate> Errors handing now uses Exceptions rather than JError</translate>

=== Client ===
\Joomla\CMS\Client\ClientWrapper has been removed. Use the static methods in \Joomla\CMS\Client\ClientHelper

=== Crypt ===
* JCrypt::hasStrongPasswordSupport has been removed without replacement as all PHP versions Joomla 4 matches will support strong password hashing.

<translate>
==== Removed Classes ==== 
</translate>

<translate>
The following ciphers have been removed in Joomla! 4.0:</translate>
*JCryptCipher3Des
*JCryptCipherBlowfish
*JCryptCipherMcrypt
*JCryptCipherRijndael256
*JCryptCipherSimple

<translate>
These have been removed without replacement. Use JCryptCipherCrypto</translate>

<translate>
==== Removed Methods ==== 
</translate>
* <translate> JCrypt::hasStrongPasswordSupport has been removed without replacement (this attempted to detect bcrypt polyfills on linux hosting but has always returned true since we required PHP 5.3.10 in Joomla 3.3)</translate>

<translate>
=== Cache === 
</translate>
* <translate> JCacheController::get now requires a callable. As a result JCacheControllerCallback::call has been removed.</translate>
* <translate> JCacheStorage::test has been removed. Use JCacheStorage::isSupported instead</translate>
* <translate> The default storage engines are no longer manually loaded as they are now autoloaded</translate>
* <translate> JCacheControllerOutput::start and JCacheControllerOutput::end have been removed without replacement</translate>
* <translate> Removed CacheLite storage as it not compatible with PHP7 (which is our minimum version)</translate>
* <translate> Error handling now uses Exceptions instead of JError</translate>

<translate>
=== Component === 
</translate>
* <translate> \Joomla\CMS\Component\ComponentRecord no longer extends JObject</translate>

<translate>
=== Document === 
</translate>

<translate>
==== Inheritance Change ==== 
</translate>
<translate>
The following classes have had their inheritance changed:
*JDocumentError (now extends from \Joomla\Cms\Document\HtmlDocument instead of \Joomla\Cms\Document\Document)</translate>

<translate> Note as a result of this change rendering an error page resets the document object in Joomla\CMS\Factory::$document, the rationale being we want a clean document to work from; if the error page is triggered we aren't interested in the metadata your component has set, or the media added from some bad module, or whatever plugins are adding to the display. We want a clean environment for rendering the error page only containing the error page's loaded data.</translate>

<translate>
==== Renderers ==== 
</translate>
* <translate> In order to comply with the RSS feed specification, JDocumentRendererFeedRss now allows the lastBuildDate element to be configured using the JDocumentFeed::$lastBuildDate class property when a feed is rendered. This value defaults to the current time, as is the case with Joomla! 3.x and earlier, however the time can be correctly set by changing this class property to a JDate object representing the desired timestamp.</translate>
* <translate> There is now a RendererInterface that all Renderers should implement</translate>
* <translate> JDocumentRenderer is now an abstract class and implements RendererInterface</translate>
* <translate> As an alternative to <jdoc:include type="head" /> you can now individually load <jdoc:include type="metas" /> for metadata, <jdoc:include type="styles" /> for CSS and <jdoc:include type="scripts" /> for javascript. The intention of this is to optionally allow users to place all javascript at the bottom of the HTML Document in their templates.</translate>

==== JDocumentFeed ====
<translate>
The property type of JDocumentFeed::$lastBuildDate has changed from a string to a JDate object. The property was previously unused by the core Joomla API but extensions may have used it.</translate>

<translate>
=== Database === 
</translate>
* <translate> This package has been replaced by the Joomla Framework Database Package</translate>
* <translate> Debug mode has been reworked (see the framework docs for more information</translate> [https://github.com/joomla-framework/database])

=== Factory ===
* <translate> Factory::getApplication no longer takes arguments. These were misleading as it always returned the active application after the first call in the bootstrap, whatever arguments were passed into the function.</translate>
* <translate> Factory::getXml has been removed along with JXMLElement. Use SimpleXMLElement directly instead.</translate>
* <translate> Factory:: getEditor has been removed use JEditor::getInstance instead.</translate>

<translate>
=== Environment === 
</translate>
* <noinclude>JBrowser::isSSLConnection has been removed. Use JApplicationCms::isSSLConnection (available since Joomla 3.2)</noinclude>

<translate>
=== Filesystem === 
</translate>
* <translate> The filesystem wrapper classes have been removed. Continue using the original static methods.</translate>

=== Filter ===
* JFilterInput::_remove has been removed in favour of JFilterInput::remove
* JFilterInput::_cleanTags has been removed in favour of JFilterInput::cleanTags
* JFilterInput::_cleanAttributes has been removed in favour of JFilterInput::cleanAttributes
* JFilterInput::_decode has been removed in favour of JFilterInput::decode
* JFilterInput::_escapeAttributeValues has been removed in favour of JFilterInput::escapeAttributeValues
* JFilterInput::_stripCSSExpressions has been removed in favour of JFilterInput::stripCSSExpressions

All of the above deprecations and removals are to allow the class to be reunified with the framework parent class.

=== Form ===
*<translate> The libraries/joomla/form/fields and libraries/joomla/form/rules directories are no longer registered to find form classes, all form classes should be autoloaded instead</translate>
*<translate> 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 [https://github.com/joomla/joomla-cms/pull/16419 this Github PR]</translate>
* <translate> JForm::getControlGroup has been removed use the alias JForm::renderField (available since Joomla 3.2.3)</translate>
* <translate> JForm::getControlGroups has been removed use the alias JForm::renderFieldset (available since Joomla 3.2.3)</translate>
* When rendering a field using the hiddenLabel option in JForm - it now only hides the label from the User Interface - the html is still rendered with the sr-only class for screen-reader accessibility purposes.
* <translate> JFormFieldUsergroup has been removed. Use Joomla\CMS\Form\Field\UsergrouplistField instead (available since Joomla 3.2)</translate>

==== Fields ====
* <translate>
JFormFieldFilelist and JFormFieldFolderList have had their filter properties renamed to <code>fileFilter</code> and <code>folderFilter</code> respectively (in order to allow the use of the regular Joomla filter attribute on returned values)</translate>
* JFormPredefinedlistField has its filter properties renamed to <code>optionsFilter</code> (in order to allow the use of the regular Joomla filter attribute on returned values)
* JFormFieldEditor::save has been removed without replacement
* JFormFieldText::getSuggestions has been removed in favour of JFormFieldText::getOptions

=== Wrapper ===
* The form wrapper classes have been removed. Continue using the original static methods.

=== HTTP ===

<translate>
==== Deprecated Classes and Interfaces ==== 
</translate>
<translate>
The following classes and interfaces have been deprecated and scheduled for removal in Joomla! 5.0:
*JHttpResponse (use Joomla\Http\Response instead)
*JHttpTransport (implement Joomla\Http\TransportInterface instead)</translate>

<translate>
==== Class Changes ==== 
</translate>
<translate>
The Framework's HTTP package is now included in Joomla! 4.0 and JHttp and the JHttpTransport subclasses have been refactored to use the upstream package.</translate>

===== JHttp =====
<translate>
The JHttp class constructor has been loosened with the following changes:</translate>
<translate>
*The options parameter is no longer typehinted as a Joomla\Registry\Registry object, an array or any object implementing the [https://secure.php.net/manual/en/class.arrayaccess.php ArrayAccess] interface can be used instead
*The transport parameter now allows any Joomla\Http\TransportInterface object.</translate>

===== JHttpTransport =====
<translate>
The now deprecated JHttpTransport interface extends Joomla\Http\TransportInterface now and has caused backward compatibility breaking changes in the interface. The constructor is no longer part of the interface, and the interface's `request()` method has had a signature change. Specifically, the second parameter which previously typehinted the JUri class now typehints Joomla\Uri\UriInterface.</translate>

===== JHttpResponse =====
<translate>
In refactoring the response object to inherit from the Framework's HTTP package, which is now using the PSR-7 ResponseInterface API, a minor compatibility break has been made in the structure of the response headers. As of 4.0, this will now always be a multi-dimensional array where the key is the header name and the value is an array of values for that header (previously, this was a string).</translate>

<translate>
=== Image === 
</translate>

<translate>
==== Deprecated Classes and Interfaces ==== 
</translate>
<translate>
The following classes and interfaces have been deprecated and scheduled for removal in Joomla! 5.0:
* JImageFilter (use Joomla\CMS\Image\ImageFilter instead)
* JImageFilterBackgroundfill (use Joomla\CMS\Image\Filter\Backgroundfill instead)
* JImageFilterBrightness (use Joomla\CMS\Image\Filter\Brightness instead)
* JImageFilterContrast (use Joomla\CMS\Image\Filter\Contrast instead)
* JImageFilterEdgedetect (use Joomla\CMS\Image\Filter\Edgedetect instead)
* JImageFilterEmboss (use Joomla\CMS\Image\Filter\Emboss instead)
* JImageFilterGrayscale (use Joomla\CMS\Image\Filter\Grayscale instead)
* JImageFilterNegate (use Joomla\CMS\Image\Filter\Negate instead)
* JImageFilterSketchy (use Joomla\CMS\Image\Filter\Sketchy instead)
* JImageFilterSmooth (use Joomla\CMS\Image\Filter\Smooth instead)</translate>

<translate>
==== Class Changes ==== 
</translate>
<translate>
The classes from Framework's Image package have been inlined into CMS and JImage and the JImageFilter subclasses have been refactored to use them. I.e. all classes under Joomla\Image namespace moved to Joomla\CMS\Image namespace.</translate>

<translate>

=== Menu === 
</translate>
* <translate> JMenu::$_items, JMenu::$_default and JMenu::$_active have been had their underscore prefix's removed (note these properties were protected so this only affects custom subclasses of JMenu)</translate>

=== New MVC Layer ===
* This has been removed in Joomla 4. We have decided that this effort was not successful and as a result have continued development work on the original MVC Layer (see the "Legacy MVC" section). There is a plugin located [https://github.com/joomla-extensions/legacy-mvc on GitHub] you can ship with your extensions whilst you migrate them back to the Legacy MVC (note that this is not shipped by default in Joomla 4).

=== Keychain ===
<translate> Removing the keychain with 4.0 has resulted in the removal of the following class:</translate>
*JKeychain

=== Pathway ===
* <translate> JPathway::$_pathway and JPathway::$_count have been had their underscore prefix's removed (note these properties were protected so this only affects custom subclasses of JPathway)</translate>
* <translate> JPathway::_makeItem has been removed in favour of JPathway::makeItem (note this method was protected so this only affects custom subclasses of JPathway)</translate>

=== Profiler ===
* JProfiler::getmicrotime and JProfiler::getMemory have been removed in favour of the native PHP methods they wrapped (<source lang="php" inline>microtime(1)</source> and <source lang="php" inline>memory_get_usage()</source> respectively

<translate>

=== Table === 
</translate>
<translate>

* JTable::__construct database object is now typehinted to be a JDatabaseDriver.
** Subclasses of JTable will need to ensure they are passing a JDatabaseDriver object to the parent constructor
** Subclasses of JTable will need to change the method signature of setDbo() if they have an extended version of that method to include the typehint
* There is a new method JTable::hasField - all instances of property_exists on JTable instances will now use this proxy method instead to allow better interoperability of Table instances
* The JTableObserver pattern (and corresponding classes) has been removed from JTable. JTable now triggers events and Tags, Content History (and any other custom uses of this pattern) should move to standard plugins.</translate>

<translate>
=== Mail === 
</translate>
<translate>
The following methods have been removed in Joomla! 4.0:</translate>
<translate>
* JMail::sendAdminMail has been removed</translate>

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

<translate>

=== Language === 
</translate>
<translate>
* The functions setTransliterator, setPluralSuffixesCallback, setIgnoredSearchWordsCallback, setLowerLimitSearchWordCallback, setUpperLimitSearchWordCallback and setSearchDisplayedCharactersNumberCallback are now typehinted to require a callable.
* The <tt>"_QQ_"</tt> placeholder for double quotes has been removed (this only existed to work around an old PHP Bug that has been fixed). Escape double quotes if required (i.e. <tt>\"</tt>)
</translate>
* The format for language file names has been changes to ease the work in 3rd party translation tools (such as crowdin). INI language files no longer have to contain the language code (i.e. en-GB.com_contact.ini => com_contact.ini), in this case the special case of en-GB.ini has been renamed to joomla.ini in the core language pack. en-GB.xml has been named langmetadata.xml. There is a b/c layer that will continue to read the old Joomla 3 file names throughout Joomla 4.
* \Joomla\CMS\Language\Multilanguage::getSiteLangs has been removed. Use \Joomla\CMS\Language\LanguageHelper::getInstalledLanguages(0) instead
* JLanguage::exists has been removed. Use Joomla\CMS\Language\LanguageHelper::exists instead.
* The wrapper classes JTextWrapper, LanguageHelperWrapper and TransliterateWrapper have been removed. Continue to use the static methods they wrapped
<translate>

=== Legacy MVC Layer === 
</translate>

<translate>
==== Legacy Controller ==== 
</translate>
<translate>
* JControllerLegacy has been removed from the legacy layer, and we no longer intend to remove it or it's subclasses in the near future.
* JControllerLegacy no longer extends JObject. Controllers should not call any of the methods contained in the JObject class.
* JControllerLegacy implements an interface for multiple task controllers
* JControllerLegacy::_construct now takes additional arguments. If you were previously getting a Controller object through JControllerLegacy::getInstance you do not need to change your code.
** Parameter 2: An optional MVCFactoryInterface instance
** Parameter 3: An optional CMSApplicationInterface instance
** Parameter 4: An optional Input instance
** Parameter 5: An optional FormFactoryInterface instance
* JControllerForm now using the StringInflector package to determine the list view. This should improve it's ability to guess determine the list view of more view names. If extension developers find that their list view is no longer being found they should manually set the `view_list` class property in their controller.</translate>

<translate>
==== Legacy View ==== 
</translate>
<translate>
* 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.</translate>

=== Library ===
* JLibraryHelper::_load has been removed. Use \Joomla\CMS\Helper\LibraryHelper::loadLibrary instead

<translate>
=== Session === 
</translate>
<translate>
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.</translate>

=== String ===
<translate> The old JString class alias has been removed. Use \Joomla\String\StringHelper instead</translate>

<translate>
==== Removed Classes and Interfaces ==== 
</translate>
<translate>
The following classes and interfaces have been removed in Joomla! 5.0:</translate>
*JSessionExceptionUnsupported
*JSessionHandlerInterface
*JSessionHandlerJoomla
*JSessionHandlerNative
*JSessionStorage
*JSessionStorageApc
*JSessionStorageDatabase
*JSessionStorageMemcache
*JSessionStorageMemcached
*JSessionStorageNone
*JSessionStorageWincache
*JSessionStorageXcache

<translate>
==== JSession ==== 
</translate>
<translate>
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.</translate>

<translate>
===== Namespace Parameter Deprecated ===== 
</translate>
<translate>
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.</translate>

<translate>
===== JSession::clear() Repurposed ===== 
</translate>
<translate>
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.</translate>

<translate>
===== JSession::getInstance() Deprecated ===== 
</translate>
<translate>
The singleton getInstance() method has been deprecated. The session object should be retrieved from the active application or the dependency injection container instead.</translate>

<translate>
===== Session Handlers ===== 
</translate>
<translate>
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 [https://secure.php.net/manual/en/class.sessionhandlerinterface.php 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.</translate>

<translate>
=== Social Media Libraries === 
</translate>
<translate> The facebook, github, google, linkedin, openstreetmap, mediawiki and twitter packages have all been removed from the CMS.</translate>

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

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

<translate>

=== Classes Removed Without Replacement === 
</translate>
* JNode
* JTree
* JGrid
* JError <translate> (use native exceptions when error handling is required)</translate>

<translate>
==== Utilities ==== 
</translate>

<translate>
===== Removed Classes and Interfaces ===== 
</translate>
<translate>

The following classes and interfaces have been removed in Joomla! 4.0:
*JArrayHelper
use Joomla\Utilities\ArrayHelper; instead.</translate>

<translate>

== External Libraries == 
</translate>
<translate>
The following changes have been made to the external libraries that Joomla! packages and ships.</translate>

=== PHPMailer ===
<translate>
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.</translate>

=== PHPUTF8 ===
<translate>
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.</translate>

=== SimplePie ===
<translate>
The SimplePie library is no longer included with Joomla! 4.0.</translate>

=== jQuery ===
<translate>
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.</translate>

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

=== Bootstrap ===
<translate>
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)</translate>

=== FOF ===
<translate> FOF 2.x has been removed.</translate>

<translate>
== Templates == 
</translate>
<translate>
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.</translate>

<translate> 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/]</translate>

* Joomla 4 will load the template favicon first rather than the one in the Joomla Root in keeping with the concept the template is the single source of truth.
* Frontend components and module views now use BEM class markup to make it easier for templates to support frameworks other than bootstrap. See [http://getbem.com/ the BEM website] for more information on how to build similar classes.

<translate>

== Other == 
</translate>
* The $_PROFILER global variable has been removed. Use \Joomla\CMS\Profiler\Profiler::getInstance instead

<translate>
=== Media in Libraries === 
</translate>
<translate> 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.</translate>

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

<translate>
=== Components === 
</translate>
* <translate> All components have been namespaced and directories reworked accordingly. For more information about this read the tutorial on building a component in Joomla 4</translate>
* <translate> 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)</translate>
* <translate> 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</translate>
* com_actionlogs CSV export headers have been changed to match the strings shown in the UI.
* <translate> 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]]</translate>
* The MailTo component has been removed without replacement. If you used this functionality you will need to find an alternative component on JED
* In com_contact 's frontend contact view - the contact property has been removed as it was a duplicate of the item property. We chose to keep $this->item as it was consistent with that in the article and tag views. Template overrides will need updating to reflect this.
* The repeatable field in com_fields has been removed in favour of the new subform field. Data from repeatable fields is automatically migrated to the new subform field but is stored in a different format.
* the xreference fields have been removed from ''#__contact_details'', ''#__content'' and ''#__newsfeeds'' as they were unused

<translate>

=== Plugins === 
</translate>
* <translate> 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]</translate>
* <translate> 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.</translate>
* <translate> The Recaptcha plugin now uses google's official php library for captcha under the hood</translate>
* <translate> 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]]</translate>
* 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
* <translate> 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)</translate>
* Returning before calling <source lang="php" inline>parent::__construct()</source> in the constructor of a plugin is no longer supported to avoid queuing the plugin into the event dispatcher
* *onUserBeforeDataValidation* is deprecated as an event in favor of *onContentBeforeValidateData* (as the event was usable by all content types and was not specific to users. Note both events will be called for the duration of Joomla 4 - however you should migrate your code to the new event when you no longer need to support Joomla 3.

<translate>

=== Administrator Helpers === 
</translate>
* <translate> JAdministratorHelper has been removed without replacement (it's been merged into JApplicationAdministrator)</translate>
* <translate> JSubMenuHelper has been removed without replacement (use JHtmlSidebar instead - available since 3.0)</translate>
* <translate> JToolbarHelper has been moved to the main libraries directory</translate>

<translate>
=== Modules === 
</translate>
* <translate> The administrator module "submenu" has been removed</translate>
* Logic of "Module Chromes" (module styles) in template files <code>html/modules.php</code> have been moved to <code>JLayout</code> files. <code>modChrome_x</code> functions in <code>modules.php</code> are no longer supported. See https://github.com/joomla/joomla-cms/pull/23570 for details.
* "Module Chromes" (module styles) <code>modChrome_horz</code>, <code>modChrome_xhtml</code>, <code>modChrome_rounded</code> have been removed from template <code>system</code> without replacement.
* Module Class Suffixes have been renamed and standardized. These now called Module Class and are appended to the list of classes in the Module Chrome (they are no longer rendered in the module output itself)
<translate>

=== Error Handling === 
</translate>
* <translate> 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)</translate>
* <translate> 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.</translate>
* <translate> Joomla\CMS\Exception\ExceptionHandler is now format aware and will render errors in html, json, xml, feed or cli aware formats</translate>
* <translate> 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.</translate>

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

=== Javascript ===
* caption.js has been removed from Joomla. Use the native HTML elements ''figure'' and ''figcaption'' (you can look the JLayout in layouts/joomla/content/intro_image.php for an example).

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

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

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

Plugin/Events/System

2019-11-27T06:38:34Z

Sharky: Remove reference to onBeforeExecute event

This topic is aimed at "global" system events, including those triggered on every page load (onAfterInitialise, onAfterRoute, onAfterDispatch, onAfterRender). Visit [[Plugin/Events|Plugin Events]] for a complete list over available core events.

== onAfterInitialise ==
=== Description ===

This event is triggered after the framework has loaded and the application initialise method has been called.

=== Parameters ===

None.

=== Return Value ===

None.

=== Called in files ===

*<tt>index.php</tt>
*<tt>administrator/index.php</tt>

== onAfterRoute ==
=== Description ===

This event is triggered after the framework has loaded and initialised and the router has routed the client request.

Routing is the process of examining the request environment to determine which component should receive the request. The component optional parameters are then set in the request object that will be processed when the application is being dispatched.

When this event triggers, the router has parsed the route and pushed the request parameters into JInput to be retrieved by the application.

====Beware====

It's bad practice to instantiate the <code>Document</code> object inside this and earlier running plugin events. Don't use <code>Factory::getApplication()->getDocument()</code>, <code>Factory::getDocument();</code> or HTMLHelper/JHtml methods in <code>function onAfterRoute()</code> that instantiate the <code>Document</code> too early (e.g. for loading scripts or stylesheets). See also comments [https://github.com/joomla/joomla-cms/pull/25669#issuecomment-513574075 github.com/joomla/joomla-cms/pull/25669#issuecomment-513574075] and [https://github.com/joomla/joomla-cms/pull/25669#issuecomment-513574282 github.com/joomla/joomla-cms/pull/25669#issuecomment-513574282]

=== Parameters ===

None.

=== Return Value ===

None.

=== Used in files ===

* <tt>index.php</tt>
* <tt>administrator/index.php</tt>

==onAfterDispatch==
=== Description ===
This event is triggered after the framework has dispatched the application.

Dispatching is the process of pulling the option from the request object and mapping them to a component. If the component does not exist, it handles determining a default component to dispatch.

When this event is triggered the output of the component is available in the document buffer.

=== Parameters ===

None.

=== Return Value ===

None.

=== Used in files ===

* <tt>index.php</tt>
* <tt>administrator/index.php</tt>

==onBeforeRender==
=== Description ===
This event is triggered immediately before the framework has rendered the application.

=== Parameters ===

None.

=== Return Value ===

None.

=== Used in files ===

* <tt>includes/application.php</tt>
* <tt>administrator/includes/application.php</tt>

==onAfterRender==
=== Description ===
This event is triggered after the framework has rendered the application.

When this event is triggered the output of the application is available in the response buffer.

=== Parameters ===

None.

=== Return Value ===

None.

=== Used in files ===

* <tt>includes/application.php</tt>
* <tt>administrator/includes/application.php</tt>

==onBeforeCompileHead==
=== Description ===
This event is triggered before the framework creates the Head section of the Document.

=== Parameters ===

None.

===Return Value===

None.

===Used in files===

* <tt>libraries/joomla/document/html/renderer/head.php</tt>

==Example==
This is an example system plugin. Please note that because system plugins are loaded before any other event group, they may also contain any other event.

The following class would be located in the file <tt>/plugins/system/example/example.php</tt>.

<source lang="php">
<?php
defined('_JEXEC') or die;

/**
* Example system plugin
*
* @since 1.0
*/
class plgSystemExample extends JPlugin
{
/**
* Constructor.
*
* @param object &$subject The object to observe.
* @param array $config An optional associative array of configuration settings.
*
* @since 1.0
*/
public function __construct(&$subject, $config)
{
// Calling the parent Constructor
parent::__construct($subject, $config);

// Do some extra initialisation in this constructor if required
}

/**
* Listener for the `onAfterInitialise` event
*
* @return void
*
* @since 1.0
*/
public function onAfterInitialise()
{
// Do something onAfterInitialise
}

/**
* Listener for the `onAfterRoute` event
*
* @return void
*
* @since 1.0
*/
public function onAfterRoute()
{
// Do something onAfterRoute
}

/**
* Listener for the `onAfterDispatch` event
*
* @return void
*
* @since 1.0
*/
public function onAfterDispatch()
{
// Do something onAfterDispatch
}

/**
* Listener for the `onAfterRender` event
*
* @return void
*
* @since 1.0
*/
public function onAfterRender()
{
// Do something onAfterRender
}
}
</source>

The plugin's XML installation file would be located at <tt>/plugins/system/example/example.xml</tt> would be defined as follows:

<source lang="xml">
<?xml version="1.0" encoding="utf-8"?>
<extension version="3.7" type="plugin" group="system">
<name>plg_system_example</name>
<author>Author</author>
<creationDate>Month 2008</creationDate>
<copyright>Copyright (C) 2008 Holder. All rights reserved.</copyright>
<license>GNU General Public License</license>
<authorEmail>email</authorEmail>
<authorUrl>url</authorUrl>
<version>1.0.1</version>
<description>An example system plugin</description>
<files>
<filename plugin="example">example.php</filename>
</files>
<config>
<fields name="params">
<fieldset name="basic">
<field
name="example"
type="text"
default=""
label="Example"
description="An example text parameter"
/>
</fieldset>
</fields>
</config>
</extension>
</source>

More system Plugin examples can be found here: https://github.com/joomla/joomla-cms/tree/staging/plugins/system

<noinclude>[[Category:Plugin Development]][[Category:Specifications]]</noinclude>

Plugin/Events

2019-11-27T06:37:21Z

Sharky: Remove reference to onBeforeExecute event

<noinclude><languages /></noinclude>
<noinclude>{{Joomla version|version=3.x|}}</noinclude>
{{-}}
<translate>
Joomla! ships with a variety of core events, organised into groups. These are described in the following topics.</translate>

<translate>

=== Authentication === 
</translate>
* [[S:MyLanguage/Plugin/Events/Authentication#onUserAuthenticate|onUserAuthenticate]]

<translate>
=== Captcha === 
</translate>
* [[S:MyLanguage/Plugin/Events/Captcha#onInit|onInit]]
* [[S:MyLanguage/Plugin/Events/Captcha#onDisplay|onDisplay]]
* [[S:MyLanguage/Plugin/Events/Captcha#onCheckAnswer|onCheckAnswer]]

<translate>
=== Content === 
</translate>
* [[S:MyLanguage/Plugin/Events/Content#onContentPrepare|onContentPrepare]]
* [[S:MyLanguage/Plugin/Events/Content#onContentAfterTitle|onContentAfterTitle]] ({{JVer|3.0}} <translate> and higher</translate>)
* [[S:MyLanguage/Plugin/Events/Content#onContentBeforeDisplay|onContentBeforeDisplay]]
* [[S:MyLanguage/Plugin/Events/Content#onContentAfterDisplay|onContentAfterDisplay]]
* [[S:MyLanguage/Plugin/Events/Content#onContentBeforeSave|onContentBeforeSave]]
* [[S:MyLanguage/Plugin/Events/Content#onContentAfterSave|onContentAfterSave]]
* [[S:MyLanguage/Plugin/Events/Content#onContentPrepareForm|onContentPrepareForm]]
* [[S:MyLanguage/Plugin/Events/Content#onContentPrepareData|onContentPrepareData]]
* [[S:MyLanguage/Plugin/Events/Content#onContentBeforeDelete|onContentBeforeDelete]]
* [[S:MyLanguage/Plugin/Events/Content#onContentAfterDelete|onContentAfterDelete]]
* [[S:MyLanguage/Plugin/Events/Content#onContentChangeState|onContentChangeState]]
* [[S:MyLanguage/Plugin/Events/Content#onContentSearch|onContentSearch]]
* [[S:MyLanguage/Plugin/Events/Content#onContentSearchAreas|onContentSearchAreas]]

<translate>

=== Editors === 
</translate>
* [[S:MyLanguage/Plugin/Events/Editor#onInit|onInit]]
* [[S:MyLanguage/Plugin/Events/Editor#onSave|onSave]]
* [[S:MyLanguage/Plugin/Events/Editor#onSetContent|onSetContent]]
* [[S:MyLanguage/Plugin/Events/Editor#onDisplay|onDisplay]]
* [[S:MyLanguage/Plugin/Events/Editor#onGetContent|onGetContent]]
* [[S:MyLanguage/Plugin/Events/Editor#onGetInsertMethod|onGetInsertMethod]]

<translate>
=== Extensions === 
</translate>
* [[S:MyLanguage/Plugin/Events/Extension#onExtensionAfterInstall|onExtensionAfterInstall]]
* [[S:MyLanguage/Plugin/Events/Extension#onExtensionAfterUninstall|onExtensionAfterUninstall]]
* [[S:MyLanguage/Plugin/Events/Extension#onExtensionAfterUpdate|onExtensionAfterUpdate]]
* [[S:MyLanguage/Plugin/Events/Extension#onExtensionAfterUpdate|onExtensionBeforeSave]]
* [[S:MyLanguage/Plugin/Events/Extension#onExtensionAfterUpdate|onExtensionAfterSave]]
* [[S:MyLanguage/Plugin/Events/Extension#onExtensionAfterDelete|onExtensionAfterDelete]]

<translate>
=== Finder === 
</translate>
* [[S:MyLanguage/Plugin/Events/Finder#onFinderCategoryChangeState|onFinderCategoryChangeState]]
* [[S:MyLanguage/Plugin/Events/Finder#onFinderChangeState|onFinderChangeState]]
* [[S:MyLanguage/Plugin/Events/Finder#onFinderBeforeDelete|onFinderAfterDelete]]
* [[S:MyLanguage/Plugin/Events/Finder#onFinderAfterDelete|onFinderAfterDelete]]
* [[S:MyLanguage/Plugin/Events/Finder#onFinderBeforeSave|onFinderBeforeSave]]
* [[S:MyLanguage/Plugin/Events/Finder#onFinderAfterSave|onFinderAfterSave]]

<translate>
=== Privacy === 
</translate>
* [[S:MyLanguage/Plugin/Events/Privacy#onPrivacyCanRemoveData|onPrivacyCanRemoveData]]
* [[S:MyLanguage/Plugin/Events/Privacy#onPrivacyExportRequest|onPrivacyExportRequest]]
* [[S:MyLanguage/Plugin/Events/Privacy#onPrivacyRemoveData|onPrivacyRemoveData]]

<translate>
=== Quick Icons === 
</translate>
* [[S:MyLanguage/Plugin/Events/Quickicon#onGetIcons|onGetIcons]]

<translate>
=== Sampledata === 
</translate>
* [[S:MyLanguage/Plugin/Events/SampleData#onSampledataGetOverview|onSampledataGetOverview]]
* [[S:MyLanguage/Plugin/Events/SampleData#onAjaxSampledataApplyStep1|onAjaxSampledataApplyStep1]]
* [[S:MyLanguage/Plugin/Events/SampleData#onAjaxSampledataApplyStep2|onAjaxSampledataApplyStep2]]
* [[S:MyLanguage/Plugin/Events/SampleData#onAjaxSampledataApplyStep3|onAjaxSampledataApplyStep3]]

<translate>

=== System === 
</translate>
* [[S:MyLanguage/Plugin/Events/System#onAfterInitialise|onAfterInitialise]]
* [[S:MyLanguage/Plugin/Events/System#onAfterRoute|onAfterRoute]]
* [[S:MyLanguage/Plugin/Events/System#onAfterDispatch|onAfterDispatch]]
* [[S:MyLanguage/Plugin/Events/System#onAfterRender|onAfterRender]]
* [[S:MyLanguage/Plugin/Events/System#onBeforeRender|onBeforeRender]]
* [[S:MyLanguage/Plugin/Events/System#onBeforeCompileHead|onBeforeCompileHead]]

<translate>

=== User === 
</translate>
* [[S:MyLanguage/Plugin/Events/User#onUserAuthorisation|onUserAuthorisation]]
* [[S:MyLanguage/Plugin/Events/User#onUserAuthorisationFailure|onUserAuthorisationFailure]]
* [[S:MyLanguage/Plugin/Events/User#onUserBeforeSave|onUserBeforeSave]]
* [[S:MyLanguage/Plugin/Events/User#onUserAfterSave|onUserAfterSave]]
* [[S:MyLanguage/Plugin/Events/User#onUserBeforeDelete|onUserBeforeDelete]]
* [[S:MyLanguage/Plugin/Events/User#onUserAfterDelete|onUserAfterDelete]]
* [[S:MyLanguage/Plugin/Events/User#onUserLogin|onUserLogin]]
* [[S:MyLanguage/Plugin/Events/User#onUserLoginFailure|onUserLoginFailure]]
* [[S:MyLanguage/Plugin/Events/User#onUserAfterLogin|onUserAfterLogin]]
* [[S:MyLanguage/Plugin/Events/User#onUserLogout|onUserLogout]]
* [[S:MyLanguage/Plugin/Events/User#onUserBeforeSaveGroup|onUserBeforeSaveGroup]]
* [[S:MyLanguage/Plugin/Events/User#onUserAfterSaveGroup|onUserAfterSaveGroup]]
* [[S:MyLanguage/Plugin/Events/User#onUserBeforeDeleteGroup|onUserBeforeDeleteGroup]]
* [[S:MyLanguage/Plugin/Events/User#onUserAfterDeleteGroup|onUserAfterDeleteGroup]]
* [[S:MyLanguage/Plugin/Events/User#onUserAfterRemind|onUserAfterRemind]]

<translate>
=== Other Core Component Events === </translate>

<translate>
==== Actionlog Component ==== 
</translate>
* [[S:MyLanguage/Plugin/Events/Actionlog#onAfterLogPurge|onAfterLogPurge]]
* [[S:MyLanguage/Plugin/Events/Actionlog#onAfterLogExport|onAfterLogExport]]

<translate>
==== Cache Component ==== 
</translate>
* [[S:MyLanguage/Plugin/Events/Cache#onAfterPurge|onAfterPurge]]

<translate>
==== Checkin Component ==== 
</translate>
* [[S:MyLanguage/Plugin/Events/Checkin#onAfterCheckin|onAfterCheckin]]

<translate>
==== Config Component ==== 
</translate>
* [[S:MyLanguage/Plugin/Events/Config#onApplicationAfterSave|onApplicationAfterSave]]

<translate>
==== Contact Component ==== 
</translate>
* [[S:MyLanguage/Plugin/Events/Contact#onValidateContact|onValidateContact]]
* [[S:MyLanguage/Plugin/Events/Contact#onSubmitContact|onSubmitContact]]

<translate>
==== Installer Component ==== 
</translate>
* [[S:MyLanguage/Plugin/Events/Install#onInstallerBeforeInstallation|onInstallerBeforeInstallation]]
* [[S:MyLanguage/Plugin/Events/Install#onInstallerBeforeInstaller|onInstallerBeforeInstaller]]
* [[S:MyLanguage/Plugin/Events/Install#onInstallerAfterInstaller|onInstallerAfterInstaller]]

<translate>
==== Menu Component ==== 
</translate>
* [[S:MyLanguage/Plugin/Events/Menu#onAfterGetMenuTypeOptions|onAfterGetMenuTypeOptions]]

<translate>
==== Module ==== 
</translate>
* [[S:MyLanguage/Plugin/Events/Module#onRenderModule|onRenderModule]]
* [[S:MyLanguage/Plugin/Events/Module#onAfterRenderModule|onAfterRenderModule]]
* [[S:MyLanguage/Plugin/Events/Module#onAfterRenderModules|onAfterRenderModules]]
* [[S:MyLanguage/Plugin/Events/Module#onPrepareModuleList|onPrepareModuleList]]
* [[S:MyLanguage/Plugin/Events/Module#onAfterModuleList|onAfterModuleList]]
* [[S:MyLanguage/Plugin/Events/Module#onAfterCleanModuleList|onAfterCleanModuleList]]

<noinclude>
[[Category:Plugin Development|Events{{#translation:}}]]
[[Category:Specifications{{#translation:}}]]
[[Category:Tutorials{{#translation:}}]]
</noinclude>