Applying custom module chrome

2019-10-19T05:44:50Z

Donmcg: removed exclamation mark, falsely indicating end of a sentence.

<includeonly>==Applying custom Module chrome==</includeonly>
To define custom Module chrome in your template you need to create a file called modules.php in your template html directory. For example, this might be PATH_TO_JOOMLA/templates/TEMPLATE_NAME/html/modules.php.

In this file you should define a function called <code>modChrome_STYLE</code> where '<code>STYLE</code>' is the name of your custom Module chrome. This function will take three arguments, <code>$module</code>, <code>&$params</code>, and <code>&$attribs</code>, as shown:

<source lang="php">
<?php
function modChrome_STYLE( $module, &$params, &$attribs )
{
/* chromed Module output goes here */
}
?>
</source>

Within this function you can make use of any of the available Module properties (i.e. the fields in the <code>jos_modules</code> table in the Joomla database on your server) for that Module, but the main ones you are likely to need are <code>$module->content</code>, <code>$module->showtitle</code> and <code>$module->title</code>. <code>$module->showtitle</code> is a Boolean variable, so is either ''true'' (when the Module title '''should''' be shown) or ''false'' (when it '''shouldn't''' be shown). <code>$module->content</code> and <code>$module->title</code> will return the main Module content and the Module title respectively.

The function is a normal PHP function and so can use any regular PHP code. One common example is to use an <code>if</code> statement to check the value of <code>$module->showtitle</code>, and then include the title or not accordingly:

<source lang="php">
<?php
if ($module->showtitle)
{
echo '<h2>' .$module->title .'</h2>';
}
?>
</source>

The Module parameters are accessed using the <code>$params</code> object. For example, it is possible to assign a ''Module class suffix'' to a Module in the backend of your Joomla! site; this is then stored in the parameters for that Module as <code>moduleclass_sfx</code>. To create a <code><div></code> with a <code>class</code> determined by the Module class suffix, you would use:

<source lang="php">
<div class="<?php echo $params->get( 'moduleclass_sfx' ); ?>">

</div>
</source>

=== Custom chrome attributes ===
It is also possible to pass further attributes into the Module chrome function using the same <code><jdoc:include /></code> statement that sets the Module chrome. These additional attributes can be anything you like, and are stored in the <code>$attribs</code> array. Take the following example Module chrome function:

<source lang="php">
<?php
function modChrome_custom( $module, &$params, &$attribs ) {
if (isset( $attribs['headerLevel'] ))
{
$headerLevel = $attribs['headerLevel'];
} else {
$headerLevel = 3;
}

if (isset( $attribs['background'] ))
{
$background = $attribs['background'];
} else {
$background = 'blue';
}

echo '<div class="' .$params->get( 'moduleclass_sfx' ) .'" >';

if ($module->showtitle)
{
echo '<h' .$headerLevel .'>' .$module->title .'</h' .$headerLevel .'>';
}

echo '<div class="' .$background .'">';
echo $module->content;
echo '</div>';

echo '</div>';
}
?>
</source>

You would then set the values for <code>background</code> and <code>headerLevel</code> in the <code><jdoc:include /></code> statement as shown below. If no values are set, the attributes default to 'blue' and '3' respectively.

{| class="wikitable"
|+ Passing attributes to Module chrome from <code><jdoc:include /></code>
! <code><jdoc:include /></code> statement
! Output
|-
|
<code><jdoc:include type="modules" name="user1" style="custom" /></code>
|
<source lang="html4strict">
<div>
<h3></h3>

<div class="blue">

</div>
</div>
</source>
|-
|
<code><jdoc:include type="modules" name="user1" style="custom" background="green" /></code>
|
<source lang="html4strict">
<div>
<h3></h3>

<div class="green">

</div>
</div>
</source>
|-
|
<code><jdoc:include type="modules" name="user1" style="custom" headerLevel="1" background="yellow" /></code>
|
<source lang="html4strict">
<div>
<h1></h1>

<div class="yellow">

</div>
</div>
</source>
|}
Further information about passing attributes to Module chrome can be found in [[jtopic:115953]].
<noinclude>
[[Category:Advanced]]
[[Category:Modules]]
[[Category:Template Development]]
[[Category:Template Reference]]
</noinclude>

