UsingJoomla - Good Practices

There are many pieces of good advice available with regards to good practices in keeping your Joomla!^® website safe and secure.

Much of those pieces of advice are consistent - UsingJoomla.com would like to give you some tips and advice here.

Some of the items below may seem 'baffling' - but for many, you will become more familiar (and comfortable) with what we describe as you move along your Joomla journey so do not let any tips on this page distract you from progressing.

Why do we want, or need, to keep our website safe ?

To maintain our own control and ownership of our website

On a shared server, in particular, where you share the server with other hosting company clients - a compromised website can affect the stability of the entire server - including other people's websites.

You do not want another person's website to affect the operation of your website - and the other way around too.

How can our website be compromised ?

We protect our home(s) and computers from hack*ers and in the same way we need to protect our website(s) from unscrupulous persons;
A website can be breached - data can be accessed illegally;
Your website could be taken over (hijacked) - you lose access to the administrator area and you cannot recover it;

Here is our list of Best-Practices, in no particular order:

Choose a good web-host
Use the latest 'Stable' release of Joomla
Use extensions that are secure, regularly and recently updated
Use the latest 'Stable' release of extensions
Use the 'Stable' release of extensions on live websites
Keep folder and file permissions appropriate
Use a Web Application Firewall (WAF)
Take regular backups
Use difficult to guess Username(s) and Passwords
Use Joomla security extensions
When using an FTP client - use SFTP
Protect the Administrator area login
Have your website served over HTTPS using an SSL certificate
Do not keep backup archives within your website
Keep more than one copy of your backup archive
Keep backup archives for a period of time
Test your backup
Public_html Directory And Security
Update And Secure
Change the Meta Generator Tag
Access Restrictions
Validating User Input
Pro-active Versus Re-active
Beware of the Pirates
Access Control Levels
Installing And Updating Extensions - 'When' and 'How'

Let us expand on those items above.

Go to top of page

Choose a good web-host

A good web-host will take security very seriously, and will indeed be very proactive in ensuring their servers are secure - but it is your responsibility to ensure your website is secure.

Read reviews.

Seek recommendations from people (developers) who you trust and who themselves are held in high regard.

Go to list of Best Practices

Go to top of page

Use the latest stable version of Joomla

Joomla gets updated at intervals - many updates are for new or improved features - but if a vulnerability is identified an update may be solely for security fixes and remedies.

Typically, when a security vulnerability is identified it will be remedied with a new release of Joomla before any details are released into the public domain of that vulnerability.

In the case where a release contains a security fix - it would be very important to update your Joomla install promptly because the release change-log will most likely explain what and where the vulnerability is.

An unscrupulous person could then attempt to find Joomla powered websites that have not been updated and still contain the said vulnerability.

Go to list of Best Practices

Go to top of page

Use the latest stable release of extensions

For exactly the same reason(s) above as using the latest stable release of Joomla.

Ask yourself:

Is there an extension version compatible with the most recent version of Joomla ?
Is there an extension version compatible with the version of Joomla that you are using ?

This point is particularly important in any transition period between two Joomla versions, where two valid Joomla versions are in use simultaneously - an example of this is Joomla 3.10.x and 4.0.x

The Joomla 3.10.x branch is being used simultaneously with the next major Joomla version 4.0.x in order that users, and extension developers can migrate their extensions (and hence websites) to Joomla version 4.0.x

It is important to know that the extension is compatible with the current latest Joomla version, when the older Joomla version will reach end-of-life.

Updating your Joomla installation is easier, much easier, when all extensions are compatible with the most recent version of Joomla.

Go to list of Best Practices

Go to top of page

Use the 'Stable' releases of extensions on your live website

Granted - this is similar to the previous section of this article - yet there is a subtle difference in the point I am trying to make in THIS section.

The previous section is really referring to 'Stable' versions ONLY.

There may be multiple 'Stable' versions - which were released as 'Stable' and were indeed 'Stable' at the time of release but since been updated with a newer 'Stable' version.

So, what twist is THIS section putting on it?

What kind of release is it?

Broadly speaking, there are five categories of release:

