Joomla! Documentation - User contributions [en]

J3.x:Duplicate usernames cause update issue

2020-03-10T16:47:08Z

Mbabker:

<noinclude><languages /></noinclude>
In some websites, updating to Joomla 3.9.16 results in a database error due to duplicated usernames. If this happens do not panic - the upgrade has been mostly completed without issue, and the remaining database change can be applied after following the instructions below.

==Errors reported==
Users receive an update error regarding a failed database query due to a duplicated key in their site's <source lang="sql" inline>#__users</source> table when upgrading from Joomla 3.9.15 or older.
[[File:76331128-c6389180-62ff-11ea-81d6-14cd3e5ab28d.png|thumb|Joomla 3.9.16 Upgrade Error]]

==Versions affected==
{{tip|This pertains only to Joomla! version(s): '''3.9.16'''|title=General Information}}

==What is the cause==
Your website has more than one user in the <source lang="sql" inline>#__users</source> table with the same username, which is a security concern in that the incorrect account may be accessed by the wrong account owner.

==How to fix==
You will need to review your <source lang="sql" inline>#__users</source> table in your database and fix any duplicated usernames by either removing old user accounts or changing the username until all usernames are unique. Once this is finished, if you have already upgraded to 3.9.16 run the database schema fixer tool to finish the upgrade (this step is not required if you do this review prior to upgrading).

Joomla is unable to automatically determine the correct action to take and as a result is unable to perform this step for you - it has to be fixed by you as the site owner.

The following SQL Query can be run on your database to view which usernames are duplicated:

<source lang="sql" inline>SELECT username FROM #__users GROUP BY username HAVING COUNT(*) > 1</source>

__NOTOC__

<noinclude>
[[Category:Version 3.9 FAQ]]
[[Category:Version 3.9.16 FAQ]]
[[Category:FAQ]]
[[Category:Joomla! 3.9]]
</noinclude>

J3.x:Duplicate usernames cause update issue

2020-03-10T16:43:58Z

Mbabker: Revisions

In a small number of sites (generally older sites) there have been issues upgrading to Joomal 3.9.16 showing a SQL Error. If this happens do not panic - the upgrade has largely completed on your site and you need to make a small adjustment as detailed below.

==Errors reported==
Users receive an update error regarding a failed database query due to a duplicated key in their site's <pre>#__users</pre> table when upgrading from Joomla 3.9.15 or older.
[[File:76331128-c6389180-62ff-11ea-81d6-14cd3e5ab28d.png|thumb|Joomla 3.9.16 Upgrade Error]]

==Versions affected==
{{tip|This pertains only to Joomla! version(s): '''3.9.16'''|title=General Information}}

==What is the cause==
Your website has more than one user in the <pre>#__users</pre> table with the same username, which is a security concern in that the incorrect account may be accessed by the wrong account owner.

==How to fix==
You will need to review your <pre>#__users</pre> table in your database and fix any duplicated usernames by either removing old user accounts or changing the username until all usernames are unique. Once this is finished, if you have already upgraded to 3.9.16 run the database schema fixer tool to finish the upgrade (this step is not required if you do this review prior to upgrading).

Joomla is unable to automatically determine the correct action to take and as a result is unable to perform this step for you - it has to be fixed by you as the site owner.

The following SQL Query can be run on your database to view which usernames are duplicated:

<source lang="sql" inline>SELECT username FROM #__users GROUP BY username HAVING COUNT(*) > 1</source>

__NOTOC__

<noinclude>
[[Category:Version 3.9 FAQ]]
[[Category:Version 3.9.16 FAQ]]
[[Category:FAQ]]
[[Category:Joomla! 3.9]]
</noinclude>

Install from Web

2019-04-05T12:20:03Z

Mbabker: Add 2.0.1 release