Security Checklist/Hosting and Server Setup

2019-10-19T03:19:26Z

Donmcg: Grammar improvement on first sentence.

<noinclude><languages /></noinclude>
{{:Security Checklist/TOC}}
<translate>
== Choose a Qualified Hosting Provider == 
</translate>

<translate>
===The most important decision=== 
</translate>
: <translate> Probably no decision is more critical to site security than the choice of hosts and servers. However, due to the wide variety of hosting options and configurations, it's not possible to provide a complete list for all situations. Check this [https://resources.joomla.org/en/category/hosting-providers list of hosts] who meet the security requirements of a typical Joomla site. ([[S:MyLanguage/Security_and_Performance_FAQs#How_do_I_choose_a_quality_hosting_provider.3F|FAQ]])</translate>
<translate>
===Shared server risks=== 
</translate>
: <translate> If you are on a tight budget and your site does not process highly confidential data, you can probably get by with a shared server, but you must understand the unavoidable risks. Most of the tips listed below are appropriate for securing sites on shared server environments.</translate>
<translate>
==Configuring Apache== 
</translate>
<translate>
===Use Apache .htaccess=== 
</translate>
''<translate> See also [[S:MyLanguage/htaccess examples (security)|.htaccess examples]]</translate>''
: <translate> Block typical exploit attempts with local Apache ''.htaccess'' files. This option is not enabled on all servers. Check with your host if you run into problems. Using ''.htaccess'', you can password protect sensitive directories, such as administrator, restrict access to sensitive directories by IP Address, and depending on your server's configuration, you may be able to increase security by switching to PHP7.</translate>

: <translate> Joomla ships with a [[S:MyLanguage/Preconfigured htaccess|preconfigured .htaccess]] file, but *you* need to choose to use it. The file is called htaccess.txt. To use it, rename it to .htaccess and place it in the root of your site using FTP. One important point to note is that as the distributed file is called htaccess.txt and the live file on your site is called .htaccess, the file your site actually uses is NOT updated when you update your site to use to a new version of Joomla. You must manually make the changes to use the new file version.</translate>

: <translate> Consider following the "Least Privilege" principle for running PHP using tools such as PHPsuExec, php_suexec or suPHP. (Note: These are advanced methods that require agreement and coordination with your hosting provider. Such options are enabled or disabled on a server-wide basis and are not individually adjustable on shared servers.)</translate>