'Stable' - final release - vast majority of issues resolved
'Release Candidate' (RC) - Released after 'Beta' releases. Most issues resolved. May be released as 'Release Candidate 1', 'Release Candidate 2', 'Release Candidate 3' etc. Each 'Release Candidate' variant resolving, at least partially, issues from the preceding 'Release Candidate' variant
'Beta' - Released after 'Alpha' releases - released as 'Beta 1', 'Beta 2', Beta 3', etc. Each 'Beta' variant resolving, at least partially, issues from the preceding 'Beta' variant
'Alpha' - initial release - can come as 'Alpha 1', 'Alpha 2', 'Alpha 3' etc. Each 'Alpha' variant resolving, at least partially, issues from the preceding 'Alpha' variant
'Development' - perhaps not often heard of, but they do exist

For live websites (commonly called 'Production' sites) you should be using 'Stable' releases.

Release Candidates (RC), Beta releases, Alpha releases and Development releases should certainly be used on non-live websites first - that is, you should use them on test / development websites.

'Alpha' releases, 'Beta' releases, 'Release Candidates' and 'Development' releases can mean they could

still have bugs - in terms of extension functionality
still have security bugs / issues
not have been tested fully in the 'real world'

Side Note

Developers often release 'Alpha' releases, 'Beta' releases, 'Release Candidates' and 'Development' releases for interested users to test and help find bugs that can be reported back to the extension developer in preparation of the ultimate 'Stable' release.

These should be tested on 'Test' or 'Development' sites - not public facing websites that could become victim to a fatal bug.

Go to list of Best Practices

Go to top of page

Use extensions that are secure, regularly and recently updated

Using secure and recently updated extensions is important.

An extension that is not recently updated by the developer(s) of that extension - say several months ago - may contain one or more vulnerability.

An extension that has not been updated by the developer(s) of that extension, for say several months - may be an extension that is no longer be supported/developed.

An extension not updated recently by the developer(s) of that extension may not be compatible with the latest stable version of Joomla or the latest versions of PHP that are used on your server.

If an extension has not been updated in more than one year (which is a massive timescale for software), perhaps consider the extension no longer developed.

Some questions and issues to consider

Does the extension use explicit path names when invoking external programs ?
Is there security against Cross Site Scripting (XSS) ?
Is there Security againt direct access throught the URL ? For example: www.yoursite.com/components/extension.php?bad_code_here
Security against remote file inclusions ?
Security against SQL injections ?
Relying on the PATH environment variable to resolve partial path names is a dangerous practice.
Does the extension need PHP register_globals* ON ? See our note below . . .
Does the extension need Joomla RG Emulation ON ?
Does the extension have url_fopen off ?
Does the extension have open_basedir restrictions ?
Does the extension have disabled PHP functions ? If 'Yes' - there may be legitimate (or illegitimate) reasons for disabling PHP functions
Does the extension have poorly configured file / folder permissions ?
Look out for missing: defined('_JEXEC') or die; ... statements
Look out for poorly constructed include() statements
Is there a lack of request filtering through mod_rewrite rules ?
Is there a lack of request filtering through mod_security Apache modules ?

Go to list of Best Practices

Go to top of page

A note on register_globals

* Register Globals (register_globals) has been officially deprecated in PHP5.

The use of register-globals can allow anyone to inject variables into scripts - on this basis we recommend that you do not use register_globals.

Beginning with PHP7 Register Globals (register_globals) will (officially) no longer exist . . . though it may be possible to create a workaround - so be aware of the workaround being used to bring back register_globals by people using it for less than honest reasons.

Keep File and Folder permissions appropriate

File and folder permissions can, broadly, be classed as determining Read, Write, and Execute rights for the file/directory.

Only certain levels of access should be able to write, and likewise read or execute a file.

You might also want to read further down this article: Access Restrictions

Go to list of Best Practices

Go to top of page

Use a Web Application Firewall

Using a Web Application Firewall (WAF) is like using a filter.

While a WAF is used to help provide real-time protection against common attacks, it should always be borne in mind that NO security system is 100% effective 100% of the time.

A good security feature is always being developed and adapted to suit current trends and technologies.

A Web Application Firewall (WAF) can be used to help:

Give protection against SQL Injection attacks
Give protection against Brute Force Attack
Provide Login Protection
And much more

Go to list of Best Practices

Go to top of page

Take Regular Backups

How regular is regular ?

How much work or data can you "afford" to lose ? 2 hours work? Two days work ?

Do you have an eCommerce website with one or two sales taking place hourly ? Or hundreds of sales per hour ?

The above, hopefully places some form of "scale" to your back-up approach.

There are times when you should backup your website as a matter of routine:

Before, and again after carrying out an extension update
Before, and again after carrying out a Joomla update
If you write several articles each day - carry out a backup before and after each article
If you make several sales from your eCommerce website every hour - carry out a backup every 1/2 an hour

You should be able to completely recover from a major failure from at least two previous full backups. Just in case the most recent full backup is damaged, lost, or corrupt.

A good backup regime should contain at least one full backup within a chosen cycle, for example: Daily, weekly, fortnightly, monthly.

Also, a good backup practice is to store backups away from the current data location, preferably off site.

Consider the 'Types' of Backup

Dynamic / Hot / On-Line
Static / Cold / Off-line

Dynamic data should be backed up off-line or 'cold' to avoid 'fuzzy' backups (data is changing as you back it up) potentially leading to related information not being in sync when backed up.

Data which can be changing (dynamic) as you back it up includes, for example

Forums (New 'Threads', new 'Posts' to existing 'threads')
e-commerce / shops (Think about: sales / purchases, shopping carts, stock quantities)
Website registrations

Dynamic, hot or on-line backups - your website backup is taken while your website is still on-line ('Live').

While off-line (also known as 'Maintenance' mode), typically users cannot see your website (Have you ever seen the 'Under Maintenance' page) - therefore visitors cannot register, login, buy or check-out from your e-commerce website, create new forum Topics or reply to existing Forum topics. Your website is taken off-line, backed-up, and then placed back on-line.

During a Dynamic, hot, or on-line backup people are still navigating your website: Registering, logging-in, adding items to shopping carts, creating new Forum topics or replying to exisitng Forum topics.

If you really must carry out a 'Dynamic' backup - do so during less busy times when data is changing the least.

Why do we say these things ?

Two draw backs of a Dynamic backup . . .

Incomplete data is backed-up where some data is left out of the backup. This incomplete backup is known as a 'Fuzzy' backup
Where file sizes are dynamically changing, this can cause your backup to become corrupt. Where the backup records file sizes, which are changing during backup, you potentially get a corrupt backup at worst

Tip

When downloading a backup via an FTP client (for example but not limited to cuteFTP), use 'Binary' mode - this is much less likely than ASCII to create a corrupt backup.

Tip

Carrying out a back-up and restoring that back-up is less, much less, trouble than losing several hours work, or losing any amount of sales information.

The good news is

Carrying out a backup does not have to be a burden.

If you use a great web-host, or Akeeba Backup Professional you can schedule your backups to take place - even to take place while you sleep, eat, socialise - by using a CRON schedule.

Tip

If you are a user of Akeeba Backup for Joomla, when Akeeba Backup carries out a Backup you will most likely use the "Default Backup Directory" - this is where your backup goes.

The location of the default backup directory is well documented.

The drawback of this - 'hackers' have a fair chance of attacking this location and abuse your backups.

The good thing with Akeeba Backup - you can configure where the backup goes - a good place in your hosting diectory tree is to create a uniquely named directory (folder) above public_html which by definition is inaccessible over the web, and significantly harder for the unscrupulous to guess and find.

Go to list of Best Practices

Go to top of page

Use difficult to guess usernames and passwords

Do not use words from a dictionary as either a username or password.

There are software programs that can be used to attempt to find a password.

Dictionary words are quite easy for a computer program to work out: the word "Dictionary" could take a computer approximately 1 month to determine. The word "Joomla" could take a computer program approximately 500 milliseconds (that is 1/2 a second !) to determine.

There are some excellent tools available to help you create a strong password one such tool is this Strong Password Generator

Tip

Do not use (or allow) a Username of, or similar to the following as these can be easy to "guess":
- Admin
- admin
- Administrator
- administrator

The "default" Joomla Super User id should be changed as you are setting up your Joomla install.

Tip:

Do not use a Username or Password that you use on another website - either for the Administrator area or the "front-end"

Seriously - good advice that can never be repeated too often !

Go to list of Best Practices

Go to top of page

Have your website served over HTTPS with an SSL certificate

HTTPS is a secure encrypted form of website delivery to your browser.

Installing and setting up an SSL certificate used to be a time consuming and expensive process.

However now it can be very easy and either free of charge or very cheap.

Some web hosts even offer clients the option of a free LetsEncrypt SSL certificate and the host will even set it up for you and renew it when required.

One such web host is SiteGround - their cPanel allows you to simply choose "yes" for an SSL against your cPanel domain name.