<noinclude><languages /></noinclude>
<translate>
The Joomla Install from Web feature was added as part of {{JVer|3.2|Joomla! 3.2|long}} to make installing extensions from the [http://extensions.joomla.org Joomla! Extensions Directory (JED)].</translate>

<translate>
To enable it simply go into the Joomla Extension Manager and click on the notice at the top to install the extra plugin needed for it to function (Note there are known issues with Akeeba Backup hiding this message).</translate>

<translate>
==Video Demo== 
</translate>
<translate>
You can see a video walk through of the Install from web feature here:</translate> http://www.youtube.com/watch?v=P33D24gNEUk

{{#Widget:YouTube|id=P33D24gNEUk}}

<translate>
==Information for Extension Developers== 
</translate>
<translate>
If you already have an extension on JED then you need to make a few small changes to get your extension working on the Joomla Extension Finder. [[S:MyLanguage/Install From Web For Developers|Click Here]] for more information.</translate>

<translate>
==Plugin versions== 
</translate>
<translate>
* 1.0.2 Initial released version with Joomla 3.2.0 Stable</translate>
<translate>
* 1.0.3 Minor fix for translations escapings (server-side fix for "Sort by rating" to correspond to JED)</translate>
<translate>
* 1.0.4 Minor addition for support of display of commercial/non-commercial "$" icon and for number of reviews and votes in category views (server-side: Same additions and fix of sorting in leaf-category view by rating to reflect JED sorting)</translate>
<translate>
* 1.0.5 Mandatory upgrade for Joomla 3.2.1 to adapt to a change in Javascript introduced by Joomla 3.2.1</translate>
<translate>
* 1.1.0 was a maintenance release of the plugin.</translate>
* <translate> 2.0.0 is an upgrade of the plugin's internal handling to be compatible with the core version of the plugin included in Joomla! 4.0. This version requires Joomla! 3.9 or 3.10 to be used. Please see https://github.com/joomla-extensions/install-from-web-client/releases/tag/2.0.0 for further details about this update.</translate>
2.0.1 is a maintenance release which restores JSONP support to address browser security changes. Please see https://github.com/joomla-extensions/install-from-web-client/releases/tag/2.0.1 for further details about this update.

<noinclude>
[[Category:Extensions{{#translation:}}]]
[[Category:Extension development{{#translation:}}]]
[[Category:Extension Installation{{#translation:}}]]
[[Category:Video{{#translation:}}]]
</noinclude>

Install from Web

2019-04-04T03:49:46Z

Mbabker: Add 2.0 release

<noinclude><languages /></noinclude>
<translate>
The Joomla Install from Web feature was added as part of {{JVer|3.2|Joomla! 3.2|long}} to make installing extensions from the [http://extensions.joomla.org Joomla! Extensions Directory (JED)].</translate>

<translate>
To enable it simply go into the Joomla Extension Manager and click on the notice at the top to install the extra plugin needed for it to function (Note there are known issues with Akeeba Backup hiding this message).</translate>

<translate>
==Video Demo== 
</translate>
<translate>
You can see a video walk through of the Install from web feature here:</translate> http://www.youtube.com/watch?v=P33D24gNEUk

{{#Widget:YouTube|id=P33D24gNEUk}}

<translate>
==Information for Extension Developers== 
</translate>
<translate>
If you already have an extension on JED then you need to make a few small changes to get your extension working on the Joomla Extension Finder. [[S:MyLanguage/Install From Web For Developers|Click Here]] for more information.</translate>

<translate>
==Plugin versions== 
</translate>
<translate>
* 1.0.2 Initial released version with Joomla 3.2.0 Stable</translate>
<translate>
* 1.0.3 Minor fix for translations escapings (server-side fix for "Sort by rating" to correspond to JED)</translate>
<translate>
* 1.0.4 Minor addition for support of display of commercial/non-commercial "$" icon and for number of reviews and votes in category views (server-side: Same additions and fix of sorting in leaf-category view by rating to reflect JED sorting)</translate>
<translate>
* 1.0.5 Mandatory upgrade for Joomla 3.2.1 to adapt to a change in Javascript introduced by Joomla 3.2.1</translate>
<translate>
* 1.1.0 was a maintenance release of the plugin.</translate>
* 2.0.0 is an upgrade of the plugin's internal handling to be compatible with the core version of the plugin included in Joomla! 4.0. This version requires Joomla! 3.9 or 3.10 to be used. Please see https://github.com/joomla-extensions/install-from-web-client/releases/tag/2.0.0 for further details about this update.

<noinclude>
<translate>

[[Category:Extensions]]
[[Category:Extension development]]
[[Category:Extension Installation]]
[[Category:Video]]
</translate>
</noinclude>

Joomla:Release procedure and checklist

2018-12-18T03:05:17Z

Mbabker: /* Post Release Actions */

{{incomplete}}{{RightTOC}}

This is a general checklist for managing releases of Joomla! and the Joomla! Framework. This list is best suited for a [[Minor Release]] or [[Maintenance Release]], however the steps will generally apply to a [[Major Release]] as well but will require some judgement calls from the release manager and/or leadership team.

{{note|''This document is a work in progress.'' The information on this page is currently undergoing a major revision.|type=notice}}

= CMS Release Cycle =

== Issue Triage, Patch Review, Merging Patches ==
The release cycle for a new software version begins immediately after the previous one is completed. In the immediate hours and days after a release, the [https://github.com/joomla/joomla-cms issue tracker] and [https://forum.joomla.org/ support forums], in close coordination with the [https://volunteers.joomla.org/teams/bug-squad Bug Squad] and [https://volunteers.joomla.org/teams/cms-release-team CMS Release Team], should be monitored for reports of potential regressions or critical bugs that would warrant a quick follow-on release to address the issue. It is generally suggested to wait 48-72 hours before resuming merging of reviewed and ready for commit pull requests to keep the release branch "clean" and ready for a release (note this is only a suggestion, if need be a release manager could create a branch from the release tag however this involves a bit more effort therefore this suggestion is for simplicity's sake).

Throughout the release cycle, the release manager should be involved with reviewing patches and merging reviewed patches to the appropriate release branch. As of this writing (where 3.9.1 is the present release), the following branches are generally active:

* <tt>staging</tt>: This is the main release branch and is where most activity occurs, generally only bug fixes and "general" maintenance work should merge to this branch although minor features may be merged at the discretion of the release manager and/or leadership team
* <tt>3.10-dev</tt>: This is the release branch for the next minor release (the branch's name will always be the version it represents), new features should be merged to this branch
* <tt>4.0-dev</tt>: This is the release branch for the next major release (the branch's name will always be the version it represents)

=== Branch Merging ===
All branches should remain in-sync and all work should be regularly merged forward. Given the above example, the following is the recommended merging workflow (in general, the suggested workflow is that staging is merged to the next minor branch and the next minor branch is merged to the next major branch):

* <tt>staging</tt> should be merged into <tt>3.10-dev</tt>
* <tt>3.10-dev</tt> should be merged to <tt>4.0-dev</tt>

It is suggested that at least once per week branch merging occurs.

== Preparing To Release ==
When scheduling and preparing a release, the timeline should be communicated with the Production and Marketing & Communication Department leadership so that all teams are prepared to support the release. Note that when scheduling releases, consideration should be given to holidays around the world and the impact of issuing a release near those periods considered. Helpful resources include http://interfaith-calendar.org/ and https://www.timeanddate.com/holidays/

=== Review Release Milestone and Blockers ===
On GitHub, check the [https://github.com/joomla/joomla-cms/milestones milestone] for the release you are preparing to create and for any open items with the [https://github.com/joomla/joomla-cms/labels/release-blocker release-blocker] label. If there are remaining open items, review them to determine if they are items that should be included in the release or if they can be rescheduled to a later release.

=== Release Schedule ===
==== Minor Release ====
Given the nature of a minor release, the following is the suggested release timeline:

* Six weeks prior to planned stable release: Tag the first Beta release
** At this point the release should be considered feature complete and new features should be deferred to the next minor release
* Weekly Beta releases should follow this until the Release Candidate
* Two weeks prior to planned stable release: Tag the Release Candidate
** At this point the release branch (generally <tt>staging</tt>) should remain closed for committing except for high priority bug fixes and language updates
** With the Release Candidate, language freeze is also in effect and no language changes are permitted unless there is an urgent need (which should be communicated with the translations coordinator); note that if necessary the language freeze may be declared earlier but the Release Candidate should be considered the "no later than" time
* One week prior to planned stable release: If necessary, create a second Release Candidate
* Planned release date: Tag the stable release

==== Maintenance Release ====
Maintenance releases operate on a 4-6 week cycle and the following is the suggested release timeline:

* 4-5 days before planned release date: Tag a Release Candidate
** With the Release Candidate, language freeze is also in effect and no language changes are permitted unless there is an urgent need (which should be communicated with the translations coordinator); note that if necessary the language freeze may be declared earlier but the Release Candidate should be considered the "no later than" time
* Planned release date: Tag the stable release

=== Reviewing Release Changes ===
Before tagging a release, the list of changes in the release should be reviewed by the release manager and/or leadership team. The list of changes can be found using GitHub's compare function with the URL <tt>https://github.com/joomla/joomla-cms/compare/<version>...staging</tt> which will compare the changes from <tt><version></tt> to the current staging branch (for example, https://github.com/joomla/joomla-cms/compare/3.9.0...3.9.1-rc is the comparison from the 3.9.0 release tag to the 3.9.1-rc tag). Key purposes of this review include:

* Ensuring all patches are compliant with Semantic Versioning (SemVer) (i.e. no backward compatibility breaks in minor or maintenance releases and no features in maintenance releases); SemVer violations should be cleared with the Production Department leadership
* Ensuring all code revisions are compatible with Joomla's minimum supported versions (i.e. no PHP 5.4 syntax in 3.x releases where PHP 5.3 is the minimum supported version, exceptions may be made if introducing a code path and files that will only be executed on newer PHP versions)
** Joomla's testing integrations should not be relied on in full for this as there are large portions of the Joomla code base which do not have automated test coverage, and as of this writing, there is not a code linting process in place checking for potential issues
* Ensuring features and "significant" changes are documented

=== Security Fixes ===
From time to time, security fixes must be included in a release. Prior to every release, the release manager should check with the [https://volunteers.joomla.org/teams/security-strike-team Security Strike Team] to determine if security fixes are required, and if so ensure this is communicated to all members involved with release work (i.e. the marketing team liaison who assists with the publication of release related material). When a security release is necessary, an internal Release Candidate should be built for testing by the Security Strike Team, CMS Release Team, and [https://volunteers.joomla.org/teams/cms-maintenance-team CMS Maintenance Team] with all security patches included. These teams should also receive information about the vulnerabilities being addressed to ensure there are no regressions in the impacted areas.

Note, when a security fix involves a Joomla Framework package, the Framework package should be patched first and a release created of the affected package then the CMS updated with <tt>composer update</tt>.

== Building a Release ==
Building a release starts with checking that any files and folders that have been deleted are included in the arrays in the installer script at <tt>administrator/components/com_admin/script.php</tt>. There is a helper script in the repository to assist with this located at <tt>build/deleted_file_check.php</tt>. Running <tt>php build/deleted_file_check.php</tt> with its required <tt>--from</tt> option will write a file to <tt>build/deleted_files.txt</tt> with the list of files deleted since the from reference. Please see the PHP file for all documentation about this script.

The following steps require the individual to create commits and tags. It is suggested that these commits and tags be GPG signed as an extra security step but this is not a mandatory requirement as of this writing.

If creating a security release, at this point you should apply all patches provided by the security team.

Once it is confirmed that the deleted files listing is correct, the <tt>build/bump.php</tt> script should be executed to set the new version number. This script will also perform maintenance steps such as correcting the copyright year ranges for all files and replacing the <tt>__DEPLOY_VERSION__</tt> placeholder. Please see the file for all documentation about this script.

After running this script, review all changes with <tt>git diff</tt> as a final check before creating your release commit. Once you are satisfied that all changes are correct, commit your changes locally. Once committed, create the release tag locally; all release tags should be the version number you are creating and should match the output of <tt>Joomla\CMS\Version::getShortVersion()</tt> (so if you have created 3.9.0-beta2 then the tag should be named 3.9.0-beta2).

Once the tag has been created, you will run the <tt>build/build.php</tt> script to generate the release packages. To ensure a clean build is produced, the script makes an archive of the tag you are building using the <tt>git archive</tt> command and extracts this to the <tt>build/tmp/<timestamp></tt> directory. Depending on the patch version number, the following packages will be created in the <tt>build/tmp/packages</tt>:

* 0: Full installation and upgrade packages
* 1: Full installation, upgrade packages, and patch packages for x.y.0 to x.y.1
* 2+: Full installation, upgrade packages, patch packages for x.y.0 to x.y.<new> and x.y.<new-1> to x.y.<new> (i.e. when creating 3.8.8 this will create a patch package suitable for all 3.8.x releases and an optimized patch package for 3.8.7 to 3.8.8)

Additionally, the script will generate a <tt>build/tmp/checksums.txt</tt> file with the checksums for all generated packages.

After the packages are created, you should validate that you are able to install and update a site using the ZIP packages (as these are the most frequently used type and served by our update system).

== Publishing a Release ==
=== Release Packages ===
Depending on the type of release being created, you will publish the release packages in different locations.

==== Alpha, Beta, Release Candidate ====
The packages for these releases are uploaded to GitHub. When ready to publish, you should push the release tag you created to GitHub and use their interface to create a release from the tag and upload the packages. There is a text template used for the releases, generally you can copy a previous release's text and adjust it to the version you are publishing.

==== Stable ====
The packages for stable releases are uploaded to multiple locations, this is in part driven by the fact that the Amazon Web Services (AWS) S3 region used by Joomla is blocked in some locations therefore download mirrors are available when necessary.

===== Joomla! Downloads Portal =====
The canonical source for all stable releases is the [https://downloads.joomla.org/ Joomla! Downloads Portal]. The packages served from the site use Joomla's AWS account. You will need to log into the AWS console to upload the packages to S3 under the <tt>joomla-official-downloads</tt> bucket. The exact path inside the bucket is <tt>joomladownloads/joomla<version></tt> where <tt><version></tt> is the major version number (i.e. <tt>joomla3</tt>), note for compatibility with Akeeba Release System folders for each individual release are not used.

===== Joomla! Update Server =====
The Joomla! Update Server is used as a mirror for the download packages. After connecting to the server, you should create a new folder at <tt>www/releases/<version></tt> (i.e. <tt>www/releases/3.9.1</tt> for the 3.9.1 release) and upload the packages here.

===== GitHub =====
The packages are also uploaded to GitHub. This is similar to the steps for alpha, beta, and release candidate releases above. Note that you only need to push the release tag at this point (i.e. <tt>git push --tags</tt>), you can wait to push the updated release branch until after the release is available.

=== Announcements ===
==== joomla.org ====
For all stable releases, the main release announcement is published to the <tt>Joomla! Official News > Project Release News</tt> category on the main <tt>joomla.org</tt> website.

For a minor release, an updated version of the landing page at <tt>joomla.org/3</tt> is published. Generally, this site is backed up from the sandbox location and transferred to the live domain shortly before release, this transfer should be coordinated with the [https://volunteers.joomla.org/teams/webmasters-team Webmasters Team].

==== developer.joomla.org ====
For security releases, all accompanying articles are published to the <tt>News > Security Centre</tt> category on the Joomla! Developer Network. As these articles are referenced from the main release announcement, these should be published at the same time.

== Update Server ==
The update server must be updated to alert websites that a core update is available, this subdomain is managed on GitHub at https://github.com/joomla/update.joomla.org. Prior to each release, a pull request should be prepared with necessary changes for the release (generally this updates the version number, announcement URL, package URLs, and package checksums for the stable release and updating the version number for the nightly builds), see https://github.com/joomla/update.joomla.org/pull/117 as an example of this update for the 3.9.1 release. Pushes to the <tt>master</tt> branch of this repo are automatically deployed thanks to a Jenkins job, notifications for many of the Jenkins jobs are sent to the <tt>.org Build Notifications</tt> channel on RingCentral Glip so you should ensure a success notification was sent here otherwise check if there was an issue with the job and/or manually deploy the updated files.

Note that the <tt>update.joomla.org</tt> subdomain is behind a CDN and it generally takes 5-10 minutes for all nodes to update, if need be you can access <tt>update1.joomla.org</tt> to verify the right files are deployed without using the CDN.

== Post Release Actions ==
Once the release is published, there are several additional tasks that should be completed shortly after.

=== Post-Release Version Bump ===
The version should be bumped to the next version scheduled for release using the <tt>build/bump.php</tt> script (i.e. after the 3.9.1 release this would be bumped to 3.9.2-dev).

=== Branch Merging ===
After incrementing the version number, you should merge all the release changes forward to other active branches (especially in the case of a security release). Ensure you pay careful attention while resolving merge conflicts, when making a merge that includes a version bump generally all files which contain the version string and/or release date will be in conflict (as of this writing this is 8 files).

=== Push Updated Branches ===
When ready, you should directly push your updates to the Git repo. If you elect to use pull requests, the pull requests should NEVER be squashed or rebased otherwise this will wipe out Git's awareness of the merged commits and will make your next branch merges even more complex. Likewise, as an example, if the commit preparing the 3.9.1 release and bumping the version string to 3.9.2-dev were squash merged as a pull request, then the commit that the 3.9.1 release was tagged from would not be in the repository.

=== Update Release Milestones ===
On GitHub, all merged items are assigned to a milestone to help organize items. With each release, the [https://github.com/joomla/joomla-cms/milestones milestones] should be updated to ensure that the milestone for the release you created has been closed and a milestone for the next release is open.

=== Regenerate Nightly Builds ===
The nightly builds for any branch updated during the release process should be regenerated to include the release's changes. These can be manually triggered within the <tt>CMS Packaging</tt> folder on the Jenkins server.

=== Website Updates ===
With all code updates pushed, there are several website updates that need to be triggered.

==== api.joomla.org ====
With each release, an updated build of the API documentation should be deployed to the <tt>api.joomla.org</tt> website. These updates are triggered with the <tt>Joomla! API > Deploy Docs - CMS</tt> job on Jenkins. As this job relies on the release tags from the CMS repo, this can only be done after the release tag has been pushed.

==== developer.joomla.org ====
After a release, the <tt>Joomla! Project Roadmap</tt> article in the <tt>Uncategorised</tt> category should be updated to reflect the newly released version and updated links. The version whitelist for the statistics server should also be updated to allow the next version to be submitted; if you have not already, you should have a clone of the https://github.com/joomla/statistics-server repository on your local system. Once cloned and set up, run the <tt>bin/stats tags:joomla</tt> command to regenerate the Joomla version whitelist. As this command relies on the release tags from the CMS repo, this can only be done after the release tag has been pushed. The updated <tt>versions/joomla.json</tt> should be committed and pushed, and a Jenkins job will deploy the updated site resources.

== Additional Considerations ==
The release manager or a delegate is suggested to be in communication with the Webmasters Team to ensure the <tt>joomla.org</tt> websites are updated in a timely manner. When a security release is scheduled, it is encouraged to share the update release package with the team so that our sites may be updated before the fix is made public to mitigate the chance of the vulnerability being used to exploit one of our sites.

= Framework Release Cycle =
The packages of the Joomla Framework are on an independent lifecycle meaning each package can be updated and released independently of all others. Generally the only restriction is with major releases, which should coincide with the CMS release cycle (i.e. CMS 3.x uses Framework 1.x, CMS 4.x will use Framework 2.x therefore Framework 2.0 stable releases should not be made until the CMS is in its beta phase at the earliest).

== Tagging a Release ==
Most packages can be tagged and released through the <tt>Joomla! Framework > Package Release</tt> job on Jenkins, however as of this writing this job only supports tagging releases from a repository's <tt>master</tt> branch. To tag a release, select the package you wish to update and specify the version you are releasing in the job's parameters and run the job; all releases should follow Semantic Versioning to set the correct number.

Once the job has completed, you should verify the new release is visible on [https://packagist.org/packages/joomla/ Packagist]. Within a day, the new update should be visible on the [https://framework.joomla.org/status Joomla Framework Status page] (the database is updated via cron job reading from Packagist's API), if the updated version isn't seen on the site in a relatively timely manner you should clone the website locally and debug the <tt>packagist:sync:releases</tt> command.

== Security Releases ==
When a security release is created, a pull request should be sent to the [https://github.com/FriendsOfPHP/security-advisories FriendsOfPHP/security-advisories repository] with relevant details. This repository is used by many tools in the PHP and Composer ecosystem to alert users of security issues. https://github.com/FriendsOfPHP/security-advisories/pull/134 is an example of this pull request.

[[Category:Bug Squad]]
[[Category:Coordinators]]
[[Category:Development]]

Joomla:Release procedure and checklist

2018-12-18T02:47:59Z

Mbabker: /* Review Release Milestone and Release Blockers */

{{incomplete}}{{RightTOC}}

This is a general checklist for managing releases of Joomla! and the Joomla! Framework. This list is best suited for a [[Minor Release]] or [[Maintenance Release]], however the steps will generally apply to a [[Major Release]] as well but will require some judgement calls from the release manager and/or leadership team.

{{note|''This document is a work in progress.'' The information on this page is currently undergoing a major revision.|type=notice}}

= CMS Release Cycle =

== Issue Triage, Patch Review, Merging Patches ==
The release cycle for a new software version begins immediately after the previous one is completed. In the immediate hours and days after a release, the [https://github.com/joomla/joomla-cms issue tracker] and [https://forum.joomla.org/ support forums], in close coordination with the [https://volunteers.joomla.org/teams/bug-squad Bug Squad] and [https://volunteers.joomla.org/teams/cms-release-team CMS Release Team], should be monitored for reports of potential regressions or critical bugs that would warrant a quick follow-on release to address the issue. It is generally suggested to wait 48-72 hours before resuming merging of reviewed and ready for commit pull requests to keep the release branch "clean" and ready for a release (note this is only a suggestion, if need be a release manager could create a branch from the release tag however this involves a bit more effort therefore this suggestion is for simplicity's sake).

Throughout the release cycle, the release manager should be involved with reviewing patches and merging reviewed patches to the appropriate release branch. As of this writing (where 3.9.1 is the present release), the following branches are generally active:

* <tt>staging</tt>: This is the main release branch and is where most activity occurs, generally only bug fixes and "general" maintenance work should merge to this branch although minor features may be merged at the discretion of the release manager and/or leadership team
* <tt>3.10-dev</tt>: This is the release branch for the next minor release (the branch's name will always be the version it represents), new features should be merged to this branch
* <tt>4.0-dev</tt>: This is the release branch for the next major release (the branch's name will always be the version it represents)

=== Branch Merging ===
All branches should remain in-sync and all work should be regularly merged forward. Given the above example, the following is the recommended merging workflow (in general, the suggested workflow is that staging is merged to the next minor branch and the next minor branch is merged to the next major branch):

* <tt>staging</tt> should be merged into <tt>3.10-dev</tt>
* <tt>3.10-dev</tt> should be merged to <tt>4.0-dev</tt>

It is suggested that at least once per week branch merging occurs.

== Preparing To Release ==
When scheduling and preparing a release, the timeline should be communicated with the Production and Marketing & Communication Department leadership so that all teams are prepared to support the release. Note that when scheduling releases, consideration should be given to holidays around the world and the impact of issuing a release near those periods considered. Helpful resources include http://interfaith-calendar.org/ and https://www.timeanddate.com/holidays/

=== Review Release Milestone and Blockers ===
On GitHub, check the [https://github.com/joomla/joomla-cms/milestones milestone] for the release you are preparing to create and for any open items with the [https://github.com/joomla/joomla-cms/labels/release-blocker release-blocker] label. If there are remaining open items, review them to determine if they are items that should be included in the release or if they can be rescheduled to a later release.

=== Release Schedule ===
==== Minor Release ====
Given the nature of a minor release, the following is the suggested release timeline:

* Six weeks prior to planned stable release: Tag the first Beta release
** At this point the release should be considered feature complete and new features should be deferred to the next minor release
* Weekly Beta releases should follow this until the Release Candidate
* Two weeks prior to planned stable release: Tag the Release Candidate
** At this point the release branch (generally <tt>staging</tt>) should remain closed for committing except for high priority bug fixes and language updates
** With the Release Candidate, language freeze is also in effect and no language changes are permitted unless there is an urgent need (which should be communicated with the translations coordinator); note that if necessary the language freeze may be declared earlier but the Release Candidate should be considered the "no later than" time
* One week prior to planned stable release: If necessary, create a second Release Candidate
* Planned release date: Tag the stable release

==== Maintenance Release ====
Maintenance releases operate on a 4-6 week cycle and the following is the suggested release timeline:

* 4-5 days before planned release date: Tag a Release Candidate
** With the Release Candidate, language freeze is also in effect and no language changes are permitted unless there is an urgent need (which should be communicated with the translations coordinator); note that if necessary the language freeze may be declared earlier but the Release Candidate should be considered the "no later than" time
* Planned release date: Tag the stable release

=== Reviewing Release Changes ===
Before tagging a release, the list of changes in the release should be reviewed by the release manager and/or leadership team. The list of changes can be found using GitHub's compare function with the URL <tt>https://github.com/joomla/joomla-cms/compare/<version>...staging</tt> which will compare the changes from <tt><version></tt> to the current staging branch (for example, https://github.com/joomla/joomla-cms/compare/3.9.0...3.9.1-rc is the comparison from the 3.9.0 release tag to the 3.9.1-rc tag). Key purposes of this review include:

* Ensuring all patches are compliant with Semantic Versioning (SemVer) (i.e. no backward compatibility breaks in minor or maintenance releases and no features in maintenance releases); SemVer violations should be cleared with the Production Department leadership
* Ensuring all code revisions are compatible with Joomla's minimum supported versions (i.e. no PHP 5.4 syntax in 3.x releases where PHP 5.3 is the minimum supported version, exceptions may be made if introducing a code path and files that will only be executed on newer PHP versions)
** Joomla's testing integrations should not be relied on in full for this as there are large portions of the Joomla code base which do not have automated test coverage, and as of this writing, there is not a code linting process in place checking for potential issues
* Ensuring features and "significant" changes are documented

=== Security Fixes ===
From time to time, security fixes must be included in a release. Prior to every release, the release manager should check with the [https://volunteers.joomla.org/teams/security-strike-team Security Strike Team] to determine if security fixes are required, and if so ensure this is communicated to all members involved with release work (i.e. the marketing team liaison who assists with the publication of release related material). When a security release is necessary, an internal Release Candidate should be built for testing by the Security Strike Team, CMS Release Team, and [https://volunteers.joomla.org/teams/cms-maintenance-team CMS Maintenance Team] with all security patches included. These teams should also receive information about the vulnerabilities being addressed to ensure there are no regressions in the impacted areas.

Note, when a security fix involves a Joomla Framework package, the Framework package should be patched first and a release created of the affected package then the CMS updated with <tt>composer update</tt>.

== Building a Release ==
Building a release starts with checking that any files and folders that have been deleted are included in the arrays in the installer script at <tt>administrator/components/com_admin/script.php</tt>. There is a helper script in the repository to assist with this located at <tt>build/deleted_file_check.php</tt>. Running <tt>php build/deleted_file_check.php</tt> with its required <tt>--from</tt> option will write a file to <tt>build/deleted_files.txt</tt> with the list of files deleted since the from reference. Please see the PHP file for all documentation about this script.

The following steps require the individual to create commits and tags. It is suggested that these commits and tags be GPG signed as an extra security step but this is not a mandatory requirement as of this writing.

If creating a security release, at this point you should apply all patches provided by the security team.

Once it is confirmed that the deleted files listing is correct, the <tt>build/bump.php</tt> script should be executed to set the new version number. This script will also perform maintenance steps such as correcting the copyright year ranges for all files and replacing the <tt>__DEPLOY_VERSION__</tt> placeholder. Please see the file for all documentation about this script.

After running this script, review all changes with <tt>git diff</tt> as a final check before creating your release commit. Once you are satisfied that all changes are correct, commit your changes locally. Once committed, create the release tag locally; all release tags should be the version number you are creating and should match the output of <tt>Joomla\CMS\Version::getShortVersion()</tt> (so if you have created 3.9.0-beta2 then the tag should be named 3.9.0-beta2).

Once the tag has been created, you will run the <tt>build/build.php</tt> script to generate the release packages. To ensure a clean build is produced, the script makes an archive of the tag you are building using the <tt>git archive</tt> command and extracts this to the <tt>build/tmp/<timestamp></tt> directory. Depending on the patch version number, the following packages will be created in the <tt>build/tmp/packages</tt>:

* 0: Full installation and upgrade packages
* 1: Full installation, upgrade packages, and patch packages for x.y.0 to x.y.1
* 2+: Full installation, upgrade packages, patch packages for x.y.0 to x.y.<new> and x.y.<new-1> to x.y.<new> (i.e. when creating 3.8.8 this will create a patch package suitable for all 3.8.x releases and an optimized patch package for 3.8.7 to 3.8.8)

Additionally, the script will generate a <tt>build/tmp/checksums.txt</tt> file with the checksums for all generated packages.

After the packages are created, you should validate that you are able to install and update a site using the ZIP packages (as these are the most frequently used type and served by our update system).

== Publishing a Release ==
=== Release Packages ===
Depending on the type of release being created, you will publish the release packages in different locations.

==== Alpha, Beta, Release Candidate ====
The packages for these releases are uploaded to GitHub. When ready to publish, you should push the release tag you created to GitHub and use their interface to create a release from the tag and upload the packages. There is a text template used for the releases, generally you can copy a previous release's text and adjust it to the version you are publishing.

==== Stable ====
The packages for stable releases are uploaded to multiple locations, this is in part driven by the fact that the Amazon Web Services (AWS) S3 region used by Joomla is blocked in some locations therefore download mirrors are available when necessary.

===== Joomla! Downloads Portal =====
The canonical source for all stable releases is the [https://downloads.joomla.org/ Joomla! Downloads Portal]. The packages served from the site use Joomla's AWS account. You will need to log into the AWS console to upload the packages to S3 under the <tt>joomla-official-downloads</tt> bucket. The exact path inside the bucket is <tt>joomladownloads/joomla<version></tt> where <tt><version></tt> is the major version number (i.e. <tt>joomla3</tt>), note for compatibility with Akeeba Release System folders for each individual release are not used.

===== Joomla! Update Server =====
The Joomla! Update Server is used as a mirror for the download packages. After connecting to the server, you should create a new folder at <tt>www/releases/<version></tt> (i.e. <tt>www/releases/3.9.1</tt> for the 3.9.1 release) and upload the packages here.

===== GitHub =====
The packages are also uploaded to GitHub. This is similar to the steps for alpha, beta, and release candidate releases above. Note that you only need to push the release tag at this point (i.e. <tt>git push --tags</tt>), you can wait to push the updated release branch until after the release is available.

=== Announcements ===
==== joomla.org ====
For all stable releases, the main release announcement is published to the <tt>Joomla! Official News > Project Release News</tt> category on the main <tt>joomla.org</tt> website.

For a minor release, an updated version of the landing page at <tt>joomla.org/3</tt> is published. Generally, this site is backed up from the sandbox location and transferred to the live domain shortly before release, this transfer should be coordinated with the [https://volunteers.joomla.org/teams/webmasters-team Webmasters Team].

==== developer.joomla.org ====
For security releases, all accompanying articles are published to the <tt>News > Security Centre</tt> category on the Joomla! Developer Network. As these articles are referenced from the main release announcement, these should be published at the same time.

== Update Server ==
The update server must be updated to alert websites that a core update is available, this subdomain is managed on GitHub at https://github.com/joomla/update.joomla.org. Prior to each release, a pull request should be prepared with necessary changes for the release (generally this updates the version number, announcement URL, package URLs, and package checksums for the stable release and updating the version number for the nightly builds), see https://github.com/joomla/update.joomla.org/pull/117 as an example of this update for the 3.9.1 release. Pushes to the <tt>master</tt> branch of this repo are automatically deployed thanks to a Jenkins job, notifications for many of the Jenkins jobs are sent to the <tt>.org Build Notifications</tt> channel on RingCentral Glip so you should ensure a success notification was sent here otherwise check if there was an issue with the job and/or manually deploy the updated files.

Note that the <tt>update.joomla.org</tt> subdomain is behind a CDN and it generally takes 5-10 minutes for all nodes to update, if need be you can access <tt>update1.joomla.org</tt> to verify the right files are deployed without using the CDN.

== Post Release Actions ==
Once the release is published, there are several additional tasks that should be completed shortly after.

=== Post-Release Version Bump ===
The version should be bumped to the next version scheduled for release using the <tt>build/bump.php</tt> script (i.e. after the 3.9.1 release this would be bumped to 3.9.2-dev).

=== Branch Merging ===
After incrementing the version number, you should merge all the release changes forward to other active branches (especially in the case of a security release). Ensure you pay careful attention while resolving merge conflicts, when making a merge that includes a version bump generally all files which contain the version string and/or release date will be in conflict (as of this writing this is 8 files).

=== Push Updated Branches ===
When ready, you should directly push your updates to the Git repo. If you elect to use pull requests, the pull requests should NEVER be squashed or rebased otherwise this will wipe out Git's awareness of the merged commits and will make your next branch merges even more complex. Likewise, as an example, if the commit preparing the 3.9.1 release and bumping the version string to 3.9.2-dev were squash merged as a pull request, then the commit that the 3.9.1 release was tagged from would not be in the repository.

=== Update Release Milestones ===
On GitHub, all merged items are assigned to a milestone to help organize items. With each release, the [https://github.com/joomla/joomla-cms/milestones milestones] should be updated to ensure that the milestone for the release you created has been closed and a milestone for the next release is open.

=== Website Updates ===
With all code updates pushed, there are several website updates that need to be triggered.

==== api.joomla.org ====
With each release, an updated build of the API documentation should be deployed to the <tt>api.joomla.org</tt> website. These updates are triggered with the <tt>Joomla! API > Deploy Docs - CMS</tt> job on Jenkins. As this job relies on the release tags from the CMS repo, this can only be done after the release tag has been pushed.

==== developer.joomla.org ====
After a release, the <tt>Joomla! Project Roadmap</tt> article in the <tt>Uncategorised</tt> category should be updated to reflect the newly released version and updated links. The version whitelist for the statistics server should also be updated to allow the next version to be submitted; if you have not already, you should have a clone of the https://github.com/joomla/statistics-server repository on your local system. Once cloned and set up, run the <tt>bin/stats tags:joomla</tt> command to regenerate the Joomla version whitelist. As this command relies on the release tags from the CMS repo, this can only be done after the release tag has been pushed. The updated <tt>versions/joomla.json</tt> should be committed and pushed, and a Jenkins job will deploy the updated site resources.

== Additional Considerations ==
The release manager or a delegate is suggested to be in communication with the Webmasters Team to ensure the <tt>joomla.org</tt> websites are updated in a timely manner. When a security release is scheduled, it is encouraged to share the update release package with the team so that our sites may be updated before the fix is made public to mitigate the chance of the vulnerability being used to exploit one of our sites.

= Framework Release Cycle =
The packages of the Joomla Framework are on an independent lifecycle meaning each package can be updated and released independently of all others. Generally the only restriction is with major releases, which should coincide with the CMS release cycle (i.e. CMS 3.x uses Framework 1.x, CMS 4.x will use Framework 2.x therefore Framework 2.0 stable releases should not be made until the CMS is in its beta phase at the earliest).

== Tagging a Release ==
Most packages can be tagged and released through the <tt>Joomla! Framework > Package Release</tt> job on Jenkins, however as of this writing this job only supports tagging releases from a repository's <tt>master</tt> branch. To tag a release, select the package you wish to update and specify the version you are releasing in the job's parameters and run the job; all releases should follow Semantic Versioning to set the correct number.

Once the job has completed, you should verify the new release is visible on [https://packagist.org/packages/joomla/ Packagist]. Within a day, the new update should be visible on the [https://framework.joomla.org/status Joomla Framework Status page] (the database is updated via cron job reading from Packagist's API), if the updated version isn't seen on the site in a relatively timely manner you should clone the website locally and debug the <tt>packagist:sync:releases</tt> command.

== Security Releases ==
When a security release is created, a pull request should be sent to the [https://github.com/FriendsOfPHP/security-advisories FriendsOfPHP/security-advisories repository] with relevant details. This repository is used by many tools in the PHP and Composer ecosystem to alert users of security issues. https://github.com/FriendsOfPHP/security-advisories/pull/134 is an example of this pull request.

[[Category:Bug Squad]]
[[Category:Coordinators]]
[[Category:Development]]

Joomla:Release procedure and checklist

2018-12-18T02:47:27Z

Mbabker:

{{incomplete}}{{RightTOC}}

This is a general checklist for managing releases of Joomla! and the Joomla! Framework. This list is best suited for a [[Minor Release]] or [[Maintenance Release]], however the steps will generally apply to a [[Major Release]] as well but will require some judgement calls from the release manager and/or leadership team.

{{note|''This document is a work in progress.'' The information on this page is currently undergoing a major revision.|type=notice}}

= CMS Release Cycle =

== Issue Triage, Patch Review, Merging Patches ==
The release cycle for a new software version begins immediately after the previous one is completed. In the immediate hours and days after a release, the [https://github.com/joomla/joomla-cms issue tracker] and [https://forum.joomla.org/ support forums], in close coordination with the [https://volunteers.joomla.org/teams/bug-squad Bug Squad] and [https://volunteers.joomla.org/teams/cms-release-team CMS Release Team], should be monitored for reports of potential regressions or critical bugs that would warrant a quick follow-on release to address the issue. It is generally suggested to wait 48-72 hours before resuming merging of reviewed and ready for commit pull requests to keep the release branch "clean" and ready for a release (note this is only a suggestion, if need be a release manager could create a branch from the release tag however this involves a bit more effort therefore this suggestion is for simplicity's sake).

Throughout the release cycle, the release manager should be involved with reviewing patches and merging reviewed patches to the appropriate release branch. As of this writing (where 3.9.1 is the present release), the following branches are generally active:

* <tt>staging</tt>: This is the main release branch and is where most activity occurs, generally only bug fixes and "general" maintenance work should merge to this branch although minor features may be merged at the discretion of the release manager and/or leadership team
* <tt>3.10-dev</tt>: This is the release branch for the next minor release (the branch's name will always be the version it represents), new features should be merged to this branch
* <tt>4.0-dev</tt>: This is the release branch for the next major release (the branch's name will always be the version it represents)

=== Branch Merging ===
All branches should remain in-sync and all work should be regularly merged forward. Given the above example, the following is the recommended merging workflow (in general, the suggested workflow is that staging is merged to the next minor branch and the next minor branch is merged to the next major branch):

* <tt>staging</tt> should be merged into <tt>3.10-dev</tt>
* <tt>3.10-dev</tt> should be merged to <tt>4.0-dev</tt>

It is suggested that at least once per week branch merging occurs.

== Preparing To Release ==
When scheduling and preparing a release, the timeline should be communicated with the Production and Marketing & Communication Department leadership so that all teams are prepared to support the release. Note that when scheduling releases, consideration should be given to holidays around the world and the impact of issuing a release near those periods considered. Helpful resources include http://interfaith-calendar.org/ and https://www.timeanddate.com/holidays/

=== Review Release Milestone and Release Blockers ===
On GitHub, check the [https://github.com/joomla/joomla-cms/milestones milestone] milestone for the release you are preparing to create and for any open items with the [https://github.com/joomla/joomla-cms/labels/release-blocker release-blocker] label. If there are remaining open items, review them to determine if they are items that should be included in the release or if they can be rescheduled to a later release.

=== Release Schedule ===
==== Minor Release ====
Given the nature of a minor release, the following is the suggested release timeline:

* Six weeks prior to planned stable release: Tag the first Beta release
** At this point the release should be considered feature complete and new features should be deferred to the next minor release
* Weekly Beta releases should follow this until the Release Candidate
* Two weeks prior to planned stable release: Tag the Release Candidate
** At this point the release branch (generally <tt>staging</tt>) should remain closed for committing except for high priority bug fixes and language updates
** With the Release Candidate, language freeze is also in effect and no language changes are permitted unless there is an urgent need (which should be communicated with the translations coordinator); note that if necessary the language freeze may be declared earlier but the Release Candidate should be considered the "no later than" time
* One week prior to planned stable release: If necessary, create a second Release Candidate
* Planned release date: Tag the stable release

==== Maintenance Release ====
Maintenance releases operate on a 4-6 week cycle and the following is the suggested release timeline:

* 4-5 days before planned release date: Tag a Release Candidate
** With the Release Candidate, language freeze is also in effect and no language changes are permitted unless there is an urgent need (which should be communicated with the translations coordinator); note that if necessary the language freeze may be declared earlier but the Release Candidate should be considered the "no later than" time
* Planned release date: Tag the stable release

=== Reviewing Release Changes ===
Before tagging a release, the list of changes in the release should be reviewed by the release manager and/or leadership team. The list of changes can be found using GitHub's compare function with the URL <tt>https://github.com/joomla/joomla-cms/compare/<version>...staging</tt> which will compare the changes from <tt><version></tt> to the current staging branch (for example, https://github.com/joomla/joomla-cms/compare/3.9.0...3.9.1-rc is the comparison from the 3.9.0 release tag to the 3.9.1-rc tag). Key purposes of this review include:

* Ensuring all patches are compliant with Semantic Versioning (SemVer) (i.e. no backward compatibility breaks in minor or maintenance releases and no features in maintenance releases); SemVer violations should be cleared with the Production Department leadership
* Ensuring all code revisions are compatible with Joomla's minimum supported versions (i.e. no PHP 5.4 syntax in 3.x releases where PHP 5.3 is the minimum supported version, exceptions may be made if introducing a code path and files that will only be executed on newer PHP versions)
** Joomla's testing integrations should not be relied on in full for this as there are large portions of the Joomla code base which do not have automated test coverage, and as of this writing, there is not a code linting process in place checking for potential issues
* Ensuring features and "significant" changes are documented

=== Security Fixes ===
From time to time, security fixes must be included in a release. Prior to every release, the release manager should check with the [https://volunteers.joomla.org/teams/security-strike-team Security Strike Team] to determine if security fixes are required, and if so ensure this is communicated to all members involved with release work (i.e. the marketing team liaison who assists with the publication of release related material). When a security release is necessary, an internal Release Candidate should be built for testing by the Security Strike Team, CMS Release Team, and [https://volunteers.joomla.org/teams/cms-maintenance-team CMS Maintenance Team] with all security patches included. These teams should also receive information about the vulnerabilities being addressed to ensure there are no regressions in the impacted areas.

Note, when a security fix involves a Joomla Framework package, the Framework package should be patched first and a release created of the affected package then the CMS updated with <tt>composer update</tt>.

== Building a Release ==
Building a release starts with checking that any files and folders that have been deleted are included in the arrays in the installer script at <tt>administrator/components/com_admin/script.php</tt>. There is a helper script in the repository to assist with this located at <tt>build/deleted_file_check.php</tt>. Running <tt>php build/deleted_file_check.php</tt> with its required <tt>--from</tt> option will write a file to <tt>build/deleted_files.txt</tt> with the list of files deleted since the from reference. Please see the PHP file for all documentation about this script.

The following steps require the individual to create commits and tags. It is suggested that these commits and tags be GPG signed as an extra security step but this is not a mandatory requirement as of this writing.

If creating a security release, at this point you should apply all patches provided by the security team.

Once it is confirmed that the deleted files listing is correct, the <tt>build/bump.php</tt> script should be executed to set the new version number. This script will also perform maintenance steps such as correcting the copyright year ranges for all files and replacing the <tt>__DEPLOY_VERSION__</tt> placeholder. Please see the file for all documentation about this script.

After running this script, review all changes with <tt>git diff</tt> as a final check before creating your release commit. Once you are satisfied that all changes are correct, commit your changes locally. Once committed, create the release tag locally; all release tags should be the version number you are creating and should match the output of <tt>Joomla\CMS\Version::getShortVersion()</tt> (so if you have created 3.9.0-beta2 then the tag should be named 3.9.0-beta2).

Once the tag has been created, you will run the <tt>build/build.php</tt> script to generate the release packages. To ensure a clean build is produced, the script makes an archive of the tag you are building using the <tt>git archive</tt> command and extracts this to the <tt>build/tmp/<timestamp></tt> directory. Depending on the patch version number, the following packages will be created in the <tt>build/tmp/packages</tt>:

* 0: Full installation and upgrade packages
* 1: Full installation, upgrade packages, and patch packages for x.y.0 to x.y.1
* 2+: Full installation, upgrade packages, patch packages for x.y.0 to x.y.<new> and x.y.<new-1> to x.y.<new> (i.e. when creating 3.8.8 this will create a patch package suitable for all 3.8.x releases and an optimized patch package for 3.8.7 to 3.8.8)

Additionally, the script will generate a <tt>build/tmp/checksums.txt</tt> file with the checksums for all generated packages.

After the packages are created, you should validate that you are able to install and update a site using the ZIP packages (as these are the most frequently used type and served by our update system).

== Publishing a Release ==
=== Release Packages ===
Depending on the type of release being created, you will publish the release packages in different locations.

==== Alpha, Beta, Release Candidate ====
The packages for these releases are uploaded to GitHub. When ready to publish, you should push the release tag you created to GitHub and use their interface to create a release from the tag and upload the packages. There is a text template used for the releases, generally you can copy a previous release's text and adjust it to the version you are publishing.

==== Stable ====
The packages for stable releases are uploaded to multiple locations, this is in part driven by the fact that the Amazon Web Services (AWS) S3 region used by Joomla is blocked in some locations therefore download mirrors are available when necessary.

===== Joomla! Downloads Portal =====
The canonical source for all stable releases is the [https://downloads.joomla.org/ Joomla! Downloads Portal]. The packages served from the site use Joomla's AWS account. You will need to log into the AWS console to upload the packages to S3 under the <tt>joomla-official-downloads</tt> bucket. The exact path inside the bucket is <tt>joomladownloads/joomla<version></tt> where <tt><version></tt> is the major version number (i.e. <tt>joomla3</tt>), note for compatibility with Akeeba Release System folders for each individual release are not used.

===== Joomla! Update Server =====
The Joomla! Update Server is used as a mirror for the download packages. After connecting to the server, you should create a new folder at <tt>www/releases/<version></tt> (i.e. <tt>www/releases/3.9.1</tt> for the 3.9.1 release) and upload the packages here.

===== GitHub =====
The packages are also uploaded to GitHub. This is similar to the steps for alpha, beta, and release candidate releases above. Note that you only need to push the release tag at this point (i.e. <tt>git push --tags</tt>), you can wait to push the updated release branch until after the release is available.

=== Announcements ===
==== joomla.org ====
For all stable releases, the main release announcement is published to the <tt>Joomla! Official News > Project Release News</tt> category on the main <tt>joomla.org</tt> website.

For a minor release, an updated version of the landing page at <tt>joomla.org/3</tt> is published. Generally, this site is backed up from the sandbox location and transferred to the live domain shortly before release, this transfer should be coordinated with the [https://volunteers.joomla.org/teams/webmasters-team Webmasters Team].

==== developer.joomla.org ====
For security releases, all accompanying articles are published to the <tt>News > Security Centre</tt> category on the Joomla! Developer Network. As these articles are referenced from the main release announcement, these should be published at the same time.

== Update Server ==
The update server must be updated to alert websites that a core update is available, this subdomain is managed on GitHub at https://github.com/joomla/update.joomla.org. Prior to each release, a pull request should be prepared with necessary changes for the release (generally this updates the version number, announcement URL, package URLs, and package checksums for the stable release and updating the version number for the nightly builds), see https://github.com/joomla/update.joomla.org/pull/117 as an example of this update for the 3.9.1 release. Pushes to the <tt>master</tt> branch of this repo are automatically deployed thanks to a Jenkins job, notifications for many of the Jenkins jobs are sent to the <tt>.org Build Notifications</tt> channel on RingCentral Glip so you should ensure a success notification was sent here otherwise check if there was an issue with the job and/or manually deploy the updated files.

Note that the <tt>update.joomla.org</tt> subdomain is behind a CDN and it generally takes 5-10 minutes for all nodes to update, if need be you can access <tt>update1.joomla.org</tt> to verify the right files are deployed without using the CDN.

== Post Release Actions ==
Once the release is published, there are several additional tasks that should be completed shortly after.

=== Post-Release Version Bump ===
The version should be bumped to the next version scheduled for release using the <tt>build/bump.php</tt> script (i.e. after the 3.9.1 release this would be bumped to 3.9.2-dev).

=== Branch Merging ===
After incrementing the version number, you should merge all the release changes forward to other active branches (especially in the case of a security release). Ensure you pay careful attention while resolving merge conflicts, when making a merge that includes a version bump generally all files which contain the version string and/or release date will be in conflict (as of this writing this is 8 files).

=== Push Updated Branches ===
When ready, you should directly push your updates to the Git repo. If you elect to use pull requests, the pull requests should NEVER be squashed or rebased otherwise this will wipe out Git's awareness of the merged commits and will make your next branch merges even more complex. Likewise, as an example, if the commit preparing the 3.9.1 release and bumping the version string to 3.9.2-dev were squash merged as a pull request, then the commit that the 3.9.1 release was tagged from would not be in the repository.

=== Update Release Milestones ===
On GitHub, all merged items are assigned to a milestone to help organize items. With each release, the [https://github.com/joomla/joomla-cms/milestones milestones] should be updated to ensure that the milestone for the release you created has been closed and a milestone for the next release is open.

=== Website Updates ===
With all code updates pushed, there are several website updates that need to be triggered.

==== api.joomla.org ====
With each release, an updated build of the API documentation should be deployed to the <tt>api.joomla.org</tt> website. These updates are triggered with the <tt>Joomla! API > Deploy Docs - CMS</tt> job on Jenkins. As this job relies on the release tags from the CMS repo, this can only be done after the release tag has been pushed.

==== developer.joomla.org ====
After a release, the <tt>Joomla! Project Roadmap</tt> article in the <tt>Uncategorised</tt> category should be updated to reflect the newly released version and updated links. The version whitelist for the statistics server should also be updated to allow the next version to be submitted; if you have not already, you should have a clone of the https://github.com/joomla/statistics-server repository on your local system. Once cloned and set up, run the <tt>bin/stats tags:joomla</tt> command to regenerate the Joomla version whitelist. As this command relies on the release tags from the CMS repo, this can only be done after the release tag has been pushed. The updated <tt>versions/joomla.json</tt> should be committed and pushed, and a Jenkins job will deploy the updated site resources.

== Additional Considerations ==
The release manager or a delegate is suggested to be in communication with the Webmasters Team to ensure the <tt>joomla.org</tt> websites are updated in a timely manner. When a security release is scheduled, it is encouraged to share the update release package with the team so that our sites may be updated before the fix is made public to mitigate the chance of the vulnerability being used to exploit one of our sites.

= Framework Release Cycle =
The packages of the Joomla Framework are on an independent lifecycle meaning each package can be updated and released independently of all others. Generally the only restriction is with major releases, which should coincide with the CMS release cycle (i.e. CMS 3.x uses Framework 1.x, CMS 4.x will use Framework 2.x therefore Framework 2.0 stable releases should not be made until the CMS is in its beta phase at the earliest).

== Tagging a Release ==
Most packages can be tagged and released through the <tt>Joomla! Framework > Package Release</tt> job on Jenkins, however as of this writing this job only supports tagging releases from a repository's <tt>master</tt> branch. To tag a release, select the package you wish to update and specify the version you are releasing in the job's parameters and run the job; all releases should follow Semantic Versioning to set the correct number.

Once the job has completed, you should verify the new release is visible on [https://packagist.org/packages/joomla/ Packagist]. Within a day, the new update should be visible on the [https://framework.joomla.org/status Joomla Framework Status page] (the database is updated via cron job reading from Packagist's API), if the updated version isn't seen on the site in a relatively timely manner you should clone the website locally and debug the <tt>packagist:sync:releases</tt> command.

== Security Releases ==
When a security release is created, a pull request should be sent to the [https://github.com/FriendsOfPHP/security-advisories FriendsOfPHP/security-advisories repository] with relevant details. This repository is used by many tools in the PHP and Composer ecosystem to alert users of security issues. https://github.com/FriendsOfPHP/security-advisories/pull/134 is an example of this pull request.

[[Category:Bug Squad]]
[[Category:Coordinators]]
[[Category:Development]]

Joomla:Release procedure and checklist

2018-12-18T02:38:49Z

Mbabker:

{{incomplete}}{{RightTOC}}

This is a general checklist for managing releases of Joomla! and the Joomla! Framework. This list is best suited for a [[Minor Release]] or [[Maintenance Release]], however the steps will generally apply to a [[Major Release]] as well but will require some judgement calls from the release manager and/or leadership team.

{{note|''This document is a work in progress.'' The information on this page is currently undergoing a major revision.|type=notice}}

= CMS Release Cycle =

== Issue Triage, Patch Review, Merging Patches ==
The release cycle for a new software version begins immediately after the previous one is completed. In the immediate hours and days after a release, the [https://github.com/joomla/joomla-cms issue tracker] and [https://forum.joomla.org/ support forums], in close coordination with the [https://volunteers.joomla.org/teams/bug-squad Bug Squad] and [https://volunteers.joomla.org/teams/cms-release-team CMS Release Team], should be monitored for reports of potential regressions or critical bugs that would warrant a quick follow-on release to address the issue. It is generally suggested to wait 48-72 hours before resuming merging of reviewed and ready for commit pull requests to keep the release branch "clean" and ready for a release (note this is only a suggestion, if need be a release manager could create a branch from the release tag however this involves a bit more effort therefore this suggestion is for simplicity's sake).

Throughout the release cycle, the release manager should be involved with reviewing patches and merging reviewed patches to the appropriate release branch. As of this writing (where 3.9.1 is the present release), the following branches are generally active:

* <tt>staging</tt>: This is the main release branch and is where most activity occurs, generally only bug fixes and "general" maintenance work should merge to this branch although minor features may be merged at the discretion of the release manager and/or leadership team
* <tt>3.10-dev</tt>: This is the release branch for the next minor release (the branch's name will always be the version it represents), new features should be merged to this branch
* <tt>4.0-dev</tt>: This is the release branch for the next major release (the branch's name will always be the version it represents)

=== Branch Merging ===
All branches should remain in-sync and all work should be regularly merged forward. Given the above example, the following is the recommended merging workflow (in general, the suggested workflow is that staging is merged to the next minor branch and the next minor branch is merged to the next major branch):

* <tt>staging</tt> should be merged into <tt>3.10-dev</tt>
* <tt>3.10-dev</tt> should be merged to <tt>4.0-dev</tt>

It is suggested that at least once per week branch merging occurs.

== Preparing To Release ==
When scheduling and preparing a release, the timeline should be communicated with the Production and Marketing & Communication Department leadership so that all teams are prepared to support the release. Note that when scheduling releases, consideration should be given to holidays around the world and the impact of issuing a release near those periods considered. Helpful resources include http://interfaith-calendar.org/ and https://www.timeanddate.com/holidays/

=== Release Schedule ===
==== Minor Release ====
Given the nature of a minor release, the following is the suggested release timeline:

* Six weeks prior to planned stable release: Tag the first Beta release
** At this point the release should be considered feature complete and new features should be deferred to the next minor release
* Weekly Beta releases should follow this until the Release Candidate
* Two weeks prior to planned stable release: Tag the Release Candidate
** At this point the release branch (generally <tt>staging</tt>) should remain closed for committing except for high priority bug fixes and language updates
** With the Release Candidate, language freeze is also in effect and no language changes are permitted unless there is an urgent need (which should be communicated with the translations coordinator); note that if necessary the language freeze may be declared earlier but the Release Candidate should be considered the "no later than" time
* One week prior to planned stable release: If necessary, create a second Release Candidate
* Planned release date: Tag the stable release

==== Maintenance Release ====
Maintenance releases operate on a 4-6 week cycle and the following is the suggested release timeline:

* 4-5 days before planned release date: Tag a Release Candidate
** With the Release Candidate, language freeze is also in effect and no language changes are permitted unless there is an urgent need (which should be communicated with the translations coordinator); note that if necessary the language freeze may be declared earlier but the Release Candidate should be considered the "no later than" time
* Planned release date: Tag the stable release

=== Reviewing Release Changes ===
Before tagging a release, the list of changes in the release should be reviewed by the release manager and/or leadership team. The list of changes can be found using GitHub's compare function with the URL <tt>https://github.com/joomla/joomla-cms/compare/<version>...staging</tt> which will compare the changes from <tt><version></tt> to the current staging branch (for example, https://github.com/joomla/joomla-cms/compare/3.9.0...3.9.1-rc is the comparison from the 3.9.0 release tag to the 3.9.1-rc tag). Key purposes of this review include:

* Ensuring all patches are compliant with Semantic Versioning (SemVer) (i.e. no backward compatibility breaks in minor or maintenance releases and no features in maintenance releases); SemVer violations should be cleared with the Production Department leadership
* Ensuring all code revisions are compatible with Joomla's minimum supported versions (i.e. no PHP 5.4 syntax in 3.x releases where PHP 5.3 is the minimum supported version, exceptions may be made if introducing a code path and files that will only be executed on newer PHP versions)
** Joomla's testing integrations should not be relied on in full for this as there are large portions of the Joomla code base which do not have automated test coverage, and as of this writing, there is not a code linting process in place checking for potential issues
* Ensuring features and "significant" changes are documented

=== Security Fixes ===
From time to time, security fixes must be included in a release. Prior to every release, the release manager should check with the [https://volunteers.joomla.org/teams/security-strike-team Security Strike Team] to determine if security fixes are required, and if so ensure this is communicated to all members involved with release work (i.e. the marketing team liaison who assists with the publication of release related material). When a security release is necessary, an internal Release Candidate should be built for testing by the Security Strike Team, CMS Release Team, and [https://volunteers.joomla.org/teams/cms-maintenance-team CMS Maintenance Team] with all security patches included. These teams should also receive information about the vulnerabilities being addressed to ensure there are no regressions in the impacted areas.

Note, when a security fix involves a Joomla Framework package, the Framework package should be patched first and a release created of the affected package then the CMS updated with <tt>composer update</tt>.

== Building a Release ==
Building a release starts with checking that any files and folders that have been deleted are included in the arrays in the installer script at <tt>administrator/components/com_admin/script.php</tt>. There is a helper script in the repository to assist with this located at <tt>build/deleted_file_check.php</tt>. Running <tt>php build/deleted_file_check.php</tt> with its required <tt>--from</tt> option will write a file to <tt>build/deleted_files.txt</tt> with the list of files deleted since the from reference. Please see the PHP file for all documentation about this script.

The following steps require the individual to create commits and tags. It is suggested that these commits and tags be GPG signed as an extra security step but this is not a mandatory requirement as of this writing.

If creating a security release, at this point you should apply all patches provided by the security team.

Once it is confirmed that the deleted files listing is correct, the <tt>build/bump.php</tt> script should be executed to set the new version number. This script will also perform maintenance steps such as correcting the copyright year ranges for all files and replacing the <tt>__DEPLOY_VERSION__</tt> placeholder. Please see the file for all documentation about this script.

After running this script, review all changes with <tt>git diff</tt> as a final check before creating your release commit. Once you are satisfied that all changes are correct, commit your changes locally. Once committed, create the release tag locally; all release tags should be the version number you are creating and should match the output of <tt>Joomla\CMS\Version::getShortVersion()</tt> (so if you have created 3.9.0-beta2 then the tag should be named 3.9.0-beta2).

Once the tag has been created, you will run the <tt>build/build.php</tt> script to generate the release packages. To ensure a clean build is produced, the script makes an archive of the tag you are building using the <tt>git archive</tt> command and extracts this to the <tt>build/tmp/<timestamp></tt> directory. Depending on the patch version number, the following packages will be created in the <tt>build/tmp/packages</tt>:

* 0: Full installation and upgrade packages
* 1: Full installation, upgrade packages, and patch packages for x.y.0 to x.y.1
* 2+: Full installation, upgrade packages, patch packages for x.y.0 to x.y.<new> and x.y.<new-1> to x.y.<new> (i.e. when creating 3.8.8 this will create a patch package suitable for all 3.8.x releases and an optimized patch package for 3.8.7 to 3.8.8)

Additionally, the script will generate a <tt>build/tmp/checksums.txt</tt> file with the checksums for all generated packages.

After the packages are created, you should validate that you are able to install and update a site using the ZIP packages (as these are the most frequently used type and served by our update system).

== Publishing a Release ==
=== Release Packages ===
Depending on the type of release being created, you will publish the release packages in different locations.

==== Alpha, Beta, Release Candidate ====
The packages for these releases are uploaded to GitHub. When ready to publish, you should push the release tag you created to GitHub and use their interface to create a release from the tag and upload the packages. There is a text template used for the releases, generally you can copy a previous release's text and adjust it to the version you are publishing.

==== Stable ====
The packages for stable releases are uploaded to multiple locations, this is in part driven by the fact that the Amazon Web Services (AWS) S3 region used by Joomla is blocked in some locations therefore download mirrors are available when necessary.

===== Joomla! Downloads Portal =====
The canonical source for all stable releases is the [https://downloads.joomla.org/ Joomla! Downloads Portal]. The packages served from the site use Joomla's AWS account. You will need to log into the AWS console to upload the packages to S3 under the <tt>joomla-official-downloads</tt> bucket. The exact path inside the bucket is <tt>joomladownloads/joomla<version></tt> where <tt><version></tt> is the major version number (i.e. <tt>joomla3</tt>), note for compatibility with Akeeba Release System folders for each individual release are not used.

===== Joomla! Update Server =====
The Joomla! Update Server is used as a mirror for the download packages. After connecting to the server, you should create a new folder at <tt>www/releases/<version></tt> (i.e. <tt>www/releases/3.9.1</tt> for the 3.9.1 release) and upload the packages here.

===== GitHub =====
The packages are also uploaded to GitHub. This is similar to the steps for alpha, beta, and release candidate releases above. Note that you only need to push the release tag at this point (i.e. <tt>git push --tags</tt>), you can wait to push the updated release branch until after the release is available.

=== Announcements ===
==== joomla.org ====
For all stable releases, the main release announcement is published to the <tt>Joomla! Official News > Project Release News</tt> category on the main <tt>joomla.org</tt> website.

For a minor release, an updated version of the landing page at <tt>joomla.org/3</tt> is published. Generally, this site is backed up from the sandbox location and transferred to the live domain shortly before release, this transfer should be coordinated with the [https://volunteers.joomla.org/teams/webmasters-team Webmasters Team].

==== developer.joomla.org ====
For security releases, all accompanying articles are published to the <tt>News > Security Centre</tt> category on the Joomla! Developer Network. As these articles are referenced from the main release announcement, these should be published at the same time.

== Update Server ==
The update server must be updated to alert websites that a core update is available, this subdomain is managed on GitHub at https://github.com/joomla/update.joomla.org. Prior to each release, a pull request should be prepared with necessary changes for the release (generally this updates the version number, announcement URL, package URLs, and package checksums for the stable release and updating the version number for the nightly builds), see https://github.com/joomla/update.joomla.org/pull/117 as an example of this update for the 3.9.1 release. Pushes to the <tt>master</tt> branch of this repo are automatically deployed thanks to a Jenkins job, notifications for many of the Jenkins jobs are sent to the <tt>.org Build Notifications</tt> channel on RingCentral Glip so you should ensure a success notification was sent here otherwise check if there was an issue with the job and/or manually deploy the updated files.

Note that the <tt>update.joomla.org</tt> subdomain is behind a CDN and it generally takes 5-10 minutes for all nodes to update, if need be you can access <tt>update1.joomla.org</tt> to verify the right files are deployed without using the CDN.

== Post Release Actions ==
Once the release is published, there are several additional tasks that should be completed shortly after.

=== Post-Release Version Bump ===
The version should be bumped to the next version scheduled for release using the <tt>build/bump.php</tt> script (i.e. after the 3.9.1 release this would be bumped to 3.9.2-dev).

=== Branch Merging ===
After incrementing the version number, you should merge all the release changes forward to other active branches (especially in the case of a security release). Ensure you pay careful attention while resolving merge conflicts, when making a merge that includes a version bump generally all files which contain the version string and/or release date will be in conflict (as of this writing this is 8 files).

=== Push Updated Branches ===
When ready, you should directly push your updates to the Git repo. If you elect to use pull requests, the pull requests should NEVER be squashed or rebased otherwise this will wipe out Git's awareness of the merged commits and will make your next branch merges even more complex. Likewise, as an example, if the commit preparing the 3.9.1 release and bumping the version string to 3.9.2-dev were squash merged as a pull request, then the commit that the 3.9.1 release was tagged from would not be in the repository.

=== Website Updates ===
With all code updates pushed, there are several website updates that need to be triggered.

==== api.joomla.org ====
With each release, an updated build of the API documentation should be deployed to the <tt>api.joomla.org</tt> website. These updates are triggered with the <tt>Joomla! API > Deploy Docs - CMS</tt> job on Jenkins. As this job relies on the release tags from the CMS repo, this can only be done after the release tag has been pushed.

==== developer.joomla.org ====
After a release, the <tt>Joomla! Project Roadmap</tt> article in the <tt>Uncategorised</tt> category should be updated to reflect the newly released version and updated links. The version whitelist for the statistics server should also be updated to allow the next version to be submitted; if you have not already, you should have a clone of the https://github.com/joomla/statistics-server repository on your local system. Once cloned and set up, run the <tt>bin/stats tags:joomla</tt> command to regenerate the Joomla version whitelist. As this command relies on the release tags from the CMS repo, this can only be done after the release tag has been pushed. The updated <tt>versions/joomla.json</tt> should be committed and pushed, and a Jenkins job will deploy the updated site resources.

== Additional Considerations ==
The release manager or a delegate is suggested to be in communication with the Webmasters Team to ensure the <tt>joomla.org</tt> websites are updated in a timely manner. When a security release is scheduled, it is encouraged to share the update release package with the team so that our sites may be updated before the fix is made public to mitigate the chance of the vulnerability being used to exploit one of our sites.

= Framework Release Cycle =
The packages of the Joomla Framework are on an independent lifecycle meaning each package can be updated and released independently of all others. Generally the only restriction is with major releases, which should coincide with the CMS release cycle (i.e. CMS 3.x uses Framework 1.x, CMS 4.x will use Framework 2.x therefore Framework 2.0 stable releases should not be made until the CMS is in its beta phase at the earliest).

== Tagging a Release ==
Most packages can be tagged and released through the <tt>Joomla! Framework > Package Release</tt> job on Jenkins, however as of this writing this job only supports tagging releases from a repository's <tt>master</tt> branch. To tag a release, select the package you wish to update and specify the version you are releasing in the job's parameters and run the job; all releases should follow Semantic Versioning to set the correct number.

Once the job has completed, you should verify the new release is visible on [https://packagist.org/packages/joomla/ Packagist]. Within a day, the new update should be visible on the [https://framework.joomla.org/status Joomla Framework Status page] (the database is updated via cron job reading from Packagist's API), if the updated version isn't seen on the site in a relatively timely manner you should clone the website locally and debug the <tt>packagist:sync:releases</tt> command.

== Security Releases ==
When a security release is created, a pull request should be sent to the [https://github.com/FriendsOfPHP/security-advisories FriendsOfPHP/security-advisories repository] with relevant details. This repository is used by many tools in the PHP and Composer ecosystem to alert users of security issues. https://github.com/FriendsOfPHP/security-advisories/pull/134 is an example of this pull request.

[[Category:Bug Squad]]
[[Category:Coordinators]]
[[Category:Development]]

Joomla:Release procedure and checklist

2018-12-18T02:36:13Z

Mbabker: Framework releases

{{incomplete}}{{RightTOC}}

This is a general checklist for managing releases of Joomla! and the Joomla! Framework. This list is best suited for a [[Minor Release]] or [[Maintenance Release]], however the steps will generally apply to a [[Major Release]] as well but will require some judgement calls from the release manager and/or leadership team.

{{note|''This document is a work in progress.'' The information on this page is currently undergoing a major revision, the previous version of this document is available below as a point of reference for these revisions.|type=notice}}

= CMS Release Cycle =

== Issue Triage, Patch Review, Merging Patches ==
The release cycle for a new software version begins immediately after the previous one is completed. In the immediate hours and days after a release, the [https://github.com/joomla/joomla-cms issue tracker] and [https://forum.joomla.org/ support forums], in close coordination with the [https://volunteers.joomla.org/teams/bug-squad Bug Squad] and [https://volunteers.joomla.org/teams/cms-release-team CMS Release Team], should be monitored for reports of potential regressions or critical bugs that would warrant a quick follow-on release to address the issue. It is generally suggested to wait 48-72 hours before resuming merging of reviewed and ready for commit pull requests to keep the release branch "clean" and ready for a release (note this is only a suggestion, if need be a release manager could create a branch from the release tag however this involves a bit more effort therefore this suggestion is for simplicity's sake).

Throughout the release cycle, the release manager should be involved with reviewing patches and merging reviewed patches to the appropriate release branch. As of this writing (where 3.9.1 is the present release), the following branches are generally active:

* <tt>staging</tt>: This is the main release branch and is where most activity occurs, generally only bug fixes and "general" maintenance work should merge to this branch although minor features may be merged at the discretion of the release manager and/or leadership team
* <tt>3.10-dev</tt>: This is the release branch for the next minor release (the branch's name will always be the version it represents), new features should be merged to this branch
* <tt>4.0-dev</tt>: This is the release branch for the next major release (the branch's name will always be the version it represents)

=== Branch Merging ===
All branches should remain in-sync and all work should be regularly merged forward. Given the above example, the following is the recommended merging workflow (in general, the suggested workflow is that staging is merged to the next minor branch and the next minor branch is merged to the next major branch):

* <tt>staging</tt> should be merged into <tt>3.10-dev</tt>
* <tt>3.10-dev</tt> should be merged to <tt>4.0-dev</tt>

It is suggested that at least once per week branch merging occurs.

== Preparing To Release ==
When scheduling and preparing a release, the timeline should be communicated with the Production and Marketing & Communication Department leadership so that all teams are prepared to support the release. Note that when scheduling releases, consideration should be given to holidays around the world and the impact of issuing a release near those periods considered. Helpful resources include http://interfaith-calendar.org/ and https://www.timeanddate.com/holidays/

=== Release Schedule ===
==== Minor Release ====
Given the nature of a minor release, the following is the suggested release timeline:

* Six weeks prior to planned stable release: Tag the first Beta release
** At this point the release should be considered feature complete and new features should be deferred to the next minor release
* Weekly Beta releases should follow this until the Release Candidate
* Two weeks prior to planned stable release: Tag the Release Candidate
** At this point the release branch (generally <tt>staging</tt>) should remain closed for committing except for high priority bug fixes and language updates
** With the Release Candidate, language freeze is also in effect and no language changes are permitted unless there is an urgent need (which should be communicated with the translations coordinator); note that if necessary the language freeze may be declared earlier but the Release Candidate should be considered the "no later than" time
* One week prior to planned stable release: If necessary, create a second Release Candidate
* Planned release date: Tag the stable release

==== Maintenance Release ====
Maintenance releases operate on a 4-6 week cycle and the following is the suggested release timeline:

* 4-5 days before planned release date: Tag a Release Candidate
** With the Release Candidate, language freeze is also in effect and no language changes are permitted unless there is an urgent need (which should be communicated with the translations coordinator); note that if necessary the language freeze may be declared earlier but the Release Candidate should be considered the "no later than" time
* Planned release date: Tag the stable release

=== Reviewing Release Changes ===
Before tagging a release, the list of changes in the release should be reviewed by the release manager and/or leadership team. The list of changes can be found using GitHub's compare function with the URL <tt>https://github.com/joomla/joomla-cms/compare/<version>...staging</tt> which will compare the changes from <tt><version></tt> to the current staging branch (for example, https://github.com/joomla/joomla-cms/compare/3.9.0...3.9.1-rc is the comparison from the 3.9.0 release tag to the 3.9.1-rc tag). Key purposes of this review include:

* Ensuring all patches are compliant with Semantic Versioning (SemVer) (i.e. no backward compatibility breaks in minor or maintenance releases and no features in maintenance releases); SemVer violations should be cleared with the Production Department leadership
* Ensuring all code revisions are compatible with Joomla's minimum supported versions (i.e. no PHP 5.4 syntax in 3.x releases where PHP 5.3 is the minimum supported version, exceptions may be made if introducing a code path and files that will only be executed on newer PHP versions)
** Joomla's testing integrations should not be relied on in full for this as there are large portions of the Joomla code base which do not have automated test coverage, and as of this writing, there is not a code linting process in place checking for potential issues
* Ensuring features and "significant" changes are documented

=== Security Fixes ===
From time to time, security fixes must be included in a release. Prior to every release, the release manager should check with the [https://volunteers.joomla.org/teams/security-strike-team Security Strike Team] to determine if security fixes are required, and if so ensure this is communicated to all members involved with release work (i.e. the marketing team liaison who assists with the publication of release related material). When a security release is necessary, an internal Release Candidate should be built for testing by the Security Strike Team, CMS Release Team, and [https://volunteers.joomla.org/teams/cms-maintenance-team CMS Maintenance Team] with all security patches included. These teams should also receive information about the vulnerabilities being addressed to ensure there are no regressions in the impacted areas.

Note, when a security fix involves a Joomla Framework package, the Framework package should be patched first and a release created of the affected package then the CMS updated with <tt>composer update</tt>.

== Building a Release ==
Building a release starts with checking that any files and folders that have been deleted are included in the arrays in the installer script at <tt>administrator/components/com_admin/script.php</tt>. There is a helper script in the repository to assist with this located at <tt>build/deleted_file_check.php</tt>. Running <tt>php build/deleted_file_check.php</tt> with its required <tt>--from</tt> option will write a file to <tt>build/deleted_files.txt</tt> with the list of files deleted since the from reference. Please see the PHP file for all documentation about this script.

The following steps require the individual to create commits and tags. It is suggested that these commits and tags be GPG signed as an extra security step but this is not a mandatory requirement as of this writing.

If creating a security release, at this point you should apply all patches provided by the security team.

Once it is confirmed that the deleted files listing is correct, the <tt>build/bump.php</tt> script should be executed to set the new version number. This script will also perform maintenance steps such as correcting the copyright year ranges for all files and replacing the <tt>__DEPLOY_VERSION__</tt> placeholder. Please see the file for all documentation about this script.

After running this script, review all changes with <tt>git diff</tt> as a final check before creating your release commit. Once you are satisfied that all changes are correct, commit your changes locally. Once committed, create the release tag locally; all release tags should be the version number you are creating and should match the output of <tt>Joomla\CMS\Version::getShortVersion()</tt> (so if you have created 3.9.0-beta2 then the tag should be named 3.9.0-beta2).

Once the tag has been created, you will run the <tt>build/build.php</tt> script to generate the release packages. To ensure a clean build is produced, the script makes an archive of the tag you are building using the <tt>git archive</tt> command and extracts this to the <tt>build/tmp/<timestamp></tt> directory. Depending on the patch version number, the following packages will be created in the <tt>build/tmp/packages</tt>:

* 0: Full installation and upgrade packages
* 1: Full installation, upgrade packages, and patch packages for x.y.0 to x.y.1
* 2+: Full installation, upgrade packages, patch packages for x.y.0 to x.y.<new> and x.y.<new-1> to x.y.<new> (i.e. when creating 3.8.8 this will create a patch package suitable for all 3.8.x releases and an optimized patch package for 3.8.7 to 3.8.8)

Additionally, the script will generate a <tt>build/tmp/checksums.txt</tt> file with the checksums for all generated packages.

After the packages are created, you should validate that you are able to install and update a site using the ZIP packages (as these are the most frequently used type and served by our update system).

== Publishing a Release ==
=== Release Packages ===
Depending on the type of release being created, you will publish the release packages in different locations.

==== Alpha, Beta, Release Candidate ====
The packages for these releases are uploaded to GitHub. When ready to publish, you should push the release tag you created to GitHub and use their interface to create a release from the tag and upload the packages. There is a text template used for the releases, generally you can copy a previous release's text and adjust it to the version you are publishing.

==== Stable ====
The packages for stable releases are uploaded to multiple locations, this is in part driven by the fact that the Amazon Web Services (AWS) S3 region used by Joomla is blocked in some locations therefore download mirrors are available when necessary.

===== Joomla! Downloads Portal =====
The canonical source for all stable releases is the [https://downloads.joomla.org/ Joomla! Downloads Portal]. The packages served from the site use Joomla's AWS account. You will need to log into the AWS console to upload the packages to S3 under the <tt>joomla-official-downloads</tt> bucket. The exact path inside the bucket is <tt>joomladownloads/joomla<version></tt> where <tt><version></tt> is the major version number (i.e. <tt>joomla3</tt>), note for compatibility with Akeeba Release System folders for each individual release are not used.

===== Joomla! Update Server =====
The Joomla! Update Server is used as a mirror for the download packages. After connecting to the server, you should create a new folder at <tt>www/releases/<version></tt> (i.e. <tt>www/releases/3.9.1</tt> for the 3.9.1 release) and upload the packages here.

===== GitHub =====
The packages are also uploaded to GitHub. This is similar to the steps for alpha, beta, and release candidate releases above. Note that you only need to push the release tag at this point (i.e. <tt>git push --tags</tt>), you can wait to push the updated release branch until after the release is available.

=== Announcements ===
==== joomla.org ====
For all stable releases, the main release announcement is published to the <tt>Joomla! Official News > Project Release News</tt> category on the main <tt>joomla.org</tt> website.

For a minor release, an updated version of the landing page at <tt>joomla.org/3</tt> is published. Generally, this site is backed up from the sandbox location and transferred to the live domain shortly before release, this transfer should be coordinated with the [https://volunteers.joomla.org/teams/webmasters-team Webmasters Team].

==== developer.joomla.org ====
For security releases, all accompanying articles are published to the <tt>News > Security Centre</tt> category on the Joomla! Developer Network. As these articles are referenced from the main release announcement, these should be published at the same time.

== Update Server ==
The update server must be updated to alert websites that a core update is available, this subdomain is managed on GitHub at https://github.com/joomla/update.joomla.org. Prior to each release, a pull request should be prepared with necessary changes for the release (generally this updates the version number, announcement URL, package URLs, and package checksums for the stable release and updating the version number for the nightly builds), see https://github.com/joomla/update.joomla.org/pull/117 as an example of this update for the 3.9.1 release. Pushes to the <tt>master</tt> branch of this repo are automatically deployed thanks to a Jenkins job, notifications for many of the Jenkins jobs are sent to the <tt>.org Build Notifications</tt> channel on RingCentral Glip so you should ensure a success notification was sent here otherwise check if there was an issue with the job and/or manually deploy the updated files.

Note that the <tt>update.joomla.org</tt> subdomain is behind a CDN and it generally takes 5-10 minutes for all nodes to update, if need be you can access <tt>update1.joomla.org</tt> to verify the right files are deployed without using the CDN.

== Post Release Actions ==
Once the release is published, there are several additional tasks that should be completed shortly after.

=== Post-Release Version Bump ===
The version should be bumped to the next version scheduled for release using the <tt>build/bump.php</tt> script (i.e. after the 3.9.1 release this would be bumped to 3.9.2-dev).

=== Branch Merging ===
After incrementing the version number, you should merge all the release changes forward to other active branches (especially in the case of a security release). Ensure you pay careful attention while resolving merge conflicts, when making a merge that includes a version bump generally all files which contain the version string and/or release date will be in conflict (as of this writing this is 8 files).

=== Push Updated Branches ===
When ready, you should directly push your updates to the Git repo. If you elect to use pull requests, the pull requests should NEVER be squashed or rebased otherwise this will wipe out Git's awareness of the merged commits and will make your next branch merges even more complex. Likewise, as an example, if the commit preparing the 3.9.1 release and bumping the version string to 3.9.2-dev were squash merged as a pull request, then the commit that the 3.9.1 release was tagged from would not be in the repository.

=== Website Updates ===
With all code updates pushed, there are several website updates that need to be triggered.

==== api.joomla.org ====
With each release, an updated build of the API documentation should be deployed to the <tt>api.joomla.org</tt> website. These updates are triggered with the <tt>Joomla! API > Deploy Docs - CMS</tt> job on Jenkins. As this job relies on the release tags from the CMS repo, this can only be done after the release tag has been pushed.

==== developer.joomla.org ====
After a release, the <tt>Joomla! Project Roadmap</tt> article in the <tt>Uncategorised</tt> category should be updated to reflect the newly released version and updated links. The version whitelist for the statistics server should also be updated to allow the next version to be submitted; if you have not already, you should have a clone of the https://github.com/joomla/statistics-server repository on your local system. Once cloned and set up, run the <tt>bin/stats tags:joomla</tt> command to regenerate the Joomla version whitelist. As this command relies on the release tags from the CMS repo, this can only be done after the release tag has been pushed. The updated <tt>versions/joomla.json</tt> should be committed and pushed, and a Jenkins job will deploy the updated site resources.

== Additional Considerations ==
The release manager or a delegate is suggested to be in communication with the Webmasters Team to ensure the <tt>joomla.org</tt> websites are updated in a timely manner. When a security release is scheduled, it is encouraged to share the update release package with the team so that our sites may be updated before the fix is made public to mitigate the chance of the vulnerability being used to exploit one of our sites.

= Framework Release Cycle =
The packages of the Joomla Framework are on an independent lifecycle meaning each package can be updated and released independently of all others. Generally the only restriction is with major releases, which should coincide with the CMS release cycle (i.e. CMS 3.x uses Framework 1.x, CMS 4.x will use Framework 2.x therefore Framework 2.0 stable releases should not be made until the CMS is in its beta phase at the earliest).

== Tagging a Release ==
Most packages can be tagged and released through the <tt>Joomla! Framework > Package Release</tt> job on Jenkins, however as of this writing this job only supports tagging releases from a repository's <tt>master</tt> branch. To tag a release, select the package you wish to update and specify the version you are releasing in the job's parameters and run the job; all releases should follow Semantic Versioning to set the correct number.

Once the job has completed, you should verify the new release is visible on [https://packagist.org/packages/joomla/ Packagist]. Within a day, the new update should be visible on the [https://framework.joomla.org/status Joomla Framework Status page] (the database is updated via cron job reading from Packagist's API), if the updated version isn't seen on the site in a relatively timely manner you should clone the website locally and debug the <tt>packagist:sync:releases</tt> command.

== Security Releases ==
When a security release is created, a pull request should be sent to the [https://github.com/FriendsOfPHP/security-advisories FriendsOfPHP/security-advisories repository] with relevant details. This repository is used by many tools in the PHP and Composer ecosystem to alert users of security issues. https://github.com/FriendsOfPHP/security-advisories/pull/134 is an example of this pull request.

[[Category:Bug Squad]]
[[Category:Coordinators]]
[[Category:Development]]

Joomla:Release procedure and checklist

2018-12-18T02:12:48Z

Mbabker: Finish out CMS release section, clear old version

{{incomplete}}{{RightTOC}}

This is a general checklist for managing releases of Joomla! and the Joomla! Framework. This list is best suited for a [[Minor Release]] or [[Maintenance Release]], however the steps will generally apply to a [[Major Release]] as well but will require some judgement calls from the release manager and/or leadership team.

{{note|''This document is a work in progress.'' The information on this page is currently undergoing a major revision, the previous version of this document is available below as a point of reference for these revisions.|type=notice}}

= CMS Release Cycle =

== Issue Triage, Patch Review, Merging Patches ==
The release cycle for a new software version begins immediately after the previous one is completed. In the immediate hours and days after a release, the [https://github.com/joomla/joomla-cms issue tracker] and [https://forum.joomla.org/ support forums], in close coordination with the [https://volunteers.joomla.org/teams/bug-squad Bug Squad] and [https://volunteers.joomla.org/teams/cms-release-team CMS Release Team], should be monitored for reports of potential regressions or critical bugs that would warrant a quick follow-on release to address the issue. It is generally suggested to wait 48-72 hours before resuming merging of reviewed and ready for commit pull requests to keep the release branch "clean" and ready for a release (note this is only a suggestion, if need be a release manager could create a branch from the release tag however this involves a bit more effort therefore this suggestion is for simplicity's sake).

Throughout the release cycle, the release manager should be involved with reviewing patches and merging reviewed patches to the appropriate release branch. As of this writing (where 3.9.1 is the present release), the following branches are generally active:

* <tt>staging</tt>: This is the main release branch and is where most activity occurs, generally only bug fixes and "general" maintenance work should merge to this branch although minor features may be merged at the discretion of the release manager and/or leadership team
* <tt>3.10-dev</tt>: This is the release branch for the next minor release (the branch's name will always be the version it represents), new features should be merged to this branch
* <tt>4.0-dev</tt>: This is the release branch for the next major release (the branch's name will always be the version it represents)

=== Branch Merging ===
All branches should remain in-sync and all work should be regularly merged forward. Given the above example, the following is the recommended merging workflow (in general, the suggested workflow is that staging is merged to the next minor branch and the next minor branch is merged to the next major branch):

* <tt>staging</tt> should be merged into <tt>3.10-dev</tt>
* <tt>3.10-dev</tt> should be merged to <tt>4.0-dev</tt>

It is suggested that at least once per week branch merging occurs.

== Preparing To Release ==
When scheduling and preparing a release, the timeline should be communicated with the Production and Marketing & Communication Department leadership so that all teams are prepared to support the release. Note that when scheduling releases, consideration should be given to holidays around the world and the impact of issuing a release near those periods considered. Helpful resources include http://interfaith-calendar.org/ and https://www.timeanddate.com/holidays/

=== Release Schedule ===
==== Minor Release ====
Given the nature of a minor release, the following is the suggested release timeline:

* Six weeks prior to planned stable release: Tag the first Beta release
** At this point the release should be considered feature complete and new features should be deferred to the next minor release
* Weekly Beta releases should follow this until the Release Candidate
* Two weeks prior to planned stable release: Tag the Release Candidate
** At this point the release branch (generally <tt>staging</tt>) should remain closed for committing except for high priority bug fixes and language updates
** With the Release Candidate, language freeze is also in effect and no language changes are permitted unless there is an urgent need (which should be communicated with the translations coordinator); note that if necessary the language freeze may be declared earlier but the Release Candidate should be considered the "no later than" time
* One week prior to planned stable release: If necessary, create a second Release Candidate
* Planned release date: Tag the stable release

==== Maintenance Release ====
Maintenance releases operate on a 4-6 week cycle and the following is the suggested release timeline:

* 4-5 days before planned release date: Tag a Release Candidate
** With the Release Candidate, language freeze is also in effect and no language changes are permitted unless there is an urgent need (which should be communicated with the translations coordinator); note that if necessary the language freeze may be declared earlier but the Release Candidate should be considered the "no later than" time
* Planned release date: Tag the stable release

=== Reviewing Release Changes ===
Before tagging a release, the list of changes in the release should be reviewed by the release manager and/or leadership team. The list of changes can be found using GitHub's compare function with the URL <tt>https://github.com/joomla/joomla-cms/compare/<version>...staging</tt> which will compare the changes from <tt><version></tt> to the current staging branch (for example, https://github.com/joomla/joomla-cms/compare/3.9.0...3.9.1-rc is the comparison from the 3.9.0 release tag to the 3.9.1-rc tag). Key purposes of this review include:

* Ensuring all patches are compliant with Semantic Versioning (SemVer) (i.e. no backward compatibility breaks in minor or maintenance releases and no features in maintenance releases); SemVer violations should be cleared with the Production Department leadership
* Ensuring all code revisions are compatible with Joomla's minimum supported versions (i.e. no PHP 5.4 syntax in 3.x releases where PHP 5.3 is the minimum supported version, exceptions may be made if introducing a code path and files that will only be executed on newer PHP versions)
** Joomla's testing integrations should not be relied on in full for this as there are large portions of the Joomla code base which do not have automated test coverage, and as of this writing, there is not a code linting process in place checking for potential issues
* Ensuring features and "significant" changes are documented

=== Security Fixes ===
From time to time, security fixes must be included in a release. Prior to every release, the release manager should check with the [https://volunteers.joomla.org/teams/security-strike-team Security Strike Team] to determine if security fixes are required, and if so ensure this is communicated to all members involved with release work (i.e. the marketing team liaison who assists with the publication of release related material). When a security release is necessary, an internal Release Candidate should be built for testing by the Security Strike Team, CMS Release Team, and [https://volunteers.joomla.org/teams/cms-maintenance-team CMS Maintenance Team] with all security patches included. These teams should also receive information about the vulnerabilities being addressed to ensure there are no regressions in the impacted areas.

Note, when a security fix involves a Joomla Framework package, the Framework package should be patched first and a release created of the affected package then the CMS updated with <tt>composer update</tt>.

== Building a Release ==
Building a release starts with checking that any files and folders that have been deleted are included in the arrays in the installer script at <tt>administrator/components/com_admin/script.php</tt>. There is a helper script in the repository to assist with this located at <tt>build/deleted_file_check.php</tt>. Running <tt>php build/deleted_file_check.php</tt> with its required <tt>--from</tt> option will write a file to <tt>build/deleted_files.txt</tt> with the list of files deleted since the from reference. Please see the PHP file for all documentation about this script.

The following steps require the individual to create commits and tags. It is suggested that these commits and tags be GPG signed as an extra security step but this is not a mandatory requirement as of this writing.

If creating a security release, at this point you should apply all patches provided by the security team.

Once it is confirmed that the deleted files listing is correct, the <tt>build/bump.php</tt> script should be executed to set the new version number. This script will also perform maintenance steps such as correcting the copyright year ranges for all files and replacing the <tt>__DEPLOY_VERSION__</tt> placeholder. Please see the file for all documentation about this script.

After running this script, review all changes with <tt>git diff</tt> as a final check before creating your release commit. Once you are satisfied that all changes are correct, commit your changes locally. Once committed, create the release tag locally; all release tags should be the version number you are creating and should match the output of <tt>Joomla\CMS\Version::getShortVersion()</tt> (so if you have created 3.9.0-beta2 then the tag should be named 3.9.0-beta2).

Once the tag has been created, you will run the <tt>build/build.php</tt> script to generate the release packages. To ensure a clean build is produced, the script makes an archive of the tag you are building using the <tt>git archive</tt> command and extracts this to the <tt>build/tmp/<timestamp></tt> directory. Depending on the patch version number, the following packages will be created in the <tt>build/tmp/packages</tt>:

* 0: Full installation and upgrade packages
* 1: Full installation, upgrade packages, and patch packages for x.y.0 to x.y.1
* 2+: Full installation, upgrade packages, patch packages for x.y.0 to x.y.<new> and x.y.<new-1> to x.y.<new> (i.e. when creating 3.8.8 this will create a patch package suitable for all 3.8.x releases and an optimized patch package for 3.8.7 to 3.8.8)

Additionally, the script will generate a <tt>build/tmp/checksums.txt</tt> file with the checksums for all generated packages.

After the packages are created, you should validate that you are able to install and update a site using the ZIP packages (as these are the most frequently used type and served by our update system).

== Publishing a Release ==
=== Release Packages ===
Depending on the type of release being created, you will publish the release packages in different locations.

==== Alpha, Beta, Release Candidate ====
The packages for these releases are uploaded to GitHub. When ready to publish, you should push the release tag you created to GitHub and use their interface to create a release from the tag and upload the packages. There is a text template used for the releases, generally you can copy a previous release's text and adjust it to the version you are publishing.

==== Stable ====
The packages for stable releases are uploaded to multiple locations, this is in part driven by the fact that the Amazon Web Services (AWS) S3 region used by Joomla is blocked in some locations therefore download mirrors are available when necessary.

===== Joomla! Downloads Portal =====
The canonical source for all stable releases is the [https://downloads.joomla.org/ Joomla! Downloads Portal]. The packages served from the site use Joomla's AWS account. You will need to log into the AWS console to upload the packages to S3 under the <tt>joomla-official-downloads</tt> bucket. The exact path inside the bucket is <tt>joomladownloads/joomla<version></tt> where <tt><version></tt> is the major version number (i.e. <tt>joomla3</tt>), note for compatibility with Akeeba Release System folders for each individual release are not used.

===== Joomla! Update Server =====
The Joomla! Update Server is used as a mirror for the download packages. After connecting to the server, you should create a new folder at <tt>www/releases/<version></tt> (i.e. <tt>www/releases/3.9.1</tt> for the 3.9.1 release) and upload the packages here.

===== GitHub =====
The packages are also uploaded to GitHub. This is similar to the steps for alpha, beta, and release candidate releases above. Note that you only need to push the release tag at this point (i.e. <tt>git push --tags</tt>), you can wait to push the updated release branch until after the release is available.

=== Announcements ===
==== joomla.org ====
For all stable releases, the main release announcement is published to the <tt>Joomla! Official News > Project Release News</tt> category on the main <tt>joomla.org</tt> website.

For a minor release, an updated version of the landing page at <tt>joomla.org/3</tt> is published. Generally, this site is backed up from the sandbox location and transferred to the live domain shortly before release, this transfer should be coordinated with the [https://volunteers.joomla.org/teams/webmasters-team Webmasters Team].

==== developer.joomla.org ====
For security releases, all accompanying articles are published to the <tt>News > Security Centre</tt> category on the Joomla! Developer Network. As these articles are referenced from the main release announcement, these should be published at the same time.

== Update Server ==
The update server must be updated to alert websites that a core update is available, this subdomain is managed on GitHub at https://github.com/joomla/update.joomla.org. Prior to each release, a pull request should be prepared with necessary changes for the release (generally this updates the version number, announcement URL, package URLs, and package checksums for the stable release and updating the version number for the nightly builds), see https://github.com/joomla/update.joomla.org/pull/117 as an example of this update for the 3.9.1 release. Pushes to the <tt>master</tt> branch of this repo are automatically deployed thanks to a Jenkins job, notifications for many of the Jenkins jobs are sent to the <tt>.org Build Notifications</tt> channel on RingCentral Glip so you should ensure a success notification was sent here otherwise check if there was an issue with the job and/or manually deploy the updated files.

Note that the <tt>update.joomla.org</tt> subdomain is behind a CDN and it generally takes 5-10 minutes for all nodes to update, if need be you can access <tt>update1.joomla.org</tt> to verify the right files are deployed without using the CDN.

== Post Release Actions ==
Once the release is published, there are several additional tasks that should be completed shortly after.

=== Post-Release Version Bump ===
The version should be bumped to the next version scheduled for release using the <tt>build/bump.php</tt> script (i.e. after the 3.9.1 release this would be bumped to 3.9.2-dev).

=== Branch Merging ===
After incrementing the version number, you should merge all the release changes forward to other active branches (especially in the case of a security release). Ensure you pay careful attention while resolving merge conflicts, when making a merge that includes a version bump generally all files which contain the version string and/or release date will be in conflict (as of this writing this is 8 files).

=== Push Updated Branches ===
When ready, you should directly push your updates to the Git repo. If you elect to use pull requests, the pull requests should NEVER be squashed or rebased otherwise this will wipe out Git's awareness of the merged commits and will make your next branch merges even more complex. Likewise, as an example, if the commit preparing the 3.9.1 release and bumping the version string to 3.9.2-dev were squash merged as a pull request, then the commit that the 3.9.1 release was tagged from would not be in the repository.

=== Website Updates ===
With all code updates pushed, there are several website updates that need to be triggered.

==== api.joomla.org ====
With each release, an updated build of the API documentation should be deployed to the <tt>api.joomla.org</tt> website. These updates are triggered with the <tt>Joomla! API > Deploy Docs - CMS</tt> job on Jenkins. As this job relies on the release tags from the CMS repo, this can only be done after the release tag has been pushed.

==== developer.joomla.org ====
After a release, the <tt>Joomla! Project Roadmap</tt> article in the <tt>Uncategorised</tt> category should be updated to reflect the newly released version and updated links. The version whitelist for the statistics server should also be updated to allow the next version to be submitted; if you have not already, you should have a clone of the https://github.com/joomla/statistics-server repository on your local system. Once cloned and set up, run the <tt>bin/stats tags:joomla</tt> command to regenerate the Joomla version whitelist. As this command relies on the release tags from the CMS repo, this can only be done after the release tag has been pushed. The updated <tt>versions/joomla.json</tt> should be committed and pushed, and a Jenkins job will deploy the updated site resources.

== Additional Considerations ==
The release manager or a delegate is suggested to be in communication with the Webmasters Team to ensure the <tt>joomla.org</tt> websites are updated in a timely manner. When a security release is scheduled, it is encouraged to share the update release package with the team so that our sites may be updated before the fix is made public to mitigate the chance of the vulnerability being used to exploit one of our sites.

[[Category:Bug Squad]]
[[Category:Coordinators]]
[[Category:Development]]

Joomla:Release procedure and checklist

2018-12-16T17:38:55Z

Mbabker: A lot of text

{{incomplete}}{{RightTOC}}

This is a general checklist for managing releases of Joomla! and the Joomla! Framework. This list is best suited for a [[Minor Release]] or [[Maintenance Release]], however the steps will generally apply to a [[Major Release]] as well but will require some judgement calls from the release manager and/or leadership team.

{{note|''This document is a work in progress.'' The information on this page is currently undergoing a major revision, the previous version of this document is available below as a point of reference for these revisions.|type=notice}}

= CMS Release Cycle =

== Issue Triage, Patch Review, Merging Patches ==
The release cycle for a new software version begins immediately after the previous one is completed. In the immediate hours and days after a release, the [https://github.com/joomla/joomla-cms issue tracker] and [https://forum.joomla.org/ support forums], in close coordination with the [https://volunteers.joomla.org/teams/bug-squad Bug Squad] and [https://volunteers.joomla.org/teams/cms-release-team CMS Release Team], should be monitored for reports of potential regressions or critical bugs that would warrant a quick follow-on release to address the issue. It is generally suggested to wait 48-72 hours before resuming merging of reviewed and ready for commit pull requests to keep the release branch "clean" and ready for a release (note this is only a suggestion, if need be a release manager could create a branch from the release tag however this involves a bit more effort therefore this suggestion is for simplicity's sake).

Throughout the release cycle, the release manager should be involved with reviewing patches and merging reviewed patches to the appropriate release branch. As of this writing (where 3.9.1 is the present release), the following branches are generally active:

* <tt>staging</tt>: This is the main release branch and is where most activity occurs, generally only bug fixes and "general" maintenance work should merge to this branch although minor features may be merged at the discretion of the release manager and/or leadership team
* <tt>3.10-dev</tt>: This is the release branch for the next minor release (the branch's name will always be the version it represents), new features should be merged to this branch
* <tt>4.0-dev</tt>: This is the release branch for the next major release (the branch's name will always be the version it represents)

=== Branch Merging ===
All branches should remain in-sync and all work should be regularly merged forward. Given the above example, the following is the recommended merging workflow (in general, the suggested workflow is that staging is merged to the next minor branch and the next minor branch is merged to the next major branch):

* <tt>staging</tt> should be merged into <tt>3.10-dev</tt>
* <tt>3.10-dev</tt> should be merged to <tt>4.0-dev</tt>

It is suggested that at least once per week branch merging occurs.

== Preparing To Release ==
When scheduling and preparing a release, the timeline should be communicated with the Production and Marketing & Communication Department leadership so that all teams are prepared to support the release. Note that when scheduling releases, consideration should be given to holidays around the world and the impact of issuing a release near those periods considered. Helpful resources include http://interfaith-calendar.org/ and https://www.timeanddate.com/holidays/

=== Release Schedule ===
==== Minor Release ====
Given the nature of a minor release, the following is the suggested release timeline:

* Six weeks prior to planned stable release: Tag the first Beta release
** At this point the release should be considered feature complete and new features should be deferred to the next minor release
* Weekly Beta releases should follow this until the Release Candidate
* Two weeks prior to planned stable release: Tag the Release Candidate
** At this point the release branch (generally <tt>staging</tt>) should remain closed for committing except for high priority bug fixes and language updates
** With the Release Candidate, language freeze is also in effect and no language changes are permitted unless there is an urgent need (which should be communicated with the translations coordinator); note that if necessary the language freeze may be declared earlier but the Release Candidate should be considered the "no later than" time
* One week prior to planned stable release: If necessary, create a second Release Candidate
* Planned release date: Tag the stable release

==== Maintenance Release ====
Maintenance releases operate on a 4-6 week cycle and the following is the suggested release timeline:

* 4-5 days before planned release date: Tag a Release Candidate
** With the Release Candidate, language freeze is also in effect and no language changes are permitted unless there is an urgent need (which should be communicated with the translations coordinator); note that if necessary the language freeze may be declared earlier but the Release Candidate should be considered the "no later than" time
* Planned release date: Tag the stable release

=== Reviewing Release Changes ===
Before tagging a release, the list of changes in the release should be reviewed by the release manager and/or leadership team. The list of changes can be found using GitHub's compare function with the URL <tt>https://github.com/joomla/joomla-cms/compare/<version>...staging</tt> which will compare the changes from <tt><version></tt> to the current staging branch (for example, https://github.com/joomla/joomla-cms/compare/3.9.0...3.9.1-rc is the comparison from the 3.9.0 release tag to the 3.9.1-rc tag). Key purposes of this review include:

* Ensuring all patches are compliant with Semantic Versioning (SemVer) (i.e. no backward compatibility breaks in minor or maintenance releases and no features in maintenance releases); SemVer violations should be cleared with the Production Department leadership
* Ensuring all code revisions are compatible with Joomla's minimum supported versions (i.e. no PHP 5.4 syntax in 3.x releases where PHP 5.3 is the minimum supported version, exceptions may be made if introducing a code path and files that will only be executed on newer PHP versions)
** Joomla's testing integrations should not be relied on in full for this as there are large portions of the Joomla code base which do not have automated test coverage, and as of this writing, there is not a code linting process in place checking for potential issues
* Ensuring features and "significant" changes are documented

=== Security Fixes ===
From time to time, security fixes must be included in a release. Prior to every release, the release manager should check with the [https://volunteers.joomla.org/teams/security-strike-team Security Strike Team] to determine if security fixes are required, and if so ensure this is communicated to all members involved with release work (i.e. the marketing team liaison who assists with the publication of release related material). When a security release is necessary, an internal Release Candidate should be built for testing by the Security Strike Team, CMS Release Team, and [https://volunteers.joomla.org/teams/cms-maintenance-team CMS Maintenance Team] with all security patches included. These teams should also receive information about the vulnerabilities being addressed to ensure there are no regressions in the impacted areas.

Note, when a security fix involves a Joomla Framework package, the Framework package should be patched first and a release created of the affected package then the CMS updated with <tt>composer update</tt>.

== Building a Release ==
Building a release starts with checking that any files and folders that have been deleted are included in the arrays in the installer script at <tt>administrator/components/com_admin/script.php</tt>. There is a helper script in the repository to assist with this located at <tt>build/deleted_file_check.php</tt>. Running <tt>php build/deleted_file_check.php</tt> with its required <tt>--from</tt> option will write a file to <tt>build/deleted_files.txt</tt> with the list of files deleted since the from reference. Please see the PHP file for all documentation about this script.

The following steps require the individual to create commits and tags. It is suggested that these commits and tags be GPG signed as an extra security step but this is not a mandatory requirement as of this writing.

If creating a security release, at this point you should apply all patches provided by the security team.

Once it is confirmed that the deleted files listing is correct, the <tt>build/bump.php</tt> script should be executed to set the new version number. This script will also perform maintenance steps such as correcting the copyright year ranges for all files and replacing the <tt>__DEPLOY_VERSION__</tt> placeholder. Please see the file for all documentation about this script.

After running this script, review all changes with <tt>git diff</tt> as a final check before creating your release commit. Once you are satisfied that all changes are correct, commit your changes locally. Once committed, create the release tag locally; all release tags should be the version number you are creating and should match the output of <tt>Joomla\CMS\Version::getShortVersion()</tt> (so if you have created 3.9.0-beta2 then the tag should be named 3.9.0-beta2).

Once the tag has been created, you will run the <tt>build/build.php</tt> script to generate the release packages. To ensure a clean build is produced, the script makes an archive of the tag you are building using the <tt>git archive</tt> command and extracts this to the <tt>build/tmp/<timestamp></tt> directory. Depending on the patch version number, the following packages will be created in the <tt>build/tmp/packages</tt>:

* 0: Full installation and upgrade packages
* 1: Full installation, upgrade packages, and patch packages for x.y.0 to x.y.1
* 2+: Full installation, upgrade packages, patch packages for x.y.0 to x.y.<new> and x.y.<new-1> to x.y.<new> (i.e. when creating 3.8.8 this will create a patch package suitable for all 3.8.x releases and an optimized patch package for 3.8.7 to 3.8.8)

Additionally, the script will generate a <tt>build/tmp/checksums.txt</tt> file with the checksums for all generated packages.

After the packages are created, you should validate that you are able to install and update a site using the ZIP packages (as these are the most frequently used type and served by our update system).

== Publishing a Release ==
=== Release Packages ===
Depending on the type of release being created, you will publish the release packages in different locations.

==== Alpha, Beta, Release Candidate ====
The packages for these releases are uploaded to GitHub. When ready to publish, you should push the release tag you created to GitHub and use their interface to create a release from the tag and upload the packages. There is a text template used for the releases, generally you can copy a previous release's text and adjust it to the version you are publishing.

==== Stable ====
The packages for stable releases are uploaded to multiple locations, this is in part driven by the fact that the Amazon Web Services (AWS) S3 region used by Joomla is blocked in some locations therefore download mirrors are available when necessary.

===== Joomla! Downloads Portal =====
The canonical source for all stable releases is the [https://downloads.joomla.org/ Joomla! Downloads Portal]. The packages served from the site use Joomla's AWS account. You will need to log into the AWS console to upload the packages to S3 under the <tt>joomla-official-downloads</tt> bucket. The exact path inside the bucket is <tt>joomladownloads/joomla<version></tt> where <tt><version></tt> is the major version number (i.e. <tt>joomla3</tt>), note for compatibility with Akeeba Release System folders for each individual release are not used.

===== Joomla! Update Server =====
The Joomla! Update Server is used as a mirror for the download packages. After connecting to the server, you should create a new folder at <tt>www/releases/<version></tt> (i.e. <tt>www/releases/3.9.1</tt> for the 3.9.1 release) and upload the packages here.

===== GitHub =====
The packages are also uploaded to GitHub. This is similar to the steps for alpha, beta, and release candidate releases above.

[[Category:Bug Squad]]
[[Category:Coordinators]]
[[Category:Development]]

= Old Version =
This is a general checklist when a version of Joomla! is released. Keep in mind that a major release differs a lot from a [[Minor Release]] or even a [[Maintenance Release]]. The checklist here describes the steps that need to be done for (at least) [[Maintenance Release]] and [[Minor Release]].

== Release checklist ==
It depends on the [[Development Cycle]] when the checklist is triggered. A release can be done during every stage of the [[Development Cycle]], it does not matter if you release a beta or a stable version, this is a general checklist that can be used when releasing a new version of Joomla! The checklist starts when it's decided to release a version:

=== Preparation phase ===
# Communication pre-release: check with PLT on timing
# Communication pre-release: inform Bug Squad and LT's about timing
# Decision: when the above has positive result, set a date and time for release
# [Communication pre-release: inform Global Forum Moderators about upcoming release]
# Communication pre-release: check availability and assign release tasks to JBS and PLT members
# Minimum 14 days prior to a minor release: freeze trunk for language changes
# Minimum 7 days prior to a patch release: freeze trunk for language changes
# Minimum 3 days prior to release: freeze trunk for all changes, draft release notes to translation teams, package release candidate for testing
# Day of release: add the new release on Joomlacode and upload the files, update web pages
# Announce on forum, announce to LT's
# [[Joomla:Release_procedure_and_checklist#Pages to update|Update specific web pages with current version data]]
# Contact caped crusader for updating Joomla related sites
# [[Joomla:Release_procedure_and_checklist#Sites to update|Update the sites]]

=== Pre-release phase ===
# Apply latest installation translations (need to be delivered by translation work group Thomas Hunziker).
# Create pre-release package for testing.
# Offer pre-package to testers: [[Bug Squad]] members, [[Development Team]] members, translation members, and [https://groups.google.com/forum/#!forum/jtesters JTesters]
# If problems are found during this stage, go back to fix the problem. Use the [[Joomla! Maintenance Procedures]] and repeat until tests are performed successfully.
# Draft the release notes on Joomla.org and post draft to the [http://forum.joomla.org/viewforum.php?f=54 private translation forum].
# Obtain any CVE numbers needed.
# Draft security notices as needed and leave unpublished on [https://developer.joomla.org Joomla! Developer Network].

=== Release phase ===
# Check with JSST for security fixes. *
# Create release notes document on joomla.org.
# Run the bump.php script
# Check language/en-GB/en-GB.files_joomla.sys.ini file for version number (not needed for minor update).
# Commit and tag release locally
# Package build by running build/build.php
# Packages are now in the build/tmp folder
# Push to GitHub
# If problems are found during this stage, go back to fix the problem. Use the [[Joomla! Maintenance Procedures]] and repeat until tests are performed successfully.
# Add package to GitHub
## This must be done after the version has been tagged and the tag pushed to GitHub due to how the Releases system works
## After pushing the tag, edit the release and attach all of the release packages to the release.
## Copy the description from a previous release and update for the new release.
# Update XML file on update.joomla.org site for the new version number information.
## FTP connect to update1.joomla.org and Navigate to www/core
## All releases
### Change version attribute in list.xml (don't add new line except when incrementing major/minor version numbers)
## LTS Release
### Change the update elements for the series with the new version number and new downloadurl and link to new archive file to extension.xml
## STS Release
### Navigate to www/core/sts
### Change version attribute in list_sts.xml (don't add new line except when incrementing major/minor version numbers)
### Change the update elements for the series with the new version number, new downloadurl and link to new archive file to extension_sts.xml, and the infourl linking to the release announcement
## Test auto update from prior version(s) (make sure XML files have been copied to the CDN on update.joomla.org first)
### All releases
#### Navigate to www/core/test
#### Change version attribute in list_test.xml (don't add new line except when incrementing major/minor version numbers)
### LTS
#### Upload patch package to this folder
### Change the update elements for the series with the new version number, new downloadurl and link to new archive file to extension_sts.xml, and the infourl linking to the release announcement
### STS
#### Navigate to www/core/teststs
#### Upload patch package to this folder
### Change the update elements for the series with the new version number, new downloadurl and link to new archive file to extension_sts.xml, and the infourl linking to the release announcement
# Update Joomla Download Portal with new release data *
# Publish security articles on developer site. *
# Publish release announcement on Joomla.org
# Publish announcement on the forum [Peter Martin]
# Update Wiki: FAQ, Version history [Mat]
# Post to leadership in Glip
# Create the Web Platform Installer packs and submit them *
# Add package to joomlacode.org
## Before the release is public, set the JoomlaCode package flags as follows: Visible=No, Public=No, Require Login=Yes.
## Set the Release flags as follows: Visible=Yes, Released=Yes.
## Once package is released, change the Package flags to Visible=Yes, Public=Yes, Require Login=No.
## Change the prior version package to Visible=No but leave the prior version release flags as they are.

Note: Items with an asterisk can be skipped for non-stable releases

=== Post-release & Finalization phase ===
# Update GitHub repo for new version development
## Run build/bump.php with next version
# Delete old release branch after confirming all commits are merged to series development head and there are no open pull requests
# Close security issues in security tracker

=== Pages to update ===
#Global:
#* [https://developer.joomla.org/development-status.html Development Status]
#* [https://downloads.joomla.org Downloads Portal]

=== Sites to update ===
#PLT Owned sites
#* [https://developer.joomla.org Developer Site]
#* [https://downloads.joomla.org Downloads Portal]
#* [https://api.joomla.org API Site]
#** Regenerate API docs for the new release via Jenkins

=== Calculating Release Statistics ===
==== Using JoomlaCode and CHANGELOG ====
# Extract *all* issues from Tracker into spreadsheet. Make note of the date of the last release and the number of active issues at the time of the last release.
# Set a filter on the "Closed Date" column to be "after" "the day of the last release".
#* Calculate "Closed" count by aggregating status values for Closed, Duplicate Report, Known Issue, Not a bug, Not Joomla! Core, Unable to Confirm.
#* Calculate "Fixed in SVN" count by aggregating status values for Open and Information Required. (Note: this value is presented two times in the report.)
# Set a filter on the "Closed Date" column to be blanks:
#* Calculate "Open" count by aggregating status values for "Open" and "Information Required."
#* Calculate "Confirmed" count by aggregating status values for "Confirmed" and "In Progress."
#* Calculate "Pending" count by aggregating status values for "Pending" and "Ready to Commit."
# Calculate the "New Active Issues" by aggregating the "Open", "Confirmed" and "Pending" counts.
# Calculate the "net increase/decrease" by subtracting the "Last Release Active Issues" from the "New Active Issues."
# Count the "number of commits" by reviewing the CHANGELOG.php file and counting the documented commits.

==== Using GitHub ====
# Go to https://github.com/joomla/joomla-cms/compare/<version>...master where <version> is the previous release, this is GitHub's comparison view and will give stats from the previous release tag to the currently published master
# From this page, you can compile the number of commits, contributors, and files changed during the release period

==== Download Statistics ====
# Go to http://joomlacode.org/gf/project/joomla/frs/?action=FrsReport
# In the filter bar, set the start date to the date of the previous release and the end date to the day before the new release
# The "Downloads By Package" chart is the total number of downloads for each release (i.e. 2.5.16 and 3.2.0) and includes an "Other" piece for all older version downloads
# The "Downloads By Release" chart separates the packages by new install and updates

==== Alternative Method for Stats ====
* Fixed in SVN: Create query with close date > date of prior release and status = Fixed in SVN.
* Commits: Count from CHANGELOG.php as indicated above.
* New Reports: Run query with all status codes and open date > date of prior release.
* Increase / decrease in active issues: See note below
* Closed: Run query with closed date > date of prior release and status code one of Closed, Duplicate Report, Known Issue, Not a bug, Not Joomla! Core, Unable to Confirm.
* Open at time of release: query of all issues with status = Open or Information Required
* Confirmed at time of release: query of all issues with status = Confirmed or In Progress
* Pending at time of release: query of all issues with status = Pending or Ready to Commit

==== Increase/Decrease in Active Issues ====
* Total active issues now = Open at time of release + Confirmed at time of release + Pending at time of release
* This number minus the total active as of prior release is the net increase or decrease

As a check, make sure the following formula works:
* Prior release total active issues + New Reports - (Closed + Fixed in SVN) should equal the Total Active Issues now.

Joomla:Release procedure and checklist

2018-12-16T16:27:54Z

Mbabker: Scheduling

Joomla:Release procedure and checklist

2018-12-16T16:10:26Z

Mbabker: Starting on new version of the page

J3.x:Integrate Extensions with the Privacy Component

2018-09-04T23:26:41Z

Mbabker: Fill in removal processing

The information below is provided to extension developers to help create integrations with the [[S:MyLanguage/J3.x:Privacy|Privacy Tool Suite]].

== Privacy Related Extension Capabilities ==

The new privacy component has a '''Capabilities''' section which allows extensions to report privacy related capabilities. The aim for this section is to help users to understand what an extension may do related to personal data on users and help site owners plan accordingly. For details on this section, including how a plugin should integrate with it, please see the [[S:MyLanguage/J3.x:Report_Extension_Capabilities_in_Privacy_Component|Report Extension Capabilities in Privacy Component]] page.

== Check for a Published Privacy Policy ==

The privacy component's health check notifies users if there is a privacy policy published on the website. This check is performed by the <tt>onPrivacyCheckPrivacyPolicyPublished</tt> event which can be subscribed to by plugins in the privacy, system, and user plugin groups. The event receives an associative array by reference with two keys as its argument:

* "published" - A boolean value indicating that there is a published policy
* "editLink" - The URL to edit the policy item, this is displayed if there is a privacy policy published

As a best practice, it is suggested that plugins first check if the "published" flag is already set to true and not make further changes to the data array if so. Note that the '''System - Privacy Consent''' core plugin will process this event.

<source lang="php">
public function onPrivacyCheckPrivacyPolicyPublished(&$policy)
{
// If another plugin has already indicated a policy is published, we won't change anything here
if ($policy['published'])
{
return;
}

// Do stuff to find the privacy policy data

$policy['published'] = true;
$policy['editLink'] = ''; // The link to the item's edit page, processed through JRoute, i.e. JRoute::_('index.php?option=com_content&task=article.edit&id=1');
}
</source>

== Add Data to Export Requests ==

As a convenience, there are several helper methods in the <tt>PrivacyPlugin</tt> class and it is recommended that privacy plugins extend this class to inherit those helpers (this is similar to the <tt>FinderIndexerAdapter</tt> class for Smart Search plugins as an example).

<source lang="php">
JLoader::register('PrivacyPlugin', JPATH_ADMINISTRATOR . '/components/com_privacy/helpers/plugin.php');

class PlgPrivacyContent extends PrivacyPlugin {}
</source>

To add data to an export request, a plugin in the privacy or system plugin groups must subscribe to the <tt>onPrivacyExportRequest</tt> event.

The event receives two arguments:

* <tt>$request</tt> - A <tt>PrivacyTableRequest</tt> object containing the information request record from the database
* <tt>$user</tt> - If there is an account for the email address of the information request, a <tt>Joomla\CMS\User\User</tt> object is given containing the user account data

The event must return an array of <tt>PrivacyExportDomain</tt> objects containing the data to be exported for a given domain. If the plugin has no data, it must return an empty array.

A <tt>PrivacyExportDomain</tt> data object typically represents the data found from a table in the database and is made up of three elements:

* Domain name - A name to identify the domain
* Domain description - A short description of the data contained in the domain
* Domain items - An array of <tt>PrivacyExportItem</tt> data objects containing all items within the domain

A <tt>PrivacyExportItem</tt> data object represents a single item within the data domain and is made up of two elements:

* Item ID - The primary identifier for this item within the domain, typically this will be the database record's primary key
* Item fields - An array of <tt>PrivacyExportField</tt> data objects containing each field for the item

The <tt>PrivacyExportField</tt> data object represents a single field within an item and is made up of two elements:

* Field name - The name of the field
* Field value - The field's value

The general workflow for the export process is this:

* Validate the plugin should actually process data
* Query the data from the database
* Create a domain for the results (the <tt>createDomain</tt> method inherited from the <tt>PrivacyPlugin</tt> class can help with this)
* Add items for each row
** The <tt>createItemFromArray</tt> method inherited from the <tt>PrivacyPlugin</tt> class can be used to create a <tt>PrivacyExportItem</tt> object from an array (this should be used in conjunction with the database's <tt>loadAssocList</tt> method
** The <tt>createItemForTable</tt> method inherited from the <tt>PrivacyPlugin</tt> class can be used to create a <tt>PrivacyExportItem</tt> object from a <tt>Joomla\CMS\Table\Table</tt> object
* Return the domain

Below is an example for exporting articles created by a user, including custom field data.

<source lang="php">
use Joomla\CMS\User\User;

JLoader::register('FieldsHelper', JPATH_ADMINISTRATOR . '/components/com_fields/helpers/fields.php');
JLoader::register('PrivacyPlugin', JPATH_ADMINISTRATOR . '/components/com_privacy/helpers/plugin.php');

class PlgPrivacyContent extends PrivacyPlugin
{
/**
* @var JDatabaseDriver
*/
protected $db;

/**
* @var array
*/
protected $contents = array();

public function onPrivacyExportRequest(PrivacyTableRequest $request, User $user = null)
{
// This plugin only processes data for registered user accounts
if (!$user)
{
return array();
}

$domains = array();
$domains[] = $this->createContentDomain($user);

// Create domains for each article's custom fields
foreach ($this->contents as $content)
{
$domains[] = $this->createContentCustomFieldsDomain($content);
}

return $domains;
}

private function createContentDomain(User $user)
{
$domain = $this->createDomain('user content', 'Joomla! user content data');

$query = $this->db->getQuery(true)
->select('*')
->from($this->db->quoteName('#__content'))
->where($this->db->quoteName('created_by') . ' = ' . (int) $user->id)
->order($this->db->quoteName('ordering') . ' ASC');

$items = $this->db->setQuery($query)->loadAssocList();

// Add each article to the domain
foreach ($items as $item)
{
$domain->addItem($this->createItemFromArray($item));

// Store the article for use in the custom fields processing
$this->contents[] = (object) $item;
}

return $domain;
}

private function createContentCustomFieldsDomain($content)
{
$domain = $this->createDomain('content custom fields', 'Joomla! content custom fields data');

// Get item's fields, also preparing their value property for manual display
$fields = FieldsHelper::getFields('com_content.article', $content);

foreach ($fields as $field)
{
$fieldValue = is_array($field->value) ? implode(', ', $field->value) : $field->value;

$data = array(
'content_id' => $content->id,
'field_name' => $field->name,
'field_title' => $field->title,
'field_value' => $fieldValue,
);

$domain->addItem($this->createItemFromArray($data));
}

return $domain;
}
}
</source>

== Process Removal Requests ==

Processing a removal request requires two steps: Validating that the subject's data can be removed, and the actual removal. Again it is suggested that plugins extend the <tt>PrivacyPlugin</tt> class, however this is not a strict requirement.

<source lang="php">
JLoader::register('PrivacyPlugin', JPATH_ADMINISTRATOR . '/components/com_privacy/helpers/plugin.php');

class PlgPrivacyUser extends PrivacyPlugin {}
</source>

=== Validate Data Can Be Removed ===

If the plugin may need to block a subject's data from being removed, it must subscribe to the <tt>onPrivacyCanRemoveData</tt> event. Generally, a removal should be blocked if there are valid legal reasons to retain the data or if removal may cause permanent damage to the site (for example, the core '''Privacy - User Accounts''' prohibits removing a super user account).

The event receives two arguments:

* <tt>$request</tt> - A <tt>PrivacyTableRequest</tt> object containing the information request record from the database
* <tt>$user</tt> - If there is an account for the email address of the information request, a <tt>Joomla\CMS\User\User</tt> object is given containing the user account data

The event must return a <tt>PrivacyRemovalStatus</tt> data object which specifies if the data cannot be removed and a reason for the inability to remove the data.

<source lang="php">
use Joomla\CMS\Language\Text;
use Joomla\CMS\User\User;

JLoader::register('PrivacyPlugin', JPATH_ADMINISTRATOR . '/components/com_privacy/helpers/plugin.php');
JLoader::register('PrivacyRemovalStatus', JPATH_ADMINISTRATOR . '/components/com_privacy/helpers/removal/status.php');

class PlgPrivacyUser extends PrivacyPlugin
{
public function onPrivacyCanRemoveData(PrivacyTableRequest $request, User $user = null)
{
$status = new PrivacyRemovalStatus;

// We only need to check if there is an associated user account
if (!$user)
{
return $status;
}

// We will not remove a super user account from the site
if ($user->authorise('core.admin'))
{
$status->canRemove = false;
$status->reason = Text::_('PLG_PRIVACY_USER_ERROR_CANNOT_REMOVE_SUPER_USER');
}

return $status;
}
}
</source>

=== Remove or Anonymize Data ===

If the plugin handles the removal or anonymization of data, it must subscribe to the <tt>onPrivacyRemoveData</tt> event.

The event receives two arguments:

* <tt>$request</tt> - A <tt>PrivacyTableRequest</tt> object containing the information request record from the database
* <tt>$user</tt> - If there is an account for the email address of the information request, a <tt>Joomla\CMS\User\User</tt> object is given containing the user account data

Unlike the other events in this component, plugins are not expected to return any data.

Depending on the underlying data's requirements, plugins should anonymize information that is retained and remove any data that is no longer necessary. If necessary, the plugin may perform other actions related to the request and/or user account.

The below example demonstrates how Joomla anonymizes and removes data related to the core user account.

<source lang="php">
use Joomla\CMS\Factory;
use Joomla\CMS\User\User;

JLoader::register('PrivacyPlugin', JPATH_ADMINISTRATOR . '/components/com_privacy/helpers/plugin.php');

class PlgPrivacyUser extends PrivacyPlugin
{
/**
* @var JDatabaseDriver
*/
protected $db;

public function onPrivacyRemoveData(PrivacyTableRequest $request, User $user = null)
{
// This plugin only processes data for registered user accounts
if (!$user)
{
return;
}

$pseudoanonymisedData = array(
'name' => 'User ID ' . $user->id,
'username' => bin2hex(random_bytes(12)), // Generates a random username
'email' => 'UserID' . $user->id . 'removed@email.invalid',
'block' => true,
);

$user->bind($pseudoanonymisedData);

$user->save();

// Destroy all sessions for the user account
$sessionIds = $this->db->setQuery(
$this->db->getQuery(true)
->select($this->db->quoteName('session_id'))
->from($this->db->quoteName('#__session'))
->where($this->db->quoteName('userid') . ' = ' . (int) $user->id)
)->loadColumn();

// If there aren't any active sessions then there's nothing to do here
if (empty($sessionIds))
{
return;
}

$storeName = Factory::getConfig()->get('session_handler', 'none');
$store = JSessionStorage::getInstance($storeName);
$quotedIds = array();

// Destroy the sessions and quote the IDs to purge the session table
foreach ($sessionIds as $sessionId)
{
$store->destroy($sessionId);
$quotedIds[] = $this->db->quote($sessionId);
}

$this->db->setQuery(
$this->db->getQuery(true)
->delete($this->db->quoteName('#__session'))
->where($this->db->quoteName('session_id') . ' IN (' . implode(', ', $quotedIds) . ')')
)->execute();
}
}
</source>

<noinclude>
[[Category:Privacy]]
[[Category:Components]]
[[Category:Joomla! 3.9]]
[[Category:Plugins]]
[[Category:Tutorials]]
</noinclude>

J3.x:Information Request Workflow in Privacy Component

2018-08-29T02:54:20Z

Mbabker: /* Additional Resources */

Information requests are the central element to the privacy component and processing user requests for their data to be exported or removed from a site.

== Creating a Request ==

A request can be created either by a super user for the website or an authenticated user through the request form.

{{note|''IMPORTANT'' To create and process information requests, your website MUST be able to send emails due to the requirement for the information owner to confirm the request.|type=notice}}

=== Super User Creation ===

Through the '''Privacy: Information Requests''' screen, any super user may create a new information request. This is the only way to create information requests for users who do NOT have accounts on the website. To create a request, the super user must specify:

* The email address of the user for whom to process data
* The request type (export or remove)

Note: In this context, a user means any individual or organization who has made a request, regardless of whether there is a registered user account on the site for a user (as an example, this would allow the tool suite to process requests for sites which have a commenting system which allows guests to comment by providing a name and/or email address without requiring to be registered on the site).

=== Authenticated User Request ===

Registered users may submit information requests for their accounts on the website. It is suggested to create a '''Privacy > Create Request''' menu item to link to the information request form. When submitting an information request, the user must provide:

* Their email address
* The request type (export or remove)

== Confirming a Request ==

Once a request has been created, regardless of how it is created, the user must confirm that this is a valid request for their information. They will receive an email from the website alerting them to the request's creation and be provided a link to a confirmation form where they will need to enter the token provided in the email and their email address to confirm the request's validity. Once the user confirms the request, it will be marked as '''Confirmed''' in the component's requests list and the site's super user(s) will be able to process it.

The token in this email is valid for 24 hours. If a request is not confirmed in that timeframe, the request will be marked as '''Invalid''' in the component's requests list and a new request must be submitted.

It is suggested to create a hidden '''Privacy > Confirm Request''' menu item in order to provide a SEF URL for this page, however this is not required.

== Processing a Request ==

=== Export Request ===

[[File:Info Request Export-en.png|600px|none]]
Once an export request has been confirmed, there are two actions available to super users.

* Export Data: This will collect all data for the information request's subject and create a XML file that will be downloaded to your computer. This is useful to enable site owners to review the data export prior to sending it to the user.
* Email Data Export: This will collect all data for the information request's subject, create a XML file (the same as generated by the Export Data action), and send an email to the user with the exported data file attached.

{{note|''Important'' The export action can only process data from supported extensions. Therefore, the super user who is acting on the request should review the export and if necessary include data that was not processed from extensions.|type=notice}}

=== Removal Request ===

[[File:Info Request Remove-en.png|600px|none]]
Once a remove request has been confirmed, there is one action available to super users.

* Delete Data: This process will anonymize and/or remove data related to the information subject. For requests where the information owner also has a registered user account, this process will anonymize the account's name, username, and email address, as well as block the account from being logged into and log the user out of the site if they are logged in at the time the request is processed.

{{note|''Important'' The delete action can only process data from supported extensions. Therefore, the super user who is acting on the request should review the site after the removal is completed and if necessary manually anonymize or remove data that was not processed from extensions.|type=notice}}

== Completing a Request ==

After the request has been processed, the request should be marked as completed. This will indicate that the request has been fulfilled and there is no further action to be taken.

== Additional Resources ==

* [[S:MyLanguage/J3.x:Integrate_Extensions_with_the_Privacy_Component|Developer's Guide for the Privacy Tool Suite]]

<noinclude>
[[Category:Privacy{{#translation:}}]]
[[Category:Components{{#translation:}}]]
[[Category:Joomla! 3.9{{#translation:}}]]
[[Category:Plugins{{#translation:}}]]
</noinclude>

J3.x:Integrate Extensions with the Privacy Component

2018-08-29T02:34:53Z

Mbabker:

J3.x:Integrate Extensions with the Privacy Component

2018-08-29T01:58:57Z

Mbabker: Created page with "The information below is provided to extension developers to help create integrations with the Privacy Tool Suite. == Privacy Related Extension..."

J3.x:Information Request Workflow in Privacy Component

2018-08-29T01:42:18Z

Mbabker: /* Processing a Request */

Information requests are the central element to the privacy component and processing user requests for their data to be exported or removed from a site.

== Creating a Request ==

A request can be created either by a super user for the website or an authenticated user through the request form.

{{note|''IMPORTANT'' To create and process information requests, your website MUST be able to send emails due to the requirement for the information owner to confirm the request.|type=notice}}

=== Super User Creation ===

Through the '''Privacy: Information Requests''' screen, any super user may create a new information request. This is the only way to create information requests for users who do NOT have accounts on the website. To create a request, the super user must specify:

* The email address of the user for whom to process data
* The request type (export or remove)

Note: In this context, a user means any individual or organization who has made a request, regardless of whether there is a registered user account on the site for a user (as an example, this would allow the tool suite to process requests for sites which have a commenting system which allows guests to comment by providing a name and/or email address without requiring to be registered on the site).

=== Authenticated User Request ===

Registered users may submit information requests for their accounts on the website. It is suggested to create a '''Privacy > Create Request''' menu item to link to the information request form. When submitting an information request, the user must provide:

* Their email address
* The request type (export or remove)

== Confirming a Request ==

Once a request has been created, regardless of how it is created, the user must confirm that this is a valid request for their information. They will receive an email from the website alerting them to the request's creation and be provided a link to a confirmation form where they will need to enter the token provided in the email and their email address to confirm the request's validity. Once the user confirms the request, it will be marked as '''Confirmed''' in the component's requests list and the site's super user(s) will be able to process it.

The token in this email is valid for 24 hours. If a request is not confirmed in that timeframe, the request will be marked as '''Invalid''' in the component's requests list and a new request must be submitted.

It is suggested to create a hidden '''Privacy > Confirm Request''' menu item in order to provide a SEF URL for this page, however this is not required.

== Processing a Request ==

=== Export Request ===

[[File:Info Request Export-en.png|600px|none]]
Once an export request has been confirmed, there are two actions available to super users.

* Export Data: This will collect all data for the information request's subject and create a XML file that will be downloaded to your computer. This is useful to enable site owners to review the data export prior to sending it to the user.
* Email Data Export: This will collect all data for the information request's subject, create a XML file (the same as generated by the Export Data action), and send an email to the user with the exported data file attached.

{{note|''Important'' The export action can only process data from supported extensions. Therefore, the super user who is acting on the request should review the export and if necessary include data that was not processed from extensions.|type=notice}}

=== Removal Request ===

[[File:Info Request Remove-en.png|600px|none]]
Once a remove request has been confirmed, there is one action available to super users.

* Delete Data: This process will anonymize and/or remove data related to the information subject. For requests where the information owner also has a registered user account, this process will anonymize the account's name, username, and email address, as well as block the account from being logged into and log the user out of the site if they are logged in at the time the request is processed.

{{note|''Important'' The delete action can only process data from supported extensions. Therefore, the super user who is acting on the request should review the site after the removal is completed and if necessary manually anonymize or remove data that was not processed from extensions.|type=notice}}

== Completing a Request ==

After the request has been processed, the request should be marked as completed. This will indicate that the request has been fulfilled and there is no further action to be taken.

== Additional Resources ==

* [[S:MyLanguage/J3.x:Integrate Extensions with the Privacy Component|Developer's Guide for the Privacy Tool Suite]]

<noinclude>
[[Category:Privacy{{#translation:}}]]
[[Category:Components{{#translation:}}]]
[[Category:Joomla! 3.9{{#translation:}}]]
[[Category:Plugins{{#translation:}}]]
</noinclude>

File:Info Request Remove-en.png

2018-08-29T01:37:11Z

Mbabker:

J3.x:Information Request Workflow in Privacy Component

2018-08-29T01:36:16Z

Mbabker: /* Export Request */

Information requests are the central element to the privacy component and processing user requests for their data to be exported or removed from a site.

== Creating a Request ==

A request can be created either by a super user for the website or an authenticated user through the request form.

{{note|''IMPORTANT'' To create and process information requests, your website MUST be able to send emails due to the requirement for the information owner to confirm the request.|type=notice}}

=== Super User Creation ===

Through the '''Privacy: Information Requests''' screen, any super user may create a new information request. This is the only way to create information requests for users who do NOT have accounts on the website. To create a request, the super user must specify:

* The email address of the user for whom to process data
* The request type (export or remove)

Note: In this context, a user means any individual or organization who has made a request, regardless of whether there is a registered user account on the site for a user (as an example, this would allow the tool suite to process requests for sites which have a commenting system which allows guests to comment by providing a name and/or email address without requiring to be registered on the site).

=== Authenticated User Request ===

Registered users may submit information requests for their accounts on the website. It is suggested to create a '''Privacy > Create Request''' menu item to link to the information request form. When submitting an information request, the user must provide:

* Their email address
* The request type (export or remove)

== Confirming a Request ==

Once a request has been created, regardless of how it is created, the user must confirm that this is a valid request for their information. They will receive an email from the website alerting them to the request's creation and be provided a link to a confirmation form where they will need to enter the token provided in the email and their email address to confirm the request's validity. Once the user confirms the request, it will be marked as '''Confirmed''' in the component's requests list and the site's super user(s) will be able to process it.

The token in this email is valid for 24 hours. If a request is not confirmed in that timeframe, the request will be marked as '''Invalid''' in the component's requests list and a new request must be submitted.

It is suggested to create a hidden '''Privacy > Confirm Request''' menu item in order to provide a SEF URL for this page, however this is not required.

== Processing a Request ==

=== Export Request ===

[[File:Info Request Export-en.png|600px|none]]
Once an export request has been confirmed, there are two actions available to super users.

* Export Data: This will collect all data for the information request's subject and create a XML file that will be downloaded to your computer. This is useful to enable site owners to review the data export prior to sending it to the user.
* Email Data Export: This will collect all data for the information request's subject, create a XML file (the same as generated by the Export Data action), and send an email to the user with the exported data file attached.

{{note|''Important'' The export action can only process data from supported extensions. Therefore, the super user who is acting on the request should review the export and if necessary include data that was not processed from extensions.|type=notice}}

=== Removal Request ===

Coming soon

== Completing a Request ==

After the request has been processed, the request should be marked as completed. This will indicate that the request has been fulfilled and there is no further action to be taken.

== Additional Resources ==

* [[S:MyLanguage/J3.x:Integrate Extensions with the Privacy Component|Developer's Guide for the Privacy Tool Suite]]

<noinclude>
[[Category:Privacy{{#translation:}}]]
[[Category:Components{{#translation:}}]]
[[Category:Joomla! 3.9{{#translation:}}]]
[[Category:Plugins{{#translation:}}]]
</noinclude>

File:Info Request Export-en.png

2018-08-29T01:24:48Z

Mbabker:

J3.x:Information Request Workflow in Privacy Component

2018-08-29T01:20:02Z

Mbabker: /* Confirming a Request */

J3.x:Information Request Workflow in Privacy Component

2018-08-29T01:18:10Z

Mbabker: /* Authenticated User Request */

J3.x:Information Request Workflow in Privacy Component

2018-08-29T01:17:20Z

Mbabker: /* Super User Creation */

J3.x:Information Request Workflow in Privacy Component

2018-08-29T01:14:47Z

Mbabker: /* Creating a Request */

J3.x:Information Request Workflow in Privacy Component

2018-08-29T01:13:26Z

Mbabker: /* Super User Creation */

J3.x:Privacy

2018-08-29T01:04:16Z

Mbabker: /* Health Check */

<noinclude>[[Category:Needs to be marked for translation]]</noinclude>
{{Top portal heading|color=white-bkgd|icon=magic|icon-color=#5091cd|size=3x|text-color=#333|title=Tutorial 
How to Use the New Privacy Tool Suite}}
<noinclude>{{Joomla version|version=3.9}}</noinclude>

As of Joomla 3.9, Joomla introduced a privacy tool suite in response to laws and regulations such as GDPR. 
In this tutorial, you will find information on how to set up these new extensions.

== Component ==
=== Privacy Dashboard ===
The privacy dashboard provides a summary of the information requests for the website and a status of recommended actions to take. The Privacy Dashboard is located under the Menu link 'Users" in the admin panel

==== Request Count ====
The request count "module" is a summary of the information requests on a website, this is similar to the privacy dashboard module explained below.

==== Health Check ====
[[File:Privacy Dashboard Health Check-en.png|600px|none]]
The health check "module" checks the status of several actions that it is recommended site owners take as it relates to integrating the privacy tools into their website, including:

* Check if a privacy policy is published - This will check if a privacy policy is configured and published; developers can integrate support for this check through the <tt>onPrivacyCheckPrivacyPolicyPublished</tt> event. If a policy is set in the '''System - Privacy Consent''' plugin then this check will succeed.
* Check if the information request form has a published menu item - This will determine if the frontend information request form has a published menu item to help authenticated users submit valid requests. Regardless of a menu item being published, a valid URL for the request form is always displayed.
* Check if there are any urgent requests - This will check for confirmed requests older than the age specified in the component parameters (default 14 days) and alert the site owner of any requests requiring urgent attention.
* Check if mail sending is enabled - To process information requests, the site must be able to send email. With mail sending disabled, information requests cannot be created or actioned.

=== Extension Capabilities ===
This screen collects and displays information about privacy related capabilities (such as personal data processing, cookies set in your browser, or information shared with third parties for a feature to work) to assist users with evaluating extensions for privacy related concerns and preparing documentation such as a privacy policy or terms of service. More information about this screen and information on how developers can add support for it can be found on the [[S:MyLanguage/J3.x:Report_Extension_Capabilities_in_Privacy_Component|Report Extension Capabilities in Privacy Component]] page.

=== Information Requests ===
This screen is the central location for processing and managing user information requests. More information about this screen and the workflow for information requests can be found on the [[S:MyLanguage/J3.x:Information_Request_Workflow_in_Privacy_Component|Information Request Workflow in Privacy Component]] page.

== Plugins ==
=== System - Privacy Consent ===
[[File:Consent to Privacy Policy-en.png|600px|none]]
When personal identifiable information is collected you should ensure:
* the user is informed why you are requesting this information in plain and easy to understand language
* the user knows what data you collect about them
* the user knows what you will be using the data for
* the user has actively consented to your usage of the data.

This plugin does '''NOT''' make your web site legally compliant, it is just a step in the process.

Once the plugin has been enabled then any new user registering on your site will be required to consent to the Privacy conditions. The date and IP address of the user will be recorded. All existing users will be redirected to their User Profile so that they can consent.

==== Plugin Configuration ====
[[File:Privacy Consent Configuration-en.png|600px|none]]
The plugin is installed but not enabled by default with Joomla 3.9 - to enable it go to '''Extensions {{rarr}} Plugins''' and search for '''Privacy'''. Once you have located the plugin you can enable it and configure the settings.

==== Short Privacy Policy ====
This is a brief notice that will appear above the Privacy Consent checkbox. You can leave it as it is and the displayed message will be used or you can enter your own custom text.

{{note|''Note for Multilingual sites.'' If you use the default text then it will be displayed in the user's language. It is not possible to translate the custom text. If you wish to customise the text and display it in multiple languages then you should leave this field blank and use the Joomla language override facility to customise the <tt>PLG_USER_PRIVACYCONSENT_NOTE_FIELD_DEFAULT</tt> language string for each language installed.|type=notice}}

==== Privacy Article ====
If you wish to have a longer Privacy Policy you can create/edit the article here which will be displayed in a modal window.

{{note|''Note for Multilingual sites.'' If you associate this article with alternatives in other languages then the privacy policy will be displayed in the correct language for the user.|type=notice}}

==== Redirect Message ====
[[File:Redirect message-en.png|600px|none]]
This is the message that is displayed to existing users when they login for the first time since the Privacy Consent plugin was enabled on the site. You can leave it as it is and the displayed message will be used or you can enter your own custom text.

{{note|''Note for Multilingual sites.'' If you use the default text then it will be displayed in the user's language. It is not possible to translate the custom text. If you wish to customise the text and display it in multiple languages then you should leave this field blank and use the Joomla language override facility to customise the <tt>PLG_USER_PRIVACYCONSENT_REDIRECT_MESSAGE_DEFAULT</tt> language string for each language installed.|type=notice}}

=== User - Terms and Condition ===
==== Plugin Configuration ====
The plugin is installed but not enabled by default with Joomla 3.9 - to enable it go to '''Extensions {{rarr}} Plugins''' and search for '''Terms'''. Once you have located the plugin you can enable it and configure the settings.

==== Short Terms & Conditions ====
This is a brief notice that will appear above the Terms & Conditions checkbox. You can leave it as it is and the displayed message will be used or you can enter your own custom text.

{{note|''Note for Multilingual sites.'' If you use the default text then it will be displayed in the user's language. It is not possible to translate the custom text. If you wish to customise the text and display it in multiple languages then you should leave this field blank and use the Joomla language override facility to customise the <tt>PLG_USER_TERMS_NOTE_FIELD_DEFAULT</tt> language string for each language installed.|type=notice}}

==== Terms & Conditions Article ====
If you wish to have a longer Terms & Conditions you can create/edit the article here which will be displayed in a modal window.

{{note|''Note for Multilingual sites:'' If you associate this article with alternatives in other languages then the Terms & Conditions will be displayed in the correct language for the user.|type=notice}}

* Bulleted list item

=== Content - Confirm Consent ===
[[File:Confirm Consent checkbox-en.png|600px|none]]
This plugin will add a required checkbox to a form eg the core contact form

==== Plugin Configuration ====
[[File:Confirmconsent configuration-en.png|600px|none]]

The plugin is installed but not enabled by default with Joomla 3.9 - to enable it go to '''Extensions {{rarr}} Plugins''' and search for '''Consent'''. Once you have located the plugin you can enable it and configure the settings.

==== Short Privacy Policy ====
This is a brief notice that will appear above the Privacy Consent checkbox. You can leave it as it is and the displayed message will be used or you can enter your own custom text.

{{note|''Note for Multilingual sites:'' If you use the default text then it will be displayed in the user's language. It is not possible to translate the custom text. If you wish to customise the text and display it in multiple languages then you should leave this field blank and use the Joomla language override facility to customise the <tt>PLG_CONTENT_CONFIRMCONSENT_FIELD_NOTE_DEFAULT</tt> language string for each language installed.|type=notice}}

==== Privacy Article ====
If you wish to have a longer Privacy Policy you can create/edit the article here which will be displayed in a modal window.

{{note|''Note for Multilingual sites:'' If you associate this article with alternatives in other languages then the privacy policy will be displayed in the correct language for the user.|type=notice}}

== Modules ==
=== Privacy Dashboard ===
[[File:Privacy Dashboard Module-en.png|600px|none]]

This module provides a summary of the information requests received for your website. The module is installed and enabled by default with a new Joomla 3.9 installation. To add it to your dashboard on an updated site, go to '''Extensions {{rarr}} Modules''', change the Site filter to '''Administrator''', add a new '''Privacy Dashboard''' module, assign it to the '''cpanel''' position, and set access to '''Super Users'''.

<noinclude>
[[Category:Privacy]]
[[Category:Components]]
[[Category:Joomla! 3.9]]
[[Category:Plugins]]
[[Category:Modules]]
[[Category:Tutorials]]
</noinclude>

File:Privacy Dashboard Health Check-en.png

2018-08-29T01:01:55Z

Mbabker: Mbabker uploaded a new version of File:Privacy Dashboard Health Check-en.png

== Licensing ==
{{JEDL}}

Development Best Practices

2018-08-07T20:16:35Z

Mbabker: Remove link that per Radek is not authorized content for publishing on a Joomla site due to it being a third party site and an implicit endorsement of a third party.

Here are a collection of the Joomla! Development practices you should observe when developing a component, plugin or module for Joomla.

== General Development Guidelines ==

* Don't use the <code>DS</code> or <code>DIRECTORY_SEPARATOR</code> constant when including files. It is no longer needed, as pointed out by [http://us2.php.net/manual/en/ref.filesystem.php#73954 Christian on php.net]
* Don't depend on <code>register_globals</code>. This is a HIGH security risk, and the feature has been deprecated in PHP 5.3 and removed in 5.4.
* Don't access the <code>$_GET, $_POST, $_REQUEST, $_FILES and $_SERVER</code> superglobals directly. Use <code>JInput</code> (typically: <code>JFactory::getApplication()->input)</code> instead. <code>JInput</code> filters the input, helping you to easily write more secure software.
* Don't hardcode your SQL queries and do not include unescaped raw data into them. Always use <code>JDatabase</code> / <code>JDatabaseQuery</code>. It's as simple as <code>JFactory::getDbo()->getQuery(true)</code>.
* Don't use arbitrary entry points, i.e. .php files which must be accessible outside Joomla!, directly from the web. Typically used to accommodate for payment processors and image resizers, this practice is extremely insecure and strongly discouraged. Use a Joomla! component or a system plugin instead.
* Don't reinvent the wheel. If there's a Joomla! class to do that try using it before you roll your own. Chances are the core class is already good enough and much better tested.
* Do use sensible prefixes for your table names. If your component is called '''com_foobar''' it stands to reason that its tables follow the naming pattern:{{-}}
<source lang="sql" style="margin-left:3em;">
// Good
#__foobar_something

// Bad
#__fbr_something

//Really Bad!
#__something
</source>
* Do test your extensions with pre-release versions of Joomla! and/or the "staging" branch of the Git repository. Making sure that users of your extension can update Joomla! safely is your responsibility.
* Do provide documentation for your extensions. Even a short video with less than stellar English is better than nothing.
* Do use <code>JText</code> to translate the output of your extension instead of hardcoding text. The vast majority of Joomla! users are not native English speakers and they will thank you for your consideration.
* Do comment your code. Not just for the people who have to work with it, but also yourself six months from now.
* Do test your code under real usage conditions, with real world data sets. You might be surprised at what you find.

== Where should I place JavaScript, CSS, and Image files that belong to my Component? ==
You can see in your root a general media folder to hold all assets.

What this means in real terms is that when in your XML install manifest, if you put files inside a <media> tag instead of a <files> tag then they will be sent to the JPATH_ROOT/media folder. If you give it <media destination="com_foo"> then it will put the files in JPATH_ROOT/media/com_foo

In some cases you have a component, we'll say com_foo, and then you have a few modules that go along with com_foo... for sake of the example we'll call them mod_foo_1, mod_foo_2 and mod_foo_3. There is no reason to package media elements for the three modules if they are all the same and they depend upon the component anyway. The best and most logical way to do things is to put them all in a central place that is namespaced appropriately.

By storing media in the media folder, this enables templates to override it with template overrides versus being required to modify the files shipped with your extension, causing those customizations to be lost during updates. By loading your media using the [http://api.joomla.org/cms-3/classes/JHtml.html#method_image image], [http://api.joomla.org/cms-3/classes/JHtml.html#method_script script], and [http://api.joomla.org/cms-3/classes/JHtml.html#method_stylesheet stylesheet] methods in the JHtml class instead of loading the media directly with JDocument or hard coded tags, this enables easy overrides of your extension's media so that its output can be customized to the site it is used on.

== Where should I place files generated by my Component? ==
It depends on the nature of these files. There are two decisive factors:

* The permanence of the file: temporary, cache or permanent. Temporary files are files which are supposed to be removed immediately after use, before the page load completes. Cache files will be stored on the server for a while, at most until their expiration date. Both temporary and cache files can be deleted without prior warning and your code must anticipate that. Permanent files, on the other hand, are not meant to be removed automatically.
* The disposition of the file: web accessible or web inaccessible. The web accessible files are those which MUST be able to be accessed over the web, e.g. when you type their URL in a web browser. The web inaccessible files are those which NEEDN'T be able to be accessed over the web.

This gives us the following possibilities:
* Temporary, web inaccessible. Use Joomla!'s temp-directory. You can get it by doing JFactory::getConfig()->get('tmp_path'). Hardcoding the path as JPATH_ROOT . '/tmp' is a bad practice and you must not do it.
* Temporary, web accessible. That's not acceptable! Temporary files are by definition inaccessible from the web. Maybe you really meant "cache" instead of "temporary"?
* Cache, web inaccessible. Use the defined Joomla! cache directory. Use the JPATH_CACHE constant to find its location. Please note that the cache directory may be different in the front-end and back-end of your site.
* Cache, web accessible. Use a subdirectory of the media folder. See the section about Javascript and CSS files, it's the same thing.
* Permanent, web inaccessible. Use a folder under your extension's main directory. If you really want the files to be completely inaccessible from the web remember to place a .htaccess file or, better yet, give your users the option to use a directory outside the site's root.
* Permanent, web accessible. Use a subdirectory of the media folder. See the section about Javascript and CSS files, it's the same thing.

This applies to all files handled by your Component, including files your code generates and files the users of your component upload / generate.

Finally, if you want to manage log files you are advised to use the JLog class instead of rolling your own solution.

== Considerations for Javascript ==
When you are using addScriptDeclaration to add inline Javascript in a Joomla! page you have to be very considerate about your code's interaction with other Javascript from other extensions running on the same page. Good practices include:
* Do terminate your Javascript with a semicolon and a newline. If both are missing, your code is the source of Javascript errors as soon as another developer's code uses addScriptDeclaration after your code.
* Do make sure your Javascript code is valid and doesn't throw errors. Errors in your code will render any code after it inoperable.
* Do use try/catch blocks for risky code. If you are unsure if some code is risky just surround it with a try/catch block anyway.
* Do load your inline Javascript in the view template, not the view class (view.html.php file). Most likely it depends on the DOM which will be different when a site integrator uses a template override.

Other good practices concerning Javascript code in your extensions includes:
* Don't modify core Javascript objects including jQuery, mooTools and everything in the Joomla Javascript object. If you want to modify a core object, subclass. If you are not sure, subclass.
* Do not meddle with other developers' code. This includes moving script tags to the bottom of the page or forcibly removing script tags (e.g. removing any script tag whose source URL includes the strong "jq" – you know for whom the bell tolls).

[[Category:Development]]
[[Category:JavaScript]]

J4.x:Setting Up Your Local Environment

2018-07-28T20:58:22Z

Mbabker: Add note about platform reqs, some formatting and English cleanup

With Joomla 4 we have changed the development process, it is no longer possible to clone the repository and have a usable Joomla installation. We follow here best practices and have implemented a build process for the CMS.

== Quick start guide ==
What you have to do to setup you dev environment depends on your operating system. We can not write documentation for any OS so you should answer your favorite search engine to find a HowTo.

=== Tools you need ===

# PHP - basically the same as you need for running a Joomla Site, but you need the PHP CLI (command line interface) Version (see the [[S:MyLanguage/Configuring_a_LAMPP_server_for_PHP_development|Configuring a LAMPP server for PHP development]] page)
# Composer - for managing Joomla's PHP Dependencies - for help installing Composer read the documentation at https://getcomposer.org/doc/00-intro.md
# Node.js - for compiling Joomla's JavaScript and SASS files - for help installing Node.js please follow the instructions available on https://nodejs.org/en/
# Git - for version management

=== Steps to setup the local environment ===

# Clone the repository
# run <tt>composer install</tt> from the root of the git repo
# run <tt>npm install</tt> from the root of the git repo

== The a bit longer start guide ==

Joomla is not different to many other web tools these days. It has a large PHP part and it has more and more JavaScript code. While PHP coding doesn't need so much preparation, JavaScript needs a lot tooling around. The main reason is that nobody writes code in a way that every browser understands, so the code needs transpiling from e.g. ES6 to a compatible version of JavaScript. The same is true for CSS, for Joomla we are using SASS and this will be converted to native CSS so that any browser understands it. As downside setting up a dev environment is a bit more complicated but the tooling make coding also more convenient. Thanks to watchers and browser auto reload you can see your change in real time.

=== PHP ===
It should be enough to run <tt>composer install</tt> as this will install PHP dependencies saved in the composer.lock file. You can do this as many times as you like, it will only install new packages when the composer.lock file is changed. Don't run <tt>composer update</tt> as this will update all packages to newer versions and update the composer.lock file.

Note: You may need to run <tt>composer install</tt> with the <tt>--ignore-platform-reqs</tt> option to ignore platform requirements specified in Composer, i.e. if you do not have PHP's LDAP extension installed.

=== Node/npm scripts ===
Node.js comes with a package manager called NPM (in some way the same as Composer). NPM has a <tt>run</tt> command and we have prepared some scripts to make your life easier. You have to run the commands for the root of the repository.

==== npm run build:css ====
It will compile SASS files to CSS and also create the minified files

==== npm run build:js ====
It will compile and transpile the JavaScript files to the correct format and create minified files

==== npm run watch:css ====
This is the same as the <tt>build:css</tt> command but will watch for changes and automatically build updated files

==== npm run watch:js ====
This is the same as the <tt>build:js</tt> command but will watch for changes and automatically build updated files

==== npm run lint:js ====
This will make a syntax check on JavaScript files

==== npm run test ====
This will run other JavaScript testing suite

[[Category:Development]]
[[Category:Joomla! 4.x]]

J3.x:Privacy

2018-06-29T02:53:43Z

Mbabker: Add information requests link

{{Top portal heading|color=white-bkgd|icon=magic|icon-color=#5091cd|size=3x|text-color=#333|title=Tutorial 
How to Use the New Privacy Tool Suite}}
<noinclude>{{Joomla version|version=3.9}}</noinclude>

As of Joomla 3.9, Joomla introduced a privacy tool suite in response to laws and regulations such as GDPR. 
In this tutorial, you will find information on how to set up these new extensions.

== Component ==
=== Privacy Dashboard ===
The privacy dashboard provides a summary of the information requests for the website and a status of recommended actions to take.

==== Request Count ====
The request count "module" is a summary of the information requests on a website, this is similar to the privacy dashboard module explained below.

==== Health Check ====
[[File:Privacy Dashboard Health Check-en.png|600px|none]]
The health check "module" checks the status of several actions that it is recommended site owners take as it relates to integrating the privacy tools into their website, including:

* Check if a privacy policy is published - This will check if a privacy policy is configured and published; developers can integrate support for this check through the <tt>onPrivacyCheckPrivacyPolicyPublished</tt> event. If a policy is set in the '''System - Privacy Consent''' plugin then this check will succeed.
* Check if the information request form has a published menu item - This will determine if the frontend information request form has a published menu item to help authenticated users submit valid requests. Regardless of a menu item being published, a valid URL for the request form is always displayed.
* Check if there are any urgent requests - This will check for confirmed requests older than the age specified in the component parameters (default 14 days) and alert the site owner of any requests requiring urgent attention.

=== Extension Capabilities ===
This screen collects and displays information about privacy related capabilities (such as personal data processing, cookies set in your browser, or information shared with third parties for a feature to work) to assist users with evaluating extensions for privacy related concerns and preparing documentation such as a privacy policy or terms of service. More information about this screen and information on how developers can add support for it can be found on the [[S:MyLanguage/J3.x:Report_Extension_Capabilities_in_Privacy_Component|Report Extension Capabilities in Privacy Component]] page.

=== Information Requests ===
This screen is the central location for processing and managing user information requests. More information about this screen and the workflow for information requests can be found on the [[S:MyLanguage/J3.x:Information_Request_Workflow_in_Privacy_Component|Information Request Workflow in Privacy Component]] page.

== Plugins ==
=== System - Privacy Consent ===
[[File:Consent to Privacy Policy-en.png|600px|none]]
When personal identifiable information is collected you should ensure:
* the user is informed why you are requesting this information in plain and easy to understand language
* the user knows what data you collect about them
* the user knows what you will be using the data for
* the user has actively consented to your usage of the data.

This plugin does '''NOT''' make your web site legally compliant, it is just a step in the process.

Once the plugin has been enabled then any new user registering on your site will be required to consent to the Privacy conditions. The date and IP address of the user will be recorded. All existing users will be redirected to their User Profile so that they can consent.

==== Plugin Configuration ====
[[File:Privacy Consent Configuration-en.png|600px|none]]
The plugin is installed but not enabled by default with Joomla 3.9 - to enable it go to '''Extensions {{rarr}} Plugins''' and search for '''Privacy'''. Once you have located the plugin you can enable it and configure the settings.

==== Short Privacy Policy ====
This is a brief notice that will appear above the Privacy Consent checkbox. You can leave it as it is and the displayed message will be used or you can enter your own custom text.

{{note|''Note for Multilingual sites.'' If you use the default text then it will be displayed in the user's language. It is not possible to translate the custom text. If you wish to customise the text and display it in multiple languages then you should leave this field blank and use the Joomla language override facility to customise the <tt>PLG_USER_PRIVACYCONSENT_NOTE_FIELD_DEFAULT</tt> language string for each language installed.|type=notice}}

==== Privacy Article ====
If you wish to have a longer Privacy Policy you can create/edit the article here which will be displayed in a modal window.

{{note|''Note for Multilingual sites.'' If you associate this article with alternatives in other languages then the privacy policy will be displayed in the correct language for the user.|type=notice}}

==== Redirect Message ====
[[File:Redirect message-en.png|600px|none]]
This is the message that is displayed to existing users when they login for the first time since the Privacy Consent plugin was enabled on the site. You can leave it as it is and the displayed message will be used or you can enter your own custom text.

{{note|''Note for Multilingual sites.'' If you use the default text then it will be displayed in the user's language. It is not possible to translate the custom text. If you wish to customise the text and display it in multiple languages then you should leave this field blank and use the Joomla language override facility to customise the <tt>PLG_USER_PRIVACYCONSENT_REDIRECT_MESSAGE_DEFAULT</tt> language string for each language installed.|type=notice}}

=== User - Terms and Condition ===
==== Plugin Configuration ====
The plugin is installed but not enabled by default with Joomla 3.9 - to enable it go to '''Extensions {{rarr}} Plugins''' and search for '''Terms'''. Once you have located the plugin you can enable it and configure the settings.

==== Short Terms & Conditions ====
This is a brief notice that will appear above the Terms & Conditions checkbox. You can leave it as it is and the displayed message will be used or you can enter your own custom text.

{{note|''Note for Multilingual sites.'' If you use the default text then it will be displayed in the user's language. It is not possible to translate the custom text. If you wish to customise the text and display it in multiple languages then you should leave this field blank and use the Joomla language override facility to customise the <tt>PLG_USER_TERMS_NOTE_FIELD_DEFAULT</tt> language string for each language installed.|type=notice}}

==== Terms & Conditions Article ====
If you wish to have a longer Terms & Conditions you can create/edit the article here which will be displayed in a modal window.

{{note|''Note for Multilingual sites:'' If you associate this article with alternatives in other languages then the Terms & Conditions will be displayed in the correct language for the user.|type=notice}}

* Bulleted list item

=== Content - Confirm Consent ===
[[File:Confirm Consent checkbox-en.png|600px|none]]
This plugin will add a required checkbox to a form eg the core contact form

==== Plugin Configuration ====
[[File:Confirmconsent configuration-en.png|600px|none]]

The plugin is installed but not enabled by default with Joomla 3.9 - to enable it go to '''Extensions {{rarr}} Plugins''' and search for '''Consent'''. Once you have located the plugin you can enable it and configure the settings.

==== Short Privacy Policy ====
This is a brief notice that will appear above the Privacy Consent checkbox. You can leave it as it is and the displayed message will be used or you can enter your own custom text.

{{note|''Note for Multilingual sites:'' If you use the default text then it will be displayed in the user's language. It is not possible to translate the custom text. If you wish to customise the text and display it in multiple languages then you should leave this field blank and use the Joomla language override facility to customise the <tt>PLG_CONTENT_CONFIRMCONSENT_FIELD_NOTE_DEFAULT</tt> language string for each language installed.|type=notice}}

==== Privacy Article ====
If you wish to have a longer Privacy Policy you can create/edit the article here which will be displayed in a modal window.

{{note|''Note for Multilingual sites:'' If you associate this article with alternatives in other languages then the privacy policy will be displayed in the correct language for the user.|type=notice}}

== Modules ==
=== Privacy Dashboard ===
[[File:Privacy Dashboard Module-en.png|600px|none]]

This module provides a summary of the information requests received for your website. The module is installed and enabled by default with a new Joomla 3.9 installation. To add it to your dashboard on an updated site, go to '''Extensions {{rarr}} Modules''', change the Site filter to '''Administrator''', add a new '''Privacy Dashboard''' module, assign it to the '''cpanel''' position, and set access to '''Super Users'''.

<noinclude>
[[Category:Privacy]]
[[Category:Components]]
[[Category:Joomla! 3.9]]
[[Category:Plugins]]
[[Category:Modules]]
[[Category:Tutorials]]
</noinclude>

J3.x:Information Request Workflow in Privacy Component

2018-06-29T02:51:55Z

Mbabker: Created page with "Information requests are the central element to the privacy component and processing user requests for their data to be exported or removed from a site. == Creating a Request..."

J3.x:Privacy

2018-06-29T02:31:58Z

Mbabker: /* Health Check */

{{Top portal heading|color=white-bkgd|icon=magic|icon-color=#5091cd|size=3x|text-color=#333|title=Tutorial 
How to Use the New Privacy Tool Suite}}
<noinclude>{{Joomla version|version=3.9}}</noinclude>

As of Joomla 3.9, Joomla introduced a privacy tool suite in response to laws and regulations such as GDPR. 
In this tutorial, you will find information on how to set up these new extensions.

== Component ==
=== Privacy Dashboard ===
The privacy dashboard provides a summary of the information requests for the website and a status of recommended actions to take.

==== Request Count ====
The request count "module" is a summary of the information requests on a website, this is similar to the privacy dashboard module explained below.

==== Health Check ====
[[File:Privacy Dashboard Health Check-en.png|600px|none]]
The health check "module" checks the status of several actions that it is recommended site owners take as it relates to integrating the privacy tools into their website, including:

* Check if a privacy policy is published - This will check if a privacy policy is configured and published; developers can integrate support for this check through the <tt>onPrivacyCheckPrivacyPolicyPublished</tt> event. If a policy is set in the '''System - Privacy Consent''' plugin then this check will succeed.
* Check if the information request form has a published menu item - This will determine if the frontend information request form has a published menu item to help authenticated users submit valid requests. Regardless of a menu item being published, a valid URL for the request form is always displayed.
* Check if there are any urgent requests - This will check for confirmed requests older than the age specified in the component parameters (default 14 days) and alert the site owner of any requests requiring urgent attention.

=== Extension Capabilities ===
This screen collects and displays information about privacy related capabilities (such as personal data processing, cookies set in your browser, or information shared with third parties for a feature to work) to assist users with evaluating extensions for privacy related concerns and preparing documentation such as a privacy policy or terms of service. More information about this screen and information on how developers can add support for it can be found on the [[S:MyLanguage/J3.x:Report_Extension_Capabilities_in_Privacy_Component|Report Extension Capabilities in Privacy Component]] page.

== Plugins ==
=== System - Privacy Consent ===
[[File:Consent to Privacy Policy-en.png|600px|none]]
When personal identifiable information is collected you should ensure:
* the user is informed why you are requesting this information in plain and easy to understand language
* the user knows what data you collect about them
* the user knows what you will be using the data for
* the user has actively consented to your usage of the data.

This plugin does '''NOT''' make your web site legally compliant, it is just a step in the process.

Once the plugin has been enabled then any new user registering on your site will be required to consent to the Privacy conditions. The date and IP address of the user will be recorded. All existing users will be redirected to their User Profile so that they can consent.

==== Plugin Configuration ====
[[File:Privacy Consent Configuration-en.png|600px|none]]
The plugin is installed but not enabled by default with Joomla 3.9 - to enable it go to '''Extensions {{rarr}} Plugins''' and search for '''Privacy'''. Once you have located the plugin you can enable it and configure the settings.

==== Short Privacy Policy ====
This is a brief notice that will appear above the Privacy Consent checkbox. You can leave it as it is and the displayed message will be used or you can enter your own custom text.

{{note|''Note for Multilingual sites.'' If you use the default text then it will be displayed in the user's language. It is not possible to translate the custom text. If you wish to customise the text and display it in multiple languages then you should leave this field blank and use the Joomla language override facility to customise the <tt>PLG_USER_PRIVACYCONSENT_NOTE_FIELD_DEFAULT</tt> language string for each language installed.|type=notice}}

==== Privacy Article ====
If you wish to have a longer Privacy Policy you can create/edit the article here which will be displayed in a modal window.

{{note|''Note for Multilingual sites.'' If you associate this article with alternatives in other languages then the privacy policy will be displayed in the correct language for the user.|type=notice}}

==== Redirect Message ====
[[File:Redirect message-en.png|600px|none]]
This is the message that is displayed to existing users when they login for the first time since the Privacy Consent plugin was enabled on the site. You can leave it as it is and the displayed message will be used or you can enter your own custom text.

{{note|''Note for Multilingual sites.'' If you use the default text then it will be displayed in the user's language. It is not possible to translate the custom text. If you wish to customise the text and display it in multiple languages then you should leave this field blank and use the Joomla language override facility to customise the <tt>PLG_USER_PRIVACYCONSENT_REDIRECT_MESSAGE_DEFAULT</tt> language string for each language installed.|type=notice}}

=== User - Terms and Condition ===
==== Plugin Configuration ====
The plugin is installed but not enabled by default with Joomla 3.9 - to enable it go to '''Extensions {{rarr}} Plugins''' and search for '''Terms'''. Once you have located the plugin you can enable it and configure the settings.

==== Short Terms & Conditions ====
This is a brief notice that will appear above the Terms & Conditions checkbox. You can leave it as it is and the displayed message will be used or you can enter your own custom text.

{{note|''Note for Multilingual sites.'' If you use the default text then it will be displayed in the user's language. It is not possible to translate the custom text. If you wish to customise the text and display it in multiple languages then you should leave this field blank and use the Joomla language override facility to customise the <tt>PLG_USER_TERMS_NOTE_FIELD_DEFAULT</tt> language string for each language installed.|type=notice}}

==== Terms & Conditions Article ====
If you wish to have a longer Terms & Conditions you can create/edit the article here which will be displayed in a modal window.

{{note|''Note for Multilingual sites:'' If you associate this article with alternatives in other languages then the Terms & Conditions will be displayed in the correct language for the user.|type=notice}}

* Bulleted list item

=== Content - Confirm Consent ===
[[File:Confirm Consent checkbox-en.png|600px|none]]
This plugin will add a required checkbox to a form eg the core contact form

==== Plugin Configuration ====
[[File:Confirmconsent configuration-en.png|600px|none]]

The plugin is installed but not enabled by default with Joomla 3.9 - to enable it go to '''Extensions {{rarr}} Plugins''' and search for '''Consent'''. Once you have located the plugin you can enable it and configure the settings.

==== Short Privacy Policy ====
This is a brief notice that will appear above the Privacy Consent checkbox. You can leave it as it is and the displayed message will be used or you can enter your own custom text.

{{note|''Note for Multilingual sites:'' If you use the default text then it will be displayed in the user's language. It is not possible to translate the custom text. If you wish to customise the text and display it in multiple languages then you should leave this field blank and use the Joomla language override facility to customise the <tt>PLG_CONTENT_CONFIRMCONSENT_FIELD_NOTE_DEFAULT</tt> language string for each language installed.|type=notice}}

==== Privacy Article ====
If you wish to have a longer Privacy Policy you can create/edit the article here which will be displayed in a modal window.

{{note|''Note for Multilingual sites:'' If you associate this article with alternatives in other languages then the privacy policy will be displayed in the correct language for the user.|type=notice}}

== Modules ==
=== Privacy Dashboard ===
[[File:Privacy Dashboard Module-en.png|600px|none]]

This module provides a summary of the information requests received for your website. The module is installed and enabled by default with a new Joomla 3.9 installation. To add it to your dashboard on an updated site, go to '''Extensions {{rarr}} Modules''', change the Site filter to '''Administrator''', add a new '''Privacy Dashboard''' module, assign it to the '''cpanel''' position, and set access to '''Super Users'''.

<noinclude>
[[Category:Privacy]]
[[Category:Components]]
[[Category:Joomla! 3.9]]
[[Category:Plugins]]
[[Category:Modules]]
[[Category:Tutorials]]
</noinclude>

J3.x:Privacy

2018-06-29T02:31:40Z

Mbabker: /* Component */ Add dashboard

{{Top portal heading|color=white-bkgd|icon=magic|icon-color=#5091cd|size=3x|text-color=#333|title=Tutorial 
How to Use the New Privacy Tool Suite}}
<noinclude>{{Joomla version|version=3.9}}</noinclude>

As of Joomla 3.9, Joomla introduced a privacy tool suite in response to laws and regulations such as GDPR. 
In this tutorial, you will find information on how to set up these new extensions.

== Component ==
=== Privacy Dashboard ===
The privacy dashboard provides a summary of the information requests for the website and a status of recommended actions to take.

==== Request Count ====
The request count "module" is a summary of the information requests on a website, this is similar to the privacy dashboard module explained below.

==== Health Check ====
[[File:Privacy Dashboard Health Check.png|600px|none]]
The health check "module" checks the status of several actions that it is recommended site owners take as it relates to integrating the privacy tools into their website, including:

* Check if a privacy policy is published - This will check if a privacy policy is configured and published; developers can integrate support for this check through the <tt>onPrivacyCheckPrivacyPolicyPublished</tt> event. If a policy is set in the '''System - Privacy Consent''' plugin then this check will succeed.
* Check if the information request form has a published menu item - This will determine if the frontend information request form has a published menu item to help authenticated users submit valid requests. Regardless of a menu item being published, a valid URL for the request form is always displayed.
* Check if there are any urgent requests - This will check for confirmed requests older than the age specified in the component parameters (default 14 days) and alert the site owner of any requests requiring urgent attention.

=== Extension Capabilities ===
This screen collects and displays information about privacy related capabilities (such as personal data processing, cookies set in your browser, or information shared with third parties for a feature to work) to assist users with evaluating extensions for privacy related concerns and preparing documentation such as a privacy policy or terms of service. More information about this screen and information on how developers can add support for it can be found on the [[S:MyLanguage/J3.x:Report_Extension_Capabilities_in_Privacy_Component|Report Extension Capabilities in Privacy Component]] page.

== Plugins ==
=== System - Privacy Consent ===
[[File:Consent to Privacy Policy-en.png|600px|none]]
When personal identifiable information is collected you should ensure:
* the user is informed why you are requesting this information in plain and easy to understand language
* the user knows what data you collect about them
* the user knows what you will be using the data for
* the user has actively consented to your usage of the data.

This plugin does '''NOT''' make your web site legally compliant, it is just a step in the process.

Once the plugin has been enabled then any new user registering on your site will be required to consent to the Privacy conditions. The date and IP address of the user will be recorded. All existing users will be redirected to their User Profile so that they can consent.

==== Plugin Configuration ====
[[File:Privacy Consent Configuration-en.png|600px|none]]
The plugin is installed but not enabled by default with Joomla 3.9 - to enable it go to '''Extensions {{rarr}} Plugins''' and search for '''Privacy'''. Once you have located the plugin you can enable it and configure the settings.

==== Short Privacy Policy ====
This is a brief notice that will appear above the Privacy Consent checkbox. You can leave it as it is and the displayed message will be used or you can enter your own custom text.

{{note|''Note for Multilingual sites.'' If you use the default text then it will be displayed in the user's language. It is not possible to translate the custom text. If you wish to customise the text and display it in multiple languages then you should leave this field blank and use the Joomla language override facility to customise the <tt>PLG_USER_PRIVACYCONSENT_NOTE_FIELD_DEFAULT</tt> language string for each language installed.|type=notice}}

==== Privacy Article ====
If you wish to have a longer Privacy Policy you can create/edit the article here which will be displayed in a modal window.

{{note|''Note for Multilingual sites.'' If you associate this article with alternatives in other languages then the privacy policy will be displayed in the correct language for the user.|type=notice}}

==== Redirect Message ====
[[File:Redirect message-en.png|600px|none]]
This is the message that is displayed to existing users when they login for the first time since the Privacy Consent plugin was enabled on the site. You can leave it as it is and the displayed message will be used or you can enter your own custom text.

{{note|''Note for Multilingual sites.'' If you use the default text then it will be displayed in the user's language. It is not possible to translate the custom text. If you wish to customise the text and display it in multiple languages then you should leave this field blank and use the Joomla language override facility to customise the <tt>PLG_USER_PRIVACYCONSENT_REDIRECT_MESSAGE_DEFAULT</tt> language string for each language installed.|type=notice}}

=== User - Terms and Condition ===
==== Plugin Configuration ====
The plugin is installed but not enabled by default with Joomla 3.9 - to enable it go to '''Extensions {{rarr}} Plugins''' and search for '''Terms'''. Once you have located the plugin you can enable it and configure the settings.

==== Short Terms & Conditions ====
This is a brief notice that will appear above the Terms & Conditions checkbox. You can leave it as it is and the displayed message will be used or you can enter your own custom text.

{{note|''Note for Multilingual sites.'' If you use the default text then it will be displayed in the user's language. It is not possible to translate the custom text. If you wish to customise the text and display it in multiple languages then you should leave this field blank and use the Joomla language override facility to customise the <tt>PLG_USER_TERMS_NOTE_FIELD_DEFAULT</tt> language string for each language installed.|type=notice}}

==== Terms & Conditions Article ====
If you wish to have a longer Terms & Conditions you can create/edit the article here which will be displayed in a modal window.

{{note|''Note for Multilingual sites:'' If you associate this article with alternatives in other languages then the Terms & Conditions will be displayed in the correct language for the user.|type=notice}}

* Bulleted list item

=== Content - Confirm Consent ===
[[File:Confirm Consent checkbox-en.png|600px|none]]
This plugin will add a required checkbox to a form eg the core contact form

==== Plugin Configuration ====
[[File:Confirmconsent configuration-en.png|600px|none]]

The plugin is installed but not enabled by default with Joomla 3.9 - to enable it go to '''Extensions {{rarr}} Plugins''' and search for '''Consent'''. Once you have located the plugin you can enable it and configure the settings.

==== Short Privacy Policy ====
This is a brief notice that will appear above the Privacy Consent checkbox. You can leave it as it is and the displayed message will be used or you can enter your own custom text.

{{note|''Note for Multilingual sites:'' If you use the default text then it will be displayed in the user's language. It is not possible to translate the custom text. If you wish to customise the text and display it in multiple languages then you should leave this field blank and use the Joomla language override facility to customise the <tt>PLG_CONTENT_CONFIRMCONSENT_FIELD_NOTE_DEFAULT</tt> language string for each language installed.|type=notice}}

==== Privacy Article ====
If you wish to have a longer Privacy Policy you can create/edit the article here which will be displayed in a modal window.

{{note|''Note for Multilingual sites:'' If you associate this article with alternatives in other languages then the privacy policy will be displayed in the correct language for the user.|type=notice}}

== Modules ==
=== Privacy Dashboard ===
[[File:Privacy Dashboard Module-en.png|600px|none]]

This module provides a summary of the information requests received for your website. The module is installed and enabled by default with a new Joomla 3.9 installation. To add it to your dashboard on an updated site, go to '''Extensions {{rarr}} Modules''', change the Site filter to '''Administrator''', add a new '''Privacy Dashboard''' module, assign it to the '''cpanel''' position, and set access to '''Super Users'''.

<noinclude>
[[Category:Privacy]]
[[Category:Components]]
[[Category:Joomla! 3.9]]
[[Category:Plugins]]
[[Category:Modules]]
[[Category:Tutorials]]
</noinclude>

File:Privacy Dashboard Health Check-en.png

2018-06-29T02:19:04Z

Mbabker:

== Licensing ==
{{JEDL}}

J3.x:Privacy

2018-06-26T02:39:16Z

Mbabker: Reverted edits by Sandra97 (talk) to last revision by Mbabker

== Component ==
=== Extension Capabilities ===
This screen collects and displays information about privacy related capabilities (such as personal data processing, cookies set in your browser, or information shared with third parties for a feature to work) to assist users with evaluating extensions for privacy related concerns and preparing documentation such as a privacy policy or terms of service. More information about this screen and information on how developers can add support for it can be found on the [[J3.x:Report_Extension_Capabilities_in_Privacy_Component|Report Extension Capabilities in Privacy Component]] page.

== Plugins ==
=== System - Privacy Consent ===
[[File:Consent to Privacy Policy-en.png|thumb]]
When personal identifiable information is collected you should ensure:
* the user is informed why you are requesting this information in plain and easy to understand language.
* the user knows what data you collect about them
* the user knows what you will be using the data for
* the user has actively consented to your usage of the data

This plugin does NOT make your web site legally compliant, it is just a step in the process.

Once the plugin has been enabled then any new user registering on your site will be required to consent to the Privacy conditions. The date and ip address of the user will be recorded. All existing users will be redirected to their User Profile so that they can consent.

==== Plugin Configuration ====
[[File:Privacy Consent Configuration-en.png|thumb]]
The plugin is installed but not enabled by default with Joomla 3.9 - to enable it go to Extensions -> Plugins and search for Privacy. Once you have located the plugin you can enable it and configure the settings.

==== Short Privacy Policy ====
This is a brief notice that will appear above the Privacy Consent checkbox. You can leave it as it is and the displayed message will be used or you can enter your own custom text.

[NOTE - Multilingual sites] - If you use the default text then it will be displayed in the user's language. It is not possible to translate the custom text. If you wish to customise the text and display it in multiple languages then you should leave this field blank and use the Joomla language override facility to customise the PLG_USER_PRIVACYCONSENT_NOTE_FIELD_DEFAULT language string for each language installed.

==== Privacy Article ====
If you wish to have a longer Privacy Policy you can create/edit the article here which will be displayed in a modal window.

[NOTE - Multilingual sites] - If you associate this article with alternatives in other languages then the privacy policy will be displayed in the correct language for the user.


==== Redirect Message ====
[[File:Redirect message-en.png|thumb]]
This is the message that is displayed to existing users when they login for the first time since the Privacy Consent plugin was enabled on the site. You can leave it as it is and the displayed message will be used or you can enter your own custom text.

[NOTE - Multilingual sites] - If you use the default text then it will be displayed in the user's language. It is not possible to translate the custom text. If you wish to customise the text and display it in multiple languages then you should leave this field blank and use the Joomla language override facility to customise the PLG_USER_PRIVACYCONSENT_REDIRECT_MESSAGE_DEFAULT language string for each language installed.

=== User - Terms and Condition ===
==== Plugin Configuration ====
The plugin is installed but not enabled by default with Joomla 3.9 - to enable it go to Extensions -> Plugins and search for Terms. Once you have located the plugin you can enable it and configure the settings.

==== Short Terms & Conditions ====
This is a brief notice that will appear above the Terms & Conditions checkbox. You can leave it as it is and the displayed message will be used or you can enter your own custom text.

[NOTE - Multilingual sites] - If you use the default text then it will be displayed in the user's language. It is not possible to translate the custom text. If you wish to customise the text and display it in multiple languages then you should leave this field blank and use the Joomla language override facility to customise the PLG_USER_TERMS_NOTE_FIELD_DEFAULT language string for each language installed.

==== Terms & Conditions Article ====
If you wish to have a longer Terms & Conditions you can create/edit the article here which will be displayed in a modal window.

[NOTE - Multilingual sites] - If you associate this article with alternatives in other languages then the Terms & Conditions will be displayed in the correct language for the user.


* Bulleted list item
=== Content - Confirm Consent ===
[[File:Confirm Consent checkbox-en.png|thumb]]
This plugin will add a required checkbox to a form eg the core contact form

==== Plugin Configuration ====
[[File:Confirmconsent configuration-en.png|thumb]]

The plugin is installed but not enabled by default with Joomla 3.9 - to enable it go to Extensions -> Plugins and search for Consent. Once you have located the plugin you can enable it and configure the settings.

==== Short Privacy Policy ====
This is a brief notice that will appear above the Privacy Consent checkbox. You can leave it as it is and the displayed message will be used or you can enter your own custom text.

[NOTE - Multilingual sites] - If you use the default text then it will be displayed in the user's language. It is not possible to translate the custom text. If you wish to customise the text and display it in multiple languages then you should leave this field blank and use the Joomla language override facility to customise the PLG_CONTENT_CONFIRMCONSENT_FIELD_NOTE_DEFAULT language string for each language installed.

==== Privacy Article ====
If you wish to have a longer Privacy Policy you can create/edit the article here which will be displayed in a modal window.

[NOTE - Multilingual sites] - If you associate this article with alternatives in other languages then the privacy policy will be displayed in the correct language for the user.


== Modules ==
=== Privacy Dashboard ===
[[File:Privacy Dashboard Module.png|thumb]]

This module provides a summary of the information requests received for your website. The module is installed and enabled by default with a new Joomla 3.9 installation. To add it to your dashboard on an updated site, go to Extensions -> Modules, change the Site filter to Administrator, add a new "Privacy Dashboard" module, assign it to the "cpanel" position, and set access to "Super Users".

<noinclude>
[[Category:Privacy]]
[[Category:Components]]
[[Category:Joomla! 3.9]]
[[Category:Plugins]]
[[Category:Modules]]
</noinclude>

J3.x:Privacy

2018-06-20T03:25:10Z

Mbabker: Put thumbnails before text

J3.x:Privacy

2018-06-20T03:22:19Z

Mbabker: Add dashboard module

== Component ==

=== Extension Capabilities ===

This screen collects and displays information about privacy related capabilities (such as personal data processing, cookies set in your browser, or information shared with third parties for a feature to work) to assist users with evaluating extensions for privacy related concerns and preparing documentation such as a privacy policy or terms of service. More information about this screen and information on how developers can add support for it can be found on the [[J3.x:Report_Extension_Capabilities_in_Privacy_Component|Report Extension Capabilities in Privacy Component]] page.

== Plugins ==
=== System - Privacy Consent ===
When personal identifiable information is collected you should ensure:
* the user is informed why you are requesting this information in plain and easy to understand language.
* the user knows what data you collect about them
* the user knows what you will be using the data for
* the user has actively consented to your usage of the data

[[File:Consent to Privacy Policy-en.png|thumb]]
This plugin does NOT make your web site legally compliant, it is just a step in the process.

Once the plugin has been enabled then any new user registering on your site will be required to consent to the Privacy conditions. The date and ip address of the user will be recorded. All existing users will be redirected to their User Profile so that they can consent.

==== Plugin Configuration ====
The plugin is installed but not enabled by default with Joomla 3.9 - to enable it go to Extensions -> Plugins and search for Privacy. Once you have located the plugin you can enable it and configure the settings.

[[File:Privacy Consent Configuration-en.png|thumb]]

==== Short Privacy Policy ====
This is a brief notice that will appear above the Privacy Consent checkbox. You can leave it as it is and the displayed message will be used or you can enter your own custom text.

[NOTE - Multilingual sites] - If you use the default text then it will be displayed in the user's language. It is not possible to translate the custom text. If you wish to customise the text and display it in multiple languages then you should leave this field blank and use the Joomla language override facility to customise the PLG_USER_PRIVACYCONSENT_NOTE_FIELD_DEFAULT language string for each language installed.

==== Privacy Article ====
If you wish to have a longer Privacy Policy you can create/edit the article here which will be displayed in a modal window.

[NOTE - Multilingual sites] - If you associate this article with alternatives in other languages then the privacy policy will be displayed in the correct language for the user.


==== Redirect Message ====
This is the message that is displayed to existing users when they login for the first time since the Privacy Consent plugin was enabled on the site. You can leave it as it is and the displayed message will be used or you can enter your own custom text.

[[File:Redirect message-en.png|thumb]]

[NOTE - Multilingual sites] - If you use the default text then it will be displayed in the user's language. It is not possible to translate the custom text. If you wish to customise the text and display it in multiple languages then you should leave this field blank and use the Joomla language override facility to customise the PLG_USER_PRIVACYCONSENT_REDIRECT_MESSAGE_DEFAULT language string for each language installed.

=== User - Terms and Condition ===
==== Plugin Configuration ====
The plugin is installed but not enabled by default with Joomla 3.9 - to enable it go to Extensions -> Plugins and search for Terms. Once you have located the plugin you can enable it and configure the settings.

==== Short Terms & Conditions ====
This is a brief notice that will appear above the Terms & Conditions checkbox. You can leave it as it is and the displayed message will be used or you can enter your own custom text.

[NOTE - Multilingual sites] - If you use the default text then it will be displayed in the user's language. It is not possible to translate the custom text. If you wish to customise the text and display it in multiple languages then you should leave this field blank and use the Joomla language override facility to customise the PLG_USER_TERMS_NOTE_FIELD_DEFAULT language string for each language installed.

==== Terms & Conditions Article ====
If you wish to have a longer Terms & Conditions you can create/edit the article here which will be displayed in a modal window.

[NOTE - Multilingual sites] - If you associate this article with alternatives in other languages then the Terms & Conditions will be displayed in the correct language for the user.


* Bulleted list item
=== Content - Confirm Consent ===
This plugin will add a required checkbox to a form eg the core contact form
[[File:Confirm Consent checkbox-en.png|thumb]]

==== Plugin Configuration ====
The plugin is installed but not enabled by default with Joomla 3.9 - to enable it go to Extensions -> Plugins and search for Consent. Once you have located the plugin you can enable it and configure the settings.

[[File:Confirmconsent configuration-en.png|thumb]]

==== Short Privacy Policy ====
This is a brief notice that will appear above the Privacy Consent checkbox. You can leave it as it is and the displayed message will be used or you can enter your own custom text.

[NOTE - Multilingual sites] - If you use the default text then it will be displayed in the user's language. It is not possible to translate the custom text. If you wish to customise the text and display it in multiple languages then you should leave this field blank and use the Joomla language override facility to customise the PLG_CONTENT_CONFIRMCONSENT_FIELD_NOTE_DEFAULT language string for each language installed.

==== Privacy Article ====
If you wish to have a longer Privacy Policy you can create/edit the article here which will be displayed in a modal window.

[NOTE - Multilingual sites] - If you associate this article with alternatives in other languages then the privacy policy will be displayed in the correct language for the user.


== Modules ==
=== Privacy Dashboard ===
This module provides a summary of the information requests received for your website. The module is installed and enabled by default with a new Joomla 3.9 installation. To add it to your dashboard on an updated site, go to Extensions -> Modules, change the Site filter to Administrator, add a new "Privacy Dashboard" module, assign it to the "cpanel" position, and set access to "Super Users".

[[File:Privacy Dashboard Module.png|thumb]]

<noinclude>
[[Category:Privacy]]
[[Category:Components]]
[[Category:Joomla! 3.9]]
[[Category:Plugins]]
[[Category:Modules]]
</noinclude>

File:Privacy Dashboard Module-en.png

2018-06-20T03:18:22Z

Mbabker:

== Licensing ==
{{JEDL}}

J3.x:Privacy

2018-06-20T03:15:50Z

Mbabker: /* Component */ Add capabilities screen reference

== Component ==

=== Extension Capabilities ===

This screen collects and displays information about privacy related capabilities (such as personal data processing, cookies set in your browser, or information shared with third parties for a feature to work) to assist users with evaluating extensions for privacy related concerns and preparing documentation such as a privacy policy or terms of service. More information about this screen and information on how developers can add support for it can be found on the [[J3.x:Report_Extension_Capabilities_in_Privacy_Component|Report Extension Capabilities in Privacy Component]] page.

== Plugins ==
=== System - Privacy Consent ===
When personal identifiable information is collected you should ensure:
* the user is informed why you are requesting this information in plain and easy to understand language.
* the user knows what data you collect about them
* the user knows what you will be using the data for
* the user has actively consented to your usage of the data

[[File:Consent to Privacy Policy-en.png|thumb]]
This plugin does NOT make your web site legally compliant, it is just a step in the process.

Once the plugin has been enabled then any new user registering on your site will be required to consent to the Privacy conditions. The date and ip address of the user will be recorded. All existing users will be redirected to their User Profile so that they can consent.

==== Plugin Configuration ====
The plugin is installed but not enabled by default with Joomla 3.9 - to enable it go to Extensions -> Plugins and search for Privacy. Once you have located the plugin you can enable it and configure the settings.

[[File:Privacy Consent Configuration-en.png|thumb]]

==== Short Privacy Policy ====
This is a brief notice that will appear above the Privacy Consent checkbox. You can leave it as it is and the displayed message will be used or you can enter your own custom text.

[NOTE - Multilingual sites] - If you use the default text then it will be displayed in the user's language. It is not possible to translate the custom text. If you wish to customise the text and display it in multiple languages then you should leave this field blank and use the Joomla language override facility to customise the PLG_USER_PRIVACYCONSENT_NOTE_FIELD_DEFAULT language string for each language installed.

==== Privacy Article ====
If you wish to have a longer Privacy Policy you can create/edit the article here which will be displayed in a modal window.

[NOTE - Multilingual sites] - If you associate this article with alternatives in other languages then the privacy policy will be displayed in the correct language for the user.


==== Redirect Message ====
This is the message that is displayed to existing users when they login for the first time since the Privacy Consent plugin was enabled on the site. You can leave it as it is and the displayed message will be used or you can enter your own custom text.

[[File:Redirect message-en.png|thumb]]

[NOTE - Multilingual sites] - If you use the default text then it will be displayed in the user's language. It is not possible to translate the custom text. If you wish to customise the text and display it in multiple languages then you should leave this field blank and use the Joomla language override facility to customise the PLG_USER_PRIVACYCONSENT_REDIRECT_MESSAGE_DEFAULT language string for each language installed.

=== User - Terms and Condition ===
==== Plugin Configuration ====
The plugin is installed but not enabled by default with Joomla 3.9 - to enable it go to Extensions -> Plugins and search for Terms. Once you have located the plugin you can enable it and configure the settings.

==== Short Terms & Conditions ====
This is a brief notice that will appear above the Terms & Conditions checkbox. You can leave it as it is and the displayed message will be used or you can enter your own custom text.

[NOTE - Multilingual sites] - If you use the default text then it will be displayed in the user's language. It is not possible to translate the custom text. If you wish to customise the text and display it in multiple languages then you should leave this field blank and use the Joomla language override facility to customise the PLG_USER_TERMS_NOTE_FIELD_DEFAULT language string for each language installed.

==== Terms & Conditions Article ====
If you wish to have a longer Terms & Conditions you can create/edit the article here which will be displayed in a modal window.

[NOTE - Multilingual sites] - If you associate this article with alternatives in other languages then the Terms & Conditions will be displayed in the correct language for the user.


* Bulleted list item
=== Content - Confirm Consent ===
This plugin will add a required checkbox to a form eg the core contact form
[[File:Confirm Consent checkbox-en.png|thumb]]

==== Plugin Configuration ====
The plugin is installed but not enabled by default with Joomla 3.9 - to enable it go to Extensions -> Plugins and search for Consent. Once you have located the plugin you can enable it and configure the settings.

[[File:Confirmconsent configuration-en.png|thumb]]

==== Short Privacy Policy ====
This is a brief notice that will appear above the Privacy Consent checkbox. You can leave it as it is and the displayed message will be used or you can enter your own custom text.

[NOTE - Multilingual sites] - If you use the default text then it will be displayed in the user's language. It is not possible to translate the custom text. If you wish to customise the text and display it in multiple languages then you should leave this field blank and use the Joomla language override facility to customise the PLG_CONTENT_CONFIRMCONSENT_FIELD_NOTE_DEFAULT language string for each language installed.

==== Privacy Article ====
If you wish to have a longer Privacy Policy you can create/edit the article here which will be displayed in a modal window.

[NOTE - Multilingual sites] - If you associate this article with alternatives in other languages then the privacy policy will be displayed in the correct language for the user.


== Modules ==

<noinclude>
[[Category:Privacy]]
[[Category:Components]]
[[Category:Joomla! 3.9]]
[[Category:Plugins]]
[[Category:Modules]]
</noinclude>

J3.x:Report Extension Capabilities in Privacy Component

2018-06-20T03:08:13Z

Mbabker: Add page describing the privacy capabilities and how to implement for developers

[[File:Privacy Component Capabilities.png|thumb]]

As part of the [[J3.x:Privacy|Privacy Tool Suite]] introduced to Joomla! 3.9, a capabilities screen is present to allow extensions to report the functionality of their extensions that may require consideration when adding new features to a site or preparing documentation such as a privacy policy or terms of use.

'''IMPORTANT''' - The capabilities reported on this screen are based on the actively installed and enabled extensions on a site, and that the extensions support reporting their capabilities. As such, this should not be considered a complete list and it is recommended you consult the documentation of each installed extension for full details.

=== Implementation Guide For Developers ===

In order to report extension capabilities, a plugin must be subscribed to the `onPrivacyCollectAdminCapabilities` event. Unlike other plugins which are typically intended for use with a single plugin group, the following plugin groups are imported for potential use with this event:

* Authentication
* Captcha
* Installer
* Privacy
* System
* User

A plugin should return an associative array where the key is the text to be displayed as the section title and the value is an array of capabilities to be displayed as a bullet list within the section. All messages should be translated by the plugin. Below is an example of the array structure for the `Captcha - Recaptcha` plugin.

<source lang="php">
public function onPrivacyCollectAdminCapabilities()
{
// If a plugin does not have its language files autoloaded, ensure you manually load the language files now otherwise the below may not be translated
$this->loadLanguage();

return array(
JText::_('PLG_CAPTCHA_RECAPTCHA') => array(
JText::_('PLG_RECAPTCHA_PRIVACY_CAPABILITY_IP_ADDRESS'),
),
);
}
</source>

<noinclude>
[[Category:Privacy]]
[[Category:Components]]
[[Category:Joomla! 3.9]]
[[Category:Plugins]]
</noinclude>

File:Privacy Component Capabilities-en.png

2018-06-20T02:54:19Z

Mbabker:

== Licensing ==
{{JEDL}}

Potential backward compatibility issues in Joomla 4

2017-09-27T12:42:54Z

Mbabker: PHP 7

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

<translate>
== Updated System Requirements == 
</translate>
<translate>
The system requirements have been updated as follows:
*PHP 7
*MySQL 5.5.3
*PostgreSQL 9.2
*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>

== CMS Libraries == 
</translate>
<translate>
The following changes have been made to Joomla! CMS libraries (this is primarily code found in the `libraries/cms` directory in Joomla! 3).</translate>

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

<translate>
==== JInstallerAdapter Inheritance ==== 
</translate>
<translate>
JInstallerAdapter no longer extends from JAdapterInstance and inherently JObject.</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>

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

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

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

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

=== Crypt ===
<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>
=== Document === 
</translate>

<translate>
==== Deprecated Classes ==== 
</translate>
<translate>
The following classes have been deprecated and scheduled for removal in Joomla! 5.0:
*JDocumentError (use \Joomla\Cms\Error\RendererInterface objects instead)</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>

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

=== 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\Image\ImageFilter instead)
* JImageFilterBackgroundfill (use Joomla\Image\Filter\Backgroundfill instead)
* JImageFilterBrightness (use Joomla\Image\Filter\Brightness instead)
* JImageFilterContrast (use Joomla\Image\Filter\Contrast instead)
* JImageFilterEdgedetect (use Joomla\Image\Filter\Edgedetect instead)
* JImageFilterEmboss (use Joomla\Image\Filter\Emboss instead)
* JImageFilterGrayscale (use Joomla\Image\Filter\Grayscale instead)
* JImageFilterNegate (use Joomla\Image\Filter\Negate instead)
* JImageFilterSketchy (use Joomla\Image\Filter\Sketchy instead)
* JImageFilterSmooth (use Joomla\Image\Filter\Smooth instead)</translate>
<translate>
==== Class Changes ==== 
</translate>
<translate>
The Framework's Image package is now included in Joomla! 4.0 and JImage and the JImageFilter subclasses have been refactored to use the upstream package.</translate>
=== Keychain ===
Removing the keychain with 4.0 has resulted in the removal of the following class:
*JKeychain
<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</translate>

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

<translate>
* JMail::sendAdminMail has been removed</translate>

<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 requires a compulsory JApplicationCms object. If you were previously getting a Controller object through JControllerLegacy::getInstance you do not need to change your code.
* 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>
=== 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>

<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>
=== Classes Removed Without Replacement === 
</translate>
* JNode
* JTree

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

=== Bootstrap ===
<translate>
Joomla! 4.0 ships with Bootstrap 4.</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 Aurora.</translate>

<translate>
== Other == 
</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>

<noinclude>
<translate>

[[Category:Compatibility]]
[[Category:Development]]
[[Category:Platform]]
[[Category:Migration]]
[[Category:Update Working Group]]
[[Category:Joomla! 4.x]]
</translate>
</noinclude>

J3.x:Optional Technical Requirements

2017-09-20T13:53:00Z

Mbabker: Updates for 3.8

<noinclude><languages /></noinclude>
<translate>
==Sub-requirements for Joomla! 3.x== 
</translate>
<translate>
This page lists out ''optional'' technical requirements which aren't required to actually install and run Joomla! but are required for some dependencies running different internal APIs.</translate>

<section begin=Joomla 3.x />
{| class="wikitable" border="1"
|-
| colspan=2 style="background-color:#e1e1e1;" | '''<translate>
Application</translate>'''
|-
|JApplicationDaemon
|<translate>
Requires PHP's <tt>ext/pcntl</tt> and <tt>ext/posix</tt></translate>
|-
| colspan=2 style="background-color:#e1e1e1;" | '''<translate>
Archive</translate>'''
|-
|BZ2
|<translate>
Requires PHP's <tt>ext/bz2</tt></translate>
|-
|GZip
|<translate>
Requires PHP's <tt>ext/zlib</tt></translate>
|-
|Zip
|<translate>
Requires PHP's <tt>ext/zip</tt> or <tt>ext/zlib</tt></translate>
|-
| colspan=2 style="background-color:#e1e1e1;" | '''<translate>
Cache</translate>'''
|-
|APC
|<translate>
Requires PHP's <tt>ext/apc</tt> on PHP 5.3 or 5.4, <tt>ext/apcu</tt> on PHP 5.5 or 5.6, unsupported on PHP 7.x (Note: THIS NEED TO BE CHECKED)</translate>
|-
|APCu
|<translate>
Requires PHP's ext/apcu on PHP 5.3+</translate>
|-
|CacheLite
|<translate>
Requires the PEAR Cache_Lite package (tested on 1.7.16, will work with 1.8)</translate>
|-
|Memcache
|<translate>
Requires PHP's <tt>ext/memcache</tt> and a Memcache server (Note: The Memcache extension is not compatible with PHP 7.x)</translate>
|-
|Memcached
|<translate>
Requires PHP's <tt>ext/memcached</tt> and a Memcached server</translate>
|-
|Redis
|<translate>
Requires PHP's <tt>ext/redis</tt> and a Redis server</translate>
|-
|Wincache
|<translate>
Requires PHP's <tt>ext/wincache</tt> (Windows only)</translate>
|-
|XCache
|<translate>
Requires PHP's <tt>ext/xcache</tt></translate>
|-
| colspan=2 style="background-color:#e1e1e1;" | '''<translate>
Client adapters</translate>'''
|-
|LDAP
|<translate>
Requires PHP's <tt>ext/ldap</tt></translate>
|-
|HTTP/Curl
|<translate>
Requires PHP's <tt>ext/curl</tt></translate>
|-
|HTTP/Socket
|<translate>
Requires PHP's <tt>fsockopen()</tt> function be enabled</translate>
|-
|HTTP/Stream
|<translate>
Requires PHP's <tt>fopen()</tt> function and <tt>allow_url_fopen</tt> enabled</translate>
|-
| colspan=2 style="background-color:#e1e1e1;" | '''<translate>
Cryptography</translate>'''
|-
|JCrypt
|<translate>
Requires PHP's <tt>ext/mcrypt</tt> for all ciphers except the SodiumCipher which requires <tt>ext/sodium</tt></translate>
|-
|JKeychain
|<translate>
Requires PHP's <tt>ext/openssl</tt></translate>
|-
| colspan=2 style="background-color:#e1e1e1;" | '''<translate>
Database</translate>'''
|-
|Microsoft SQL Azure
|<translate>
Requires PHP's <tt>ext/sqlsrv</tt> (the PHP 5.x extension only supports Windows, a Linux compatible version of the extension is available for PHP 7.x)</translate>
|-
|Microsoft SQL Server
|<translate>
Requires PHP's <tt>ext/sqlsrv</tt> (the PHP 5.x extension only supports Windows, a Linux compatible version of the extension is available for PHP 7.x)</translate>
|-
|MySQL
|<translate>
Requires PHP's <tt>ext/mysql</tt> (unsupported on PHP 7.x)</translate>
|-
|MySQLi
|<translate>
Requires PHP's <tt>ext/mysqli</tt></translate>
|-
|Oracle
|<translate>
Requires PHP's <tt>ext/pdo</tt> with Oracle support (available for 3PD only; the CMS won't run with it)</translate>
|-
|PDO MySQL
|<translate>
Requires PHP's <tt>ext/pdo</tt> with MySQL support</translate>
|-
|PostgreSQL
|<translate>
Requires PHP's <tt>ext/pgsql</tt></translate>
|-
|SQLite
|<translate>
Requires PHP's <tt>ext/pdo</tt> with SQLite support (available for 3PD only; the CMS won't run with it)</translate>
|-
| colspan=2 style="background-color:#e1e1e1;" | '''<translate>
Image</translate>'''
|-
|
|<translate>
Requires PHP's <tt>ext/gd</tt></translate>
|-
| colspan=2 style="background-color:#e1e1e1;" | '''<translate>
Session</translate>'''
|-
|APC
|<translate>
Requires PHP's <tt>ext/apc</tt> on PHP 5.3 or 5.4, <tt>ext/apcu</tt> on PHP 5.5 or 5.6, unsupported on PHP 7.x (Note: THIS NEEDS TO BE CHECKED)</translate>
|-
|Memcache
|<translate>
Requires PHP's <tt>ext/memcache</tt> and a Memcache server (Note: The Memcache extension is not compatible with PHP 7.x)</translate>
|-
|Memcached
|<translate>
Requires PHP's <tt>ext/memcached</tt> and a Memcached server</translate>
|-
|Wincache
|<translate>
Requires PHP's <tt>ext/wincache</tt> (Windows only)</translate>
|-
|XCache
|<translate>
Requires PHP's <tt>ext/xcache</tt></translate>
|-
| colspan=2 style="background-color:#c1c1c1;text-align:center" | '''<translate>
OPTIONAL IMPROVEMENTS</translate>'''
|-
| colspan=2 style="background-color:#e1e1e1;" | '''<translate>
String</translate>'''
|-
|
|<translate>
Enable PHP's <tt>ext/mbstring</tt> for the phputf8 library to use native functions</translate>
|}
<section end=Joomla 3.x />

<noinclude>
<translate>

[[Category:Joomla! 3.x]]
[[Category:Joomla! 3.5]]
[[Category:Joomla! 3.6]]
</translate>
</noinclude>

J3.x:J3.8.0 LDAP

2017-09-19T19:53:26Z

Mbabker: Mbabker moved page J3.x:J3.8.0 LDAP to J3.x:LDAP Client Missing Escape Method

#REDIRECT [[J3.x:LDAP Client Missing Escape Method]]

J3.x:LDAP Client Missing Escape Method

2017-09-19T19:53:26Z

Mbabker: Mbabker moved page J3.x:J3.8.0 LDAP to J3.x:LDAP Client Missing Escape Method

==Errors reported== 
The LDAP authentication plugin tries to call a non-existing `escape` method on the Joomla\Ldap\LdapClient class.

==Versions affected== 
{{tip|This pertains only to Joomla! version(s): '''3.8.0'''|title=General Information}} 

==What is the cause== 
A file was not correctly updated in the 3.8.0 release.

==How to fix== 
Replace the file at `libraries/vendor/joomla/ldap/src/LdapClient.php` with the version found at https://github.com/joomla-framework/ldap/blob/1.2.0/src/LdapClient.php

__NOTOC__

<noinclude>
[[Category:Version 3.8 FAQ]]
[[Category:Version 3.8.0 FAQ]]
[[Category:FAQ]]
[[Category:Joomla! 3.8]]
</noinclude>

J3.x:LDAP Client Missing Escape Method

2017-09-19T19:50:52Z

Mbabker:

J3.x:LDAP Client Missing Escape Method

2017-09-19T19:50:14Z

Mbabker:

==Errors reported== 
Currently failing with line 119 of ldap.php file, specifically the $ldap->escape method that upon further inspection does not exist in the LdapClient.php file.

==Versions affected== 
{{tip|This pertains only to Joomla! version(s): '''3.8.0'''|title=General Information}} 

==What is the cause== 
A file was not correctly updated in the 3.8.0 release.

==How to fix== 
Replace the file at `libraries/vendor/joomla/ldap/src/LdapClient.php` with the version found at https://github.com/joomla-framework/ldap/blob/1.2.0/src/LdapClient.php

__NOTOC__

<noinclude>
[[Category:Version 3.8 FAQ]]
[[Category:Version 3.8.0 FAQ]]
[[Category:FAQ]]
[[Category:Joomla! 3.8]]
</noinclude>

J3.x:Call to undefined method JAdminCssMenu::addChild in backend

2017-09-19T15:50:11Z

Mbabker: Categories

In Joomla! 3.8, the administrator menu module was updated to include new features. As a result of the changes, some extensions may have been broken by the 3.8 update.

==Errors reported==
Call to undefined method JAdminCssMenu::addChild

==Versions affected== 
{{tip|This pertains only to Joomla! version(s): '''3.8.0'''|title=General Information}} 

==What is the cause==
Changes in the administrator menu module to support new features.

==How to fix==
Ensure all extensions are updated prior to updating Joomla.

__NOTOC__

<noinclude>
[[Category:Version 3.8 FAQ]]
[[Category:Version 3.8.0 FAQ]]
[[Category:FAQ]]
[[Category:Joomla! 3.8]]
</noinclude>

J3.x:Call to undefined method JAdminCssMenu::addChild in backend

2017-09-19T15:30:23Z

Mbabker: Create FAQ