: <translate> Consider using a serverside filtering solution like Apache mod_security - a great starting point is the OWASP ModSecurity</translate> [https://coreruleset.org/ CoreRuleSet]

<translate>
===PHP Being Run as an Apache Module=== 
</translate>

<translate> This causes ownership issues and thus permission problems which will lead to security issues. It is better to select a server setup/host that runs php as a cgi process (such as cgi-fcgi) along with using phpSuExec or a similar configuration.</translate>

<translate> The two best tutorials and explanations on permissions, ownerships and their relations are from this official Joomla doc page:</translate>
*[[S:MyLanguage/Where can you learn more about file permissions?|<translate> File Permissions</translate>]]
*<translate> [[S:MyLanguage/Why_can't_you_install_any_extensions%3F#File_ownership_advice_from_ianmac|File ownership advice]]</translate>

<translate> Specific topics to read would be the following two:</translate>
*[[S:MyLanguage/How do UNIX file permissions work?|<translate> Unix Permissions Primer</translate>]]
<translate> And for information on phpSuExec and similar implementations:</translate>
*[[S:MyLanguage/Using phpSuExec|<translate> Using phpSuExec</translate>]]
<translate>
===Use Apache mod_security=== 
</translate>
: <translate> Configure Apache mod_security and mod_rewrite filters to block PHP attacks. See [https://www.google.com/search?q=apache%20mod_security Google search for mod_security] and [https://www.google.com/search?q=apache%20mod_rewrite Google search for mod_rewrite]. (Note: These are advanced methods that usually require agreement and coordination with your hosting provider. Such options are enabled or disabled on a server-wide basis and are not individually adjustable on shared servers.)</translate>
<translate>
==Configuring MySQL== 
</translate>
<translate>
===Secure the database=== 
</translate>
: <translate> Be sure MySQL accounts are set with limited access. The initial install of MySQL is insecure and careful configuration is required. (See the [http://dev.mysql.com/doc/ MySQL Manuals]) Note: This item applies only to those administering their own servers, such as dedicated servers. Users of shared servers are dependent on their hosting provider to set proper database security.)</translate>
<translate>
== Configuring PHP== 
</translate>
<translate>
===Understand how PHP works=== 
</translate>
: <translate> Understand how to work with the php.ini file, and how PHP configurations are controlled. Study the [http://us3.php.net/manual/en/ini.php#ini.list Official List of php.ini Directives] at http://www.php.net, and the well-documented default php.ini file included with every PHP install.</translate>
<translate>
===Use PHP7=== 
</translate>
<translate> PHP versions become deprecated and some have become obsolete. Some hosting providers still have several available on servers to support outdated scripts. Joomla should be using PHP7.x. (See [https://downloads.joomla.org/technical-requirements Joomla Requirements])</translate>
<translate>

===Use local php.ini files=== 
</translate>
: <translate> On shared servers you can't edit the main php.ini file, but you may be able to add custom, local php.ini files. If so, you'll need to copy the php.ini files to every sub-directory that requires custom settings.</translate>

: '''<translate> There are a few important things to keep in mind.</translate>'''

# <translate> Local ''php.ini'' files '''''only''''' have an effect if your server is configured to use them. This includes a ''php.ini'' file in your ''http_root'' directory. You can test whether or not these file affect your site by setting an obvious directive in the local ''php.ini'' file to see if it affects your site.</translate>
# <translate> Local ''php.ini'' files only affect ''.php'' files that are located within the same directory (or included() or required() from those files). This means that there are normally only two Joomla! directories in which you would want to place a ''php.ini'' file. They are your ''http_root''(your actual directory name may vary), which is where Joomla's Front-end ''index.php'' file is located, and the Joomla! ''administrator'' directory, which is where the backend administrator ''index.php'' file is located. Other directories that don't have files called via the Web do not need local ''php.ini'' files.</translate>
# <translate> If you have a ''php.ini'' file in every directory, some script probably did this for you. If you didn't intend it to happen, you probably should root them out, but given #2 above, you probably only have to panic about the ''php.ini'' files in ''http_root'' and the ''administrator'' directories.</translate>
<translate>
===Use PHP disable_functions=== 
</translate>
: <translate> Use ''disable_functions'' to disable dangerous PHP functions that are not needed by your site. Here is a typical setup for a Joomla! site:</translate>

disable_functions = show_source, system, shell_exec, passthru, exec, phpinfo, popen, proc_open
<translate>
===Consider Using PHP open_basedir=== 
</translate>
: <translate> You ''might'' consider enabling ''open_basedir''. This directive limits the files that can be opened by PHP to the specified directory-tree. This directive is NOT affected by whether Safe Mode is ON or OFF.</translate>

: <translate> The restriction specified with open_basedir is a prefix, not a directory name. This means that ''open_basedir = /dir/incl'' allows access to ''/dir/include'' and ''/dir/incls'' if they exist. To restrict access to only the specified directory, end with a slash. For more information, see [http://us3.php.net/manual/en/features.safe-mode.php#ini.safe-mode PHP Security and Safe Mode Configuration Directives].</translate>

open_basedir = /home/users/you/public_html

: <translate> Additionally, if ''open_basedir'' is set it may be necessary to set PHP ''upload_tmp_dir'' configuration directive to a path that falls within the scope of ''open_basedir'' or, alternatively, add the ''upload_tmp_dir'' path to ''open_basedir'' using the appropriate path separator for the host system.</translate>

open_basedir = /home/users/you/public_html:/tmp

: <translate> PHP will use the system's temporary directory when ''upload_tmp_dir'' is not set or when it is set but the directory does not exist, therefore it may be necessary to add it to ''open_basedir'' as above to avoid uploading errors within Joomla.</translate>

<translate>
===Adjust magic_quotes_gpc=== 
</translate>
: ''' <small>''<translate> This PHP feature has been depreciated as of PHP 5.3.0 (30-06-2009) and has been removed from php as of PHP 5.4.0.</translate>''</small>'''

: <translate> Adjust the ''magic_quotes_gpc'' directive as needed for your site.</translate>
*<translate> Joomla! 3.0 and above '''requires''' ''magic_quotes_gpc'' to be set to off and will not install if ''magic_quotes_gpc'' is on.</translate>
*<translate> Joomla! advises ''magic_quotes_gpc'' to be set to off when using Joomla 2.5.xx.</translate>
*<translate> Joomla! 1.5 ignores the magic_quotes setting and works fine either way. The safest method is to turn magic_quotes_gpc off and avoid all poorly-written extensions.</translate>
*<translate> The recommended settings for Joomla! 1.0.x is ON to protect against poorly-written third-party extensions.</translate>

: <translate> For more information, see either [[S:MyLanguage/Magic quotes and security|Magic quotes and security]] or [http://php.net/magic_quotes PHP Manual, Chapter 31. Magic Quotes].</translate>

to turn off magic_quotes_gpc = 0
to turn on magic_quotes_gpc = 1

<translate>
===Don't use PHP safe_mode=== 
</translate>
: ''' <small>''<translate> This PHP feature has been DEPRECATED as of PHP 5.3.0 and REMOVED as of PHP 5.4.0</translate>''</small>'''

: <translate> Relying on this feature is highly discouraged. Avoid the use of PHP safe_mode. This was an attempt to solve shared security problems and provides a false sense of security. Safe mode can also cause ownership problems with applications and any files created by the applications. See the official PHP site for more information. [http://php.net/manual/en/features.safe-mode.php PHP Manual: Safe Mode]</translate>

safe_mode = 0
<translate>
===Don't use PHP register_globals=== 
</translate>
: ''' <small>''<translate> This PHP feature has been DEPRECATED as of PHP 5.3.0 and REMOVED as of PHP 5.4.0</translate>''</small>'''

: <translate> Automatically registering global variables was probably one of the dumbest decisions the developers of PHP made. This directive determines whether or not to register the EGPCS (Environment, GET, POST, Cookie, Server) variables as global variables where they become immediately available to all PHP scripts, and where they can easily overwrite your own variable if you're not careful. Luckily, the PHP developers long since realized the mistake and have deprecated this 'feature'.</translate>

: <translate> If your site is on a shared server with a hosting provider that insists ''register_globals'' must be on, you should be very worried. Although you can often turn register_globals off for your own site with a local php.ini file, this adds little security as other sites on the same server remain vulnerable to attacks which can then launch attacks against your site from within the server.</translate>

: <translate> For more information, see [http://php.net/manual/en/security.globals.php PHP Manual: Using Register Globals].</translate>

register_globals = 0

<translate>
===Don't use PHP allow_url_include=== 
</translate>

: <translate> Do not use PHP ''allow_url_include''. This PHP option allows a programmer to include a remote file using an URL rather than a local file path. This is insecure. If an application (or extension) can be tricked into including content from a URL outside itself, an attacker could force the application (or extension) to start running code from their own web site. If an application or extension claims to require this feature to function, you should look into alternatives, as a requirement to use of this feature indicates serious design flaws within the application or extension.</translate>

<translate>
=== Use allow_url_fopen === 
</translate>
: <translate> This option enables the URL-aware fopen wrappers that enable accessing URL object like files. Default wrappers are provided for the access of remote files using the ftp or http protocol, some extensions like zlib may register additional wrappers. Note: This can only be set in php.ini due to security reasons. '''Enable and use allow_url_fopen to allow Joomla's One-Click-Update to work properly.'''</translate>

: <translate> For more information see: [http://www.php.net/manual/en/filesystem.configuration.php#ini.allow-url-fopen PHP Manual: allow_url_fopen and allow_url_include]</translate>

Proper setup will have this:
allow_url_fopen = 1
allow_url_include = 0

PHP default: allow_url_fopen is enabled
PHP default: allow_url_include is disabled

<translate>
== File permissions == 
</translate>
: <translate> If a Joomla installation is hosted on Apache with mod_php, then all virtual hosts on that server run in the same context as your joomla code. If the files are owned by some other user than 'nobody' or 'wwwrun', the safest permissions are those which '''prevent''' changes to the joomla code, unless via an authorised channel (e.g. FTP:</translate>
*<translate> DocumentRoot directory: 750 (e.g. public_html)</translate>
*<translate> Files: 644</translate>
*<translate> Directories: 755 (711 if you are paranoid, but not for directories which need to be listed) (owner: some user)</translate>

: <translate> With these permissions set, you will need to use FTP to update your Joomla installation. Not all modules support this. Remove modules which do not support FTP upgrades</translate>.

: <translate> Other processes running under mod_php can read '''your''' configuration.php. You can frustrate automated hacks by renaming this file. You should not store your FTP password in your configuration file on such hosts, as your account ''will'' be compromised.</translate>

: <translate> If a Joomla installation is hosted on Apache with fast-cgi, suphp or cgi that runs as a different user, then you should set your permissions as follows:</translate>
* <translate> DocumentRoot directory: 750 (e.g. public_html)</translate>
* <translate> PHP files: 600 (400 if you are truly paranoid)</translate>
* <translate> HTML and image files: 644 (444 if you are truly paranoid)</translate>
* <translate> Directories: 755 (711 if you are paranoid, but not for directories which need to be listed)</translate>

: <translate> '''If''' the server your are on requires 777 permissions for Joomla to work correctly, then '''request to be put on another server''' with php as cgi and suphp and up-to-date serverside software (apache, php etc) on your existing host or find another server host if necessary.</translate>

: <translate> Do check with your hosting provider to see if they have purposely secured the server your site is on; and that they or you perform regular (weekly) security updates to keep the server up to date. Check you have jail shell. A rule of thumb is the less you pay, the less they care.</translate>

: <translate> More information on file permissions can be found here: [[S:MyLanguage/Security Checklist/Where can you learn more about file permissions?|File permissions]]</translate>

<translate>
==Setup a backup and recovery process== 
</translate>
<translate>
===The most important rule=== 
</translate>
: <translate> You should at all time be able to return your site to a previous working state through regular use of a strong, off-site backup and recovery process. Be sure your backup and recovery process is in place and tested BEFORE you go live. This is the single best way (and often the only way) to recover from such inevitable catastrophes as:</translate>

#<translate> Broken site due to a faulty upgrade.</translate>
#<translate> Hardware failure, such as dead hard drives, power failures, server theft, etc.</translate>
#<translate> Authoritarian government intervention. (More common than some think.)</translate>
#Ne<translate> eding to quickly relocate to a new server or hosting provider.</translate>

: <translate> Backups are not recommended for restoring a compromised/hacked site as it is possible the backups will contain the altered and hack files. Using the backups to restore a hacked site would just restore the hack to the site.</translate>

<noinclude>
[[Category:Security Checklist{{#translation:}}]]
[[Category:Server configurations{{#translation:}}]]
</noinclude>

Joomla! Documentation - User contributions [en]

Applying custom module chrome

Security Checklist/Hosting and Server Setup