Go to list of Best Practices

Go to top of page

Protect the Administrator area login

Joomla, by default, has access to the Administrator area login panel by a commonly known URL (web address).

Any hack*er who wants to have a go at your website simply needs to use this known url - he / she does not even need to know your site is using Joomla - attack several hundred websites and if one gets him / her the login URL part of his / her job is done !

There are security tools available that will allow you to protect the administrator area URL so that the administrator area URL is known ONLY to you.

Go to list of Best Practices

Go to top of page

Use Joomla Security Extensions

All of the above might seem like a lot to do - individually, perhaps it is a lot to do.

There are however some excellent security tools available that can do a lot of the hard work.

Here at UsingJoomla.com we highly and strongly recommend:

Akeeba Admin Tools For Joomla for Security tools, including Web Application Firewall, and Administrator area protection, among other tools within this package in addition to these two tools
Akeeba Backup for Joomla for backing up your Joomla website

If you want to read our articles on the above three items, you might like to visit:

Go to list of Best Practices

Go to top of page

When using FTP client Use SFTP

When transferring files via FTP (File Transfer Protocol), for example when using cuteFTP, to transfer files between your website and your local computer, or vice-versa, the files could be intercepted between your server and your local computer.

Using SFTP (Secure File Transfer Protocol) will help greatly in protecting your files being transferred by encrypting them during "transfer".

Go to list of Best Practices

Go to top of page

Do not keep backup archives within your website

A website backup package / extension may place your website backup archive in a backup output directory within your website directory structure.

There are two reasons why you might want to consider not keeping website backup archives within your website directory structure:

The backup archive takes up an element of your allocated server space;
In the event of your website becoming compromised - your backup archive may become accessible to someone you do not wish it to be accessible to;

So, what should you do ?

Take your backup - let it go to an output directory / folder within your website directory structure - if that is what it does, and then:

Using your FTP Client download the backup archive to somewhere of your choice, for example to your local PC, or external hard drive, and then
Returning to your website administrator area, go to the backup archive folder and delete the archive

Or, as a bonus, the Backup software package we use here at UsingJoomla.com, any number of "Profiles" can be set up. Within any profile the backup process can be configured with Post-processing.

Post-processing allows for the backup to be transferred to a remote storage facility such as:

Amazon S3
OneDrive
CloudMe
RackSpace Cloud Files
DreamObjects
OVH object Storage
SugarSync
Box.net
Box.com
WebDAV
Google Drive

Go to list of Best Practices

Go to top of page

Keep more than one copy of each of your backup archive(s)

If we keep only one copy of our backup archive - lots can happen.

The hard drive can fail - we have lost our backup stored on it;
The hard drive can become damaged - for example: water damage, fire.

Tip

Paranoia can be your friend !

Keep multiple copies of each backup archive on / in physically separate places / drives.

If you keep a copy of each backup archive on, for example, five physically separate drives - what are the chances of all five drives failing, or becoming damaged ?

Slim ?

Here at usingjoomla.com we keep a copy of every backup archive on five physically separate hard drives.

Tip

When downloading a backup via an FTP client (for example but not limited to cuteFTP), use 'Binary' mode - this is much less likely than ASCII to create a corrupt backup.

There are some excellent External Hard Drives available via Amazon

Go to list of Best Practices

Go to top of page

Keep backup archives for a period of time

Set yourself a minimum period of time over which you keep your backup archives.

Why ?

On occasion it might be conceivable that a backup archive might become corrupt - for example if a hard drive begins to fail.

Here at usingjoomla.com we retain backup archives for a minimum of 12 months.

Tip

When downloading a backup via an FTP client (for example but not limited to cuteFTP), use 'Binary' mode - this is much less likely than ASCII to create a corrupt backup.

Go to list of Best Practices

Go to top of page

Test your backup

You have done all your hard, time consuming work on your website, you are rightly proud of it, taken your website backup, saved a copy of your backup (on more than one physically separate hard drive !) - but - do you know that your backup is all good ? Have you tested it ?

Warning

Waiting until you need to restore your website from a backup is not the time to find that your chosen backup does not work !

How can we test our backup ?

In a nutshell - there are two ways: The first one below is the preferred method for us here at usingjoomla.com

Create a (password protected) "Test" directory within your hosting account and restore your backup to that directory, using a separate database created specifically for restoring your backup to;
Download and install a "local web-server", such as XAMPP and restore your backup to the local web-server. There are some "ifs and buts" associated with this method which are outside the scope of this article, but never-the-less is an option.

Tip

We have said it more than once in this article already - for good reason . . .

When downloading a backup via an FTP client (for example but not limited to cuteFTP), use 'Binary' mode - this is much less likely than ASCII to create a corrupt backup.

Go to list of Best Practices

Go to top of page

public_html Directory And Security

It is beyond the scope of this article to explain in great depth "what" the public_html directory does. Directory structure(s) and "permissions" can be an encyclopaedia (en-US: encyclopedia) all on its own !

In summary

The most insecure directory on a UNIX server is the one serving Web files, usually called public_html. This is because it is generally publicly accessible, and possibly writeable.

That status is the very definition of insecure.

If there is any weakness (vulnerability) in any file within your public_html directory, your entire hosting account is potentially at risk (vulnerable), and not just one of your Web sites but possibly every Web site in your hosting account (if you have a hosting plan that allows you to host more than one website).

Such vulnerabilities give attackers access to the scripting used to run your site. If one website gets infected, like any medical virus - the virus placed into one of your websites within public_html directory could also pass into another website (Addon domain) within the SAME public_html directory.

In the directory structure, what is above (or outside) of your public_html directory is not so easily accessible via a web browser - on that basis, each addon domain can be placed below its own unique public_html directory. How to achieve this structure is beyond the scope of this article - but perhaps gives you food-for-thought.

Go to list of Best Practices

Go to top of page

Session Security

How many times do you start doing something - filling in a form, checking your bank account (the list could go on) on a website, any website, and you get interrupted ?

Dinner
Phone call
Important email that you MUST answer

An hour later you remember what you were doing before the interruption - go back to it and one of three things has happened:

Nothing - it is just as you left it
You are still logged in - and some prying eyes and fingers have wreaked havoc
You have been automatically logged out

Number three above is probably the best of the three cpossible outcomes.

When a user logs in (including a Super User logging in to the Administrator area) a "Session" starts - you have a Session Cookie set on your browser. After a period of inactivity - when you, or your logged in user, has "done nothing" - literally - you, or your user, will then be logged out.

This is referred to as the "Session Lifetime" - this is adjustable - and is measured in minutes. Here at usingjoomla.com we recommend setting this to as low as possible - 15 minutes tends to be ample for the vast majority of users. This is the inactivity period - if you are working away you can get passed the 15 minutes without becoming automatically logged-out.

So, setting this low will reduce the chances of a user getting interrupted and having their account compromised - or even from "someone" sending that impolite message through your Contact Us form !

Go to list of Best Practices

Go to top of page

Update And Secure

This section is really a combination of other sections above.

Would you secure a seriously outdated building ?

Just asking.

If "Yes" - perhaps an excercise in futility.

Would you wait until someone walks into your home and removes your posessions before locking your doors ?

There are many gaps and weaknesses in a seriously outdated website.

Get updated.

Get secure.

An excercise in futility ?

Go to list of Best Practices

Go to top of page

Change the Meta Generator Tag

Your Joomla site always comes with a default meta generator tag to show that your website is a Joomla site, and sometimes it will show its version as well.

Finding the Meta Generator Tag - is very easy - simply by viewing the website source code - right click, select view page source

Some "unscrupulous persons" will look for and attack Joomla! powered websites, and your Meta Generator Tag - can reveal exactly what "they" are looking for.

If a known vulnerability exists in a specific Joomla! version - the unscrupulous can search out websites built using that vulnerable version and take advantage of the weakness.

It is possible, and advised, to change this for security measures if you do not want others to know you have built a Joomla site and what version it may be.

If you use Akeeba Admin Tools (Pro) - you can change / customise (or hide) the Meta Generator Tag as a feature of Admin Tools Pro

Go to list of Best Practices

Go to top of page

Access Restrictions

Ensure you have your website content (For example: Articles, Modules, Forms) restricted to appropriate access levels.

When choosing extensions: Does the extension read or write files to your server ?

Most likely it does - but that does not mean 'bad', however . . .

Extensions that write files have the potential to modify existing files, or introduce viruses.

Extensions that read files may (inadvertently or by design) violate / ignore access restrictions you have set up, and / or pass sensitive system information to the unscrupulous.

Also, consider if the extension runs with set-user-id (suid) privileges - generally this is not advised and a very good reason for doing so is needed.

Validating User Input

Use extensions that 'Validate User Input' in URLs and Form-fields.

Pro-active Versus Re-active

No security plan or system is ever 100% guaranteed.

The unscrupulous can often be one-step-ahead.

However - arguably, the best approach is to be Pro-Active and dynamic.

Even if we are on the right track we can get run over if we just sit there !

Go to list of Best Practices

Go to top of page

Beware of the Pirates / Bandits

Sometimes called, or referred to as, 'Bandits'.

What are they and what do they do?

They offer unofficial and illegal copies of software. Either for free or for a reduced fee compared to official or legal copies.

There are places on the internet where these unofficial, and illegal copies of software can be obtained.

Here at UsingJoomla.com we shall not give them the publicity of mentioning them here - 'but' we have a list - if you want the list or to know if a specific provider is on the list - please feel free to ask us - please be aware though that the list is not claimed to be exhaustive (that is - there may be someone we are not yet aware of who is not on the list). Keeping it to the concept of ONLY buying from or downloading from the official provider will keep you in much safer hands.

There are most likely many more around than we are aware of acting alone or as a group.

Why do they do it?

There are two broad reasons:

They prey on other people's work to make an income - they are thieves
The Pirates / Bandits can and do manipulate the software to contain there own malicious code - you have no idea what kind of code they add

What are the results of using illegal and unofficial copies of software?

These copies are denying the legal, legitimate developers from their well deserved and well earned income
You are opening up your own website to malicious code

Our advice

Respect the work of others - ONLY buy and download software from the official developer.

You will be doing yourself and the official developer a massive favour.

Go to list of Best Practices

Go to top of page

Access Control Levels

'Access Control Levels' controls who can do and see what.

The default list includes:

Public
Registered
Special
Super Users

The above levels can be split down further into sub-levels:

Manager
Administrator
Author
Editor
Publisher

Custom Access Levels can be added if you wish.

People registered on your website are typically assigned to the 'Registered' level.

It is beyond the scope of this article to go into each level in depth, but to reiterate, the levels control who can see and do what on your website.

When considering an extension, the levels that it gives users needs to be considered.

Does an extension give higher-level access to users who are in a level with lower priveleges or rights ?

For example, does the extension allow Guests or Registered level users to change, view, or access data that only Administrators should be able to change, view, or access ? - If 'Yes' then this could leave you open to consequences not planned on or desired.

Go to list of Best Practices

Go to top of page

Installing And Updating Extensions - 'When' and 'How'

It is beyond the scope of this article to explain 'how to install or update an extension' in terms of the Joomla process sequence.

This section is, essentially, along the same lines as 'Backing up' your website which we covered earlier in this article.

The same concept applies to installing, setting-up and updating extensions

What we want you to consider is:

'When' in terms of time of day / night and what day(s) of the week you carry out these tasks
'How' in terms of whether your website is 'on-line' or 'off-line' when installing, setting-up and updating an extension (component, plugin or module etc.)

Do you really want to update an extension for your shopping system when people are buying things ? Or updating your shopping cart while people are checking-out and paying you ? This could could give you corrupt data and un-processed or partially processed sales / payments.

Do you really want to update your Forum while people are posting topics and replies ? This could give you corrupt forum posts.

Do you really want to update your 'Contact' form while people are writing a message to send you ? This could corrupt the message content and / or prevent sending of messages.

Do you really want to update your 'Registration' form while people are registering on your website ? This could give you corrupt registrations.

You might want to consider installing, setting-up and updating extensions while your website is in 'Maintenance Mode' (remember seeing the 'Under Maintenance - please come back later" page ?). After all - is 'Maintenance' what you are doing here ?

As well as doing the above in 'Maintenance Mode' - you might want to consider having less impact in your business and of course your visitors by disrupting sales, registrations, and forum postings by carrying out the installation, setting-up and updating outside of times when the bulk of those tasks occur.

Go to list of Best Practices

Go to top of page

Remember

In this article, and indeed throughout UsingJoomla.com we write about user(s).

Mostly we refer to user(s) as human(s) - they visit your and our website.

But - there is another 'user' - this is the Database user. This is not a human. You have a Database, Database user (and Database password for that 'User') which perhaps you can see as Joomla itself. Joomla, as a user, uses your website Database to read and write data and to execute the various components, plugins, and extensions.

Go to list of Best Practices

Go to top of page