Actions

Talk

Glossary

From Joomla! Documentation

Revision as of 15:20, 24 February 2014 by Tom Hutchison (Talk | contribs)

Notes on how to write a Glossary entry

Create a page for the term (in its singular form if relevant), but instead of entering the text directly include the term as a documentation chunk. Add the page to the Glossary category and if required (which is the norm) add it to the Landing Pages category too. For example, for the term "extension", create a page called "Extension" (the first letter is automatically capitalised so don't worry about that). In the page enter the following text:

{{Chunk:Extension}}
<noinclude>[[Category:Landing Pages]][[Category:Glossary]]</noinclude>

Save the page, then click on the "Chunk:Extension" link that you will see. Enter your glossary explanation there. At the end of the page, add the following text to make it appear in the Glossary. Make sure there is nothing (not even a newline) between the last character of your text and the following.

<noinclude>[[Category:Glossary definitions|{{PAGENAME}}]]</noinclude>

If the term has a commonly used plural form then you should add a redirect to the singular form. To do this create a page for the plural form and add a #REDIRECT statement to it. If required (which is the norm) add it to the Landing Pages category too. Do not add it to the Glossary category. For example, to add the term "extensions" which will redirect to "extension", create a page called "Extensions" and enter the following text:

#REDIRECT [[Extension]]
[[Category:Landing Pages]]

Updating The Glossary

I've marked this page as needs review as

  1. I feel that having Mambots on the list of extensions is plain unhelpful.
  2. I feel there is no need to have Joomla 1.5 references on this list anymore (references to Legacy mode, Sections etc.)
  3. The upgrade package section needs to be updated ironically to mention the Joomla Updated that shipped in 1.7

Before I make this changes how do people feel about removing anything that isn't still relevant from Joomla 1.5 and earlier

Translation Hints

Suggested markup for translations

Will have to work this out, but it does work and will use the /en coding for English pages once they are all marked for translation.

Contents

!

|

[view] [edit] [history]

Template-info.pngArticle documentation
Template:Glossary/doc

!!/doc

This is an auxiliary template allowing to encode "||" within template and parser function parameters. To get both symbols in final output this template is unnecessary, better use "&#124;&#124;" which is rendered the same. Use this template in parameter values of templates and parser functions of which the result is used in table syntax, since this requires the "real" pipe character.

This template cannot be used for putting thes characters as text in a wiki table; in that case, again, "&#124;&#124;" can be used.

Note that the table syntax code "!" (exclamation mark) can be used directly in parameter values, so for that a template like this is not needed.

See also


!-/doc

This is an auxiliary template allowing to encode "|-" within template and parser function parameters. To get these symbols in final output this template is unnecessary, better use "&#124;-" which is rendered the same. Use this template in parameter values of templates and parser functions of which the result is used in table syntax, since this requires the "real" pipe character.

This template cannot be used for putting these characters as text in a wiki table; in that case, again, "&#124;-" can be used.

See also


!/doc

This is an auxiliary template allowing to encode "|" within template and parser function parameters. To get the symbol in final output this template is unnecessary, better use "&#124;" which is rendered the same. Use this template in parameter values of templates and parser functions of which the result is used in table syntax, since this requires the "real" pipe character. The same applies when a parameter is used literally for an internal link and you want to set a label.

This template cannot be used for putting the character as text in a wiki table; in that case, again, "&#124;" can be used.

Note that the table syntax code "!" (exclamation mark) can be used directly in parameter values, as it's only special at the beginning of a line, so for that a template like this is not needed.

See also


"Save as New" and "Save as Copy" removed from article manager after 3.3.4 Upgrade

After upgrading from Joomla v3.3.3 to v3.3.4 The "Save as Copy" and "Save as New" buttons are no longer available when editing an article. I used a backup to revert back to v3.3.3 and all is well.

Errors reported

N/A

Versions affected

Info non-talk.png
General Information

This pertains only to Joomla! version(s):-   

3.3.4

What is the cause

How to fix

-

template:- (edittalklinkshistory) "clears" both margins; it is often used before a header to make sure that header will be the full width of the page.

/doc

Stop!

If you are viewing this page, you may not be aware of the Joomla! Documentation template documentation pattern. Template documentation subpage should be prefixed by the name of the template. Create the glossary for your template on page: Template:TemplateNameGlossary.

Examples:

bad good
Template:/doc Template:Tl/doc
Template:/doc Template:Non-free media/doc
Template:/doc Template:ArticleHistory/doc

Thank you.

01 template-manager styles.png

02 template-manager editing-styles.png

03 menu-manager edit-menu-item.png

1

[view] [edit] [history]

Template-info.pngArticle documentation
Template:Glossary/doc

1-Extensions-ExtensionManager.png

{{:Translations:1.6.4 Installer Deleted My Files/Page_display_title/<lang code>‎}}

For a small number of implementations, the PHP timeout and hosting conditions are such that the Upgrade Process runs out of time before the Installer has had time to finish. In those cases, the upgrade fails and the site is not properly updated and files are missing. In some cases, nearly all files might be missing. Depending on how far the Upgrade process got, the errors you might experience could vary. Generally speaking, you will see some kind of message about missing files.

Although this is a very concerning problem to have, it can be easily fixed. Simply take a full install package for the release, unzip it, DELETE the installation folder, and copy ALL of the remaining files to your website, replacing the files already there. Doing so will fix the install and your website should work fine.

For the future: a work-around fix was applied to Joomla 1.6.4 to help resolve this problem by resetting the PHP time used to 0 during the unzip process and during the file copy process. This will help prevent time out situations and therefore avoid failed updates for the 1.7 upgrade (or 1.6.5, if that release comes first).

{{:Translations:1.6.4 security alert for layout override files/Page_display_title/<lang code>‎}}

In version 1.6.4 a security fix was made to a number of layout files, specifically those for category lists for articles, weblinks, newsfeeds and contacts and the featured contact list. If you are using layout overrides for these you should ensure that you make the same changes are made in your template (if the same issue is present). Overrides are found in the html folder of your template. You may also wish to check layout files for extensions for the same issue since the core layouts are sometimes used as models.

The change made is to replace JfilterOutput::ampReplace with htmlspecialchars. The following files should be changed:

  • components/com_contact/views/category/tmpl/default_items.php
  • components/com_contact/views/featured/tmpl/default_items.php
  • components/com_content/views/category/tmpl/default_articles.php
  • components/com_newsfeeds/views/category/tmpl/default_items.php
  • components/com_weblinks/views/category/tmpl/default_items.php

This change should also be made to the override found in the beez5 template

  • templates/beez5/com_content/category/default_articles.php

{{:Translations:1.6.4 security alert for layout override files/Page_display_title/<lang code>‎}}

Should this be JfilterOutput::ampReplace instead of JfilterOutput:ampReplace?

{{:Translations:1.7.0 Artisteer Template Errors/Page_display_title/<lang code>‎}}

There are reports for upgrades of sites using Artisteer Templates:

Fatal error: Cannot access protected property ContentViewArticle::$user in /home/xyz/public_html/templates/bpmusic_v1/functions.php on line 561

And others report this: Fatal error: Call to a member function getMessageQueue() on a non-object in /home1/xyz/public_html/templates/otd_white/functions.php on line 165

It is also reported that Artisteer plans to release a Joomla 1.7 compatibility release in the next few days.

http://www.artisteer.com/?post_id=170151&p=forum_post&forum_id=20


According to Artisteer Tech Support Artisteer 2.6 is not compatible with Joomla 1.7. Artisteer Tech Support suggests using Artisteer 3.0

This is the reason for the error: "Fatal error: Call to a member function getMessageQueue() on a non-object in /templates/ functions.php on line 165"

{{:Translations:1.7.0 Flash Upload broken/Page_display_title/<lang code>‎}}

The flash uploader is broken in 1.7.0 because the Flash file is outdated.

Solution: replace in media/system/swf/ with this file:

http://joomlacode.org/gf/download/trackeritem/26603/67164/uploader.swf

{{:Translations:1.7.0 Syndication module broken/Page_display_title/<lang code>‎}}

The Syndication module (mod_syndicate) is broken in 1.7.0.

To solve the issue, edit the file modules/mod_syndicate/helper.php, and replace its content by

<?php
/**
 * @version		$Id: helper.php 21913 2011-07-25 05:21:57Z infograf768 $
 * @package		Joomla.Site
 * @subpackage	mod_syndicate
 * @copyright	Copyright (C) 2005 - 2011 Open Source Matters, Inc. All rights reserved.
 * @license		GNU General Public License version 2 or later; see LICENSE.txt
 */
 
// no direct access
defined('_JEXEC') or die;
 
class modSyndicateHelper
{
	static function getLink(&$params)
	{
		$document = JFactory::getDocument();
 
		foreach($document->_links as $link => $value)
		{
			$value = JArrayHelper::toString($value);
			if (strpos($value, 'application/'.$params->get('format').'+xml')) {
				return $link;
			}
		}
 
	}
}

In trunk, was also updated the beez2 and 5 position.css to prevent display of a border for the livemarks.png image.

img { border: 0 none; }

{{:Translations:1.7.0 Update Collection Could Not Open http:/www.joomla.org/update/core/list.xml/Page_display_title/<lang code>‎}}

The Joomla Updater uses the php fopen command.

Those php configurations without fopen enabled will error with the following messages:

Update: :Collection: Could not update http://www.joomla.org/update/core/list.xml

Update: :Collection: Could not update http://www.joomla.org/update/jed/list.xml

You will not be able to use the Updater without enabling fopen for PHP. This is a web hosting issue.

{{:Translations:1.7.0 Warning: set time limit():/Page_display_title/<lang code>‎}}

During upgrade, some are getting errors like this:

Warning: set_time_limit(): Cannot set time limit in safe mode in /usr/sfw/apache2/http/hhh.hh.com/htdocs/libraries/joomla/filesystem/folder.php on line 548

or

Warning: set_time_limit() has been disabled for security reasons in /home/www/88f713b69e9666e8466e69535bceeda4/web/new/libraries/joomla/filesystem/folder.php on line 548

The first error is when safe mode is enabled on the server. Safe mode must be off as indicated on the first installer screen.

The second error is for hosting setttings which have disabled set_time_limit.

Joomla community member Mackelito offers a work around if your host cannot enable set_time_limit for you.

The change was made to prevent timeouts for some hosts which was causing the install to fail. A fix should be available in future releases to first see if the class is enabled before setting the value.

1.7.3.Featured Article Tool Bar.jpg

Licensing

Documentation all together tranparent small.png
Joomla Electronic Documentation License

This article is licensed under the Joomla! Electronic Documentation License. It grants you certain rights to use, modify and distribute documentation associated with the Joomla! project. It is designed to foster wide electronic distribution of Joomla! documentation while ensuring that any material added to the documentation by you or others can be taken up and made part of the authoritative documentation distributed by the Joomla! project.


1.7.3.Featured Block Filter.jpg

Licensing

Documentation all together tranparent small.png
Joomla Electronic Documentation License

This article is licensed under the Joomla! Electronic Documentation License. It grants you certain rights to use, modify and distribute documentation associated with the Joomla! project. It is designed to foster wide electronic distribution of Joomla! documentation while ensuring that any material added to the documentation by you or others can be taken up and made part of the authoritative documentation distributed by the Joomla! project.


1.7.3.Featured Filter.jpg

Licensing

Documentation all together tranparent small.png
Joomla Electronic Documentation License

This article is licensed under the Joomla! Electronic Documentation License. It grants you certain rights to use, modify and distribute documentation associated with the Joomla! project. It is designed to foster wide electronic distribution of Joomla! documentation while ensuring that any material added to the documentation by you or others can be taken up and made part of the authoritative documentation distributed by the Joomla! project.


1.jpg

1/doc

This template performs a single line feed but without the overhead 'code' of the {{I}}. This is much easier to subst, in particular.

Like {{I}} and other members of the indent family of templates it has some beneficial inheritance attributes within wikimarkup.

Actual code content:
<br />

This is a substable formating utility that duplicates the modified line wrapping behavior of {{I}}, but without the ability to indent.

It is thus far less costly of template pre-expansion and post expansion memory limits, making it more suitable for formatting in articles wherein a lot of templates are used pushing such limits. See: Wikipedia:Template:Indent_family_usage

10080-acl-manager-after-update-en.png

Licensing

Documentation all together tranparent small.png
Joomla Electronic Documentation License

This article is licensed under the Joomla! Electronic Documentation License. It grants you certain rights to use, modify and distribute documentation associated with the Joomla! project. It is designed to foster wide electronic distribution of Joomla! documentation while ensuring that any material added to the documentation by you or others can be taken up and made part of the authoritative documentation distributed by the Joomla! project.


16Events

See discussion on list here: http://groups.google.com/group/joomla-dev-general/browse_thread/thread/4c175ad64f051383/84b86ddb60b15295#84b86ddb60b15295

16breadcrumb-screenshot.png

Summary

Screenshot of the breadcrumb module from the front end in Joomla! 1.6 (default template used)

Licensing

GNU head Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.

16breadcrumbs-advancedoptions.png

Summary

Advanced options tab for the breadcrumbs module in Joomla! 1.6

Licensing

GNU head Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.

16breadcrumbs-basicoptions.png

Summary

screenshots of the basic options tab for the breadcrumbs module in Joomla! 1.6

Licensing

GNU head Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.

16custom htmlmod-basicparams.png

Summary

Screenshot of basic parameters fro the custom_html module in Joomla! 1.6

Licensing

GNU head Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.

1and1joomla10.png

Summary

Screen-shot showing HowTo get joomla working on the web-hosting service called 1and1 with kind permission from 1and1's customer services department. The original first appeared on the page http://faq.1and1.com/web_space__access/ftp_account/14.html

Licensing


Creative Commons License
Creative Commons Attribution iconCreative Commons Share Alike icon
This file is licensed under the Creative Commons Attribution ShareAlike 2.5 License

1and1joomla11.png

Summary

Screen-shot showing HowTo get joomla working on the web-hosting service called 1and1 with kind permission from 1and1's customer services department. The original first appeared on the page http://faq.1and1.com/web_space__access/ftp_account/14.html

Licensing


Creative Commons License
Creative Commons Attribution iconCreative Commons Share Alike icon
This file is licensed under the Creative Commons Attribution ShareAlike 2.5 License

1and1joomla12.png

Summary

Screen-shot showing HowTo get joomla working on the web-hosting service called 1and1 with kind permission from 1and1's customer services department. The original first appeared on the page http://faq.1and1.com/web_space__access/ftp_account/14.html

Licensing


Creative Commons License
Creative Commons Attribution iconCreative Commons Share Alike icon
This file is licensed under the Creative Commons Attribution ShareAlike 2.5 License

1and1joomla13.png

Summary

Screen-shot showing HowTo get joomla working on the web-hosting service called 1and1 with kind permission from 1and1's customer services department. The original first appeared on the page http://faq.1and1.com/web_space__access/ftp_account/14.html

Licensing


Creative Commons License
Creative Commons Attribution iconCreative Commons Share Alike icon
This file is licensed under the Creative Commons Attribution ShareAlike 2.5 License

1and1joomla14.png

Summary

Screen-shot showing HowTo get joomla working on the web-hosting service called 1and1 with kind permission from 1and1's customer services department. The original first appeared on the page http://faq.1and1.com/web_space__access/ftp_account/14.html

Licensing


Creative Commons License
Creative Commons Attribution iconCreative Commons Share Alike icon
This file is licensed under the Creative Commons Attribution ShareAlike 2.5 License

1and1joomla15.png

Summary

Screen-shot showing HowTo get joomla working on the web-hosting service called 1and1 with kind permission from 1and1's customer services department. The original first appeared on the page http://faq.1and1.com/web_space__access/ftp_account/14.html

Licensing


Creative Commons License
Creative Commons Attribution iconCreative Commons Share Alike icon
This file is licensed under the Creative Commons Attribution ShareAlike 2.5 License

1and1joomla2.png

Summary

Screen-shot showing HowTo get joomla working on the web-hosting service called 1and1 with kind permission from 1and1's customer services department. The original first appeared on the page http://faq.1and1.com/web_space__access/ftp_account/14.html

Licensing


Creative Commons License
Creative Commons Attribution iconCreative Commons Share Alike icon
This file is licensed under the Creative Commons Attribution ShareAlike 2.5 License

1and1joomla3.png

Screen-shot showing HowTo get joomla working on the web-hosting service called 1and1 with kind permission from 1and1's customer services department. The original first appeared on the page http://faq.1and1.com/web_space__access/ftp_account/14.html

1and1joomla4.png

Summary

Screen-shot showing HowTo get joomla working on the web-hosting service called 1and1 with kind permission from 1and1's customer services department. The original first appeared on the page http://faq.1and1.com/web_space__access/ftp_account/14.html

Licensing


Creative Commons License
Creative Commons Attribution iconCreative Commons Share Alike icon
This file is licensed under the Creative Commons Attribution ShareAlike 2.5 License

1and1joomla5.png

Summary

Screen-shot showing HowTo get joomla working on the web-hosting service called 1and1 with kind permission from 1and1's customer services department. The original first appeared on the page http://faq.1and1.com/web_space__access/ftp_account/14.html

Licensing


Creative Commons License
Creative Commons Attribution iconCreative Commons Share Alike icon
This file is licensed under the Creative Commons Attribution ShareAlike 2.5 License

1and1joomla6.png

Summary

Screen-shot showing HowTo get joomla working on the web-hosting service called 1and1 with kind permission from 1and1's customer services department. The original first appeared on the page http://faq.1and1.com/web_space__access/ftp_account/14.html

Licensing


Creative Commons License
Creative Commons Attribution iconCreative Commons Share Alike icon
This file is licensed under the Creative Commons Attribution ShareAlike 2.5 License

1and1joomla7.png

Summary

Screen-shot showing HowTo get joomla working on the web-hosting service called 1and1 with kind permission from 1and1's customer services department. The original first appeared on the page http://faq.1and1.com/web_space__access/ftp_account/14.html

Licensing


Creative Commons License
Creative Commons Attribution iconCreative Commons Share Alike icon
This file is licensed under the Creative Commons Attribution ShareAlike 2.5 License

1and1joomla8.png

Summary

Screen-shot showing HowTo get joomla working on the web-hosting service called 1and1 with kind permission from 1and1's customer services department. The original first appeared on the page http://faq.1and1.com/web_space__access/ftp_account/14.html

Licensing


Creative Commons License
Creative Commons Attribution iconCreative Commons Share Alike icon
This file is licensed under the Creative Commons Attribution ShareAlike 2.5 License

1and1joomla9.png

Summary

Screen-shot showing HowTo get joomla working on the web-hosting service called 1and1 with kind permission from 1and1's customer services department. The original first appeared on the page http://faq.1and1.com/web_space__access/ftp_account/14.html

Licensing


Creative Commons License
Creative Commons Attribution iconCreative Commons Share Alike icon
This file is licensed under the Creative Commons Attribution ShareAlike 2.5 License

2

[view] [edit] [history]

Template-info.pngArticle documentation
Template:Glossary/doc

2-Extension-Update.png

{{:Translations:2.5.1 User Notes System/Page_display_title/<lang code>‎}}


Joomla Version 2.5.1 User Note System

This new service allows you to create a one to many relationship with notes about each user in your site.

Each user of your site can have notes created and related to the user table.

Accessing the user manager will give you access to this system.

To access the notes feature look for the document icon next to the user name in the user manager user list or access the system from the sub menu after accessing the user manager menu.

This system also has the standard catagory system like articles to allow you to define unlimited categories to organize your notes under.

The user permission system is also working for this system.

The hover tool tips explain what each box could be used for.

This system is only accessible from the administrator side of Joomla at the current time.

3rd party form tool systems can access the tables and display the notes on the front end if that is desired.

2/doc

This template performs what once known as a double-space, in actual fact a double line feed (2x newlines). This is much easier to subst, in particular.

Like {{I2}} and other members of the indent family of templates it has some beneficial inheritance attributes within wikimarkup.

Actual code content:
<br /><br />

This is a substable formating utility that duplicates the modified line wrapping behavior of {{I2}}, but without the ability to indent.

It is thus far less costly of template pre-expansion and post expansion memory limits, making it more suitable for formatting in articles wherein a lot of templates are used pushing such limits. See: Wikipedia:Template:Indent_family_usage

2010soclogo.jpg

Google Summer of Code 2010 official logo.

219jondn

Jon Neubauer

What I Do in Joomla!

Joomla! World Conference Director
Joomla! Bug Squad Contributor
Joomla! Community Magazine Contributor/Editor
Joomla! Forum Moderator

How You Can Reach Me

E-mail Me! jon.neubauer@community.joomla.org
Twitter: @219jondn

25-Installing-template-install-success.png

Summary

Screenshot

Licensing

Documentation all together tranparent small.png
Joomla Electronic Documentation License

This article is licensed under the Joomla! Electronic Documentation License. It grants you certain rights to use, modify and distribute documentation associated with the Joomla! project. It is designed to foster wide electronic distribution of Joomla! documentation while ensuring that any material added to the documentation by you or others can be taken up and made part of the authoritative documentation distributed by the Joomla! project.


25-Installing-template-navigate.png

Summary

Screenshot

Licensing

Documentation all together tranparent small.png
Joomla Electronic Documentation License

This article is licensed under the Joomla! Electronic Documentation License. It grants you certain rights to use, modify and distribute documentation associated with the Joomla! project. It is designed to foster wide electronic distribution of Joomla! documentation while ensuring that any material added to the documentation by you or others can be taken up and made part of the authoritative documentation distributed by the Joomla! project.


25-Installing-template-upload-package-file.png

Summary

Screenshot

Licensing

Documentation all together tranparent small.png
Joomla Electronic Documentation License

This article is licensed under the Joomla! Electronic Documentation License. It grants you certain rights to use, modify and distribute documentation associated with the Joomla! project. It is designed to foster wide electronic distribution of Joomla! documentation while ensuring that any material added to the documentation by you or others can be taken up and made part of the authoritative documentation distributed by the Joomla! project.


25-Switching-templates-1.png

Summary

Screenshot originally uploaded by User:Wilsonge

Licensing

Documentation all together tranparent small.png
Joomla Electronic Documentation License

This article is licensed under the Joomla! Electronic Documentation License. It grants you certain rights to use, modify and distribute documentation associated with the Joomla! project. It is designed to foster wide electronic distribution of Joomla! documentation while ensuring that any material added to the documentation by you or others can be taken up and made part of the authoritative documentation distributed by the Joomla! project.


25-Switching-templates-assign-menus.png

Summary

Screenshot

Licensing

Documentation all together tranparent small.png
Joomla Electronic Documentation License

This article is licensed under the Joomla! Electronic Documentation License. It grants you certain rights to use, modify and distribute documentation associated with the Joomla! project. It is designed to foster wide electronic distribution of Joomla! documentation while ensuring that any material added to the documentation by you or others can be taken up and made part of the authoritative documentation distributed by the Joomla! project.


25-Template manager access.png

Summary

Screenshot, originally uploaded by User:Wilsonge

Licensing

Documentation all together tranparent small.png
Joomla Electronic Documentation License

This article is licensed under the Joomla! Electronic Documentation License. It grants you certain rights to use, modify and distribute documentation associated with the Joomla! project. It is designed to foster wide electronic distribution of Joomla! documentation while ensuring that any material added to the documentation by you or others can be taken up and made part of the authoritative documentation distributed by the Joomla! project.


25-article-edit-header.png

Summary

article header information for Joomla! 2.5

Licensing

GNU head Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.

25custom htmlmod-basicparams.png

Licensing

Documentation all together tranparent small.png
Joomla Electronic Documentation License

This article is licensed under the Joomla! Electronic Documentation License. It grants you certain rights to use, modify and distribute documentation associated with the Joomla! project. It is designed to foster wide electronic distribution of Joomla! documentation while ensuring that any material added to the documentation by you or others can be taken up and made part of the authoritative documentation distributed by the Joomla! project.


3-Extension-Manager-Update.png

30-Import content from template.png

Summary

Screenshot

Licensing

Documentation all together tranparent small.png
Joomla Electronic Documentation License

This article is licensed under the Joomla! Electronic Documentation License. It grants you certain rights to use, modify and distribute documentation associated with the Joomla! project. It is designed to foster wide electronic distribution of Joomla! documentation while ensuring that any material added to the documentation by you or others can be taken up and made part of the authoritative documentation distributed by the Joomla! project.


30-Installing-template-install-success-es.png

Summary

Mensaje de instalación de plantilla exitosa.

Licensing

Documentation all together tranparent small.png
Joomla Electronic Documentation License

This article is licensed under the Joomla! Electronic Documentation License. It grants you certain rights to use, modify and distribute documentation associated with the Joomla! project. It is designed to foster wide electronic distribution of Joomla! documentation while ensuring that any material added to the documentation by you or others can be taken up and made part of the authoritative documentation distributed by the Joomla! project.


30-Installing-template-install-success-fr.png

Licensing

Documentation all together tranparent small.png
Joomla Electronic Documentation License

This article is licensed under the Joomla! Electronic Documentation License. It grants you certain rights to use, modify and distribute documentation associated with the Joomla! project. It is designed to foster wide electronic distribution of Joomla! documentation while ensuring that any material added to the documentation by you or others can be taken up and made part of the authoritative documentation distributed by the Joomla! project.


30-Installing-template-install-success-nl.png

30-Installing-template-install-success.png

Summary

Screenshot

Licensing

Documentation all together tranparent small.png
Joomla Electronic Documentation License

This article is licensed under the Joomla! Electronic Documentation License. It grants you certain rights to use, modify and distribute documentation associated with the Joomla! project. It is designed to foster wide electronic distribution of Joomla! documentation while ensuring that any material added to the documentation by you or others can be taken up and made part of the authoritative documentation distributed by the Joomla! project.


30-Installing-template-navigate-es.png

Summary

Acceso al gestor de plantillas desde el menú superior del backend.

Licensing

Documentation all together tranparent small.png
Joomla Electronic Documentation License

This article is licensed under the Joomla! Electronic Documentation License. It grants you certain rights to use, modify and distribute documentation associated with the Joomla! project. It is designed to foster wide electronic distribution of Joomla! documentation while ensuring that any material added to the documentation by you or others can be taken up and made part of the authoritative documentation distributed by the Joomla! project.


30-Installing-template-navigate-fr.png

Licensing

Documentation all together tranparent small.png
Joomla Electronic Documentation License

This article is licensed under the Joomla! Electronic Documentation License. It grants you certain rights to use, modify and distribute documentation associated with the Joomla! project. It is designed to foster wide electronic distribution of Joomla! documentation while ensuring that any material added to the documentation by you or others can be taken up and made part of the authoritative documentation distributed by the Joomla! project.


30-Installing-template-navigate-nl.png

30-Installing-template-navigate.png

Summary

Screenshot

Licensing

Documentation all together tranparent small.png
Joomla Electronic Documentation License

This article is licensed under the Joomla! Electronic Documentation License. It grants you certain rights to use, modify and distribute documentation associated with the Joomla! project. It is designed to foster wide electronic distribution of Joomla! documentation while ensuring that any material added to the documentation by you or others can be taken up and made part of the authoritative documentation distributed by the Joomla! project.


30-Installing-template-upload-package-file-en.png

Summary

Screenshot

Licensing

Documentation all together tranparent small.png
Joomla Electronic Documentation License

This article is licensed under the Joomla! Electronic Documentation License. It grants you certain rights to use, modify and distribute documentation associated with the Joomla! project. It is designed to foster wide electronic distribution of Joomla! documentation while ensuring that any material added to the documentation by you or others can be taken up and made part of the authoritative documentation distributed by the Joomla! project.


30-Installing-template-upload-package-file-es.png

Summary

Instalar paquete de plantilla desde el gestor de extensiones.

Licensing

Documentation all together tranparent small.png
Joomla Electronic Documentation License

This article is licensed under the Joomla! Electronic Documentation License. It grants you certain rights to use, modify and distribute documentation associated with the Joomla! project. It is designed to foster wide electronic distribution of Joomla! documentation while ensuring that any material added to the documentation by you or others can be taken up and made part of the authoritative documentation distributed by the Joomla! project.


30-Installing-template-upload-package-file-fr.png

Licensing

Documentation all together tranparent small.png
Joomla Electronic Documentation License

This article is licensed under the Joomla! Electronic Documentation License. It grants you certain rights to use, modify and distribute documentation associated with the Joomla! project. It is designed to foster wide electronic distribution of Joomla! documentation while ensuring that any material added to the documentation by you or others can be taken up and made part of the authoritative documentation distributed by the Joomla! project.


30-Installing-template-upload-package-file-nl.png

30-Menu-item-template-management-edit-en.png

Summary

Screenshot

Licensing

Documentation all together tranparent small.png
Joomla Electronic Documentation License

This article is licensed under the Joomla! Electronic Documentation License. It grants you certain rights to use, modify and distribute documentation associated with the Joomla! project. It is designed to foster wide electronic distribution of Joomla! documentation while ensuring that any material added to the documentation by you or others can be taken up and made part of the authoritative documentation distributed by the Joomla! project.


30-Menu-item-template-management-edit-fr.png

Licensing

Documentation all together tranparent small.png
Joomla Electronic Documentation License

This article is licensed under the Joomla! Electronic Documentation License. It grants you certain rights to use, modify and distribute documentation associated with the Joomla! project. It is designed to foster wide electronic distribution of Joomla! documentation while ensuring that any material added to the documentation by you or others can be taken up and made part of the authoritative documentation distributed by the Joomla! project.


30-Menu-item-template-management-edit-nl.png

30-Switching-templates-1-en.png

Summary

Screenshot with text added.

Licensing

Documentation all together tranparent small.png
Joomla Electronic Documentation License

This article is licensed under the Joomla! Electronic Documentation License. It grants you certain rights to use, modify and distribute documentation associated with the Joomla! project. It is designed to foster wide electronic distribution of Joomla! documentation while ensuring that any material added to the documentation by you or others can be taken up and made part of the authoritative documentation distributed by the Joomla! project.


30-Switching-templates-1-fr.png

Licensing

Documentation all together tranparent small.png
Joomla Electronic Documentation License

This article is licensed under the Joomla! Electronic Documentation License. It grants you certain rights to use, modify and distribute documentation associated with the Joomla! project. It is designed to foster wide electronic distribution of Joomla! documentation while ensuring that any material added to the documentation by you or others can be taken up and made part of the authoritative documentation distributed by the Joomla! project.


30-Switching-templates-1-nl.png

30-Switching-templates-assign-menus-en.png

Summary

Screenshot

Licensing

Documentation all together tranparent small.png
Joomla Electronic Documentation License

This article is licensed under the Joomla! Electronic Documentation License. It grants you certain rights to use, modify and distribute documentation associated with the Joomla! project. It is designed to foster wide electronic distribution of Joomla! documentation while ensuring that any material added to the documentation by you or others can be taken up and made part of the authoritative documentation distributed by the Joomla! project.


30-Switching-templates-assign-menus-fr.png

Licensing

Documentation all together tranparent small.png
Joomla Electronic Documentation License

This article is licensed under the Joomla! Electronic Documentation License. It grants you certain rights to use, modify and distribute documentation associated with the Joomla! project. It is designed to foster wide electronic distribution of Joomla! documentation while ensuring that any material added to the documentation by you or others can be taken up and made part of the authoritative documentation distributed by the Joomla! project.


30-Switching-templates-assign-menus-nl.png

30-Template-manager-select-edit-en.png

Summary

Screenshot

Licensing

Documentation all together tranparent small.png
Joomla Electronic Documentation License

This article is licensed under the Joomla! Electronic Documentation License. It grants you certain rights to use, modify and distribute documentation associated with the Joomla! project. It is designed to foster wide electronic distribution of Joomla! documentation while ensuring that any material added to the documentation by you or others can be taken up and made part of the authoritative documentation distributed by the Joomla! project.


30-Template-manager-select-edit-fr.png

Licensing

Documentation all together tranparent small.png
Joomla Electronic Documentation License

This article is licensed under the Joomla! Electronic Documentation License. It grants you certain rights to use, modify and distribute documentation associated with the Joomla! project. It is designed to foster wide electronic distribution of Joomla! documentation while ensuring that any material added to the documentation by you or others can be taken up and made part of the authoritative documentation distributed by the Joomla! project.


30-Template-manager-select-edit-nl.png

30-Template-manager-template-cutomise-view.png

Summary

Screenshot

Licensing

Documentation all together tranparent small.png
Joomla Electronic Documentation License

This article is licensed under the Joomla! Electronic Documentation License. It grants you certain rights to use, modify and distribute documentation associated with the Joomla! project. It is designed to foster wide electronic distribution of Joomla! documentation while ensuring that any material added to the documentation by you or others can be taken up and made part of the authoritative documentation distributed by the Joomla! project.


30-Template-manager-template-style-view-en.png

Summary

Screenshot

Licensing

Documentation all together tranparent small.png
Joomla Electronic Documentation License

This article is licensed under the Joomla! Electronic Documentation License. It grants you certain rights to use, modify and distribute documentation associated with the Joomla! project. It is designed to foster wide electronic distribution of Joomla! documentation while ensuring that any material added to the documentation by you or others can be taken up and made part of the authoritative documentation distributed by the Joomla! project.


30-Template-manager-template-style-view-fr.png

Licensing

Documentation all together tranparent small.png
Joomla Electronic Documentation License

This article is licensed under the Joomla! Electronic Documentation License. It grants you certain rights to use, modify and distribute documentation associated with the Joomla! project. It is designed to foster wide electronic distribution of Joomla! documentation while ensuring that any material added to the documentation by you or others can be taken up and made part of the authoritative documentation distributed by the Joomla! project.


30-Template-manager-template-style-view-nl.png

30-Template-manager-template-styles-view-1-en.png

Summary

Screenshot

Licensing

Documentation all together tranparent small.png
Joomla Electronic Documentation License

This article is licensed under the Joomla! Electronic Documentation License. It grants you certain rights to use, modify and distribute documentation associated with the Joomla! project. It is designed to foster wide electronic distribution of Joomla! documentation while ensuring that any material added to the documentation by you or others can be taken up and made part of the authoritative documentation distributed by the Joomla! project.


30-Template-manager-template-styles-view-1-fr.png

Licensing

Documentation all together tranparent small.png
Joomla Electronic Documentation License

This article is licensed under the Joomla! Electronic Documentation License. It grants you certain rights to use, modify and distribute documentation associated with the Joomla! project. It is designed to foster wide electronic distribution of Joomla! documentation while ensuring that any material added to the documentation by you or others can be taken up and made part of the authoritative documentation distributed by the Joomla! project.


30-Template-manager-template-styles-view-1-nl.png

30-Template-manager-template-styles-view-2-en.png

Summary

Screenshot

Licensing

Documentation all together tranparent small.png
Joomla Electronic Documentation License

This article is licensed under the Joomla! Electronic Documentation License. It grants you certain rights to use, modify and distribute documentation associated with the Joomla! project. It is designed to foster wide electronic distribution of Joomla! documentation while ensuring that any material added to the documentation by you or others can be taken up and made part of the authoritative documentation distributed by the Joomla! project.


30-Template-manager-template-styles-view-2-fr.png

Licensing

Documentation all together tranparent small.png
Joomla Electronic Documentation License

This article is licensed under the Joomla! Electronic Documentation License. It grants you certain rights to use, modify and distribute documentation associated with the Joomla! project. It is designed to foster wide electronic distribution of Joomla! documentation while ensuring that any material added to the documentation by you or others can be taken up and made part of the authoritative documentation distributed by the Joomla! project.


30-Template-manager-template-styles-view-2-nl.png

30-Template manager access.png

Summary

Screenshot

Licensing

Documentation all together tranparent small.png
Joomla Electronic Documentation License

This article is licensed under the Joomla! Electronic Documentation License. It grants you certain rights to use, modify and distribute documentation associated with the Joomla! project. It is designed to foster wide electronic distribution of Joomla! documentation while ensuring that any material added to the documentation by you or others can be taken up and made part of the authoritative documentation distributed by the Joomla! project.


3ndriago

Open Source supporter who very often needs community help, so why not give back a little help to it? IT developer, part time blogger and full time technology passionate!

3x-preview-template-template-manager-en.png

Summary

Screenshot

Licensing

Documentation all together tranparent small.png
Joomla Electronic Documentation License

This article is licensed under the Joomla! Electronic Documentation License. It grants you certain rights to use, modify and distribute documentation associated with the Joomla! project. It is designed to foster wide electronic distribution of Joomla! documentation while ensuring that any material added to the documentation by you or others can be taken up and made part of the authoritative documentation distributed by the Joomla! project.


3x-preview-template-template-manager-fr.png

Licensing

Documentation all together tranparent small.png
Joomla Electronic Documentation License

This article is licensed under the Joomla! Electronic Documentation License. It grants you certain rights to use, modify and distribute documentation associated with the Joomla! project. It is designed to foster wide electronic distribution of Joomla! documentation while ensuring that any material added to the documentation by you or others can be taken up and made part of the authoritative documentation distributed by the Joomla! project.


3x-preview-template-template-manager-nl.png

3x-template-manager-customise-template-create-overrides-component-en.png

Summary

Screenshot

Licensing

Documentation all together tranparent small.png
Joomla Electronic Documentation License

This article is licensed under the Joomla! Electronic Documentation License. It grants you certain rights to use, modify and distribute documentation associated with the Joomla! project. It is designed to foster wide electronic distribution of Joomla! documentation while ensuring that any material added to the documentation by you or others can be taken up and made part of the authoritative documentation distributed by the Joomla! project.


3x-template-manager-customise-template-create-overrides-component-fr.png

Licensing

Documentation all together tranparent small.png
Joomla Electronic Documentation License

This article is licensed under the Joomla! Electronic Documentation License. It grants you certain rights to use, modify and distribute documentation associated with the Joomla! project. It is designed to foster wide electronic distribution of Joomla! documentation while ensuring that any material added to the documentation by you or others can be taken up and made part of the authoritative documentation distributed by the Joomla! project.


3x-template-manager-customise-template-create-overrides-component-nl.png

3x-template-manager-customise-template-create-overrides-en.png

Summary

Screenshot

Licensing

Documentation all together tranparent small.png
Joomla Electronic Documentation License

This article is licensed under the Joomla! Electronic Documentation License. It grants you certain rights to use, modify and distribute documentation associated with the Joomla! project. It is designed to foster wide electronic distribution of Joomla! documentation while ensuring that any material added to the documentation by you or others can be taken up and made part of the authoritative documentation distributed by the Joomla! project.


3x-template-manager-customise-template-create-overrides-file-list-en.png

Summary

Screenshot

Licensing

Documentation all together tranparent small.png
Joomla Electronic Documentation License

This article is licensed under the Joomla! Electronic Documentation License. It grants you certain rights to use, modify and distribute documentation associated with the Joomla! project. It is designed to foster wide electronic distribution of Joomla! documentation while ensuring that any material added to the documentation by you or others can be taken up and made part of the authoritative documentation distributed by the Joomla! project.


3x-template-manager-customise-template-create-overrides-file-list-fr.png

Licensing

Documentation all together tranparent small.png
Joomla Electronic Documentation License

This article is licensed under the Joomla! Electronic Documentation License. It grants you certain rights to use, modify and distribute documentation associated with the Joomla! project. It is designed to foster wide electronic distribution of Joomla! documentation while ensuring that any material added to the documentation by you or others can be taken up and made part of the authoritative documentation distributed by the Joomla! project.


3x-template-manager-customise-template-create-overrides-file-list-nl.png

3x-template-manager-customise-template-create-overrides-fr.png

Licensing

Documentation all together tranparent small.png
Joomla Electronic Documentation License

This article is licensed under the Joomla! Electronic Documentation License. It grants you certain rights to use, modify and distribute documentation associated with the Joomla! project. It is designed to foster wide electronic distribution of Joomla! documentation while ensuring that any material added to the documentation by you or others can be taken up and made part of the authoritative documentation distributed by the Joomla! project.


3x-template-manager-customise-template-create-overrides-message-en.png

Summary

Screenshot

Licensing

Documentation all together tranparent small.png
Joomla Electronic Documentation License

This article is licensed under the Joomla! Electronic Documentation License. It grants you certain rights to use, modify and distribute documentation associated with the Joomla! project. It is designed to foster wide electronic distribution of Joomla! documentation while ensuring that any material added to the documentation by you or others can be taken up and made part of the authoritative documentation distributed by the Joomla! project.


3x-template-manager-customise-template-create-overrides-message-fr.png

Licensing

Documentation all together tranparent small.png
Joomla Electronic Documentation License

This article is licensed under the Joomla! Electronic Documentation License. It grants you certain rights to use, modify and distribute documentation associated with the Joomla! project. It is designed to foster wide electronic distribution of Joomla! documentation while ensuring that any material added to the documentation by you or others can be taken up and made part of the authoritative documentation distributed by the Joomla! project.


3x-template-manager-customise-template-create-overrides-message-nl.png

3x-template-manager-customise-template-create-overrides-nl.png

3x-template-manager-customise-template-create-upload-file-en.png

Summary

Screenshot

Licensing

Documentation all together tranparent small.png
Joomla Electronic Documentation License

This article is licensed under the Joomla! Electronic Documentation License. It grants you certain rights to use, modify and distribute documentation associated with the Joomla! project. It is designed to foster wide electronic distribution of Joomla! documentation while ensuring that any material added to the documentation by you or others can be taken up and made part of the authoritative documentation distributed by the Joomla! project.


3x-template-manager-customise-template-create-upload-file-fr.png

Licensing

Documentation all together tranparent small.png
Joomla Electronic Documentation License

This article is licensed under the Joomla! Electronic Documentation License. It grants you certain rights to use, modify and distribute documentation associated with the Joomla! project. It is designed to foster wide electronic distribution of Joomla! documentation while ensuring that any material added to the documentation by you or others can be taken up and made part of the authoritative documentation distributed by the Joomla! project.


3x-template-manager-customise-template-create-upload-file-nl.png

3x-template-manager-customise-template-create-upload-file-types-en.png

Summary

Screenshot

Licensing

Documentation all together tranparent small.png
Joomla Electronic Documentation License

This article is licensed under the Joomla! Electronic Documentation License. It grants you certain rights to use, modify and distribute documentation associated with the Joomla! project. It is designed to foster wide electronic distribution of Joomla! documentation while ensuring that any material added to the documentation by you or others can be taken up and made part of the authoritative documentation distributed by the Joomla! project.


3x-template-manager-customise-template-create-upload-file-types-fr.png

Licensing

Documentation all together tranparent small.png
Joomla Electronic Documentation License

This article is licensed under the Joomla! Electronic Documentation License. It grants you certain rights to use, modify and distribute documentation associated with the Joomla! project. It is designed to foster wide electronic distribution of Joomla! documentation while ensuring that any material added to the documentation by you or others can be taken up and made part of the authoritative documentation distributed by the Joomla! project.


3x-template-manager-customise-template-create-upload-file-types-nl.png

3x-template-manager-customise-template-en.png

Summary

Screenshot

Licensing

Documentation all together tranparent small.png
Joomla Electronic Documentation License

This article is licensed under the Joomla! Electronic Documentation License. It grants you certain rights to use, modify and distribute documentation associated with the Joomla! project. It is designed to foster wide electronic distribution of Joomla! documentation while ensuring that any material added to the documentation by you or others can be taken up and made part of the authoritative documentation distributed by the Joomla! project.


3x-template-manager-customise-template-file-edit-en.png

Summary

Screenshot

Licensing

Documentation all together tranparent small.png
Joomla Electronic Documentation License

This article is licensed under the Joomla! Electronic Documentation License. It grants you certain rights to use, modify and distribute documentation associated with the Joomla! project. It is designed to foster wide electronic distribution of Joomla! documentation while ensuring that any material added to the documentation by you or others can be taken up and made part of the authoritative documentation distributed by the Joomla! project.


3x-template-manager-customise-template-file-edit-fr.png

Licensing

Documentation all together tranparent small.png
Joomla Electronic Documentation License

This article is licensed under the Joomla! Electronic Documentation License. It grants you certain rights to use, modify and distribute documentation associated with the Joomla! project. It is designed to foster wide electronic distribution of Joomla! documentation while ensuring that any material added to the documentation by you or others can be taken up and made part of the authoritative documentation distributed by the Joomla! project.


3x-template-manager-customise-template-file-edit-nl.png

3x-template-manager-customise-template-fr.png

Licensing

Documentation all together tranparent small.png
Joomla Electronic Documentation License

This article is licensed under the Joomla! Electronic Documentation License. It grants you certain rights to use, modify and distribute documentation associated with the Joomla! project. It is designed to foster wide electronic distribution of Joomla! documentation while ensuring that any material added to the documentation by you or others can be taken up and made part of the authoritative documentation distributed by the Joomla! project.


3x-template-manager-customise-template-manage-folders-en.png

Summary

Screenshot

Licensing

Documentation all together tranparent small.png
Joomla Electronic Documentation License

This article is licensed under the Joomla! Electronic Documentation License. It grants you certain rights to use, modify and distribute documentation associated with the Joomla! project. It is designed to foster wide electronic distribution of Joomla! documentation while ensuring that any material added to the documentation by you or others can be taken up and made part of the authoritative documentation distributed by the Joomla! project.


3x-template-manager-customise-template-manage-folders-fr.png

Licensing

Documentation all together tranparent small.png
Joomla Electronic Documentation License

This article is licensed under the Joomla! Electronic Documentation License. It grants you certain rights to use, modify and distribute documentation associated with the Joomla! project. It is designed to foster wide electronic distribution of Joomla! documentation while ensuring that any material added to the documentation by you or others can be taken up and made part of the authoritative documentation distributed by the Joomla! project.


3x-template-manager-customise-template-manage-folders-nl.png

3x-template-manager-customise-template-nl.png

3x-template-manager-customise-template-popup-copy-en.png

Summary

screenshot

Licensing

Documentation all together tranparent small.png
Joomla Electronic Documentation License

This article is licensed under the Joomla! Electronic Documentation License. It grants you certain rights to use, modify and distribute documentation associated with the Joomla! project. It is designed to foster wide electronic distribution of Joomla! documentation while ensuring that any material added to the documentation by you or others can be taken up and made part of the authoritative documentation distributed by the Joomla! project.


3x-template-manager-customise-template-popup-copy-fr.png

Licensing

Documentation all together tranparent small.png
Joomla Electronic Documentation License

This article is licensed under the Joomla! Electronic Documentation License. It grants you certain rights to use, modify and distribute documentation associated with the Joomla! project. It is designed to foster wide electronic distribution of Joomla! documentation while ensuring that any material added to the documentation by you or others can be taken up and made part of the authoritative documentation distributed by the Joomla! project.


3x-template-manager-customise-template-popup-copy-nl.png

3x-template-manager-customise-template-toolbar-en.png

Summary

Screenshot

Licensing

Documentation all together tranparent small.png
Joomla Electronic Documentation License

This article is licensed under the Joomla! Electronic Documentation License. It grants you certain rights to use, modify and distribute documentation associated with the Joomla! project. It is designed to foster wide electronic distribution of Joomla! documentation while ensuring that any material added to the documentation by you or others can be taken up and made part of the authoritative documentation distributed by the Joomla! project.


3x-template-manager-customise-template-toolbar-fr.png

Licensing

Documentation all together tranparent small.png
Joomla Electronic Documentation License

This article is licensed under the Joomla! Electronic Documentation License. It grants you certain rights to use, modify and distribute documentation associated with the Joomla! project. It is designed to foster wide electronic distribution of Joomla! documentation while ensuring that any material added to the documentation by you or others can be taken up and made part of the authoritative documentation distributed by the Joomla! project.


3x-template-manager-customise-template-toolbar-nl.png

3x-template-manager-templates-file-link.png

Summary

Screenshot

Licensing

Documentation all together tranparent small.png
Joomla Electronic Documentation License

This article is licensed under the Joomla! Electronic Documentation License. It grants you certain rights to use, modify and distribute documentation associated with the Joomla! project. It is designed to foster wide electronic distribution of Joomla! documentation while ensuring that any material added to the documentation by you or others can be taken up and made part of the authoritative documentation distributed by the Joomla! project.


3x-template-manager-templates.png

Summary

Screenshot

Licensing

Documentation all together tranparent small.png
Joomla Electronic Documentation License

This article is licensed under the Joomla! Electronic Documentation License. It grants you certain rights to use, modify and distribute documentation associated with the Joomla! project. It is designed to foster wide electronic distribution of Joomla! documentation while ensuring that any material added to the documentation by you or others can be taken up and made part of the authoritative documentation distributed by the Joomla! project.


4-Update-Joomla.png

{{:Translations:404.shtml/Page_display_title/<lang code>‎}}

The requested pagename is invalid!

You should have been redirected to the search page if the requested page does not exist, but if an internal link lead you here, the target page name may either contain invalid characters or the string "index.php", which is known to cause trouble.

Temporary workaround

If you are sure the page exists because you followed a "blue link", change the URL in your browser's address bar from
  http://docs.joomla.org/Page_name_causing_trouble
into
  http://docs.joomla.org/index.php?title=Page_name_causing_trouble

The target page should appear so you can read it.

Permanent fix for existing pages

First of all: don't try to move/redirect the page as this will not necessarily resolve the issue if the original page title is still linked to from someplace else.

Here's how you can fix links pointing to a bogus pagename:

  1. navigate to the bogus page using the workaround explained above
  2. click "What links here" in the sidebar to get a list of all pages that link to it
  3. open each page in a new tab/windows and hit edit
  4. prepend the standard wiki-link [[Page name causing trouble]] with the interwiki prefix "self:" [[self:Page name causing trouble|]]
if the regular link did not feature a link caption, use the "pipe trick" as illustrated

Fix for new pages

If you clicked on a "red link" then the target page does not appear to exist. Here's how you may fix that:

  • think of a better name for the target page that does not include strange characters or the string "index.php" and use that in the source page
  • if that is not possible use the interwiki prefix "self:" as explained in the previous section.

If none of the above helps

Post the issue in the Developer Documentation forum, or if you don't have an account for the Joomla! forums (how comes?) leave a note on the talk page. Please sign your entry by adding four tildes ~~~~ or click the "signature" button in the editor's toolbar.

Thank you

404discovery.png

Summary

Image showing 404 URL discovery in Webmaster Tools

Licensing

Documentation all together tranparent small.png
Joomla Electronic Documentation License

This article is licensed under the Joomla! Electronic Documentation License. It grants you certain rights to use, modify and distribute documentation associated with the Joomla! project. It is designed to foster wide electronic distribution of Joomla! documentation while ensuring that any material added to the documentation by you or others can be taken up and made part of the authoritative documentation distributed by the Joomla! project.


4b40d77049e1f

Test 1

This is a test of the CodeExamples extension.

Chris Davenport 12:44, 3 January 2010 (EST)

4b40dd2c8bfa4

This is a Text

This is a test comment

Alex 13:08, 3 January 2010 (EST)

4b40de8c16165

Hello again

This is it

Batch1211 13:14, 3 January 2010 (EST)

4b40ded8ec548

Why so serious

function hello(){
 echo $this->greeting;
}
Batch1211 13:15, 3 January 2010 (EST)

4ba65300e4b9c

This is a Test

Let's try this

Batch1211 13:10, 21 March 2010 (EDT) Edit comment

4ba6564a424a0

This is a test

This is a test

Batch1211 13:24, 21 March 2010 (EDT) Edit comment

4ba6641e4cb38

This is a Test

This is a Test

Doxiki 14:23, 21 March 2010 (EDT) Edit comment

4ba801dbc7c03

Tree Structures with JNode

JTree and JNode can be used to create and process simple tree structures. Let's see how this works for JNode with a simple example.

We want represent the family structure of the Smiths. Granny Barbara has two daughters. Stefanie and Aunti Sue. Stefanie has two children, Peter and Stewie. Auntie Sue doesn't have children.

Let's take a look how we can represent this familiy in an object tree.

$barbara = new JNode();
$stefanie = new JNode();
$sue = new JNode();
$peter = new JNode();
$stewie = new JNode();
 
//Granny Barbara has two children, stefanie, and sue
$barbara->addChild($stefanie);
$barbara->addChild($sue);
 
/*
 * Sometimes we want declare parent-child relationships the other way around.
 * We can also do that
 */
 
$peter->setParent($stefanie);
$stewie->setParent($stefanie);
Batch1211 19:48, 22 March 2010 (EDT) Edit comment

4ba802c761837

Tree Structures with JTree and JNote

JTree and JNode can be used to create and process simple tree structures. Let's see how this works for JTree with a simple example.

We want to create the Family Tree of the Smiths. Granny Barbara has two daughters. Stefanie and Aunti Sue. Stefanie has two children, Peter and Stewie. Auntie Sue doesn't have children.

Let's take a look how we can represent this familiy in an object tree.

$barbara = new JNode();
$stefanie = new JNode();
$sue = new JNode();
$peter = new JNode();
$stewie = new JNode();
 
$familyTree = new JTree(); //pointer set to root-node
$familyTree->addChild($barbara, true) //pointer set to barbara
$familyTree->addChild($sue) //$sue added as child to barbara, pointer still on barbara
$familyTree->addChild($stefanie, true) //$stefanie added as child to barbara, pointer on stefanie
$familyTree->addChild($peter, true) //$peter added as child to stefanie, pointer on peter
$familyTree->getParent() // pointer set to parent of peter, which is stefanie
$familyTree->addChild($stewie) //$stewie added as child to stefanie, pointer on stefanie
Batch1211 19:52, 22 March 2010 (EDT) Edit comment

4bcfd994b6e12

A typical example of loading MooTools

// This example depends on mootools
JHTML::_('behavior.mootools');
 
// Do something after page has loaded
$document =& JFactory::getDocument();
$document->addScriptDeclaration("window.addEvent('load', function() { doSomething(); })");
Chris Davenport 01:07, 22 April 2010 (EDT) Edit comment

4c4535a92d52f

getInstance example

 
$row =& JTable::getInstance('review', 'Table');
geomaras 00:35, 20 July 2010 (CDT) Edit comment

4c6c50711caa3

No Title

Example:

$query	= $db->getQuery(true);
$query->insert('#__tableName');
 
$query->set('id=4');
 
$db->setQuery( $query );
$result	= $db->loadResult();
Unhindered 16:28, 18 August 2010 (CDT) Edit comment

4ca07516bb7f7

JPagination on Frontpage

Mariska wrote:

if you want to Jpagination work on front page change Jpagination.php

on this code function _buildDataObject bicause this method use to generate link on front end // add "&limit=".$this->limit to $data->[]->link

   function _buildDataObject() {
       // Initialize variables
       $data = new stdClass();
       $data->all = new JPaginationObject(JText::_('View All'));
       if (!$this->_viewall) {
           $data->all->base = '0';
           $data->all->link = JRoute::_("&limit=".$this->limit."&limitstart="); // <== this  
       }
       // Set the start and previous data objects
       $data->start = new JPaginationObject(JText::_('Start'));
       $data->previous = new JPaginationObject(JText::_('Prev'));
       if ($this->get('pages.current') > 1) {
           $page = ($this->get('pages.current') - 2) * $this->limit;
          $page = $page == 0 ?  : $page; //set the empty for removal from route
           $data->start->base = '0';
           $data->start->link = JRoute::_("&limit=".$this->limit."&limitstart="); //<== this
           $data->previous->base = $page;
           $data->previous->link = JRoute::_("&limit=".$this->limit."&limitstart=" . $page); //<== this
       }
       // Set the next and end data objects
       $data->next = new JPaginationObject(JText::_('Next'));
       $data->end = new JPaginationObject(JText::_('End'));
       if ($this->get('pages.current') < $this->get('pages.total')) {
           $next = $this->get('pages.current') * $this->limit;
           $end = ($this->get('pages.total') - 1) * $this->limit;
           $data->next->base = $next;
           $data->next->link = JRoute::_("&limit=".$this->limit."&limitstart=" . $next); // <== this
           $data->end->base = $end;
           $data->end->link = JRoute::_("&limit=".$this->limit."&limitstart=" . $end); // <== this
       }
       $data->pages = array();
       $stop = $this->get('pages.stop');
       for ($i = $this->get('pages.start'); $i <= $stop; $i++) {
           $offset = ($i - 1) * $this->limit
           $offset = $offset == 0 ?  : $offset;  //set the empty for removal from route
           $data->pages[$i] = new JPaginationObject($i);
           if ($i != $this->get('pages.current') || $this->_viewall) {
               $data->pages[$i]->base = $offset;
               $data->pages[$i]->link = JRoute::_("&limit=".$this->limit."&limitstart=" . $offset); //<== this
           }
       }
       return $data;
   }

Batch1211 05:42, 27 September 2010 (CDT) Edit comment

4cc41287689c8

Example

<?php
/* 
    This program is for adding in Jumi module
    It will show the cooperative account of login user
    which store in CSV  file on the server
 
*/
defined('_JEXEC') OR die("Restricted access"); // Prevent direct Access to the program
$user =& JFactory::getUser(); // get user
if ($user->guest) {
    echo "<h3>Please log in to see your report ! </h3>"; // Show this message if user not yet log in
} else {
        // If user log in 
	$id = strtoupper($user->username);   // Get user and store in $id
	$fd = fopen ("http://btc-intranet.ap.bayer.cnb/coop/COOPBAL.csv", "r"); // Open CSV file
    $found=0; 
	while (!feof ($fd)) {
        $buffer = fgetcsv($fd, 4096);  // Get one record
		if(strtoupper($buffer[1]) == $id){
			$found = 1;  // if $id = login name then set flag $found
			break;  // exit loop
        }
	}
	fclose ($fd);
	if($found){   // Display account detail
		echo "<h3> Report of ".$buffer[4]." For the month".$buffer[5]. "</h3><br/>";	
		echo "<h4> Deposit Account of member no ".$buffer[3]."</h4>";
		echo "<table>";
		echo "<tr><td>Last month :</td><td align=\"right\">".$buffer[6]."</td><td> Baht </td></tr>";
		echo "<tr><td>This month :</td><td align=\"right\">".$buffer[7]."</td><td> Baht </td></tr>";
		echo "<tr><td>Next month :</td><td align=\"right\">".$buffer[8]."</td><td> Baht </td></tr>";
		echo "</table>";
		if(!($buffer[9]=="") || !($buffer[13])){
			echo "<h4>Loan account</h4>";
			echo "<table>";
			echo "<tr><td>Last month :</td><td align=\"right\"> ".$buffer[9]."</td><td> Baht </td></tr>";
			echo "<tr><td>Pay this month :</td><td align=\"right\"> ".$buffer[10]."</td><td> Baht </td></tr>";
			echo "<tr><td>Actual Payment :</td><td align=\"right\"> ".$buffer[11]."</td><td> Baht </td></tr>";
			echo "<tr><td>Interest :</td><td align=\"right\"> ".$buffer[12]."</td><td> Baht </td></tr>";
			echo "<tr><td>Next Month begin :</td><td align=\"right\"> ".$buffer[13]."</td><td> Baht </td></tr>";
			echo "</table>";
		}
                echo "<br/>Please check your account <br/>";
	}else{
                // if check to end of file but not found
		echo "<h3>No Account for you, Please let us know if you are member of the Cooperation fund </h3>";    
	}
}
?>


Jeeradate 06:03, 24 October 2010 (CDT) Edit comment

4cfc9888a45a8

Override Default Headers

From: http://groups.google.com/group/joomla-dev-general/browse_thread/thread/6ef5fe7eba4efc26

How can I override the default joomla headers from within a custom component? I would like to change

Expires: Mon, 1 Jan 2001 00:00:00 GMT 
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre- 
check=0 
Pragma: no-cache

to

Expires: ~in five hours~ 
Cache-Control: public 
Pragma: public

JResponse::allowCache(true) did the trick. If it helps anyone else, here is the code that worked for me.

JResponse::allowCache(true); 
JResponse::setHeader('Pragma', 'public',true); 
JResponse::setHeader('Cache-Control','public',true); 
JResponse::setHeader('Expires', gmdate('D, d M Y H:i:s', time() 
+(60*60*5)) . ' GMT',true);
Elin 02:02, 6 December 2010 (CST) Edit comment

4d0a2b2491399

No Title

 
jimport('joomla.error.log');
$log = &JLog::getInstance();
$log->addEntry(array('LEVEL' => '1','STATUS' => 'SOME ERROR:','COMMENT' =>'some comment'));

4d30818ae30fe

Get the name of the document

demo.xml

<jdoc>
	<doku kategory="Info">Wiki</doku>
</jdoc>
<?php
 
$xml = JFactory::getXML('demo.xml');
 
echo $xml->name();

Output:

jdoc

Elkuku 11:02, 14 January 2011 (CST) Edit comment

4d30846f12c6d

Get the element data

demo.xml

<jdoc>
	<doku kategory="Info">Wiki</doku>
</jdoc>
<?php
 
$xml = JFactory::getXML('demo.xml');
 
echo $xml->doku->data();
 
/* Better: */
echo $xml->doku;

Ausgabe:

Wiki

Elkuku 11:14, 14 January 2011 (CST) Edit comment

4d3084f89e0ff

Get the attribute of an element

demo.xml

<jdoc>
	<doku kategory="Info">Wiki</doku>
</jdoc>
<?php
 
$xml = JFactory::getXML('demo.xml');
 
echo $xml->doku->getAttribute('kategory');
 
/* Better: */
echo $xml->doku->attributes()->kategory;

Output:

Info

Elkuku 11:16, 14 January 2011 (CST) Edit comment

4d30874fd792a

Get the whole XML document or a part of it.

demo.xml

<jdoc>
	<doku kategory="Info">Wiki</doku>
</jdoc>

Get the whole XML document or a part of it.

<?php
 
$xml = JFactory::getXML('demo.xml');
 
echo '<pre>';
echo htmlentities($xml->asFormattedXML());
echo '</pre>';

Output:

<jdoc>
	<doku kategory="Info">Wiki</doku>
</jdoc>

Die "komprimierte" Ausgabe, z.B. zur Verwendung in Streams:

$xml->asFormattedXML(true)

Output:

<jdoc><doku kategory="Info">Wiki</doku></jdoc>

Output only a part of the document:

$xml->doku->asFormattedXML()

Output:

<doku kategory="Info">Wiki</doku>


Elkuku 11:26, 14 January 2011 (CST) Edit comment

4d31659b9455f

Simple text strings

    echo JText::_( 'Welcome' );

see also: http://docs.joomla.org/Tutorial:Template_translations

4d48b240a0d42

No Title

Note: At 20110201, the key=>value pairs which are arguments to function setParam (and function getParam) are stored in table jos_users, column params. This may change in the future.

Spicetrader 19:24, 1 February 2011 (CST) Edit comment

4d6cda382364a

May not always work

addCC may not always work on 1.5 due to an error in the phpmailer class. to forum topic.


E-builds 05:36, 1 March 2011 (CST) Edit comment

4d74e424a7c2b

need more info

hi, I am trying to use this go get all the subcategories of a certain category jimport('joomla.application.categories'); $categories = new JCategories('com_content'); print_r($categories); $subCategories = $categories->get(78); print_r($subCategories);

but this gives: JCategories Object ( [_nodes:protected] => [_checkedCategories:protected] => [_extension:protected] => c [_table:protected] => c [_field:protected] => c [_key:protected] => c [_statefield:protected] => c [_options:protected] => com_jumi ) subs:

So my guess is I can't acces the nessacary data because it is protected... any help?

Djemmers 07:56, 7 March 2011 (CST) Edit comment

4d986a88409e6

This function seem not to exists in joomla 1.6.1

I can't find the getGroups function in Joomla 1.6.1 JForm source code. It seems not to exists.

YannCharlou 07:39, 3 April 2011 (CDT) Edit comment

4da60eb68ca0c

Wrong description

Above syntax is wrong and doesn't work in Joomla 1.6.1.

The correct is:

$this->form->setValue($field, $group , $value);

Bornakke 15:59, 13 April 2011 (CDT) Edit comment

4daab65e66059

Example

$bunny = new JObject;
$bunny->set('animalType', 'hare');
$bunny->set('color', 'white');
$bunny->set('ears', 2);
 
$wolfy = new JObject;
$wolfy->setProperties(
                     array(
                           'animalType'=>'wolf',
                           'color'=>'grey',
                           'teeth'=>42,
                           'stomach'=>null
                           )
                     );
 
 
$wolfy->stomach = $bunny;
 
print_r($wolfy);

would output

JObject Object
(
    [_errors] => Array
        (
        )

    [animalType] => wolf
    [color] => grey
    [teeth] => 42
    [stomach] => JObject Object
        (
            [_errors] => Array
                (
                )

            [animalType] => hare
            [color] => white
            [ears] => 2
        )

)

This example was originally provided by Artyom.


Chris Davenport 04:43, 17 April 2011 (CDT) Edit comment

4daab8c55b7a8

Example

Let's say, we want to integrate Error-Handling in our application, but we don't know yet, if we want the error to be display, logged in a file, stored to the database, or all of the above. Our goal is, to keep the object that raises the error independent of the objects that store the error message.

class MyError extends JObservable {
   public $msg = NULL;
 
   function raiseError($msg){
      $this->msg = $msg;
      //Notify all attached ErrorHandlers of the state change.
      $this->notify();
   }
}
 
//We now implement the Observers, thus the error handlers
class ErrorHandlerDisplay extends JObserver {
   function update(){
      echo $this->subject->msg;
   }
}
class ErrorHandlerFileStorage extends JObserver {
   function update(){
      error_log($this->subject->msg;);
   }
}
class ErrorHandlerDB extends JObserver {
   function update(){
      $db = JFactory::getDBO();
      $sql = "INSERT INTO #__myerrors (message) VALUES (".$db->quote($this->subject->msg).")";
      $db->setQuery($sql);
      $db->query();
   }
}
 
//Now we can use newly implemented MyError class to raise Errors.
$error = new MyError();
 
/* The constructor of the observers automatically attaches the observer to the subject
 * In our example that means that the constructor of the error handler automatically
 * attaches the handler to the MyError Object.
 */
new ErrorHandlerDisplay($error);
new ErrorHandlerFileStorate($error);
new ErrorHandlerDB($error);
 
$error->raiseError('Help!!!');
 
/*
 * Would cause 'Help!!!' to be display, logged in a file, and stored in the database.
 * You can simply add and remove the error handlers as you like
 */

What happened here? We separated the functionality of raising an error of the functionality of handling an error. In the future you can add additional ErrorHandlers, or remove some of the existing handlers, without the need to change any classes at all. Furthermore you can simply change an Errorhandler, without the need to change the MyError class. This greatly increases the reusability of your code.

This example was originally provided by Batch1211.


Chris Davenport 04:54, 17 April 2011 (CDT) Edit comment

4daab98b010e3

Example

Let's say, we want to integrate Error-Handling in our application, but we don't know yet, if we want the error to be display, logged in a file, stored to the database, or all of the above. Our goal is, to keep the object that raises the error independent of the objects that store the error message.

class MyError extends JObservable {
   public $msg = NULL;
 
   function raiseError($msg){
      $this->msg = $msg;
      //Notify all attached ErrorHandlers of the state change.
      $this->notify();
   }
}
 
//We now implement the Observers, thus the error handlers
class ErrorHandlerDisplay extends JObserver {
   function update(){
      echo $this->subject->msg;
   }
}
class ErrorHandlerFileStorage extends JObserver {
   function update(){
      error_log($this->subject->msg;);
   }
}
class ErrorHandlerDB extends JObserver {
   function update(){
      $db = JFactory::getDBO();
      $sql = "INSERT INTO #__myerrors (message) VALUES (".$db->quote($this->subject->msg).")";
      $db->setQuery($sql);
      $db->query();
   }
}
 
//Now we can use newly implemented MyError class to raise Errors.
$error = new MyError();
 
/* The constructor of the observers automatically attaches the observer to the subject
 * In our example that means that the constructor of the error handler automatically
 * attaches the handler to the MyError Object.
 */
new ErrorHandlerDisplay($error);
new ErrorHandlerFileStorate($error);
new ErrorHandlerDB($error);
 
$error->raiseError('Help!!!');
 
/*
 * Would cause 'Help!!!' to be display, logged in a file, and stored in the database.
 * You can simply add and remove the error handlers as you like
 */

What happened here? We separated the functionality of raising an error of the functionality of handling an error. In the future you can add additional ErrorHandlers, or remove some of the existing handlers, without the need to change any classes at all. Furthermore you can simply change an Errorhandler, without the need to change the MyError class. This greatly increases the reusability of your code.

This example was originally contributed by Batch1211.


Chris Davenport 04:57, 17 April 2011 (CDT) Edit comment

4dab1e4e1ba2d

Example

$host = 'joomla.org';
$port = 21;
$options = null;
$user = 'randomUserName';
$pass = 'thisIsDefinatlyNotThePassword';
 
jimport('joomla.client.ftp');
 
/*
 * The JFTP::getInstance() method will connect us to the FTP server and automatically
 * log us in. We could do the same with the connect() and login() methods. Also check 
 * out JClientHelper::getCredentials('ftp');
 */
 
$ftp = JFTP::getInstance($host, $port, $options, $user, $pass);
 
if($ftp->isConnected()){
   //We are connected.
 
   //Let's print the details of the root directory
   echo '<pre>';
   print_r($ftp->listDetails());
   echo '</pre>';
 
   /* Assuming we only have one "Joomla" directory, this would look like this.
   Array
   (
    [0] => Array
        (
            [type] => 1
            [rights] => drwxr-xr-x
            [user] => randomUserName
            [group] => ftpusers
            [size] => 4096
            [date] => 03-15
            [time] => 2008
            [name] => Joomla
        )
   )
   */
   //Let's create a directory
   $ftp->mkdir('test');
 
   //Let's create a file in that new directory
   $ftp->create('test/fairyTale.txt');
 
   //Let's write the first line of our Fairy Tale into our newly created text file
   $ftp->write('test/fairyTale.txt', 'Once upon a time, there was a litte Mermaid, called Arielle');
 
   //Let's read the fairy tale out of the file, and echo it out.
   $fairyTale = '';
   $ftp->read('test/fairyTale.txt', $fairyTale);
   echo $fairyTale;
 
   //Let's think of a name for our fairyTale, and rename the file
   $ftp->rename('test/fairyTale.txt', 'test/Arielle.txt');
 
   //I think you got the idea =)
}

This example was originally contributed by User:Batch1211.


Chris Davenport 12:07, 17 April 2011 (CDT) Edit comment

4dab218c50875

Automatically Generated Properties

From 2.5 As of Joomla 2.5, JTable properties are automatically generated based on the schema of the specified table. When you specify a table in a class that extends JTable, the field names are read from the table and set as properties. When using Joomla 1.5, you must manually declare all table columns as properties of the class that extends JTable.


Chris Davenport 12:21, 17 April 2011 (CDT) Edit comment

4dab21dcdb7a8

Reserved Database Field Names

Some of the optional features of JTable require the existence of specially-named fields in the database table. If you require this additional functionality you should ensure that these named fields are present in the table. These field names should be considered reserved as any attempts to use them for purposes other than those supported by JTable may result in conflict.

Field name Methods using the field name
checked_out checkOut, checkIn, isCheckedOut
checked_out_time checkOut, checkIn, isCheckedOut
hits hit
ordering getNextOrder, reorder, move
published publish


Chris Davenport 12:22, 17 April 2011 (CDT) Edit comment

4dab22169ccc3

Check-in/check-out

Joomla tables implement a simple mechanism for preventing a race condition while editing rows in a database. This depends on the existence of database fields called "checked_out" and "checked_out_time" and if these fields are present JTable will automatically support this mechanism so that it can be easily used in your tables too. In addition to the checkOut and checkIn methods, there is a isCheckedOut method to determine if a given table row is currently checked out by another user.


Chris Davenport 12:23, 17 April 2011 (CDT) Edit comment

4dab224eaef1e

Hit counter

Some Joomla tables contain a field called "hits" which records the number of times that a table row has been accessed. JTable provides a simple method to increment this field: hit.


Chris Davenport 12:24, 17 April 2011 (CDT) Edit comment

4dab24ff969cc

Adding support for new document types

New document types are added by creating a new sub-directory under the /libraries/joomla/document/ directory with the same name as the type. For example, to add a document type called "mytype", you would create the directory /libraries/joomla/document/mytype. In this directory you must then create a file called mytype.php which will contain the class definition for JDocumentMytype which extends JDocument. Look at the code for existing document types to see what needs to be done.


Chris Davenport 12:35, 17 April 2011 (CDT) Edit comment

4dab25ee5b352

Adding support for new document renderers

New renderer types are added by creating a new file in the renderer directory under the document type directory with the same name as the renderer. For example, to add a document renderer type called "myrenderer" for document type "mytype", you would create the file /libraries/joomla/document/mytype/renderer/myrenderer.php. This file will contain the class definition for JDocumentRendererMytype which extends JDocumentRenderer. Look at the code for existing document renderers to see what needs to be done.


Chris Davenport 12:39, 17 April 2011 (CDT) Edit comment

4dab2eb7b2abb

Example of Get and Set Methods

Get and set methods are provided for all the component parts of a URI. The following names of the component parts are used:

     http://fredbloggs:itsasecret@www.example.com:8080/path/to/Joomla/index.php?task=view&id=32#anchorthis
     \__/   \________/ \________/ \_____________/ \__/\_______________________/ \_____________/ \________/
      |          |         |              |        |              |                    |            |
   scheme      user       pass          host      port          path                 query       fragment

The example column in the following table illustrates the result of each of the get methods on the URI above.

Get method Set method Description Example
getFragment setFragment Fragment (everything after the '#'). This is often referred to as an anchor. anchorthis
getHost setHost Hostname or IP address. For example, 'www.joomla.org' or '192.168.2.45'. www.example.com
getPass setPass Password part of the authority. itsasecret
getPath setPath Path string. Note that the path always includes the leading "/" character. /path/to/Joomla/index.php
getPort setPort Port number. Specific schemes (protocols) have their own defaults (for example, 'http' is port 80, 'ftp' is port 21). 8080
getQuery setQuery Query in string format. For example, "foo=bar&x=y". See also buildQuery. task=view&id=32
getScheme setScheme Scheme (protocol). For example, 'http', 'https', 'ftp'. http
getUser setUser Username part of the authority. fredbloggs
getVar setVar An individual query item value from within the query part. See also delVar. 32


Chris Davenport 13:17, 17 April 2011 (CDT) Edit comment

4dab2fe9de3d9

Example

$p = JProfiler::getInstance('Application');
 
$p->mark('Start');
$a = str_repeat("hello world!\n", 100000);
$p->mark('Middle');
unset($a);
$p->mark('Stop');
 
print_r($p->getBuffer());

would output

Array
(
    [0] => Application Start: 0.000 seconds, 0.10 MB
    [1] => Application Middle: 0.005 seconds, 1.34 MB
    [2] => Application Stop: 0.005 seconds, 0.10 MB
)

This example was originally contributed by User:Artyom.


Chris Davenport 13:22, 17 April 2011 (CDT) Edit comment

4dab30df74dba

Example

Let's think of an event, that could affect different parts of your application... To keep it simple, we say that we create an onEmailChange event, that is triggered once the user changes his email address. When he does that, we want to display the change to the screen, but we also want to store it to the database. We also know, that there might be some components out there, who would like to implement their own functionality, once the useer changes his email-address.

/*
 * Let's define our concrete Event Handlers. One for the display, one for 
 * database storage
 *
 * The concrete Event Handlers only have to implement the functionality that should
 * be triggered once the event happens. All underlying functionality is implemented
 * by the abstract JEvent and JObserver classes.
 */
class EventHandlerEcho extends JEvent {
public function onEmailChange($user, $oldEmail, $newEmail){
echo $user->name . 'has changed his or her email address: <br/>';
echo 'OldEmail: '.$oldEmail.'<br/>';
echo 'NewEmail: '.$newEmail;
}
}
class EventHandlerDB extends JEvent {
public function onEmailChange($user, $oldEmail, $newEmail){
$db = JFactory::getDBO();
$sql = "UPDATE #__users SET email = ".$db->quote($newEmail)." " .
"WHERE id = " . $db->quote($user->id);
$db->setQuery($sql);
$db->query();
}
}
 
 
//Let's get the global dispatcher
$dispatcher = JDispatcher::getInstance();
 
/*
 * Let's construct the event handlers
 *
 * Since our Eventhandlers are decendents of JEvent, and JEvent is a decendent of JObserver the constructor
 * automatically attaches the eventhandler object to the dispatcher(which is a JObservable descendant).
 * This means when the Event Handlers are initialized they are automatically added to the observer stack of
 * the dispatcher.
 */
new EventHandlerEcho($dispatcher);
new EventHandlerDB($dispatcher);

After the Event Handlers have been created and added to the dispatcher, the event can be triggered from anywhere in the application. This could be in another module, another component, within the framework or even in another plugin.

 //Access the global dispatcher
 $dispatcher = JDispatcher::getInstance();
 
 /*
  * If we wanted, we could see, that our two Event handlers have been added to
  * observer stack of the dispachter before
  */
 
 var_dump($dispatcher->_observers);
 
 //Instead we want to trigger the event, and see what happens
 $user = JFactory::getUser();
 $oldEmail = 'old@email.com';
 $newEmail = 'new@email.com';
 
 $dispatcher->trigger('onEmailChange', array($user, $oldEmail, $newEmail));
 
 /*
  * Both event handlers have been triggered.
  * The email addresses have been displayed. The new one 
  * has been stored to the database
  */

Other components can now create their own concrete Event Handlers for the onEmailChange event and register it to the dispatcher. They will automatically be triggered once the event occurs anywhere in the application.

This example was originally contributed by User:Batch1211.


Chris Davenport 13:26, 17 April 2011 (CDT) Edit comment

4dab31e600c93

Example

Let's think of an event, that could affect different parts of your application... To keep it simple, we say that we create an onEmailChange event, that is triggered once the user changes his email address. When he does that, we want to display the change to the screen, but we also want to store it to the database. We also know, that there might be some components out there, who would like to implement their own functionality, once the useer changes his email-address.

/*
 * Let's define our concrete Event Handlers. One for the display, one for 
 * database storage
 *
 * The concrete Event Handlers only have to implement the functionality that should
 * be triggered once the event happens. All underlying functionality is implemented
 * by the abstract JEvent and JObserver classes.
 */
class EventHandlerEcho extends JEvent {
public function onEmailChange($user, $oldEmail, $newEmail){
echo $user->name . 'has changed his or her email address: <br/>';
echo 'OldEmail: '.$oldEmail.'<br/>';
echo 'NewEmail: '.$newEmail;
}
}
class EventHandlerDB extends JEvent {
public function onEmailChange($user, $oldEmail, $newEmail){
$db = JFactory::getDBO();
$sql = "UPDATE #__users SET email = ".$db->quote($newEmail)." " .
"WHERE id = " . $db->quote($user->id);
$db->setQuery($sql);
$db->query();
}
}
 
 
//Let's get the global dispatcher
$dispatcher = JDispatcher::getInstance();
 
/*
 * Let's construct the event handlers
 *
 * Since our Eventhandlers are decendents of JEvent, and JEvent is a decendent of JObserver the constructor
 * automatically attaches the eventhandler object to the dispatcher(which is a JObservable descendant).
 * This means when the Event Handlers are initialized they are automatically added to the observer stack of
 * the dispatcher.
 */
new EventHandlerEcho($dispatcher);
new EventHandlerDB($dispatcher);

After the Event Handlers have been created and added to the dispatcher, the event can be triggered from anywhere in the application. This could be in another module, another component, within the framework or even in another plugin.

 //Access the global dispatcher
 $dispatcher = JDispatcher::getInstance();
 
 /*
  * If we wanted, we could see, that our two Event handlers have been added to
  * observer stack of the dispachter before
  */
 
 var_dump($dispatcher->_observers);
 
 //Instead we want to trigger the event, and see what happens
 $user = JFactory::getUser();
 $oldEmail = 'old@email.com';
 $newEmail = 'new@email.com';
 
 $dispatcher->trigger('onEmailChange', array($user, $oldEmail, $newEmail));
 
 /*
  * Both event handlers have been triggered.
  * The email addresses have been displayed. The new one 
  * has been stored to the database
  */

Other components can now create their own concrete Event Handlers for the onEmailChange event and register it to the dispatcher. They will automatically be triggered once the event occurs anywhere in the application.

This example was originally contributed by User:Batch1211.

Chris Davenport 13:31, 17 April 2011 (CDT) Edit comment

4dab33b149953

Pagination like Google

Stop hand nuvola.svg.png
Warning!

This is a core hack. Files you change as described on this page will be overwritten during updates of Joomla!. For more information, see Core hack.

  • edit the libraries/joomla/html/pagination.php
  • In the function __construct see the line $displayedPages = 10;
  • Replace the $this->set( 'pages.start',... with the following lines
  $_remainder = $this->get('pages.current') % $displayedPages;
  if($__remainder == 0){
     $this->set( 'pages.start', (floor( $this->get('pages.current') / $displayedPages)) * $displayedPages -4);  
  }elseif($__remainder == 1 and $this->get('pages.current') > $displayedPages){
     $this->set( 'pages.start', (floor( ($this->get('pages.current')-1) / $displayedPages)) * $displayedPages -4);  
  }else{
    $this->set( 'pages.start', (floor( $this->get('pages.current') / $displayedPages)) * $displayedPages + 1);
  }
  • In the function _buildDataObject find the line
 for ($i = $this->get('pages.start'); $i <= $stop; $i ++)
  • In this for loop, find the line
 if ($i != $this->get('pages.current') || $this->_viewall)
  • Add the elseif statement,
 if ($i != $this->get('pages.current') || $this->_viewall)
 {
   $data->pages[$i]->base = $offset;
   $data->pages[$i]->link = JRoute::_("&limitstart=".$offset);
 }elseif($i == $this->get('pages.current')){
   $data->pages[$i]->text = '<b>' . $i . '</b>';
 }

This example was originally contributed by User:Mahboobkhalid.


Chris Davenport 13:38, 17 April 2011 (CDT) Edit comment

4dab51422cbbd

Create a fresh user

/*
 
I handle this code as if it is a snippet of a method or function!!
 
First set up some variables/objects
*/
// get the ACL
$acl =& JFactory::getACL();
 
/* get the com_user params */
 
jimport('joomla.application.component.helper'); // include libraries/application/component/helper.php
$usersParams = &JComponentHelper::getParams( 'com_users' ); // load the Params
 
// "generate" a new JUser Object
$user = JFactory::getUser(0); // it's important to set the "0" otherwise your admin user information will be loaded
 
$data = array(); // array for all user settings
 
// get the default usertype
$usertype = $usersParams->get( 'new_usertype' );
if (!$usertype) {
    $usertype = 'Registered';
}
 
// set up the "main" user information
 
$data['name'] = $firstname.' '.$lastname; // add first- and lastname
$data['username'] = $username; // add username
$data['email'] = $email; // add email
$data['gid'] = $acl->get_group_id( '', $usertype, 'ARO' );  // generate the gid from the usertype
 
/* no need to add the usertype, it will be generated automaticaly from the gid */
 
$data['password'] = $password; // set the password
$data['password2'] = $password; // confirm the password
$data['sendEmail'] = 1; // should the user receive system mails?
 
/* Now we can decide, if the user will need an activation */
 
$useractivation = $usersParams->get( 'useractivation' ); // in this example, we load the config-setting
if ($useractivation == 1) { // yeah we want an activation
 
    jimport('joomla.user.helper'); // include libraries/user/helper.php
    $data['block'] = 1; // block the User
    $data['activation'] =JUtility::getHash( JUserHelper::genRandomPassword() ); // set activation hash (don't forget to send an activation email)
 
}
else { // no we need no activation
 
    $data['block'] = 0; // don't block the user
 
}
 
if (!$user->bind($data)) { // now bind the data to the JUser Object, if it not works....
 
    JError::raiseWarning('', JText::_( $user->getError())); // ...raise an Warning
    return false; // if you're in a method/function return false
 
}
 
if (!$user->save()) { // if the user is NOT saved...
 
    JError::raiseWarning('', JText::_( $user->getError())); // ...raise an Warning
    return false; // if you're in a method/function return false
 
}
 
return $user; // else return the new JUser object

This example was originally contributed by User:Bembelimen


Chris Davenport 15:44, 17 April 2011 (CDT) Edit comment

4dade689c06c7

Example

This method is most often used to get a reference to the global application object, in which case it can be called with no arguments. In this example, the application object is obtained so that a test can be made to see if the code is running on the front-end (client is 'site') or the back-end (client is 'administrator').

$app =& JFactory::getApplication();
if ($app->isSite())  echo 'Client is site';
if ($app->isAdmin()) echo 'Client is administrator';
Chris Davenport 14:46, 19 April 2011 (CDT) Edit comment

6-Final.png

A2Ggeir

Geir Thomas Jakobsen is a webdeveloper at A2G Grafisk AS in Bergen, Norway. He has worked with component development and hacks for Joomla for about 2 years.

Now working on: Learning the new 1.6 ish, woot!

ACHRAF

PAGINA EN CONSTRUCCION

ACL Action Access Component

  • Access Component. Open the component manger screens (User Manager, Menu Manager, Article Manager, and so on).

ACL Action Admin Login

  • Admin Login. Login to the back end of the site.

ACL Action Configure

  • Configure. Access the Options screen for a component.

ACL Action Create

  • Create. Create an object in the component (for example, create a user, article, contact, and so on).

ACL Action Delete

  • Delete. Delete an object in the component (for example, delete a user, article, contact, and so on).

ACL Action Edit

  • Edit. Edit an object in the component (for example, edit a user, article, contact, and so on).

ACL Action Edit Own

  • Edit Own. Edit component objects created by you. This is the same as the Edit action except that it only applies to objects created by the current user.

ACL Action Edit State

  • Edit State. Change the published state of an object in the component. Normal states include Published, Unpublished, Archived, and Trashed.

ACL Action Site Login

  • Site Login. Login to the front end of the site.

ACL Action Super Admin

  • Super Admin. Grants the user "super user" status. Users with this permission can do anything on the site. Only users with this permission can change Global Configuration settings (this screen). These permissions cannot be restricted. It is important to understand that, if a user is a member of a Super Admin group, any other permissions assigned to this user are irrelevant. The user can do anything action on the site. However, Access Levels can still be assigned to control what this group sees on the site. (Obviously, a Super Admin user can change Access Levels if they want to, so Access Levels do not totally restrict what a Super Admin user can see.)

ACL Calculated Settings

Important Note: The Calculated Settings column is only updated after you press the Save button. If you make changes to the permissions settings, press the Save button to see the updated Calculated settings.

The following values may be shown in the Calculated Settings column.

  • Allowed. Help16-ACL-Allowed.pngThis action is allowed for this group. This is because the action has been allowed at this level or at a higher level in the component/group hierarchy.
  • Not Allowed. Help16-ACL-Not-Allowed.pngThis action is not allowed for this group. This is because the action has not been allowed anywhere in the component/group hierarchy. This setting can be overridden.
  • Not Allowed (Locked). Help16-ACL-Not-Allowed-Locked.pngThis action is not allowed for this group. This is because the action has been denied at this level or a higher level in the component/group hierarchy. This setting can not be overridden at this level or for any lower level in the component/group hierarchy.

ACL Groups

  • Groups. Permissions are set for one group at a time. Click on the desired group to open the slider for that group.

ACL Help Screens

Access Control List or ACL is according to the Wikipedia definition, “...ACL specifies which users or system processes are granted access to objects, as well as what operations are allowed to be performed on given objects.” In the case of Joomla there are two separate aspects to its Access Control List which site administrators can control:

  • Which users can gain access to what parts of the website? For example, will a given menu choice be visible for a given user? A registered user can view, but the public at large cannot. Perhaps the menu choice is hidden from all except an Editor user and higher.
  • What operations (or actions) can a user perform on any given object? For example, can a user listed as an "Editor" submit an article or only edit an existing article. The ACL settings could allow submitting and editing, or allow a change an article's category, add tags or any combination.

The implementation of ACL in Joomla was substantially changed in the Joomla! 2.5 series which allowed for more flexibility in groups and permissions.



You are viewing a list of Help Screen pages under the category called Glossary.

ACL Help Screens/ca

Llista de Control d'accés o ACL està d'acord amb la [de la Wiquipedia], "...ACL especifica que els usuaris o sistema són els processos de permetre l'accés a objectes, així com quines operacions es poden realitzar a objectes donats." En el cas de Joomla hi ha separat en dues aspectes de la seva Llista de Control d'Accés que els administradors del web pot controlar:

  • Què usuaris poden accedir a quines parts del lloc web? Per exemple, tindran una opció de menú determinat de ser visible per a un usuari determinat? Un usuari registrat ho pot veure, però el públic en general no pot. Potser l'opció de menú està oculta a tots, excepte un usuari Editor i superior.
  • Quines operacions (o accions) pot realitzar un usuari en un objecte donat? Per exemple, un usuari pot figurar com "Editor" Enviar un article o només editar un article existent. Els paràmetres de l'ACL podrien permetre la submissió i l'edició, o permetre fer un canvi de categoria d'un article, afegir etiquetes o qualsevol combinació.

La implementació d'ACL a Joomla es va canviar substancialment a les series de Joomla! 2.5, que va permetre una major flexibilitat en els grups i permisos.



Estàs veient una llista de pàgines d'ajuda en pantalla sota la categoria anomenada "'Glossary"'.

ACL Help Screens/da

Access Control List or ACL is according to the Wikipedia definition, “...ACL specifies which users or system processes are granted access to objects, as well as what operations are allowed to be performed on given objects.” In the case of Joomla there are two separate aspects to its Access Control List which site administrators can control:

  • Which users can gain access to what parts of the website? For example, will a given menu choice be visible for a given user? A registered user can view, but the public at large cannot. Perhaps the menu choice is hidden from all except an Editor user and higher.
  • What operations (or actions) can a user perform on any given object? For example, can a user listed as an "Editor" submit an article or only edit an existing article. The ACL settings could allow submitting and editing, or allow a change an article's category, add tags or any combination.

The implementation of ACL in Joomla was substantially changed in the Joomla! 2.5 series which allowed for more flexibility in groups and permissions.



Du ser en liste over hjælpe skærmsider under kategorien kaldet Glossary.

ACL Help Screens/en

Access Control List or ACL is according to the Wikipedia definition, “...ACL specifies which users or system processes are granted access to objects, as well as what operations are allowed to be performed on given objects.” In the case of Joomla there are two separate aspects to its Access Control List which site administrators can control:

  • Which users can gain access to what parts of the website? For example, will a given menu choice be visible for a given user? A registered user can view, but the public at large cannot. Perhaps the menu choice is hidden from all except an Editor user and higher.
  • What operations (or actions) can a user perform on any given object? For example, can a user listed as an "Editor" submit an article or only edit an existing article. The ACL settings could allow submitting and editing, or allow a change an article's category, add tags or any combination.

The implementation of ACL in Joomla was substantially changed in the Joomla! 2.5 series which allowed for more flexibility in groups and permissions.



You are viewing a list of Help Screen pages under the category called Glossary.

ACL Help Screens/es

Una Lista de Control de Acceso o ACL (Access Control List) es, de acuerdo con su definición de Wikipedia, “...una forma de determinar los permisos de acceso apropiados a un determinado objeto”, así como qué operaciones pueden realizarse sobre un objeto dado. En el caso de Joomla, hay dos aspectos diferentes relativos a la Lista de Control de Acceso que los administradores del sitio pueden controlar:

  • ¿Qué usuarios pueden conseguir acceso a qué partes del sitio? Por ejemplo, ¿podrá una opción de menú determinada ser visible para un usuario concreto? Un usuario registrado puede verla, pero el público en general no. Quizás la opción de menú está oculta para todos excepto para un usuario Editor o superior.
  • ¿Qué operaciones (o acciones) puede llevar a cabo un usuario sobre un objeto determinado? Por ejemplo, ¿puede un usuario listado como "Editor" enviar un artículo o sólo editar uno existente? Las opciones de ACL podrían permitir enviar y editar, o permitir un cambio de categoría del artículo, añadir etiquetas o cualquier combinación.

La implementación de la ACL en Joomla! cambió sustancialmente en la versión 2.5, que permitió más flexibilidad en los grupos y permisos.



Está viendo una lista de páginas de Pantallas de Ayuda bajo la categoría Glossary.

ACL Help Screens/fr

La Liste de Contrôle d'Accès ou ACL (Access Control List) est selon la définition de Wikipédia, "...une liste d’Access Control Entry (ACE) ou entrée de contrôle d'accès donnant ou supprimant des droits d'accès à une personne ou un groupe". Dans le cas de Joomla!, deux aspects distincts de cette liste de contrôle d'accès permettent aux administrateurs de sites de contrôler :

  • Quels utilisateurs peuvent accéder à quelles parties du site? Par exemple, est-ce qu'un choix de menu donné sera visible pour un utilisateur donné ? Un utilisateur enregistré peut le voir, mais le grand public ne le pourra pas. Peut-être que le choix de menu est caché pour tous sauf pour un Editeur ou supérieur.
  • Quelles sont les opérations (ou actions) pouvant être réalisées par un utilisateur sur un objet donné ? Par exemple, est-qu'un utilisateur listé en tant qu'"Editeur" peut soumettre un article ou seulement modifier un article existant. Les paramètres d'ACL peuvent autoriser à soumettre et à modifier, ou autoriser un changement de catégorie d'article, ajouter des tags ou toute combinaison.

L'implémentation d'ACL dans Joomla! a été sensiblement modifiée dans les versions Joomla! 2.5 permettant une plus grande flexibilité au niveau des groupes et des permissions.



Vous êtes en train de consulter une liste de pages d'Écran d'aide pour la catégorie Écrans d'aide pour les listes de contrôle d'accès (ACL).

ACL Help Screens/nl

Access Control List of ACL is volgens de Wikipedia definitie, “...ACL bepaalt welke gebruikers of systeemprocessen toegang wordt verleend tot objecten, alsmede welke handelingen mogen worden uitgevoerd op die objecten.” Binnen Joomla zijn er twee aparte aspecten aan de Access Control List die websitebeheerders kunnen instellen:

  • Welke gebruikers hebben toegang tot welke delen van de website? Bijvoorbeeld, is een bepaalde menu-optie zichtbaar voor een bepaalde gebruiker? Een geregistreerde gebruiker kan bekijken, maar het grote publiek niet. Misschien is de menu keuze voor iedereen verborgen behalve voor een gebruiker met auteursrechten en hoger.
  • Welke handelingen (of acties) kan een gebruiker uitvoeren op een bepaald object? Bijvoorbeeld, kan een gebruiker met de rechten "Redacteur" een artikel indienen of alleen een bestaand artikel bewerken. De ACL-instellingen kunnen indienen en bewerken toestaan of het wijzigen van een artikelcategorie, toevoegen van tags of een combinatie daarvan.

De uitvoering van ACL in Joomla is aanzienlijk veranderd in Joomla! 2.5, waardoor het mogelijk is meer flexibiliteit in groepen en rechten toe te passen.



U bekijkt een lijst met Help Screen pagina's onder de categorie genaamd "'Glossary"'.

ACL Help Screens/ru

Согласно определения Википедии, Access Control List [список контроля доступа] или ACL, “...ACL указывает каким пользователям или системным процессам предоставляется доступ к объектам, а также какие операции разрешаются осуществлять над данными объектами.” В случае с [системой] Joomla, существуют два отдельных аспекта ее ACL [списка контроля доступа], которые администраторы веб-сайта могут контролировать:

  • Какие пользователи к какой части веб-сайта получают доступ? Например, будет ли данное выбранное меню видимо данному пользователю? Зарегистрированный пользователь сможет, но общая публика - нет. Возможно, выбор этого меню скрыт ото всех, за исключением пользователей-редакторов и пользователей с высшим [правом доступа].
  • Какие операции (или действия) какой-либо пользователь может осуществлять над любым конкретным объектом? Например, может ли пользователь, показанный как "Editor"[/редактор] создать какой-либо материал или [он может] только редактировать какой-либо существующий материал? Настройки ACL могут разрешить создание и редактирование, или разрешить вносить изменения в категорию данного материала, [или] разрешить добавлять метки, или [разрешить] любую комбинацию [из этого].

Применение ACL [списка контроля доступа] в Joomla было существенно изменено в серии [версий] Joomla! 2.5, что предоставило группам и правам больше гибкости.



Вы просматриваете список веб-страниц с экранами справки для категории под названием Glossary.

ACL Publish.png

ACL Select New Setting

The Select New Setting Options as as follows:

  • Inherited. Inherited from a parent group or a higher level in the component hierarchy. Can result in this action being allowed or not allowed for this group, depending on what permission is set at a higher level in the group/component hierarchy.
  • Allowed. This action is allowed for this group.
  • Allowed - Conflict. Help16-ACL-Conflict.pngThis group is given Allowed permission for this action. However, this permission is overridden by a Denied permission at a higher level in the group/component hierarchy. So this group does not have permission for this action and will show as Not Allowed in the calculated Setting column.
  • Denied. This action is denied for this group. This will also deny this action for any groups or components at a lower level in the group/component hierarchy.

ADFS-ConfigJoomla1.5.png

Licensing:

Documentation all together tranparent small.png
Joomla Electronic Documentation License

This article is licensed under the Joomla! Electronic Documentation License. It grants you certain rights to use, modify and distribute documentation associated with the Joomla! project. It is designed to foster wide electronic distribution of Joomla! documentation while ensuring that any material added to the documentation by you or others can be taken up and made part of the authoritative documentation distributed by the Joomla! project.


ADFS-ConfigJoomla1.6.png

Licensing:

Documentation all together tranparent small.png
Joomla Electronic Documentation License

This article is licensed under the Joomla! Electronic Documentation License. It grants you certain rights to use, modify and distribute documentation associated with the Joomla! project. It is designed to foster wide electronic distribution of Joomla! documentation while ensuring that any material added to the documentation by you or others can be taken up and made part of the authoritative documentation distributed by the Joomla! project.

ADFS-ConfigWindowsLiveID-Joomla1.5.png

Licensing:

Documentation all together tranparent small.png
Joomla Electronic Documentation License

This article is licensed under the Joomla! Electronic Documentation License. It grants you certain rights to use, modify and distribute documentation associated with the Joomla! project. It is designed to foster wide electronic distribution of Joomla! documentation while ensuring that any material added to the documentation by you or others can be taken up and made part of the authoritative documentation distributed by the Joomla! project.


ADFS-ConfigWindowsLiveID-Joomla1.6.png

Licensing:

Documentation all together tranparent small.png
Joomla Electronic Documentation License

This article is licensed under the Joomla! Electronic Documentation License. It grants you certain rights to use, modify and distribute documentation associated with the Joomla! project. It is designed to foster wide electronic distribution of Joomla! documentation while ensuring that any material added to the documentation by you or others can be taken up and made part of the authoritative documentation distributed by the Joomla! project.

ADFS-ConfigWindowsLiveID.png

ADFS-ConfigWindowsLiveIDJoomla.png

Licensing:

Documentation all together tranparent small.png
Joomla Electronic Documentation License

This article is licensed under the Joomla! Electronic Documentation License. It grants you certain rights to use, modify and distribute documentation associated with the Joomla! project. It is designed to foster wide electronic distribution of Joomla! documentation while ensuring that any material added to the documentation by you or others can be taken up and made part of the authoritative documentation distributed by the Joomla! project.


ADFS-RelyingPartyTrustConfig-1.png

Summary

ADFS-RelyingPartyTrustConfig-1.png

Licensing:

Documentation all together tranparent small.png
Joomla Electronic Documentation License

This article is licensed under the Joomla! Electronic Documentation License. It grants you certain rights to use, modify and distribute documentation associated with the Joomla! project. It is designed to foster wide electronic distribution of Joomla! documentation while ensuring that any material added to the documentation by you or others can be taken up and made part of the authoritative documentation distributed by the Joomla! project.


ADFS-RelyingPartyTrustConfig-10.png

Licensing:

Documentation all together tranparent small.png
Joomla Electronic Documentation License

This article is licensed under the Joomla! Electronic Documentation License. It grants you certain rights to use, modify and distribute documentation associated with the Joomla! project. It is designed to foster wide electronic distribution of Joomla! documentation while ensuring that any material added to the documentation by you or others can be taken up and made part of the authoritative documentation distributed by the Joomla! project.


ADFS-RelyingPartyTrustConfig-11.png

Licensing:

Documentation all together tranparent small.png
Joomla Electronic Documentation License

This article is licensed under the Joomla! Electronic Documentation License. It grants you certain rights to use, modify and distribute documentation associated with the Joomla! project. It is designed to foster wide electronic distribution of Joomla! documentation while ensuring that any material added to the documentation by you or others can be taken up and made part of the authoritative documentation distributed by the Joomla! project.


ADFS-RelyingPartyTrustConfig-12.png

Licensing:

Documentation all together tranparent small.png
Joomla Electronic Documentation License

This article is licensed under the Joomla! Electronic Documentation License. It grants you certain rights to use, modify and distribute documentation associated with the Joomla! project. It is designed to foster wide electronic distribution of Joomla! documentation while ensuring that any material added to the documentation by you or others can be taken up and made part of the authoritative documentation distributed by the Joomla! project.


ADFS-RelyingPartyTrustConfig-13.png

Licensing:

Documentation all together tranparent small.png
Joomla Electronic Documentation License

This article is licensed under the Joomla! Electronic Documentation License. It grants you certain rights to use, modify and distribute documentation associated with the Joomla! project. It is designed to foster wide electronic distribution of Joomla! documentation while ensuring that any material added to the documentation by you or others can be taken up and made part of the authoritative documentation distributed by the Joomla! project.


ADFS-RelyingPartyTrustConfig-2.png

Licensing:

Documentation all together tranparent small.png
Joomla Electronic Documentation License

This article is licensed under the Joomla! Electronic Documentation License. It grants you certain rights to use, modify and distribute documentation associated with the Joomla! project. It is designed to foster wide electronic distribution of Joomla! documentation while ensuring that any material added to the documentation by you or others can be taken up and made part of the authoritative documentation distributed by the Joomla! project.


ADFS-RelyingPartyTrustConfig-3.png

Licensing:

Documentation all together tranparent small.png
Joomla Electronic Documentation License

This article is licensed under the Joomla! Electronic Documentation License. It grants you certain rights to use, modify and distribute documentation associated with the Joomla! project. It is designed to foster wide electronic distribution of Joomla! documentation while ensuring that any material added to the documentation by you or others can be taken up and made part of the authoritative documentation distributed by the Joomla! project.


ADFS-RelyingPartyTrustConfig-4.png

Licensing:

Documentation all together tranparent small.png
Joomla Electronic Documentation License

This article is licensed under the Joomla! Electronic Documentation License. It grants you certain rights to use, modify and distribute documentation associated with the Joomla! project. It is designed to foster wide electronic distribution of Joomla! documentation while ensuring that any material added to the documentation by you or others can be taken up and made part of the authoritative documentation distributed by the Joomla! project.


ADFS-RelyingPartyTrustConfig-5.png

ADFS-RelyingPartyTrustConfig-6.png

Licensing:

Documentation all together tranparent small.png
Joomla Electronic Documentation License

This article is licensed under the Joomla! Electronic Documentation License. It grants you certain rights to use, modify and distribute documentation associated with the Joomla! project. It is designed to foster wide electronic distribution of Joomla! documentation while ensuring that any material added to the documentation by you or others can be taken up and made part of the authoritative documentation distributed by the Joomla! project.


ADFS-RelyingPartyTrustConfig-7.png

Licensing:

Documentation all together tranparent small.png
Joomla Electronic Documentation License

This article is licensed under the Joomla! Electronic Documentation License. It grants you certain rights to use, modify and distribute documentation associated with the Joomla! project. It is designed to foster wide electronic distribution of Joomla! documentation while ensuring that any material added to the documentation by you or others can be taken up and made part of the authoritative documentation distributed by the Joomla! project.


ADFS-RelyingPartyTrustConfig-8.png

Licensing:

Documentation all together tranparent small.png
Joomla Electronic Documentation License

This article is licensed under the Joomla! Electronic Documentation License. It grants you certain rights to use, modify and distribute documentation associated with the Joomla! project. It is designed to foster wide electronic distribution of Joomla! documentation while ensuring that any material added to the documentation by you or others can be taken up and made part of the authoritative documentation distributed by the Joomla! project.


ADFS-RelyingPartyTrustConfig-9.png

Licensing:

Documentation all together tranparent small.png
Joomla Electronic Documentation License

This article is licensed under the Joomla! Electronic Documentation License. It grants you certain rights to use, modify and distribute documentation associated with the Joomla! project. It is designed to foster wide electronic distribution of Joomla! documentation while ensuring that any material added to the documentation by you or others can be taken up and made part of the authoritative documentation distributed by the Joomla! project.


{{:Translations:ADFS 2.0 Relying Party Trust Configuration/Page_display_title/<lang code>‎}}

This document explains how to configure the Relying Party Trust in ADFS 2.0 manually.

Prerequisites

  1. Relying party identifier
  2. Token encryption certificate(.crt file)
  3. WS-Federation Passive redirection URL.

Installation
The below screen captures will show you how to set up the ADFS Relying Party Trust manually.

  1. ADFS 2.0 Management

    Open ADFS 2.0 Management tool from Administrative tools

    AD FS 2.0 Management

  2. Relying Party Trust Wizard

    Relying Party Trust Wizard

  3. Select Data Source

    Select the option ‘Enter data bout the relying party manually’

    Select Data Source

  4. Specify Display Name

    Provide the display name for the relying party. This is the friendly name that can be used to quickly identify the relying party in ADFS 2.0 Management Console.
    For simplicity, we recommend this to be same as the relying party identifier.

    Specify Display Name

  5. Choose Profile

    Select the option ‘ADFS 2.0 profile’

    Choose Profile

  6. Configure Certificate - Optional

    If you need the response encrypted, please choose your certificate file here.

    Configure Certificate - Optional

  7. Configure URL

    Configure the WS Federation Passive protocol URL

    Configure URL

  8. Configure Identifiers

    Configure identifier for relying party

    Configure Identifiers

  9. Choose Issuance Authorization Rules

    Choose Issuance Authorization Rules

  10. Open Claim Rules

    After finishing the configuration, you can choose to open the claim rules dialog directly

    Open Claim Rules

  11. Edit Claim Rules

    Edit Claim Rules

  12. Select Rule Template

    Choose ‘Send LDAP Attributes as Claims’

    Select Rule Template

  13. Edit Rule

    Edit the required claims. You need to provide ‘Name ID’ outgoing claim type as mandatory

    Edit Rule

Known Limitations
  • Current solution is tested for keys with 1024 size. This might show you a warning while configuring the certificate.


References

  • Configure Relying Party Trust Manually
  • Open SSL Commands to create test certificates
    • openssl genrsa -des3 -out adfs-simplesaml.key 1024
    • openssl rsa -in adfs-simplesaml.key -out adfs-simplesaml.pem
    • openssl req -new -key adfs-simplesaml.key -out adfs-simplesaml.csr
    • openssl x509 -req -in adfs-simplesaml.csr -signkey adfs-simplesaml.key -out adfs-simplesaml.crt

{{:Translations:AJAX/Page_display_title/<lang code>‎}}

Copyedit.png
This Article Needs Your Help

This article is tagged because it NEEDS IMPROVEMENT. You can help the Joomla! Documentation Wiki by contributing to it.
More pages that need help similar to this one are here. NOTE-If you feel the need is satistified, please remove this notice.


Asynchronous JavaScript and XML or AJAX, is a term for a group of interrelated web development techniques used for creating interactive web applications or commonly known as web 2.0. Ajax allows web applications to retrieve data from the server asynchronously in the background without interfering with the display and behavior of the existing website page. Data is retrieved using the XMLHttpRequest object or through the use of Remote Scripting in browsers that do not support it.

Using AJAX in Joomla

Javascript Resources:

  1. jQuery
  2. MooTools
  3. Prototype
  4. Script.aculo.us
  5. Help I Don’t Know JavaScript Blog

{{:Translations:AJAX/Page_display_title/<lang code>‎}}

This category is for documentation on using AJAX in Joomla Extensions.

AJAX/bg

Тази категория е предназначена за документация за използване на AJAX в Joomla.

AJAX/ca

Aquesta categoria és per a la documentació sobre l'ús d'AJAX a extensions de Joomla.

AJAX/en

This category is for documentation on using AJAX in Joomla Extensions.

AJAX/es

Esta categoría es para documentación sobre la utilización de AJAX en Extensiones para Joomla.

AJAX/fr

Cette catégorie se rapporte à la documentation pour l'utilisation d'AJAX dans les extensions Joomla.

AJAX/nl

Deze categorie is voor documentatie over het gebruik van AJAX in Joomla extensies.

AJAX/ru

Эта категория предназначена для документации по использованию AJAX в расширениях Joomla.

AJAX and Content History menu items are displaying in the components menu

When a site is upgraded from Joomla 3.1 to 3.2 using FTP or another manual upgrade, a number of extensions show up through the discover install method.

Versions affected

Info non-talk.png
General Information

This pertains only to Joomla! version(s):- 3.2.x


What is the cause

When Discovery Install is used for those extensions, AJAX and Content History show up in Components sub-menu.

How to fix

Create a backup, then delete the "com_ajax" entry in the _menu table (you can search for it in the title column). Afterward, delete the "com_contenthistory" entry in the same table.

You can remove that using phpMyAdmin dropping the row in #__menu that refers to com_ajax.

DELETE FROM `#__menu` WHERE component_id = (SELECT extension_id FROM `#__extensions` WHERE `name` = 'com_ajax')

Replace #_ with your prefix

ANVGC

dckdekfk ffkrfkrfkrfkrfk flgmlennf clelel

{{:Translations:API/Page_display_title/<lang code>‎}}

The Joomla Content Management System (CMS) is built on top of a core of code which presents a standard Application programming interface or API to the applications built on it.

Although Joomla 1.0.x (and its predecessor, Mambo) had a core of code with a defined API, this was not well-structured and did not use modern design practices. The development of Joomla 1.5 presented the opportunity to completely restructure the foundations and resulted in the Joomla Framework which introduced design patterns such as Model-View-Controller (MVC) and Observer to the Joomla codebase. Although it is possible to build web applications on top of the Joomla Framework without involving the Joomla CMS some dependencies still exist and this continues to be true to a lesser degree with Joomla 1.6.

It has long been the plan to distribute the core Framework separately from the CMS, making it easier to build and distribute non-CMS applications without the overhead of having to include some of the CMS code. This plan is finally coming to fruition with the newly-branded Joomla Platform. Currently slated for its first release on 30 April 2011, this will be developed in a separate repository and on a different release cycle to the CMS.

See Also

Aaleksanyants

Հարգելի հայրենակիցներ,

Կոչ եմ անում միանալ Joomla-ի միջերեսի և ուղեցույցի Հայերեն թարգմանության գործընթացին։ Գրանցվե՜ք docs.joomla.org կայքում և տողեք ձեր հաղորդագրությունը User_talk:Aaleksanyants էջում։

--Aaleksanyants (talk) 04:58, 27 June 2015 (CDT)

Aaqqok

thank you ,i very happy,Your blog disger very well.

About


The Joomla! Documentation Wiki contains collaborative community-contributed documentation for the Joomla! project.

Documentation Policies and Guidelines

Documentation Help

JDOC Projects (Helping with documentation)

Our documentation relies on will volunteers to help write and maintain our articles. Please think about helping by joining a documentation project. Check out our listing of all Doc Projects or here are a specific few.

Joomla! Electronic Documentation License

Privacy policy

About/en


The Joomla! Documentation Wiki contains collaborative community-contributed documentation for the Joomla! project.

Documentation Policies and Guidelines

Documentation Help

JDOC Projects (Helping with documentation)

Our documentation relies on will volunteers to help write and maintain our articles. Please think about helping by joining a documentation project. Check out our listing of all Doc Projects or here are a specific few.

Joomla! Electronic Documentation License

Privacy policy

About/es


The Joomla! Documentation Wiki contains collaborative community-contributed documentation for the Joomla! project.

Documentation Policies and Guidelines

Documentation Help

JDOC Projects (Helping with documentation)

Our documentation relies on will volunteers to help write and maintain our articles. Please think about helping by joining a documentation project. Check out our listing of all Doc Projects or here are a specific few.

Joomla! Electronic Documentation License

Privacy policy

About/fr


La documentation Wiki de Joomla! est une documentation collaborative élaborée par la communauté pour le Projet Joomla.

Politiques et lignes directrices de la documentation

Aide de la documentation

Projets JDOC (aide à la documentation)

Notre documentation repose sur la bonne volonté des bénévoles à contribuer à l'écriture et la mise à jour de nos articles. Aidez-nous en rejoignant le projet de la documentation. Consultez notre liste de tous les projets de la documentation ou en voici quelques uns :

Joomla! Electronic Documentation License

Politique de confidentialité

About/nl


De Joomla! documentatie Wiki bevat door de community bijgedragen documentatie voor het Joomla! project.

Documentatiebeleid en richtlijnen

Documentatie hulp

JDOC projecten (Helpen met documentatie)

Onze documentatie is gebaseerd op of vrijwilligers willen helpen met schrijven en onderhouden van onze artikelen. Denk aub na over het helpen door aan een documentatie project deel te nemen. Bekijk onze lijst met alle Documentatie projecten of hier staan er een paar.

Joomla! elektronische documentatie licentie

Privacybeleid

{{:Translations:About CSS page layouts/Page_display_title/<lang code>‎}}

Professional websites separate styling from content. There are many reasons for this, the most obvious (to a developer) being the ability to control the appearance of many pages by changing one file. Styling information includes: fonts; backgrounds; images (that recur on every page); position and dimensions of elements on the page. Your HTML file will now be left with: header information; a series of elements; the text of your website. Because you are creating a Joomla! template, you will actually have: some header information; php code to request the rest of the header information; a series of elements; php code to request each module position; php code to request the main content.

Style information is coded in CSS, cascading style sheet, and usually stored in files with the suffix .css. A webpage contains a link to the associated .css file so a browser can find the appropriate style information to apply to the page. CSS can also be placed inside a html file between <style type="text/css"></style> tags.

All CSS code is applied to an element of the html/xml page. If you want a style to encompass a whole page, you would probably apply it to the <body> element. You can apply styles to any html element such as <p>, <table> or <div> elements. To style a particular element it needs to have an ID. For example, to apply styles to the <div> containing the title, you would first include an ID in the html - <div ID="title">.

About Joomla

{{:Translations:Absolute Basics of How a Component Functions/Page_display_title/<lang code>‎}}

Copyedit.png
This Article Needs Your Help

This article is tagged because it NEEDS REVIEW. You can help the Joomla! Documentation Wiki by contributing to it.
More pages that need help similar to this one are here. NOTE-If you feel the need is satistified, please remove this notice.


This document describes the absolute basics of how a component functions in the most basic ways. It is written for beginner developers to read to help them understand how a basic Joomla! component works.

Entering the Platform

You enter the Joomla! Platform by making calls to index.php. Joomla! is designed mainly to deliver the results of component files. When you call a page link, like index.php?option=com_<name>, the Joomla! Platform tries to find and load the file components/com_<name>/<name>.php from whichever folder you have installed Joomla! into. So, if your component is 'com_read' you should have a 'com_read' folder and a file named 'read.php' inside of it. I will call this file the 'base file'. It is in this file that you make the decision whether to use an old flat model (returning the HTML code for the requested page) or to use a Model-View-Controller (MVC) pattern.

This MVC model, walks over two legs: a file and a class. The Joomla! Platform will usually look for a given file and, if found, tries to register a specific class within this file. If either one is missing the call will fail.

Your controller.php File

You start all the fireworks by including a reference to a controller file in your base file. The controller file can be named anything you want, but by convention it is called 'controller.php'. In your base file (<name>.php), the following code is typical:

require_once(JPATH_COMPONENT . '/controller.php');

Your controller.php file can be created anywhere you want because you are referencing it by path. If you have written the code exactly as shown above, it should be created in the same location where your base file is located because JPATH_COMPONENT holds the path where the executing component base file is.

So create controller.php and make a reference to the library inside by importing it with:

jimport('joomla.application.component.controller');

Now that you have controller.php included and the base JControllerLegacy class imported, you have to define a class that extends the JControllerLegacy base class. This is the class leg mentioned earlier. It is here where your action will happen. You can name this class as you like but, by convention, it is named after your component so you write:

class <Name>Controller extends JControllerLegacy
{
}

In this stage you have your first two files, the base file and the controller file. The base file loads the controller and the controller defines a class. So far so good and easy. The next step is to create an object of this class and to put it to work. So add the following lines to your base file:

// Get an instance of the controller prefixed by <name>
$controller = JControllerLegacy::getInstance('<Name>');
 
// Perform the Request task
$controller->execute(JFactory::getApplication()->input->getCmd('task'));
 
// Redirect if set by the controller
$controller->redirect();

From this point on things start happening by themselves. Up to now you were able to name files/classes (except for the base one) and store them where you want because you were including the files by path/name and calling your classes by name within your code. (Well, only one file and only one class actually, but you could do it!) From now on the Joomla! Platform will begin loading your files and calling your classes automatically, so you must be careful where you put your files, what you name them, and what classes you define. A single letter mismatch will make Joomla! fail.

Getting the Data

Where does the Joomla! Platform get the data to play? Well, the answer is easy: from the request, be it a GET request or a POST request. But you have NOT written anything else in the request except option=com_<name>. Where does the 'task' in the execute call come from? Do you really have a meaningful 'task' variable?

Yes, and therein lies a 'problem': Whether you pass a request or not, Joomla! will use its defaults to complete a request, making some errors difficult to spot.

The controller->execute() call will make the Joomla! Platform try to do a request that, in this case, will be the default task 'display', because you have not specified otherwise.

class <Name>Controller extends JControllerLegacy
 
{
  function display()
  {
    echo 'displaying';
  }
}

If your request contained a 'task=jump' parameter the controller would have tried to call a method (function) named 'jump' in your controller class:

class <Name>Controller extends JControllerLegacy
{
  function jump()
  {
    echo 'jumping';
  }
}

The View

Up to now you have delved into the controller part of the model. This is a new point of decision. You can stop here or go a step further and enter the view part.

The different tasks given to the controller are methods in the controller.php file. All the needed variables are available from the Platform, so you will be able to retrieve them easily.

There is nothing that forces you to use the 'task' variable to drive the call because you can pass the value of any variable as the parameter to the execute method call. But in order to stick to the non-written rules, 'task' is usually used and as it is treated specially by the system, it is a good idea to stick with it.

To trigger the views, you have to call the __construct() method of JControllerLegacy. Do this by inserting, in your method, a call to parent::__construct() as in the last line. At a minimum, your controller file should contain the following:

jimport('joomla.application.component.controller');
 
class <name>Controller extends JControllerLegacy
{
}

What's a view? A view is a subset of data. It's the same concept as views in SQL parlance. You deliver different parts of your data with different views. So you could have a detailed data view and a resumed data view, the later presenting a subset of the whole data presented in the former.

As you can have multiple views, Joomla! uses the 'views' folder in your component's base directory to keep things tidy. This folder is only a placeholder for your views. This means that you need to create a views folder with a hierarchy that looks like this:

<name> base folder
  controller.php
  <component_name>.php
  'views' folder
     view1 folder
     view2 folder
     ...

Inside the views folder, other folders hold the files that build each view. The Joomla! Platform includes a file named view.html.php that should exist in your view folder. A bit messy, I know, so I'll try to explain.

When you built your request, you included a variable named 'view' that tells the MVC model what view you want. Or, if you did not include it, you need to include it now because there is no such a thing as a default view. So your URL is something like:

http://example.com/index.php?option=com_<name>&view=<myview>[&task=<mytask>]

The task part may or may not exist. Remember that if you omit it, you are defaulting to task=display. With this URL Joomla! is importing a file located at <site root dir>/components/<name>/views/<myview>/view.html.php. If this file or the path does not exist, Joomla! will fail. By simply swapping the value of the view, you deliver different views of your data.

Every request for a view requires that you also specify the format in which you are serving the view. There exist several well known formats such as html (the default one if none is specified), rss, etc. or you can use your own. If no format is specified in the request with the 'format=<myformat>' parameter a default value of 'html' is used.

The 'html' format makes the Joomla! Platform wrap the response in whatever template your site is using so that you get a fully built HTML page. This way, with very little effort from you, you get back your page fully loaded with modules or whatever you had configured.

The specific format you are using needs to be included in the middle part of the name of the file in your view folder (The file we talked about a few lines before 'view.html.php'). If you use a different format like 'rss' your file should be named after it like view.rss.php. Get it?

As mentioned before, you can have formats other than html and Joomla! will not wrap the template on them. You could have a 'pdf' format to deliver your data in pdf format or even an 'ajax' format to deliver ajax responses to the front-end easily. Just construct your URL like

http://example.com/index.php?option=com_<name>&view=<myview>&format=ajax

to make the Joomla! Platform look for and load the file view.ajax.php located at <site root dir>/components/<name>/views/<myview>/ from which you can echo anything you want. It's that easy.

Anyway, to achieve your goal, you will need some code inside the view.<format>.php file. You have the view file, now you need the view class. You have to extend the JView class with your own class following the strict rules mentioned before. In this case, your class name must be built by concatenating the component name, the word 'View', and the view name. So your class name will be a capitalized <name>View<myview>. If your component is named 'travels' and your view is named 'detail' (URL ...?option=com_travels&view=detail) your view class must be:

class TravelsViewDetail extends JViewLegacy
{
  function display($tpl=null)
  {
    echo 'blah, blah';
  }
}

Within this class, you only have to feed the data you want to display for your component under this specific case. You can do this directly by delivering the HTML code directly, or through calls to echo inside php tags, or be more subtle and use a layout (more on this later).

Can you have other functions besides display? I don't know. This is something that the gurus must answer. Where does the display function come from? Again, I don't know. Hope that someone else can help here.

Now you can go a bit further. Up to this point, you have a distributed Platform that dissects your request in such a way that allows you to create small and very specific files to react only to specific types of requests. In this way, the files that you must process can be very small and adjusted to the situation you are treating. This will speed up the global response time of the system by not loading a bunch of code that will never be used with these kinds of requests.

Having reached this point, you can dissect a bit more and have another layer of detail: the final layout for the data you deliver.

A layout is a way to present the data for the view. The same data can be delivered under different visual aspects so that the same preparation code (inside the display function of your view class) can present the same data in different ways simply using different files. You 'inject' the view data into the layout template and use the template code to visually format it for presenting to the user.

As before, if you do not specify a layout, the 'default' layout will be used. To use layouts you need to create a new folder under the related view folder named 'tmpl' and create a file named <mylayout>.php, nothing more, nothing less. If you are using the default layout this file will be named 'default.php'.

The desired layout can be specified in the request by means of a 'layout=<mylayout>' variable or can be injected in the call if you manage to get the layout you want to use from other sources.

To use a layout, your view class must call 'parent::display();' and pass the layout template name as a parameter. So your class should be:

class <Name>View<Viewname> extends JViewLegacy
{
  function display($tpl=null)
  {
    // Prepare the data
    $data1 = ....
    $data2 = ....
    $moredata[] = array....
 
    // Inject the data
    $this->variablename = $data1;
    $this->variablename2 = $data2;
    $this->variablename3 = $moredata;
 
    // Call the layout template. If no tpl value is set Joomla! will look for a default.php file
    $tpl = 'myTemplate';
    parent::display($tpl);
  }
}

This way, Joomla! will look for a file named 'myTemplate.php' in the 'tmpl' folder of the given view. Inside this template file you get a '$this' object that has access to the variables you have injected by means of '$this->variablename' that you can use in your constructions to deliver your HTML *FINAL* code.

As you will have determined by now, you can have different layout files in your tmpl folder, which can easily drive your output with simple, small, very specific files.

If you have been observant, you will have noticed that you have not 'used' the 'model' part of MVC model. Here you have the last point of decision. You can go without this part or fully apply the model, but I think I will keep this tale for another session, for I am sure that I have already abused my audience.

{{:Translations:Absolute Basics of How a Component Functions/Page_display_title/<lang code>‎}}

Just want to say this is a great topic and an article from which I learnt a lot. Perhaps it should feature more prominently.

Over recent weeks I've been struggling with understanding how it all hangs together grabbing snippets all over the place, reading through loads of the php source, slow & difficult progress.

I have no doubt it would have taken me several more days to workout that the 'task' was defaulting to display and that I could name my own controller methods (like jump) and have them activated by a URL parameter. (The sort of stuff I imagine every PHP developer coming to Joomla would want to know).

The article may also be a bit dated now with 1.7 I see the demo Hello World MVC component involves 4 files ?? (Basefile + M+V+C) ? Anyway, well done great article and lots of gems of knowledge about how Joomla works. Thanks

Missing in Instructions

//Hi, I have tried to follow these instructions, and found a few missing things.
Setting up my controller.php was missing the following statement in the display class:
 
return parent::display();
 
//Without this, the instructions don't work.

Cwurtz (talk) 03:07, 14 December 2013 (CST)

Feel free to correct it. Tom Hutchison (talk) 10:57, 14 December 2013 (CST)

Abuse filter

This user is an automatically created bot for use in spam prevention, malicious and other non-malicious editing activities. Its main focus is aimed at new users, but it will watch older accounts without any previous edits.

New Users

Welcome to our wiki!

We know your experience will be pleasant and you will find there is an abundance of people waiting to help you get the most enjoyable experience out of using the Joomla! CMS. As a member of the community, we really want you to contribute to our wiki and hope you will come back again and again. It takes contributions from Joomla! users like you to make this wiki possible.

Here are a few things to remember as a new user:

  • Don't take it personally if this bot stops you from performing an edit, on occasion it can't distinguish good users from bad.
  • While Wiki policy allows for links to your personal website with conditions, you should perform some edits on other pages without trying to insert or even correct an external link on any page, including your User page.
  • Once this bot sees you have performed some good edits, it will lose interest.
  • If you do accidentally trip this bot, you'll have to go to Special:Preferences and re-confirm your email address.

Thanks for reading! Abuse filter (talk) 22:47, 13 September 2013 (CDT)

Abusefilter-selflink

Hi editor, our system noticed you created a self domain link with this recent edit to our url at http://docs.joomla.org. Please consider altering the self link in this edit to correctly link to other pages on Joomla! Documentation.

For example, change the link from
 http://docs.joomla.org/Pagename to [[Pagename]] or...
[http://docs.joomla.org/Pagename Pagename] to [[Pagename]] or [[Pagename|Pagename alternate text]]
  • If you need help with editing, see our editing Cheatsheet.
  • If you feel you really need to save the link using this method of link creation, you may click save again.

Abusefilter-username

Stop hand nuvola.svg.png
Username is too long!

Warning: You're username is extremely long and has been flagged as a possible bot generated username. The maximum length of usernames on this wiki is 18 characters.

Abusefilter-warning

Warning: This action has been automatically identified as link spamming. Unconstructive edits will be quickly reverted, and egregious or repeated unconstructive editing will result in your account or IP address being blocked. If you believe this edit to be constructive, you will first have to preform edits which do not contain links. A brief description of the abuse rule which your action matched is: $1

Abusefilter-warning-key-word-filter

Warning: This action has been automatically identified as spam and your account reset to email unconfirmed. Edits of this nature are blocked automatically or quickly reverted. Egregious or repeated editing of this nature will result in your IP address being blocked. If you believe this edit to be constructive, you must re-confirm you user accounts email. It is suggested you first contact a wiki sysop before trying to resubmit the edit. A brief description of the abuse rule which your action matched is: $1

Abusefilter-warning-page-blanking

Info non-talk.png
General Information

PLEASE DON'T BLANK PAGES

  • To change the title of the page, please use the move tab at the top of the page. This preserves the page history, but please be sure your reasons for moving the page are valid.
  • If a page should be deleted for some reason, please edit the page and add {{delete|Reason}} (replacing Reason with reason= and your reason for deletion).
If you are certain that your action is correct, click the Save button again.

Acceptance.suite.dist.yml rename.png

Summary

Screenshot of rename the "acceptance.suite.dist.yml" file to "acceptance.suite.yml" and configure the parameters to your system variables

Licensing

Documentation all together tranparent small.png
Joomla Electronic Documentation License

This article is licensed under the Joomla! Electronic Documentation License. It grants you certain rights to use, modify and distribute documentation associated with the Joomla! project. It is designed to foster wide electronic distribution of Joomla! documentation while ensuring that any material added to the documentation by you or others can be taken up and made part of the authoritative documentation distributed by the Joomla! project.


Access Control


Access Control List or ACL is according to the Wikipedia definition, “...ACL specifies which users or system processes are granted access to objects, as well as what operations are allowed to be performed on given objects.” In the case of Joomla there are two separate aspects to its Access Control List which site administrators can control:

  • Which users can gain access to what parts of the website? For example, will a given menu choice be visible for a given user? A registered user can view, but the public at large cannot. Perhaps the menu choice is hidden from all except an Editor user and higher.
  • What operations (or actions) can a user perform on any given object? For example, can a user listed as an "Editor" submit an article or only edit an existing article. The ACL settings could allow submitting and editing, or allow a change an article's category, add tags or any combination.

The implementation of ACL in Joomla was substantially changed in the Joomla! 2.5 series which allowed for more flexibility in groups and permissions.

Access Control/bg


Access Control List или ACL, показва начина, по който на потребителите или системните процеси се предоставя достъп до обекти, колкото да може да се изпълнят необходимите операции за тези обекти. В случая с Joomla, има два отделни аспекта на ACL, които администраторите на сайта могат да контролират:

  • "'Кои потребители имат достъп до различните части на сайта?"' Например, ще се вижда ли дадено меню за даден потребител? Регистриран потребител е в състояние, но останалите потребители(нерегистрирани) - не. Може би, това меню е скрито за всички, с изключение на потребителите редактори и потребители с по-висш достъп.
  • "'Какъв вид работа (или дейност) даден потребител може да упражнява върху всеки конкретен обект?"' Например дали потребителят с права "Редактор" може да създава статии или може само да редактира съществуващи вече статии? Настройки на ACL позволяват създаването и редактирането или възможността да се правят промени в категорията на дадена статия, позволяване за добавяне на тагове, или някаква друга комбинация от права и достъп.

Прилагането на ACL в Joomla е значително променено във версия Joomla! 2.5, която за по - голяма гъвкавост предоставя групи и различни права към тях.

Access Control/ca


Access Control List or ACL is according to the Wikipedia definition, “...ACL specifies which users or system processes are granted access to objects, as well as what operations are allowed to be performed on given objects.” In the case of Joomla there are two separate aspects to its Access Control List which site administrators can control:

  • Which users can gain access to what parts of the website? For example, will a given menu choice be visible for a given user? A registered user can view, but the public at large cannot. Perhaps the menu choice is hidden from all except an Editor user and higher.
  • What operations (or actions) can a user perform on any given object? For example, can a user listed as an "Editor" submit an article or only edit an existing article. The ACL settings could allow submitting and editing, or allow a change an article's category, add tags or any combination.

The implementation of ACL in Joomla was substantially changed in the Joomla! 2.5 series which allowed for more flexibility in groups and permissions.

Access Control/en


Access Control List or ACL is according to the Wikipedia definition, “...ACL specifies which users or system processes are granted access to objects, as well as what operations are allowed to be performed on given objects.” In the case of Joomla there are two separate aspects to its Access Control List which site administrators can control:

  • Which users can gain access to what parts of the website? For example, will a given menu choice be visible for a given user? A registered user can view, but the public at large cannot. Perhaps the menu choice is hidden from all except an Editor user and higher.
  • What operations (or actions) can a user perform on any given object? For example, can a user listed as an "Editor" submit an article or only edit an existing article. The ACL settings could allow submitting and editing, or allow a change an article's category, add tags or any combination.

The implementation of ACL in Joomla was substantially changed in the Joomla! 2.5 series which allowed for more flexibility in groups and permissions.

Access Control/es


Una Lista de Control de Acceso o ACL (Access Control List) es, de acuerdo con su definición de Wikipedia, “...una forma de determinar los permisos de acceso apropiados a un determinado objeto”, así como qué operaciones pueden realizarse sobre un objeto dado. En el caso de Joomla, hay dos aspectos diferentes relativos a la Lista de Control de Acceso que los administradores del sitio pueden controlar:

  • ¿Qué usuarios pueden conseguir acceso a qué partes del sitio? Por ejemplo, ¿podrá una opción de menú determinada ser visible para un usuario concreto? Un usuario registrado puede verla, pero el público en general no. Quizás la opción de menú está oculta para todos excepto para un usuario Editor o superior.
  • ¿Qué operaciones (o acciones) puede llevar a cabo un usuario sobre un objeto determinado? Por ejemplo, ¿puede un usuario listado como "Editor" enviar un artículo o sólo editar uno existente? Las opciones de ACL podrían permitir enviar y editar, o permitir un cambio de categoría del artículo, añadir etiquetas o cualquier combinación.

La implementación de la ACL en Joomla! cambió sustancialmente en la versión 2.5, que permitió más flexibilidad en los grupos y permisos.

Access Control/fr


La Liste de Contrôle d'Accès ou ACL (Access Control List) est selon la définition de Wikipédia, "...une liste d’Access Control Entry (ACE) ou entrée de contrôle d'accès donnant ou supprimant des droits d'accès à une personne ou un groupe". Dans le cas de Joomla!, deux aspects distincts de cette liste de contrôle d'accès permettent aux administrateurs de sites de contrôler :

  • Quels utilisateurs peuvent accéder à quelles parties du site? Par exemple, est-ce qu'un choix de menu donné sera visible pour un utilisateur donné ? Un utilisateur enregistré peut le voir, mais le grand public ne le pourra pas. Peut-être que le choix de menu est caché pour tous sauf pour un Editeur ou supérieur.
  • Quelles sont les opérations (ou actions) pouvant être réalisées par un utilisateur sur un objet donné ? Par exemple, est-qu'un utilisateur listé en tant qu'"Editeur" peut soumettre un article ou seulement modifier un article existant. Les paramètres d'ACL peuvent autoriser à soumettre et à modifier, ou autoriser un changement de catégorie d'article, ajouter des tags ou toute combinaison.

L'implémentation d'ACL dans Joomla! a été sensiblement modifiée dans les versions Joomla! 2.5 permettant une plus grande flexibilité au niveau des groupes et des permissions.

Access Control/nl


Access Control List of ACL is volgens de Wikipedia definitie, “...ACL bepaalt welke gebruikers of systeemprocessen toegang wordt verleend tot objecten, alsmede welke handelingen mogen worden uitgevoerd op die objecten.” Binnen Joomla zijn er twee aparte aspecten aan de Access Control List die websitebeheerders kunnen instellen:

  • Welke gebruikers hebben toegang tot welke delen van de website? Bijvoorbeeld, is een bepaalde menu-optie zichtbaar voor een bepaalde gebruiker? Een geregistreerde gebruiker kan bekijken, maar het grote publiek niet. Misschien is de menu keuze voor iedereen verborgen behalve voor een gebruiker met auteursrechten en hoger.
  • Welke handelingen (of acties) kan een gebruiker uitvoeren op een bepaald object? Bijvoorbeeld, kan een gebruiker met de rechten "Redacteur" een artikel indienen of alleen een bestaand artikel bewerken. De ACL-instellingen kunnen indienen en bewerken toestaan of het wijzigen van een artikelcategorie, toevoegen van tags of een combinatie daarvan.

De uitvoering van ACL in Joomla is aanzienlijk veranderd in Joomla! 2.5, waardoor het mogelijk is meer flexibiliteit in groepen en rechten toe te passen.

Access Control/pt-br


Lista de Controle de Acessso ou ACL, de acordo com a Wikipedia definition, é “...uma lista que define quem tem permissão de acesso a certos serviços.” No caso do Joomla, existem dois aspectos distintos para sua Lista de Controle de Acesso que os administradores do site podem controlar:

  • Que usuários podem ter acesso a que partes do site? Por exemplo, uma certa opção de menu estará disponível para um certo usuário? Um usuário cadastrado pode ver, mas o público em geral não. Talvez a opção de menu esteja escondida de todos, exceto de um usuário definido como Editor ou superiores.
  • Que operações (ou ações) podem aplicar um usuário a um objeto específico? Por exemplo, um usuário cadastrado como "Editor" pode enviar um artigo ou somente editar artigos existentes. Os controles de ACL podem permitir o envio e edição ou mudança na categoria do artigo, adicionar tags ou outro tipo de combinação. submit an article or only edit an existing article.

A implementação da ACL no Joomla foi modificada de forma substancial na série Joomla 2.5 o que permitiu maior flexibilidade para os grupos e permissões.

Access Control/ru


Согласно определения Википедии, Access Control List [список контроля доступа] или ACL, “...ACL указывает каким пользователям или системным процессам предоставляется доступ к объектам, а также какие операции разрешаются осуществлять над данными объектами.” В случае с [системой] Joomla, существуют два отдельных аспекта ее ACL [списка контроля доступа], которые администраторы веб-сайта могут контролировать:

  • Какие пользователи к какой части веб-сайта получают доступ? Например, будет ли данное выбранное меню видимо данному пользователю? Зарегистрированный пользователь сможет, но общая публика - нет. Возможно, выбор этого меню скрыт ото всех, за исключением пользователей-редакторов и пользователей с высшим [правом доступа].
  • Какие операции (или действия) какой-либо пользователь может осуществлять над любым конкретным объектом? Например, может ли пользователь, показанный как "Editor"[/редактор] создать какой-либо материал или [он может] только редактировать какой-либо существующий материал? Настройки ACL могут разрешить создание и редактирование, или разрешить вносить изменения в категорию данного материала, [или] разрешить добавлять метки, или [разрешить] любую комбинацию [из этого].

Применение ACL [списка контроля доступа] в Joomla было существенно изменено в серии [версий] Joomla! 2.5, что предоставило группам и правам больше гибкости.

{{:Translations:Access Control List/Page_display_title/<lang code>‎}}

Access Control List or ACL is according to the Wikipedia definition, “...ACL specifies which users or system processes are granted access to objects, as well as what operations are allowed to be performed on given objects.” In the case of Joomla there are two separate aspects to its Access Control List which site administrators can control:

  • Which users can gain access to what parts of the website? For example, will a given menu choice be visible for a given user? A registered user can view, but the public at large cannot. Perhaps the menu choice is hidden from all except an Editor user and higher.
  • What operations (or actions) can a user perform on any given object? For example, can a user listed as an "Editor" submit an article or only edit an existing article. The ACL settings could allow submitting and editing, or allow a change an article's category, add tags or any combination.

The implementation of ACL in Joomla was substantially changed in the Joomla! 2.5 series which allowed for more flexibility in groups and permissions.

Languages

{{:Translations:Access Control List/Page_display_title/<lang code>‎}}

Overview of ACL in Joomla! 2.5

This section outlines the major ACL changes between versions 1.5 and 2.5 series (including 1.6 and 1.7). The table below summarizes the major changes from version 1.5.


Version 1.5 2.5 series
Groups 7 fixed groups (Public, Registered, Author, Editor, Publisher, Manager, Administrator, and Super-Administrator) Unlimited user-defined Groups
Users & Groups A User can be assigned to only one group A User can be assigned to multiple groups
Access Levels 3 fixed Access Levels (Public, Registered, Special) Unlimited user-defined Access Levels
Access Levels & Groups Relationship between Groups and Access Levels was fixed. Groups are assigned to Access Levels. Any combination of Groups can be assigned to any Access Level.

We see that in every case the ACL has been made much more flexible since Joomla 2.5, with unlimited Groups and Access Levels, and the ability to assign one User to multiple Groups and any Groups to any Access Level.

See also

{{:Translations:Access Control List/Page_display_title/<lang code>‎}}

Quill icon.png
Content is Incomplete

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

Overview of ACL in Version Joomla

This section outlines any major ACL changes between versions 2.5 and the 3.x series (which will include future releases). The table below summarizes the changes from version 2.5.

Version 2.5 Version 3.4
Groups Unlimited user-defined Groups Same as 2.5
Users & Groups A User can be assigned to multiple groups Same as 2.5
Access Levels Unlimited user-defined Access Levels Same as 2.5
Access Levels & Groups Groups are assigned to Access Levels. Any combination of Groups can be assigned to any Access Level. Same as 2.5

See also

{{:Translations:Access Control List/Page_display_title/<lang code>‎}}

Access Control List or ACL is according to the Wikipedia definition, “...ACL specifies which users or system processes are granted access to objects, as well as what operations are allowed to be performed on given objects.” In the case of Joomla there are two separate aspects to its Access Control List which site administrators can control:

  • Which users can gain access to what parts of the website? For example, will a given menu choice be visible for a given user? A registered user can view, but the public at large cannot. Perhaps the menu choice is hidden from all except an Editor user and higher.
  • What operations (or actions) can a user perform on any given object? For example, can a user listed as an "Editor" submit an article or only edit an existing article. The ACL settings could allow submitting and editing, or allow a change an article's category, add tags or any combination.

The implementation of ACL in Joomla was substantially changed in the Joomla! 2.5 series which allowed for more flexibility in groups and permissions.



Further reading

Versions

Tutorials

Access Control List/1/bg

Access Control List или ACL, показва начина, по който на потребителите или системните процеси се предоставя достъп до обекти, колкото да може да се изпълнят необходимите операции за тези обекти. В случая с Joomla, има два отделни аспекта на ACL, които администраторите на сайта могат да контролират:

  • "'Кои потребители имат достъп до различните части на сайта?"' Например, ще се вижда ли дадено меню за даден потребител? Регистриран потребител е в състояние, но останалите потребители(нерегистрирани) - не. Може би, това меню е скрито за всички, с изключение на потребителите редактори и потребители с по-висш достъп.
  • "'Какъв вид работа (или дейност) даден потребител може да упражнява върху всеки конкретен обект?"' Например дали потребителят с права "Редактор" може да създава статии или може само да редактира съществуващи вече статии? Настройки на ACL позволяват създаването и редактирането или възможността да се правят промени в категорията на дадена статия, позволяване за добавяне на тагове, или някаква друга комбинация от права и достъп.

Прилагането на ACL в Joomla е значително променено във версия Joomla! 2.5, която за по - голяма гъвкавост предоставя групи и различни права към тях.


Access Control List/1/ca

Llista de Control d'accés o ACL està d'acord amb la [de la Wiquipedia], "...ACL especifica que els usuaris o sistema són els processos de permetre l'accés a objectes, així com quines operacions es poden realitzar a objectes donats." En el cas de Joomla hi ha separat en dues aspectes de la seva Llista de Control d'Accés que els administradors del web pot controlar:

  • Què usuaris poden accedir a quines parts del lloc web? Per exemple, tindran una opció de menú determinat de ser visible per a un usuari determinat? Un usuari registrat ho pot veure, però el públic en general no pot. Potser l'opció de menú està oculta a tots, excepte un usuari Editor i superior.
  • Quines operacions (o accions) pot realitzar un usuari en un objecte donat? Per exemple, un usuari pot figurar com "Editor" Enviar un article o només editar un article existent. Els paràmetres de l'ACL podrien permetre la submissió i l'edició, o permetre fer un canvi de categoria d'un article, afegir etiquetes o qualsevol combinació.

La implementació d'ACL a Joomla es va canviar substancialment a les series de Joomla! 2.5, que va permetre una major flexibilitat en els grups i permisos.


Access Control List/1/da

Access Control List or ACL is according to the Wikipedia definition, “...ACL specifies which users or system processes are granted access to objects, as well as what operations are allowed to be performed on given objects.” In the case of Joomla there are two separate aspects to its Access Control List which site administrators can control:

  • Which users can gain access to what parts of the website? For example, will a given menu choice be visible for a given user? A registered user can view, but the public at large cannot. Perhaps the menu choice is hidden from all except an Editor user and higher.
  • What operations (or actions) can a user perform on any given object? For example, can a user listed as an "Editor" submit an article or only edit an existing article. The ACL settings could allow submitting and editing, or allow a change an article's category, add tags or any combination.

The implementation of ACL in Joomla was substantially changed in the Joomla! 2.5 series which allowed for more flexibility in groups and permissions.


Access Control List/1/de

Access Control List or ACL is according to the Wikipedia definition, “...ACL specifies which users or system processes are granted access to objects, as well as what operations are allowed to be performed on given objects.” In the case of Joomla there are two separate aspects to its Access Control List which site administrators can control:

  • Which users can gain access to what parts of the website? For example, will a given menu choice be visible for a given user? A registered user can view, but the public at large cannot. Perhaps the menu choice is hidden from all except an Editor user and higher.
  • What operations (or actions) can a user perform on any given object? For example, can a user listed as an "Editor" submit an article or only edit an existing article. The ACL settings could allow submitting and editing, or allow a change an article's category, add tags or any combination.

The implementation of ACL in Joomla was substantially changed in the Joomla! 2.5 series which allowed for more flexibility in groups and permissions.


Access Control List/1/en

Access Control List or ACL is according to the Wikipedia definition, “...ACL specifies which users or system processes are granted access to objects, as well as what operations are allowed to be performed on given objects.” In the case of Joomla there are two separate aspects to its Access Control List which site administrators can control:

  • Which users can gain access to what parts of the website? For example, will a given menu choice be visible for a given user? A registered user can view, but the public at large cannot. Perhaps the menu choice is hidden from all except an Editor user and higher.
  • What operations (or actions) can a user perform on any given object? For example, can a user listed as an "Editor" submit an article or only edit an existing article. The ACL settings could allow submitting and editing, or allow a change an article's category, add tags or any combination.

The implementation of ACL in Joomla was substantially changed in the Joomla! 2.5 series which allowed for more flexibility in groups and permissions.


Access Control List/1/es

Una Lista de Control de Acceso o ACL (Access Control List) es, de acuerdo con su definición de Wikipedia, “...una forma de determinar los permisos de acceso apropiados a un determinado objeto”, así como qué operaciones pueden realizarse sobre un objeto dado. En el caso de Joomla, hay dos aspectos diferentes relativos a la Lista de Control de Acceso que los administradores del sitio pueden controlar:

  • ¿Qué usuarios pueden conseguir acceso a qué partes del sitio? Por ejemplo, ¿podrá una opción de menú determinada ser visible para un usuario concreto? Un usuario registrado puede verla, pero el público en general no. Quizás la opción de menú está oculta para todos excepto para un usuario Editor o superior.
  • ¿Qué operaciones (o acciones) puede llevar a cabo un usuario sobre un objeto determinado? Por ejemplo, ¿puede un usuario listado como "Editor" enviar un artículo o sólo editar uno existente? Las opciones de ACL podrían permitir enviar y editar, o permitir un cambio de categoría del artículo, añadir etiquetas o cualquier combinación.

La implementación de la ACL en Joomla! cambió sustancialmente en la versión 2.5, que permitió más flexibilidad en los grupos y permisos.


Access Control List/1/fr

La Liste de Contrôle d'Accès ou ACL (Access Control List) est selon la définition de Wikipédia, "...une liste d’Access Control Entry (ACE) ou entrée de contrôle d'accès donnant ou supprimant des droits d'accès à une personne ou un groupe". Dans le cas de Joomla!, deux aspects distincts de cette liste de contrôle d'accès permettent aux administrateurs de sites de contrôler :

  • Quels utilisateurs peuvent accéder à quelles parties du site? Par exemple, est-ce qu'un choix de menu donné sera visible pour un utilisateur donné ? Un utilisateur enregistré peut le voir, mais le grand public ne le pourra pas. Peut-être que le choix de menu est caché pour tous sauf pour un Editeur ou supérieur.
  • Quelles sont les opérations (ou actions) pouvant être réalisées par un utilisateur sur un objet donné ? Par exemple, est-qu'un utilisateur listé en tant qu'"Editeur" peut soumettre un article ou seulement modifier un article existant. Les paramètres d'ACL peuvent autoriser à soumettre et à modifier, ou autoriser un changement de catégorie d'article, ajouter des tags ou toute combinaison.

L'implémentation d'ACL dans Joomla! a été sensiblement modifiée dans les versions Joomla! 2.5 permettant une plus grande flexibilité au niveau des groupes et des permissions.


Access Control List/1/hu

Access Control List or ACL is according to the Wikipedia definition, “...ACL specifies which users or system processes are granted access to objects, as well as what operations are allowed to be performed on given objects.” In the case of Joomla there are two separate aspects to its Access Control List which site administrators can control:

  • Which users can gain access to what parts of the website? For example, will a given menu choice be visible for a given user? A registered user can view, but the public at large cannot. Perhaps the menu choice is hidden from all except an Editor user and higher.
  • What operations (or actions) can a user perform on any given object? For example, can a user listed as an "Editor" submit an article or only edit an existing article. The ACL settings could allow submitting and editing, or allow a change an article's category, add tags or any combination.

The implementation of ACL in Joomla was substantially changed in the Joomla! 2.5 series which allowed for more flexibility in groups and permissions.


Access Control List/1/id

Menurut pengertian Wikipedia Daftar Kendali Akses, Access Control List atau ACL adalah, "...ACL menentukan proses bagi pengguna atau sistem yang diberikan hak untuk mengakses obyek-obyek, begitu juga dengan pengoperasian obyek yang bersangkutan." Pada Joomla!, terdapat dua aspek yang terpisah sehubungan dengan Daftar Kendali Akses yang bisa dikendalikan oleh administrator situs:

  • Pengguna mana yang bisa mendapat akses untuk bagian situs web apa? Sebagai contoh, apakah sebuah pilihan menu tertentu akan terlihat oleh pengguna tertentu? Seorang pengguna yang terdaftar bisa melihatnya, tapi publik secara luas tidak akan bisa. Mungkin pilihan menu itu disembunyikan dari semuanya kecuali untuk Editor dan yang lebih tinggi tingkatannya.
  • Operasi (atau tindakan) apa yang bisa dilakukan pengguna pada obyek tertentu? Sebagai contoh, bisakah seorang pengguna yang termasuk dalam daftar sebagai "Editor" mengirimkan sebuah artikel atau dia hanya bisa mengedit artikel yang sudah ada. Setelan ACL bisa mengizinkan pengiriman dan pengeditan, atau mengizinkan pergantian kategori artikel, menambah tagar atau sembarang kombinasi.

Penerapan ACL di dalam Jomla telah diganti secara mendasar sejak serial Joomla! 2.5 untuk mengizinkan fleksibilitas yang lebih luas ke dalam kelompok dan perizinan.


Access Control List/1/ja

アクセスコントロールリスト(ACL)はウィキペディアの定義と同じで"ACLとは、オブジェクト(受動体)に付属する許可属性のリスト。コンピュータセキュリティにおけるアクセス制御を実現するために、あるリソース(受動体)に対する誰からのどの操作を許可するかを列挙したもの。例えば、ファイル X についてのアクセス制御リストに要素 (Alice, delete) があれば、Alice はファイル X を削除することができる。”Joomlaではサイト管理者が制御でき二つの制御ができます

  • ユーザがウェブサイトの何処にアクセスできるのか?例えば登録ユーザに表示と指定したメニューはゲストユーザには表示されません。
  • ユーザが任意オブジェクトに対してどんな操作ができるのか?例えば"編集者"として登録されているユーザは記事を作成したり既存の記事を編集する事ができます。ACL設定では作成と編集を許可する、または編集可能なカテゴリのみを許可するなどタグや任意の組合せを指定できます。

JoomlaのACL実装はグループと権限をより柔軟に設定する為、Joomla! 2.5シリーズから変更されました。


Access Control List/1/nl

Access Control List of ACL is volgens de Wikipedia definitie, “...ACL bepaalt welke gebruikers of systeemprocessen toegang wordt verleend tot objecten, alsmede welke handelingen mogen worden uitgevoerd op die objecten.” Binnen Joomla zijn er twee aparte aspecten aan de Access Control List die websitebeheerders kunnen instellen:

  • Welke gebruikers hebben toegang tot welke delen van de website? Bijvoorbeeld, is een bepaalde menu-optie zichtbaar voor een bepaalde gebruiker? Een geregistreerde gebruiker kan bekijken, maar het grote publiek niet. Misschien is de menu keuze voor iedereen verborgen behalve voor een gebruiker met auteursrechten en hoger.
  • Welke handelingen (of acties) kan een gebruiker uitvoeren op een bepaald object? Bijvoorbeeld, kan een gebruiker met de rechten "Redacteur" een artikel indienen of alleen een bestaand artikel bewerken. De ACL-instellingen kunnen indienen en bewerken toestaan of het wijzigen van een artikelcategorie, toevoegen van tags of een combinatie daarvan.

De uitvoering van ACL in Joomla is aanzienlijk veranderd in Joomla! 2.5, waardoor het mogelijk is meer flexibiliteit in groepen en rechten toe te passen.


Access Control List/1/pl

Zgodnie z definicją Wikipedii, lista kontroli dostępu lub ACL, "...określa, którzy użytkownicy bądź procesy systemowe mają dostep do konkretnych objektów oraz jakie uprawnienia administracyjne mają." W przypadku Joomla, istnieją dwa odrębne aspekty ACL, które administratorzy serwisu mogą kontrolować:

  • Ktorzy użytkownicy mają dostęp do ktorej części witryny? Na przykład, czy dane menu jest widoczne dla danego użytkownika? Zarejestrowany i zalogowany użytkownik je widzi, ale goście - nie. Być może wybór tego menu jest ukryty przed każdym, za wyjątkiem użytkowników użytkownikow o grupie wyższej niż Redaktor.
  • Jakie działania lub operacje dany użytkownik może wykonywać w danym obiekcie? Na przykład, czy użytkownik w grupie Redaktor może dodać nowy artykuł, czy tylko edytować już istniejące? Ustawienia ACL mogą zezwolić na tworzenie i edycję lub na zmienienie kategorii artykułu, dodawanie tagów albo dowolną kombinacje powyższych.

ACL w Joomla! począwszy od wersji 2.5 został znacząco rozszerzony, co daje więcej opcji przy nadawaniu użytkownikom uprawnień.


Access Control List/1/pt

Chunk:Access Control List/pt

Access Control List/1/pt-br

Lista de Controle de Acessso ou ACL, de acordo com a Wikipedia definition, é “...uma lista que define quem tem permissão de acesso a certos serviços.” No caso do Joomla, existem dois aspectos distintos para sua Lista de Controle de Acesso que os administradores do site podem controlar:

  • Que usuários podem ter acesso a que partes do site? Por exemplo, uma certa opção de menu estará disponível para um certo usuário? Um usuário cadastrado pode ver, mas o público em geral não. Talvez a opção de menu esteja escondida de todos, exceto de um usuário definido como Editor ou superiores.
  • Que operações (ou ações) podem aplicar um usuário a um objeto específico? Por exemplo, um usuário cadastrado como "Editor" pode enviar um artigo ou somente editar artigos existentes. Os controles de ACL podem permitir o envio e edição ou mudança na categoria do artigo, adicionar tags ou outro tipo de combinação. submit an article or only edit an existing article.

A implementação da ACL no Joomla foi modificada de forma substancial na série Joomla 2.5 o que permitiu maior flexibilidade para os grupos e permissões.


Access Control List/1/ru

Согласно определения Википедии, Access Control List [список контроля доступа] или ACL, “...ACL указывает каким пользователям или системным процессам предоставляется доступ к объектам, а также какие операции разрешаются осуществлять над данными объектами.” В случае с [системой] Joomla, существуют два отдельных аспекта ее ACL [списка контроля доступа], которые администраторы веб-сайта могут контролировать:

  • Какие пользователи к какой части веб-сайта получают доступ? Например, будет ли данное выбранное меню видимо данному пользователю? Зарегистрированный пользователь сможет, но общая публика - нет. Возможно, выбор этого меню скрыт ото всех, за исключением пользователей-редакторов и пользователей с высшим [правом доступа].
  • Какие операции (или действия) какой-либо пользователь может осуществлять над любым конкретным объектом? Например, может ли пользователь, показанный как "Editor"[/редактор] создать какой-либо материал или [он может] только редактировать какой-либо существующий материал? Настройки ACL могут разрешить создание и редактирование, или разрешить вносить изменения в категорию данного материала, [или] разрешить добавлять метки, или [разрешить] любую комбинацию [из этого].

Применение ACL [списка контроля доступа] в Joomla было существенно изменено в серии [версий] Joomla! 2.5, что предоставило группам и правам больше гибкости.


Access Control List/1/sw

Kulingana na Ufafanuzi wa Wikipedia, "...orodha ya kuthibiti maingizo (Access Control List, ACL) itabainisha kuwa ni watumiaji gani (au maendeleo ya mfumo gani) wataruhisiwa kuingia kwa vyombo tofauti, na oparesheni gani wataruhusiwa kwa kiasi cha vyombo fulani". Katika kesi ya Joomla, kuna masuala mawili ya Orodha ya Kuthibiti Maingizo ambayo wasimamizi wanaweza kuthibiti:

  • Watumiaji gani wanaweza kuingia sehemu gani ya wavuti? Kwa mfano, mtumiaji maalum ataweza kuona chaguo maalum la menyu? Mtumiaji aliesajiliwa ataweza kuona, lakini waumma wengi hawataweza kuona. Pengine chaguo la menyu limefichwa kwa wote isipokuwa Mtumiaji wa Kuhariri au wa hali ya juu.
  • Oparesheni (au vitendo) gani mtumiaji ataweza kufanya kwa kiasi cha vyombo fulani? Kwa mfano, mtumiaji alieorodheshwa kama "Mhariri" ataweza kuwasilisha makala au ataweza kuhariri makala ambayo iko tayari pekee? Matayarisho ya ACL yanawaza kuruhusu mawasilisho na kuhariri, ama kuruhusu kubadilisha jamii ya makala, kuongeza matagi au machanganyiko yoyote.

Utekelezaji wa ACL katika Joomla umebadilishwa kwa kiasi kikubwa katika mfululizo wa Joomla! 2.5, ambao unaruhusu marahisisho zaidi kuhusu vikundi na maruhusa.


Access Control List/1/tr

Chunk:Access Control List/tr

Access Control List/2/bg

Версия

Access Control List/2/ca

Versions

Access Control List/2/da

Versioner

Access Control List/2/de

Versionen

Access Control List/2/en

Versions

Access Control List/2/es

Versiones

Access Control List/2/et

Versioonid

Access Control List/2/fr

Versions

Access Control List/2/hu

Verziók

Access Control List/2/id

Versi

Access Control List/2/ja

バージョン

Access Control List/2/nl

Versies

Access Control List/2/pl

ACL w różnych wersjach Joomla!

Access Control List/2/pt

Versões

Access Control List/2/pt-br

Versões

Access Control List/2/ru

Версии

Access Control List/2/sw

Matoleo

Access Control List/2/tr

Sürümler

Access Control List/3/bg

Access Control List/3/ca

Access Control List/3/da

Access Control List/3/de

Access Control List/3/en

Access Control List/3/es

Access Control List/3/fr

Access Control List/3/hu

Access Control List/3/id

Access Control List/3/ja

Access Control List/3/nl

Access Control List/3/pl

Access Control List/3/pt

Access Control List/3/pt-br

Access Control List/3/ru

Access Control List/3/sw

Access Control List/3/tr

Access Control List/4/bg

Туториали

Access Control List/4/ca

Tutorials

Access Control List/4/da

Vejledninger

Access Control List/4/de

Tutorials

Access Control List/4/en

Tutorials

Access Control List/4/es

Tutoriales

Access Control List/4/et

Õpetused

Access Control List/4/fr

Tutoriels

Access Control List/4/hu

Oktatóanyagok

Access Control List/4/id

Tutorial

Access Control List/4/ja

チュートリアル

Access Control List/4/nl

Handleidingen

Access Control List/4/pl

Materiały szkoleniowe

Access Control List/4/pt

Tutoriais

Access Control List/4/pt-br

Tutoriais

Access Control List/4/ru

Наставления

Access Control List/4/sw

Mafunzo

Access Control List/4/tr

Dersler

Access Control List/5/bg

Access Control List/5/ca

Access Control List/5/da

Access Control List/5/de

Access Control List/5/en

Access Control List/5/es

Access Control List/5/fr

Access Control List/5/hu

Access Control List/5/id

Access Control List/5/ja

Access Control List/5/nl

Access Control List/5/pl

Access Control List/5/pt

Access Control List/5/pt-br

Access Control List/5/ru

Access Control List/5/sw

Access Control List/5/tr

Access Control List/6/bg

Access Control List/6/ca

Access Control List/6/da

LandingssiderKategori adgangskontrol GloserAdgangsstyringReferencer

Access Control List/6/de

Access Control List/6/en

Access Control List/6/es

Access Control List/6/fr

Access Control List/6/hu

Access Control List/6/id

Access Control List/6/ja

Access Control List/6/nl

Access Control List/6/pl

Access Control List/6/pt

Access Control List/6/pt-br

Access Control List/6/ru

Access Control List/6/sw

Access Control List/6/tr

Access Control List/7/bg

По-нататъшно четене

Access Control List/7/ca

Altres lectures

Access Control List/7/da

Yderligere læsestof

Access Control List/7/de

Weitere Beschreibungen (en)

Access Control List/7/en

Further reading

Access Control List/7/es

Más información

Access Control List/7/fr

Lectures complémentaires

Access Control List/7/id

Bacaan selanjutnya

Access Control List/7/nl

Meer lezen

Access Control List/7/pl

Dalsze materiały

Access Control List/7/pt

Leitura Adicional

Access Control List/7/pt-br

Leitura complementar

Access Control List/7/ru

Дальнейшее чтение

Access Control List/Page display title/bg

Списък за контрол на достъпа (ACL)

Access Control List/Page display title/ca

Llista de Control d'accés

Access Control List/Page display title/da

Adgangskontrolliste (ACL)

Access Control List/Page display title/de

Zugriffsberechtigungsliste (Access Control List-ACL)

Access Control List/Page display title/en

Access Control List

Access Control List/Page display title/es

Listado de Control de acceso

Access Control List/Page display title/fr

Liste de Contrôle d'Accès (ACL)

Access Control List/Page display title/hu

Hozzáférés-jogosultsági lista

Access Control List/Page display title/id

Daftar Kendali Akses

Access Control List/Page display title/ja

アクセスコントロールリスト

Access Control List/Page display title/nl

Access Control List

Access Control List/Page display title/pl

Lista kontroli dostępu (ACL)

Access Control List/Page display title/pt

Lista de acesso de controlo

Access Control List/Page display title/pt-br

Lista de Controle de Acesso ou ACL

Access Control List/Page display title/ru

Список контроля доступа (ACL)

Access Control List/Page display title/sw

Orodha ya Kuthibiti Maingizo (ACL)

Access Control List/Page display title/tr

Erişim Kontrol Listesi (ACL)

{{:Translations:Access Control List/bg/Page_display_title/<lang code>‎}}

Access Control List или ACL, показва начина, по който на потребителите или системните процеси се предоставя достъп до обекти, колкото да може да се изпълнят необходимите операции за тези обекти. В случая с Joomla, има два отделни аспекта на ACL, които администраторите на сайта могат да контролират:

  • "'Кои потребители имат достъп до различните части на сайта?"' Например, ще се вижда ли дадено меню за даден потребител? Регистриран потребител е в състояние, но останалите потребители(нерегистрирани) - не. Може би, това меню е скрито за всички, с изключение на потребителите редактори и потребители с по-висш достъп.
  • "'Какъв вид работа (или дейност) даден потребител може да упражнява върху всеки конкретен обект?"' Например дали потребителят с права "Редактор" може да създава статии или може само да редактира съществуващи вече статии? Настройки на ACL позволяват създаването и редактирането или възможността да се правят промени в категорията на дадена статия, позволяване за добавяне на тагове, или някаква друга комбинация от права и достъп.

Прилагането на ACL в Joomla е значително променено във версия Joomla! 2.5, която за по - голяма гъвкавост предоставя групи и различни права към тях.

Languages

{{:Translations:Access Control List/bg/Page_display_title/<lang code>‎}}

Access Control List или ACL, показва начина, по който на потребителите или системните процеси се предоставя достъп до обекти, колкото да може да се изпълнят необходимите операции за тези обекти. В случая с Joomla, има два отделни аспекта на ACL, които администраторите на сайта могат да контролират:

  • "'Кои потребители имат достъп до различните части на сайта?"' Например, ще се вижда ли дадено меню за даден потребител? Регистриран потребител е в състояние, но останалите потребители(нерегистрирани) - не. Може би, това меню е скрито за всички, с изключение на потребителите редактори и потребители с по-висш достъп.
  • "'Какъв вид работа (или дейност) даден потребител може да упражнява върху всеки конкретен обект?"' Например дали потребителят с права "Редактор" може да създава статии или може само да редактира съществуващи вече статии? Настройки на ACL позволяват създаването и редактирането или възможността да се правят промени в категорията на дадена статия, позволяване за добавяне на тагове, или някаква друга комбинация от права и достъп.

Прилагането на ACL в Joomla е значително променено във версия Joomla! 2.5, която за по - голяма гъвкавост предоставя групи и различни права към тях.



По-нататъшно четене

Версия

Туториали

{{:Translations:Access Control List/ca/Page_display_title/<lang code>‎}}

Llista de Control d'accés o ACL està d'acord amb la [de la Wiquipedia], "...ACL especifica que els usuaris o sistema són els processos de permetre l'accés a objectes, així com quines operacions es poden realitzar a objectes donats." En el cas de Joomla hi ha separat en dues aspectes de la seva Llista de Control d'Accés que els administradors del web pot controlar:

  • Què usuaris poden accedir a quines parts del lloc web? Per exemple, tindran una opció de menú determinat de ser visible per a un usuari determinat? Un usuari registrat ho pot veure, però el públic en general no pot. Potser l'opció de menú està oculta a tots, excepte un usuari Editor i superior.
  • Quines operacions (o accions) pot realitzar un usuari en un objecte donat? Per exemple, un usuari pot figurar com "Editor" Enviar un article o només editar un article existent. Els paràmetres de l'ACL podrien permetre la submissió i l'edició, o permetre fer un canvi de categoria d'un article, afegir etiquetes o qualsevol combinació.

La implementació d'ACL a Joomla es va canviar substancialment a les series de Joomla! 2.5, que va permetre una major flexibilitat en els grups i permisos.



Altres lectures

Versions

Tutorials

{{:Translations:Access Control List/ca/Page_display_title/<lang code>‎}}

Llista de Control d'accés o ACL està d'acord amb la [de la Wiquipedia], "...ACL especifica que els usuaris o sistema són els processos de permetre l'accés a objectes, així com quines operacions es poden realitzar a objectes donats." En el cas de Joomla hi ha separat en dues aspectes de la seva Llista de Control d'Accés que els administradors del web pot controlar:

  • Què usuaris poden accedir a quines parts del lloc web? Per exemple, tindran una opció de menú determinat de ser visible per a un usuari determinat? Un usuari registrat ho pot veure, però el públic en general no pot. Potser l'opció de menú està oculta a tots, excepte un usuari Editor i superior.
  • Quines operacions (o accions) pot realitzar un usuari en un objecte donat? Per exemple, un usuari pot figurar com "Editor" Enviar un article o només editar un article existent. Els paràmetres de l'ACL podrien permetre la submissió i l'edició, o permetre fer un canvi de categoria d'un article, afegir etiquetes o qualsevol combinació.

La implementació d'ACL a Joomla es va canviar substancialment a les series de Joomla! 2.5, que va permetre una major flexibilitat en els grups i permisos.

Categoria:Definicions del glossari

Languages

{{:Translations:Access Control List/da/Page_display_title/<lang code>‎}}

Access Control List or ACL is according to the Wikipedia definition, “...ACL specifies which users or system processes are granted access to objects, as well as what operations are allowed to be performed on given objects.” In the case of Joomla there are two separate aspects to its Access Control List which site administrators can control:

  • Which users can gain access to what parts of the website? For example, will a given menu choice be visible for a given user? A registered user can view, but the public at large cannot. Perhaps the menu choice is hidden from all except an Editor user and higher.
  • What operations (or actions) can a user perform on any given object? For example, can a user listed as an "Editor" submit an article or only edit an existing article. The ACL settings could allow submitting and editing, or allow a change an article's category, add tags or any combination.

The implementation of ACL in Joomla was substantially changed in the Joomla! 2.5 series which allowed for more flexibility in groups and permissions.

Glosedefinitioner

Languages

{{:Translations:Access Control List/da/Page_display_title/<lang code>‎}}

Access Control List or ACL is according to the Wikipedia definition, “...ACL specifies which users or system processes are granted access to objects, as well as what operations are allowed to be performed on given objects.” In the case of Joomla there are two separate aspects to its Access Control List which site administrators can control:

  • Which users can gain access to what parts of the website? For example, will a given menu choice be visible for a given user? A registered user can view, but the public at large cannot. Perhaps the menu choice is hidden from all except an Editor user and higher.
  • What operations (or actions) can a user perform on any given object? For example, can a user listed as an "Editor" submit an article or only edit an existing article. The ACL settings could allow submitting and editing, or allow a change an article's category, add tags or any combination.

The implementation of ACL in Joomla was substantially changed in the Joomla! 2.5 series which allowed for more flexibility in groups and permissions.



Yderligere læsestof

Versioner

Vejledninger

LandingssiderKategori adgangskontrol GloserAdgangsstyringReferencer

{{:Translations:Access Control List/de/Page_display_title/<lang code>‎}}

Access Control List or ACL is according to the Wikipedia definition, “...ACL specifies which users or system processes are granted access to objects, as well as what operations are allowed to be performed on given objects.” In the case of Joomla there are two separate aspects to its Access Control List which site administrators can control:

  • Which users can gain access to what parts of the website? For example, will a given menu choice be visible for a given user? A registered user can view, but the public at large cannot. Perhaps the menu choice is hidden from all except an Editor user and higher.
  • What operations (or actions) can a user perform on any given object? For example, can a user listed as an "Editor" submit an article or only edit an existing article. The ACL settings could allow submitting and editing, or allow a change an article's category, add tags or any combination.

The implementation of ACL in Joomla was substantially changed in the Joomla! 2.5 series which allowed for more flexibility in groups and permissions.



Weitere Beschreibungen (en)

Versionen

Tutorials

{{:Translations:Access Control List/de/Page_display_title/<lang code>‎}}

Access Control List or ACL is according to the Wikipedia definition, “...ACL specifies which users or system processes are granted access to objects, as well as what operations are allowed to be performed on given objects.” In the case of Joomla there are two separate aspects to its Access Control List which site administrators can control:

  • Which users can gain access to what parts of the website? For example, will a given menu choice be visible for a given user? A registered user can view, but the public at large cannot. Perhaps the menu choice is hidden from all except an Editor user and higher.
  • What operations (or actions) can a user perform on any given object? For example, can a user listed as an "Editor" submit an article or only edit an existing article. The ACL settings could allow submitting and editing, or allow a change an article's category, add tags or any combination.

The implementation of ACL in Joomla was substantially changed in the Joomla! 2.5 series which allowed for more flexibility in groups and permissions.

Languages

{{:Translations:Access Control List/en/Page_display_title/<lang code>‎}}

Access Control List or ACL is according to the Wikipedia definition, “...ACL specifies which users or system processes are granted access to objects, as well as what operations are allowed to be performed on given objects.” In the case of Joomla there are two separate aspects to its Access Control List which site administrators can control:

  • Which users can gain access to what parts of the website? For example, will a given menu choice be visible for a given user? A registered user can view, but the public at large cannot. Perhaps the menu choice is hidden from all except an Editor user and higher.
  • What operations (or actions) can a user perform on any given object? For example, can a user listed as an "Editor" submit an article or only edit an existing article. The ACL settings could allow submitting and editing, or allow a change an article's category, add tags or any combination.

The implementation of ACL in Joomla was substantially changed in the Joomla! 2.5 series which allowed for more flexibility in groups and permissions.



Further reading

Versions

Tutorials

{{:Translations:Access Control List/en/Page_display_title/<lang code>‎}}

Access Control List or ACL is according to the Wikipedia definition, “...ACL specifies which users or system processes are granted access to objects, as well as what operations are allowed to be performed on given objects.” In the case of Joomla there are two separate aspects to its Access Control List which site administrators can control:

  • Which users can gain access to what parts of the website? For example, will a given menu choice be visible for a given user? A registered user can view, but the public at large cannot. Perhaps the menu choice is hidden from all except an Editor user and higher.
  • What operations (or actions) can a user perform on any given object? For example, can a user listed as an "Editor" submit an article or only edit an existing article. The ACL settings could allow submitting and editing, or allow a change an article's category, add tags or any combination.

The implementation of ACL in Joomla was substantially changed in the Joomla! 2.5 series which allowed for more flexibility in groups and permissions.

Languages

{{:Translations:Access Control List/en/Page_display_title/<lang code>‎}}

Quill icon.png
Content is Incomplete

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

Overview of ACL in Version Joomla

This section outlines any major ACL changes between versions 2.5 and the 3.x series (which will include future releases). The table below summarizes the changes from version 2.5.

Version 2.5 Version 3.4
Groups Unlimited user-defined Groups Same as 2.5
Users & Groups A User can be assigned to multiple groups Same as 2.5
Access Levels Unlimited user-defined Access Levels Same as 2.5
Access Levels & Groups Groups are assigned to Access Levels. Any combination of Groups can be assigned to any Access Level. Same as 2.5

See also

{{:Translations:Access Control List/es/Page_display_title/<lang code>‎}}

Una Lista de Control de Acceso o ACL (Access Control List) es, de acuerdo con su definición de Wikipedia, “...una forma de determinar los permisos de acceso apropiados a un determinado objeto”, así como qué operaciones pueden realizarse sobre un objeto dado. En el caso de Joomla, hay dos aspectos diferentes relativos a la Lista de Control de Acceso que los administradores del sitio pueden controlar:

  • ¿Qué usuarios pueden conseguir acceso a qué partes del sitio? Por ejemplo, ¿podrá una opción de menú determinada ser visible para un usuario concreto? Un usuario registrado puede verla, pero el público en general no. Quizás la opción de menú está oculta para todos excepto para un usuario Editor o superior.
  • ¿Qué operaciones (o acciones) puede llevar a cabo un usuario sobre un objeto determinado? Por ejemplo, ¿puede un usuario listado como "Editor" enviar un artículo o sólo editar uno existente? Las opciones de ACL podrían permitir enviar y editar, o permitir un cambio de categoría del artículo, añadir etiquetas o cualquier combinación.

La implementación de la ACL en Joomla! cambió sustancialmente en la versión 2.5, que permitió más flexibilidad en los grupos y permisos.

Languages

{{:Translations:Access Control List/es/Page_display_title/<lang code>‎}}

Una Lista de Control de Acceso o ACL (Access Control List) es, de acuerdo con su definición de Wikipedia, “...una forma de determinar los permisos de acceso apropiados a un determinado objeto”, así como qué operaciones pueden realizarse sobre un objeto dado. En el caso de Joomla, hay dos aspectos diferentes relativos a la Lista de Control de Acceso que los administradores del sitio pueden controlar:

  • ¿Qué usuarios pueden conseguir acceso a qué partes del sitio? Por ejemplo, ¿podrá una opción de menú determinada ser visible para un usuario concreto? Un usuario registrado puede verla, pero el público en general no. Quizás la opción de menú está oculta para todos excepto para un usuario Editor o superior.
  • ¿Qué operaciones (o acciones) puede llevar a cabo un usuario sobre un objeto determinado? Por ejemplo, ¿puede un usuario listado como "Editor" enviar un artículo o sólo editar uno existente? Las opciones de ACL podrían permitir enviar y editar, o permitir un cambio de categoría del artículo, añadir etiquetas o cualquier combinación.

La implementación de la ACL en Joomla! cambió sustancialmente en la versión 2.5, que permitió más flexibilidad en los grupos y permisos.



Más información

Versiones

Tutoriales

{{:Translations:Access Control List/et/Page_display_title/<lang code>‎}}

Access Control List or ACL is according to the Wikipedia definition, “...ACL specifies which users or system processes are granted access to objects, as well as what operations are allowed to be performed on given objects.” In the case of Joomla there are two separate aspects to its Access Control List which site administrators can control:

  • Which users can gain access to what parts of the website? For example, will a given menu choice be visible for a given user? A registered user can view, but the public at large cannot. Perhaps the menu choice is hidden from all except an Editor user and higher.
  • What operations (or actions) can a user perform on any given object? For example, can a user listed as an "Editor" submit an article or only edit an existing article. The ACL settings could allow submitting and editing, or allow a change an article's category, add tags or any combination.

The implementation of ACL in Joomla was substantially changed in the Joomla! 2.5 series which allowed for more flexibility in groups and permissions.



Further reading

Versioonid

Õpetused

{{:Translations:Access Control List/fr/Page_display_title/<lang code>‎}}

La Liste de Contrôle d'Accès ou ACL (Access Control List) est selon la définition de Wikipédia, "...une liste d’Access Control Entry (ACE) ou entrée de contrôle d'accès donnant ou supprimant des droits d'accès à une personne ou un groupe". Dans le cas de Joomla!, deux aspects distincts de cette liste de contrôle d'accès permettent aux administrateurs de sites de contrôler :

  • Quels utilisateurs peuvent accéder à quelles parties du site? Par exemple, est-ce qu'un choix de menu donné sera visible pour un utilisateur donné ? Un utilisateur enregistré peut le voir, mais le grand public ne le pourra pas. Peut-être que le choix de menu est caché pour tous sauf pour un Editeur ou supérieur.
  • Quelles sont les opérations (ou actions) pouvant être réalisées par un utilisateur sur un objet donné ? Par exemple, est-qu'un utilisateur listé en tant qu'"Editeur" peut soumettre un article ou seulement modifier un article existant. Les paramètres d'ACL peuvent autoriser à soumettre et à modifier, ou autoriser un changement de catégorie d'article, ajouter des tags ou toute combinaison.

L'implémentation d'ACL dans Joomla! a été sensiblement modifiée dans les versions Joomla! 2.5 permettant une plus grande flexibilité au niveau des groupes et des permissions.

Languages

{{:Translations:Access Control List/fr/Page_display_title/<lang code>‎}}

La Liste de Contrôle d'Accès ou ACL (Access Control List) est selon la définition de Wikipédia, "...une liste d’Access Control Entry (ACE) ou entrée de contrôle d'accès donnant ou supprimant des droits d'accès à une personne ou un groupe". Dans le cas de Joomla!, deux aspects distincts de cette liste de contrôle d'accès permettent aux administrateurs de sites de contrôler :

  • Quels utilisateurs peuvent accéder à quelles parties du site? Par exemple, est-ce qu'un choix de menu donné sera visible pour un utilisateur donné ? Un utilisateur enregistré peut le voir, mais le grand public ne le pourra pas. Peut-être que le choix de menu est caché pour tous sauf pour un Editeur ou supérieur.
  • Quelles sont les opérations (ou actions) pouvant être réalisées par un utilisateur sur un objet donné ? Par exemple, est-qu'un utilisateur listé en tant qu'"Editeur" peut soumettre un article ou seulement modifier un article existant. Les paramètres d'ACL peuvent autoriser à soumettre et à modifier, ou autoriser un changement de catégorie d'article, ajouter des tags ou toute combinaison.

L'implémentation d'ACL dans Joomla! a été sensiblement modifiée dans les versions Joomla! 2.5 permettant une plus grande flexibilité au niveau des groupes et des permissions.



Lectures complémentaires

Versions

Tutoriels

{{:Translations:Access Control List/fr/Page_display_title/<lang code>‎}}

Quill icon.png
Content is Incomplete

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

Résumé des ACL pour la Version Joomla

Cette section décrit les changements majeurs d'ACL entre les versions 2.5 et la série 3.x (incluant les futures versions). Le tableau ci-dessous résume les changements depuis la version 2.5.

Version 2.5 Version 3.4
Groupes Nombre illimité de groupes d'utilisateurs définis La même chose que pour 2.5
Utilisateurs & Groupes Un utilisateur peut être assigné à plusieurs groupes La même chose que pour 2.5
Niveaux d'accès Niveaux d'accès illimités pour les utilisateurs définis La même chose que pour 2.5
Niveaux d'accès & groupes Les groupes sont assignés à des niveaux d'accès. Toute combinaison de groupes peut être assignée à n'importe quel niveau d'accès. La même chose que pour 2.5

Voir également

{{:Translations:Access Control List/hu/Page_display_title/<lang code>‎}}

Access Control List or ACL is according to the Wikipedia definition, “...ACL specifies which users or system processes are granted access to objects, as well as what operations are allowed to be performed on given objects.” In the case of Joomla there are two separate aspects to its Access Control List which site administrators can control:

  • Which users can gain access to what parts of the website? For example, will a given menu choice be visible for a given user? A registered user can view, but the public at large cannot. Perhaps the menu choice is hidden from all except an Editor user and higher.
  • What operations (or actions) can a user perform on any given object? For example, can a user listed as an "Editor" submit an article or only edit an existing article. The ACL settings could allow submitting and editing, or allow a change an article's category, add tags or any combination.

The implementation of ACL in Joomla was substantially changed in the Joomla! 2.5 series which allowed for more flexibility in groups and permissions.



Further reading

Verziók

Oktatóanyagok

{{:Translations:Access Control List/hu/Page_display_title/<lang code>‎}}

Access Control List or ACL is according to the Wikipedia definition, “...ACL specifies which users or system processes are granted access to objects, as well as what operations are allowed to be performed on given objects.” In the case of Joomla there are two separate aspects to its Access Control List which site administrators can control:

  • Which users can gain access to what parts of the website? For example, will a given menu choice be visible for a given user? A registered user can view, but the public at large cannot. Perhaps the menu choice is hidden from all except an Editor user and higher.
  • What operations (or actions) can a user perform on any given object? For example, can a user listed as an "Editor" submit an article or only edit an existing article. The ACL settings could allow submitting and editing, or allow a change an article's category, add tags or any combination.

The implementation of ACL in Joomla was substantially changed in the Joomla! 2.5 series which allowed for more flexibility in groups and permissions.

Languages

{{:Translations:Access Control List/id/Page_display_title/<lang code>‎}}

Menurut pengertian Wikipedia Daftar Kendali Akses, Access Control List atau ACL adalah, "...ACL menentukan proses bagi pengguna atau sistem yang diberikan hak untuk mengakses obyek-obyek, begitu juga dengan pengoperasian obyek yang bersangkutan." Pada Joomla!, terdapat dua aspek yang terpisah sehubungan dengan Daftar Kendali Akses yang bisa dikendalikan oleh administrator situs:

  • Pengguna mana yang bisa mendapat akses untuk bagian situs web apa? Sebagai contoh, apakah sebuah pilihan menu tertentu akan terlihat oleh pengguna tertentu? Seorang pengguna yang terdaftar bisa melihatnya, tapi publik secara luas tidak akan bisa. Mungkin pilihan menu itu disembunyikan dari semuanya kecuali untuk Editor dan yang lebih tinggi tingkatannya.
  • Operasi (atau tindakan) apa yang bisa dilakukan pengguna pada obyek tertentu? Sebagai contoh, bisakah seorang pengguna yang termasuk dalam daftar sebagai "Editor" mengirimkan sebuah artikel atau dia hanya bisa mengedit artikel yang sudah ada. Setelan ACL bisa mengizinkan pengiriman dan pengeditan, atau mengizinkan pergantian kategori artikel, menambah tagar atau sembarang kombinasi.

Penerapan ACL di dalam Jomla telah diganti secara mendasar sejak serial Joomla! 2.5 untuk mengizinkan fleksibilitas yang lebih luas ke dalam kelompok dan perizinan.



Bacaan selanjutnya

Versi

Tutorial

{{:Translations:Access Control List/id/Page_display_title/<lang code>‎}}

Menurut pengertian Wikipedia Daftar Kendali Akses, Access Control List atau ACL adalah, "...ACL menentukan proses bagi pengguna atau sistem yang diberikan hak untuk mengakses obyek-obyek, begitu juga dengan pengoperasian obyek yang bersangkutan." Pada Joomla!, terdapat dua aspek yang terpisah sehubungan dengan Daftar Kendali Akses yang bisa dikendalikan oleh administrator situs:

  • Pengguna mana yang bisa mendapat akses untuk bagian situs web apa? Sebagai contoh, apakah sebuah pilihan menu tertentu akan terlihat oleh pengguna tertentu? Seorang pengguna yang terdaftar bisa melihatnya, tapi publik secara luas tidak akan bisa. Mungkin pilihan menu itu disembunyikan dari semuanya kecuali untuk Editor dan yang lebih tinggi tingkatannya.
  • Operasi (atau tindakan) apa yang bisa dilakukan pengguna pada obyek tertentu? Sebagai contoh, bisakah seorang pengguna yang termasuk dalam daftar sebagai "Editor" mengirimkan sebuah artikel atau dia hanya bisa mengedit artikel yang sudah ada. Setelan ACL bisa mengizinkan pengiriman dan pengeditan, atau mengizinkan pergantian kategori artikel, menambah tagar atau sembarang kombinasi.

Penerapan ACL di dalam Jomla telah diganti secara mendasar sejak serial Joomla! 2.5 untuk mengizinkan fleksibilitas yang lebih luas ke dalam kelompok dan perizinan.

Languages

Access Control List/it

Access Control List o ACL è, secondo la definizione di Wikipedia, “...ACL specifica a quali utenti o processi di sistema è garantito l'accesso agli oggetti, e quali operazioni sono consentite per essere effettuate in dati oggetti.” Nel caso di Joomla ci sono due aspetti separati del suo Access Control List che l'amministratore può controllare:

  • Quali utenti possono accedere a quali parti del sito web? Ad esempio, un determinato menu sarà visibile per un determinato utente? Gli utenti registrati possono vedere, ma i visitatori non possono. Oppure il menu è nascosto a tutti, tranne che agli utenti Editor e superiori.
  • Quali operazioni (o azioni) può eseguire un utente su un determinato oggetto? Per esempio, un utente assegnato come "Editor" può inviare un articolo o solo modificare un articolo esistente. Le impostazioni ACL potrebbe consentire l'invio e la modifica, o consentire la modifica di una categoria di articoli, aggiungere tag o qualsiasi combinazione.

L'implementazione delle ACL in Joomla è stata cambiata da Joomla! 2.5, che consente una maggiore flessibilità nei gruppi e nei permessi.

Languages

{{:Translations:Access Control List/ja/Page_display_title/<lang code>‎}}

アクセスコントロールリスト(ACL)はウィキペディアの定義と同じで"ACLとは、オブジェクト(受動体)に付属する許可属性のリスト。コンピュータセキュリティにおけるアクセス制御を実現するために、あるリソース(受動体)に対する誰からのどの操作を許可するかを列挙したもの。例えば、ファイル X についてのアクセス制御リストに要素 (Alice, delete) があれば、Alice はファイル X を削除することができる。”Joomlaではサイト管理者が制御でき二つの制御ができます

  • ユーザがウェブサイトの何処にアクセスできるのか?例えば登録ユーザに表示と指定したメニューはゲストユーザには表示されません。
  • ユーザが任意オブジェクトに対してどんな操作ができるのか?例えば"編集者"として登録されているユーザは記事を作成したり既存の記事を編集する事ができます。ACL設定では作成と編集を許可する、または編集可能なカテゴリのみを許可するなどタグや任意の組合せを指定できます。

JoomlaのACL実装はグループと権限をより柔軟に設定する為、Joomla! 2.5シリーズから変更されました。

Languages

{{:Translations:Access Control List/ja/Page_display_title/<lang code>‎}}

アクセスコントロールリスト(ACL)はウィキペディアの定義と同じで"ACLとは、オブジェクト(受動体)に付属する許可属性のリスト。コンピュータセキュリティにおけるアクセス制御を実現するために、あるリソース(受動体)に対する誰からのどの操作を許可するかを列挙したもの。例えば、ファイル X についてのアクセス制御リストに要素 (Alice, delete) があれば、Alice はファイル X を削除することができる。”Joomlaではサイト管理者が制御でき二つの制御ができます

  • ユーザがウェブサイトの何処にアクセスできるのか?例えば登録ユーザに表示と指定したメニューはゲストユーザには表示されません。
  • ユーザが任意オブジェクトに対してどんな操作ができるのか?例えば"編集者"として登録されているユーザは記事を作成したり既存の記事を編集する事ができます。ACL設定では作成と編集を許可する、または編集可能なカテゴリのみを許可するなどタグや任意の組合せを指定できます。

JoomlaのACL実装はグループと権限をより柔軟に設定する為、Joomla! 2.5シリーズから変更されました。



Further reading

バージョン

チュートリアル

{{:Translations:Access Control List/nl/Page_display_title/<lang code>‎}}

Access Control List of ACL is volgens de Wikipedia definitie, “...ACL bepaalt welke gebruikers of systeemprocessen toegang wordt verleend tot objecten, alsmede welke handelingen mogen worden uitgevoerd op die objecten.” Binnen Joomla zijn er twee aparte aspecten aan de Access Control List die websitebeheerders kunnen instellen:

  • Welke gebruikers hebben toegang tot welke delen van de website? Bijvoorbeeld, is een bepaalde menu-optie zichtbaar voor een bepaalde gebruiker? Een geregistreerde gebruiker kan bekijken, maar het grote publiek niet. Misschien is de menu keuze voor iedereen verborgen behalve voor een gebruiker met auteursrechten en hoger.
  • Welke handelingen (of acties) kan een gebruiker uitvoeren op een bepaald object? Bijvoorbeeld, kan een gebruiker met de rechten "Redacteur" een artikel indienen of alleen een bestaand artikel bewerken. De ACL-instellingen kunnen indienen en bewerken toestaan of het wijzigen van een artikelcategorie, toevoegen van tags of een combinatie daarvan.

De uitvoering van ACL in Joomla is aanzienlijk veranderd in Joomla! 2.5, waardoor het mogelijk is meer flexibiliteit in groepen en rechten toe te passen.

Languages

{{:Translations:Access Control List/nl/Page_display_title/<lang code>‎}}

Access Control List of ACL is volgens de Wikipedia definitie, “...ACL bepaalt welke gebruikers of systeemprocessen toegang wordt verleend tot objecten, alsmede welke handelingen mogen worden uitgevoerd op die objecten.” Binnen Joomla zijn er twee aparte aspecten aan de Access Control List die websitebeheerders kunnen instellen:

  • Welke gebruikers hebben toegang tot welke delen van de website? Bijvoorbeeld, is een bepaalde menu-optie zichtbaar voor een bepaalde gebruiker? Een geregistreerde gebruiker kan bekijken, maar het grote publiek niet. Misschien is de menu keuze voor iedereen verborgen behalve voor een gebruiker met auteursrechten en hoger.
  • Welke handelingen (of acties) kan een gebruiker uitvoeren op een bepaald object? Bijvoorbeeld, kan een gebruiker met de rechten "Redacteur" een artikel indienen of alleen een bestaand artikel bewerken. De ACL-instellingen kunnen indienen en bewerken toestaan of het wijzigen van een artikelcategorie, toevoegen van tags of een combinatie daarvan.

De uitvoering van ACL in Joomla is aanzienlijk veranderd in Joomla! 2.5, waardoor het mogelijk is meer flexibiliteit in groepen en rechten toe te passen.



Meer lezen

Versies

Handleidingen

{{:Translations:Access Control List/nl/Page_display_title/<lang code>‎}}

Quill icon.png
Content is Incomplete

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

Overzicht van ACL in versie Joomla

Deze paragraaf beschrijft belangrijke ACL wijzigingen tussen versie 2.5 en 3.x (waaronder ook toekomstige releases). Onderstaande tabel geeft een overzicht van de wijzigingen ten opzichte van versie 2.5.

Versie 2.5 Versie 3.4
Groepen Onbeperkt aantal zelf gedefinieerde groepen Hetzelfde als 2.5
Gebruikers & Groepen Een gebruiker kan worden toegewezen aan meerdere groepen Hetzelfde als 2.5
Toegangsniveaus Onbeperkt aantal zelf gedefinieerde toegangsniveaus Hetzelfde als 2.5
Toegangsniveaus & groepen Groepen worden toegewezen aan toegangsniveaus. Iedere combinatie van groepen kan worden toegewezen aan ieder toegangsniveau. Hetzelfde als 2.5

Zie ook

{{:Translations:Access Control List/pl/Page_display_title/<lang code>‎}}

Zgodnie z definicją Wikipedii, lista kontroli dostępu lub ACL, "...określa, którzy użytkownicy bądź procesy systemowe mają dostep do konkretnych objektów oraz jakie uprawnienia administracyjne mają." W przypadku Joomla, istnieją dwa odrębne aspekty ACL, które administratorzy serwisu mogą kontrolować:

  • Ktorzy użytkownicy mają dostęp do ktorej części witryny? Na przykład, czy dane menu jest widoczne dla danego użytkownika? Zarejestrowany i zalogowany użytkownik je widzi, ale goście - nie. Być może wybór tego menu jest ukryty przed każdym, za wyjątkiem użytkowników użytkownikow o grupie wyższej niż Redaktor.
  • Jakie działania lub operacje dany użytkownik może wykonywać w danym obiekcie? Na przykład, czy użytkownik w grupie Redaktor może dodać nowy artykuł, czy tylko edytować już istniejące? Ustawienia ACL mogą zezwolić na tworzenie i edycję lub na zmienienie kategorii artykułu, dodawanie tagów albo dowolną kombinacje powyższych.

ACL w Joomla! począwszy od wersji 2.5 został znacząco rozszerzony, co daje więcej opcji przy nadawaniu użytkownikom uprawnień.



Dalsze materiały

ACL w różnych wersjach Joomla!

Materiały szkoleniowe

{{:Translations:Access Control List/pl/Page_display_title/<lang code>‎}}

Zgodnie z definicją Wikipedii, lista kontroli dostępu lub ACL, "...określa, którzy użytkownicy bądź procesy systemowe mają dostep do konkretnych objektów oraz jakie uprawnienia administracyjne mają." W przypadku Joomla, istnieją dwa odrębne aspekty ACL, które administratorzy serwisu mogą kontrolować:

  • Ktorzy użytkownicy mają dostęp do ktorej części witryny? Na przykład, czy dane menu jest widoczne dla danego użytkownika? Zarejestrowany i zalogowany użytkownik je widzi, ale goście - nie. Być może wybór tego menu jest ukryty przed każdym, za wyjątkiem użytkowników użytkownikow o grupie wyższej niż Redaktor.
  • Jakie działania lub operacje dany użytkownik może wykonywać w danym obiekcie? Na przykład, czy użytkownik w grupie Redaktor może dodać nowy artykuł, czy tylko edytować już istniejące? Ustawienia ACL mogą zezwolić na tworzenie i edycję lub na zmienienie kategorii artykułu, dodawanie tagów albo dowolną kombinacje powyższych.

ACL w Joomla! począwszy od wersji 2.5 został znacząco rozszerzony, co daje więcej opcji przy nadawaniu użytkownikom uprawnień.

Languages

{{:Translations:Access Control List/pt/Page_display_title/<lang code>‎}}

Chunk:Access Control List/pt

Leitura Adicional

Versões

Tutoriais

{{:Translations:Access Control List/pt-br/Page_display_title/<lang code>‎}}

Lista de Controle de Acessso ou ACL, de acordo com a Wikipedia definition, é “...uma lista que define quem tem permissão de acesso a certos serviços.” No caso do Joomla, existem dois aspectos distintos para sua Lista de Controle de Acesso que os administradores do site podem controlar:

  • Que usuários podem ter acesso a que partes do site? Por exemplo, uma certa opção de menu estará disponível para um certo usuário? Um usuário cadastrado pode ver, mas o público em geral não. Talvez a opção de menu esteja escondida de todos, exceto de um usuário definido como Editor ou superiores.
  • Que operações (ou ações) podem aplicar um usuário a um objeto específico? Por exemplo, um usuário cadastrado como "Editor" pode enviar um artigo ou somente editar artigos existentes. Os controles de ACL podem permitir o envio e edição ou mudança na categoria do artigo, adicionar tags ou outro tipo de combinação. submit an article or only edit an existing article.

A implementação da ACL no Joomla foi modificada de forma substancial na série Joomla 2.5 o que permitiu maior flexibilidade para os grupos e permissões.



Leitura complementar

Versões

Tutoriais

{{:Translations:Access Control List/pt-br/Page_display_title/<lang code>‎}}

Lista de Controle de Acessso ou ACL, de acordo com a Wikipedia definition, é “...uma lista que define quem tem permissão de acesso a certos serviços.” No caso do Joomla, existem dois aspectos distintos para sua Lista de Controle de Acesso que os administradores do site podem controlar:

  • Que usuários podem ter acesso a que partes do site? Por exemplo, uma certa opção de menu estará disponível para um certo usuário? Um usuário cadastrado pode ver, mas o público em geral não. Talvez a opção de menu esteja escondida de todos, exceto de um usuário definido como Editor ou superiores.
  • Que operações (ou ações) podem aplicar um usuário a um objeto específico? Por exemplo, um usuário cadastrado como "Editor" pode enviar um artigo ou somente editar artigos existentes. Os controles de ACL podem permitir o envio e edição ou mudança na categoria do artigo, adicionar tags ou outro tipo de combinação. submit an article or only edit an existing article.

A implementação da ACL no Joomla foi modificada de forma substancial na série Joomla 2.5 o que permitiu maior flexibilidade para os grupos e permissões.

Languages

{{:Translations:Access Control List/ru/Page_display_title/<lang code>‎}}

Согласно определения Википедии, Access Control List [список контроля доступа] или ACL, “...ACL указывает каким пользователям или системным процессам предоставляется доступ к объектам, а также какие операции разрешаются осуществлять над данными объектами.” В случае с [системой] Joomla, существуют два отдельных аспекта ее ACL [списка контроля доступа], которые администраторы веб-сайта могут контролировать:

  • Какие пользователи к какой части веб-сайта получают доступ? Например, будет ли данное выбранное меню видимо данному пользователю? Зарегистрированный пользователь сможет, но общая публика - нет. Возможно, выбор этого меню скрыт ото всех, за исключением пользователей-редакторов и пользователей с высшим [правом доступа].
  • Какие операции (или действия) какой-либо пользователь может осуществлять над любым конкретным объектом? Например, может ли пользователь, показанный как "Editor"[/редактор] создать какой-либо материал или [он может] только редактировать какой-либо существующий материал? Настройки ACL могут разрешить создание и редактирование, или разрешить вносить изменения в категорию данного материала, [или] разрешить добавлять метки, или [разрешить] любую комбинацию [из этого].

Применение ACL [списка контроля доступа] в Joomla было существенно изменено в серии [версий] Joomla! 2.5, что предоставило группам и правам больше гибкости.



Дальнейшее чтение

Версии

Наставления

{{:Translations:Access Control List/ru/Page_display_title/<lang code>‎}}

Согласно определения Википедии, Access Control List [список контроля доступа] или ACL, “...ACL указывает каким пользователям или системным процессам предоставляется доступ к объектам, а также какие операции разрешаются осуществлять над данными объектами.” В случае с [системой] Joomla, существуют два отдельных аспекта ее ACL [списка контроля доступа], которые администраторы веб-сайта могут контролировать:

  • Какие пользователи к какой части веб-сайта получают доступ? Например, будет ли данное выбранное меню видимо данному пользователю? Зарегистрированный пользователь сможет, но общая публика - нет. Возможно, выбор этого меню скрыт ото всех, за исключением пользователей-редакторов и пользователей с высшим [правом доступа].
  • Какие операции (или действия) какой-либо пользователь может осуществлять над любым конкретным объектом? Например, может ли пользователь, показанный как "Editor"[/редактор] создать какой-либо материал или [он может] только редактировать какой-либо существующий материал? Настройки ACL могут разрешить создание и редактирование, или разрешить вносить изменения в категорию данного материала, [или] разрешить добавлять метки, или [разрешить] любую комбинацию [из этого].

Применение ACL [списка контроля доступа] в Joomla было существенно изменено в серии [версий] Joomla! 2.5, что предоставило группам и правам больше гибкости.

Languages

{{:Translations:Access Control List/ru/Page_display_title/<lang code>‎}}

Quill icon.png
Content is Incomplete

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

Обзор ACL в версии Joomla

Этот раздел подчеркивает главные изменения в ACL [списке контроля доступа] между версиями серий 2.5 и 3.х (в которую входят будущие выпуски). Ниже расположенная таблица суммирует изменения, [происшедшие начиная] с версии 2.5.

Версия 2.5 Версия 3.4
Группы Неограниченные определенные пользователем группы Как и в 2.5
Пользователи и группы Один пользователь может быть назначен нескольким группам Как и в 2.5
Уровни доступа Неограниченное количество определенных пользователем уровней доступа Как и в 2.5
Уровни доступа и группы Группы назначаются уровням доступа. Любая комбинация групп может быть назначена любому уровню доступа. Как и в 2.5

Смотрите также

Access Control List/sv

Access Control List or ACL is according to the Wikipedia definition, “...ACL specifies which users or system processes are granted access to objects, as well as what operations are allowed to be performed on given objects.” In the case of Joomla there are two separate aspects to its Access Control List which site administrators can control:

  • Which users can gain access to what parts of the website? For example, will a given menu choice be visible for a given user? A registered user can view, but the public at large cannot. Perhaps the menu choice is hidden from all except an Editor user and higher.
  • What operations (or actions) can a user perform on any given object? For example, can a user listed as an "Editor" submit an article or only edit an existing article. The ACL settings could allow submitting and editing, or allow a change an article's category, add tags or any combination.

The implementation of ACL in Joomla was substantially changed in the Joomla! 2.5 series which allowed for more flexibility in groups and permissions.

Languages

{{:Translations:Access Control List/sw/Page_display_title/<lang code>‎}}

Kulingana na Ufafanuzi wa Wikipedia, "...orodha ya kuthibiti maingizo (Access Control List, ACL) itabainisha kuwa ni watumiaji gani (au maendeleo ya mfumo gani) wataruhisiwa kuingia kwa vyombo tofauti, na oparesheni gani wataruhusiwa kwa kiasi cha vyombo fulani". Katika kesi ya Joomla, kuna masuala mawili ya Orodha ya Kuthibiti Maingizo ambayo wasimamizi wanaweza kuthibiti:

  • Watumiaji gani wanaweza kuingia sehemu gani ya wavuti? Kwa mfano, mtumiaji maalum ataweza kuona chaguo maalum la menyu? Mtumiaji aliesajiliwa ataweza kuona, lakini waumma wengi hawataweza kuona. Pengine chaguo la menyu limefichwa kwa wote isipokuwa Mtumiaji wa Kuhariri au wa hali ya juu.
  • Oparesheni (au vitendo) gani mtumiaji ataweza kufanya kwa kiasi cha vyombo fulani? Kwa mfano, mtumiaji alieorodheshwa kama "Mhariri" ataweza kuwasilisha makala au ataweza kuhariri makala ambayo iko tayari pekee? Matayarisho ya ACL yanawaza kuruhusu mawasilisho na kuhariri, ama kuruhusu kubadilisha jamii ya makala, kuongeza matagi au machanganyiko yoyote.

Utekelezaji wa ACL katika Joomla umebadilishwa kwa kiasi kikubwa katika mfululizo wa Joomla! 2.5, ambao unaruhusu marahisisho zaidi kuhusu vikundi na maruhusa.



Further reading

Matoleo

Mafunzo

{{:Translations:Access Control List/sw/Page_display_title/<lang code>‎}}

Kulingana na Ufafanuzi wa Wikipedia, "...orodha ya kuthibiti maingizo (Access Control List, ACL) itabainisha kuwa ni watumiaji gani (au maendeleo ya mfumo gani) wataruhisiwa kuingia kwa vyombo tofauti, na oparesheni gani wataruhusiwa kwa kiasi cha vyombo fulani". Katika kesi ya Joomla, kuna masuala mawili ya Orodha ya Kuthibiti Maingizo ambayo wasimamizi wanaweza kuthibiti:

  • Watumiaji gani wanaweza kuingia sehemu gani ya wavuti? Kwa mfano, mtumiaji maalum ataweza kuona chaguo maalum la menyu? Mtumiaji aliesajiliwa ataweza kuona, lakini waumma wengi hawataweza kuona. Pengine chaguo la menyu limefichwa kwa wote isipokuwa Mtumiaji wa Kuhariri au wa hali ya juu.
  • Oparesheni (au vitendo) gani mtumiaji ataweza kufanya kwa kiasi cha vyombo fulani? Kwa mfano, mtumiaji alieorodheshwa kama "Mhariri" ataweza kuwasilisha makala au ataweza kuhariri makala ambayo iko tayari pekee? Matayarisho ya ACL yanawaza kuruhusu mawasilisho na kuhariri, ama kuruhusu kubadilisha jamii ya makala, kuongeza matagi au machanganyiko yoyote.

Utekelezaji wa ACL katika Joomla umebadilishwa kwa kiasi kikubwa katika mfululizo wa Joomla! 2.5, ambao unaruhusu marahisisho zaidi kuhusu vikundi na maruhusa.

Languages

{{:Translations:Access Control List/tr/Page_display_title/<lang code>‎}}

Chunk:Access Control List/tr

Further reading

Sürümler

Dersler

Access Control List Tutorial

Overview of ACL in Version Joomla 2.5

This section outlines the major ACL changes between versions 1.5 and 2.5 series (including 1.6 and 1.7). The table below summarizes the major changes from version 1.5.

Version 1.5 2.5 series
Groups 7 fixed groups (Public, Registered, Author, Editor, Publisher, Manager, Administrator, and Super-Administrator) Unlimited user-defined Groups
Users & Groups A User can be assigned to only one group A User can be assigned to multiple groups
Access Levels 3 fixed Access Levels (Public, Registered, Special) Unlimited user-defined Access Levels
Access Levels & Groups Relationship between Groups and Access Levels was fixed. Groups are assigned to Access Levels. Any combination of Groups can be assigned to any Access Level.

We see that in every case the ACL has been made much more flexible, with unlimited Groups and Access Levels, and the ability to assign one User to multiple Groups and any Groups to any Access Level.

Separate ACL for Viewing and Doing

The Joomla ACL system can be thought of as being divided into two completely separate systems. One system controls what things on the site users can view. The other controls what things users can do (what actions a user can take). The ACL for each is set up differently.

Controlling What Users Can See

The setup for controlling what users can see is done as follows:

  1. Create the different User Groups required for the site. Each Group can be thought of as a role that a user will have for the site. Keep in mind that one User can be a member of one or more Groups. If desired, groups can have parent groups. In this case, they automatically inherit the Access Levels of the parent group.
  2. Create the set of Access Levels required for the site. This could be a small number or a large number depending on the number of different groups and how many categories of items there are. Assign each Access Level to one or more of the User Groups created in step 1.
  3. Assign each item to be viewed to one Access Level. Items include content items (articles, contacts, and so on), menu items, and modules.

Any time a user is about to view an item on a Joomla page, the program checks whether the user has access to the item, as follows:

  1. Creates a list of all the Access Levels that the User has access to, based on all Groups that the User belongs to. Also, if a group has a parent group, access levels for the parent group are also included in the list.
  2. Checks whether the Access Level for the item (article, module, menu item, and so on) is on that list. If yes, then the item is displayed to the user. If no, then the item is not displayed.

Note that Access Levels are set separately for each Group and are not inherited from a group's parent group.

Controlling What Users Can Do

The system for setting up what users can do -- what actions they can take on a given item -- is set up with the Permissions tab of Global Configuration and the Permissions tab of the Options screen of each component. Permissions can also be set up at the Category level for core components and at the Article level for articles.

Note that this set up is independent of the setup for viewing.

When a user wants to initiate a specific action against a component item (for example, edit an article), the system checks the permission for this combination of user, item, and action. If it is allowed, then the user can proceed. Otherwise, the action is not allowed.

The remainder of this tutorial discusses how we control what users can do -- what action permissions they have.

Actions, Groups, and Inheritance

The other side of ACL is granting permissions to users to take actions on objects. Here again there is a big change between Version 1.5 and 1.6. In 1.5, the actions allowed for a given group were fixed. For example, a User in the Author group could only submit an article whereas someone in the Publisher group could submit, edit, and publish articles. Also, in version 1.5 the permissions were all-or-nothing. A member of the Editor group could edit all articles on the site.

The table below shows what has changed between versions 1.5 and 2.5 series (including 1.6 and 1.7).

Version 1.5 2.5 series
Groups and Actions Actions allowed by different groups are fixed. Actions allowed for each group are defined by site administrator.
Permission Scope Entire Site. User has same permissions for all objects on the site. Permissions can be set at multiple levels in hierarchy: Site, Component, Category, Object.
Permission Inheritance Not applicable Permissions can be inherited from parent Groups and parent Categories

How Permissions Work

There are four possible permissions for actions, as outlined below:

  • Not set: Defaults to "deny" but, unlike the Deny permission, this permission can be overridden by setting a child group or a lower level in the permission hierarchy to "Allow". This permission only applies to the Global Configuration permissions.
  • Inherit: Inherits the value from a parent Group or from a higher level in the permission hierarchy. This permission applies to all levels except the Global Configuration level.
  • Deny: Denies this action for this level and group. IMPORTANT: This also denies this action for all child groups and all lower levels in the permission hierarchy. Putting in Allow for a child group or a lower level will not have any effect. The action will always be denied for any child group member and for any lower level in the permission hierarchy.
  • Allow: Allows this action for this level and group and for lower levels and child groups. This does not have any effect if a higher group or level is set to Deny or Allow. If a higher group or level is set to Deny, then this permission will always be denied. If a higher group or level is set to Allow, then this permission will already be allowed.

Permission Hierarchy Levels

Action permissions in version 2.5 can be defined at up to four levels, as follows:

  1. Global Configuration: determines the default permissions for each action and group.
  2. Component Options->Permissions: can override the default permissions for this component (for example, Articles, Menus, Users, Banners, and so on)
  3. Category: can override the default permissions for objects in one or more categories. Applies to all components with categories, including Articles, Banners, Contacts, Newsfeeds, and Weblinks.
  4. Article: Can override the permissions for a specific article. This level only applies to articles. Other components only allow the first three levels.

Global Configuration

This is accessed from Site → Global Configuration → Permissions. This screen allows you set the top-level permission for each group for each action, as shown in the screenshot below.

Screenshot acl tutorial 20110111-01.png

The options for each value are Inherited, Allowed, or Denied. The Calculated Setting column shows you the setting in effect. It is either Not Allowed (the default), Allowed, or Denied.

You work on one Group at a time by opening the slider for that group. You change the permissions in the Select New Settings drop-down list boxes.

Note that the Calculated Setting column is not updated until you press the Save button in the toolbar. To check that the settings are what you want, press the Save button and check the Calculated Settings column.

Component Options->Permissions

This is accessed for each component by clicking the Options icon in the toolbar. This screen is similar to the Global Configuration screen above. For example, clicking the Options toolbar icon in the Menu Manager shows the Menus Configuration below.

Screenshot acl tutorial 20110111-02.png

Access to Options is only available to members of groups who have permission for the Configure action in for each component. In the example above, the Administrator group has Allowed permission for the Configure option, so members of this group can access this screen.

Category

Category permissions are accessed in the Category Manager: Edit Category screen, in a slider at the bottom of the screen. This screen has five permissions, as shown below.

Screenshot acl tutorial 20110111-03.png

In these screens, you work on the permissions for one User Group at a time. In the example above, we are editing the permissions for the Administrator group.

Note that the Configure and Access Component actions do not apply at the category level, so those actions are not included.

Note also that Categories can be arranged in a hierarchy. If so, then action permissions in a parent category are inherited automatically by a child category. For example, if you had a category hierarchy of Animals → Pets → Dogs, then the full permission level hierarchy for an article in the Dogs category would be as follows:

  • Global Configuration
  • Article Manager → Options → Permission
  • Animals Category
  • Pets Category
  • Dogs Category
  • specific article

Article

Permissions for a single article are access in the Article Manager: Edit Article screen, again in a slider at the bottom of the screen. This screen has three actions, as shown below.

Screenshot acl tutorial 20110111-04.png

Again, you edit each group by clicking on it to open the slider for that group. You can then change the permissions under the Select New Setting column. To see the effect of any changes, press the Save button to update the Calculated Setting column.

Note that the Configure, Access Component, and Create actions do not apply at the article level, so these actions are not included. Permission to create an article is set at one of the higher levels in the hierarchy.

Access Levels

Access Levels in 2.5 series are simple and flexible. The screen below shows the Special Access Level.

Screenshot acl tutorial 20110111-05.png

Simply check the box for each group you want included in that level. The Special Access Level includes the Manager, Author, and Super Users groups. It also includes child groups of those groups. So, Administrator group is included, since it is a child group of the Manager group. The Editor, Publisher, and Shop Suppliers groups are included, since they are child groups of Author. (Note that we could check all of the child groups if we wanted and it wouldn't hurt anything.)

Once Access Levels are created, they are used in the same way as in version 1.5. Each object in the front end is assigned an Access Level. If the level is Public, then anyone may access that object. Otherwise, only members of groups assigned to that access level may access that object. Access levels are assigned to Menu Items and to Modules. Each one can only be assigned to one access level.

For example, the screen below shows the Edit Menu Item screen with the list of available access levels.

Screenshot acl tutorial 20110111-06.png

Default ACL Setup

When Joomla! is installed, these are set to their initial default settings. We will discuss these initial settings as a way to understand how the ACL works.

Default Groups

Version 2.5 allows you to define your own Groups. When you install version 2.5, it includes a set of default groups, as shown below.

Screenshot acl tutorial 20110111-07.png

The arrows indicate the child-parent relationships. As discussed above, when you set a permission for a parent group, this permission is automatically inherited by all child groups. The Inherited, and Allowed permissions can be overridden for a child group. The Denied permission cannot be overridden and will always deny an action for all child groups.

Global Configuration

Joomla! version 2.5 will install with the same familiar back-end permissions as that of version 1.5. However, with 2.5, you can easily change these to suit the needs of your site.

As discussed earlier, the permissions for each action are inherited from the level above in the permission hierarchy and from a group's parent group. Let's see how this works. The top level for this is the entire site. This is set up in the Site->Global Configuration->Permissions, as shown below.

Screenshot acl tutorial 20110111-08.png

The first thing to notice are the nine Actions: Site Login, Admin Login, Super Admin, Access Component, Create, Delete, Edit, Edit State. and Edit Own. These are the actions that a user can perform on an object in Joomla. The specific meaning of each action depends on the context. For the Global Configuration screen, they are defined as follows:

Site Login 
Login to the front end of the site
Admin Login 
Login to the back end of the site
Super Admin 
Grants the user "super user" status. Users with this permission can do anything on the site. Only users with this permission can change Global Configuration settings (this screen). These permissions cannot be restricted. It is important to understand that, if a user is a member of a Super Admin group, any other permissions assigned to this user are irrelevant. The user can do any action on the site. However, Access Levels can still be assigned to control what this group sees on the site. (Obviously, a Super Admin user can change Access Levels if they want to, so Access Levels do not totally restrict what a Super Admin user can see.)
Access Component
Open the component manager screens (User Manager, Menu Manager, Article Manager, and so on)
Create 
Create new objects (for example, users, menu items, articles, weblinks, and so on)
Delete 
Delete existing objects
Edit 
Edit existing objects
Edit State 
Change object state (Publish, Unpublish, Archive, and Trash)
Edit Own 
Edit objects that you have created.

Each Group for the site has its own slider which is opened by clicking on the group name. In this case (with the sample data installed), we have the standard 7 groups that we had in version 1.5 plus two additional groups called "Shop Suppliers" and "Customer Group". Notice that our groups are set up with the same permissions as they had in version 1.5. Keep in mind that we can change any of these permissions to make the security work the way we want. Let's go through this to see how it works.

  • Public has everything set to "Not set", as shown below.
Screenshot acl tutorial 20110112-06.png
This can be a bit confusing. Basically, "Not Set" is the same as "Inherited". Because Public is our top-level group, and because Global Configuration is the top level of the component hierarchy, there is nothing to inherit from. So "Not Set" is used instead of "Inherit".
The default in this case is for no permissions. So, as you would expect, the Public group has no special permissions. Also, it is important to note that, since nothing is set to Denied, all of these permissions may be overridden by child groups or by lower levels in the permission hierarchy.
  • Manager is a "child" group of the Public group. It has Allowed permissions for everything except Access Component and Super Admin. So a member of this group can do everything in the front and back end of the site except change Global Permissions and Component Options.
  • Administrator group members inherit all of the Manager permissions and also have Allowed for Access Component. So members of this group by default can access the Options screens for each component.
  • Registered is the same a Public except for the Allow permission for the Site Login action. This means that members of the Registered group can login to the site. Since default permissions are inherited, this means that, unless a child group overrides this permission, all child groups of the Registered group will be able to login as well.
  • Author is a child of the Registered group and inherits its permissions and also adds Create and Edit Own. Since Author, Editor, and Publisher have no back-end permissions, we will discuss them below, when we discuss front-end permissions.
  • Editor is a child of the Authors group and adds the Edit permission.
  • Publisher is a child of Editor and adds the Edit State permission.
  • Shop Suppliers is an example group that is installed if you install the sample data. It is a child group of Author.
  • Customer Group is an example group that is installed if you install the sample data. It is a child group of Registered.
  • Super Users group has the Allow permission for the Super Admin action. Because of this, members of this group have super user permissions throughout the site. They are the only users who can access and edit values on the Global Configuration screen. Users with permission for the Super Admin action have some special characteristics:
    • If a user has Super Admin permissions, no other permissions for this user matter. The user can perform any action on the site.
    • Only Super Admin users can create, edit, or delete other Super Admin users or groups.

There are two very important points to understand from this screen. The first is to see how the permissions can be inherited from the parent Group. The second is to see how you can control the default permissions by Group and by Action.

This provides a lot of flexibility. For example, if you wanted Shop Suppliers to be able to have the ability to login to the back end, you could just change their Admin Login value to "Allowed". If you wanted to not allow members of Administrator group to delete objects or change their state, you would change their permissions in these columns to Inherited (or Denied).

It is also important to understand that the ability to have child groups is completely optional. It allows you to save some time when setting up new groups. However, if you like, you can set up all groups to have Public as the parent and not inherit any permissions from a parent group.

Component Options & Permissions

Now, let's continue to see how the default back-end permissions for version 2.5 mimic the permissions for version 1.5. The Super Users group in 2.5 is equivalent to the Super Administrator group in 1.5.

Just looking at the Global Configuration screen above, it would appear that the Administrator group and the Manager group have identical permissions. However, in version 1.5 Administrators can do everything except Global Configuration, whereas Managers are not permitted to add users or work with menu items. That is also true in the default version 2.5 configuration. Let's see how this is accomplished.

If we navigate to Users->User Manager and click the Options button in the toolbar, we see the screen below:

Screenshot acl tutorial 20110111-09-en.png
Screenshot acl tutorial 20110111-10-en.png

This screen is the same as the Global Configuration Permissions screen, except that these values only affect working with Users. Let's look at how this works.

First, notice that the Administrator group has Allow permission for the Admin action and the Manager group has Deny permission for this action. Remember that the Admin action in the Global Configuration screen gives the group "super user" permissions. In this screen, the Admin action allows you to edit the Options values. So, the Administrator group can do this but the Manager group cannot.

Next, notice that the Administrator has Inherit for the Manage action and the Manager group has Deny permission. In this screen, the Manage action gives a group access to the User Manager. Since the Administrator has Allow for the Manage action by default, then the Inherit permission here means they inherit the Allow permission for the Manage action. Since the Manager group has Deny permission for the Manage action, members of the Manager group cannot access the User Manager and therefore cannot do any of the other user-related actions.

If you look at the Options for Menus->Menu Manager, you will see the same default settings as for the User Manager. Again, the Administrator group can manage and set default permissions for Menu Manager objects whereas the Manager group cannot.

In short, we can see that the different permissions for the Administrator and Manager groups are set using the Options->Permissions forms on the User Manager and Menu Manager screens.

It is also important to understand that this same Options->Permissions form for setting default permissions is available for all Joomla! objects, including Media Manager, Banners, Contacts, Newsfeeds, Redirect, Search Statistics, Web Links, Extensions, Modules, Plugins, Templates, and Language. So you now have the option to create user groups with fine-tuned sets of back-end permissions.

Front End Permissions

Default permissions for the front end are also set using the Options form. Let's look at Content->Article Manager->Options->Permissions. First, let's look at the permissions for Manager, as shown below.

Screenshot acl tutorial 20110111-11a-en.png

Manager has allowed permission for all actions except Configure. So members of the Manager group can do everything with Articles except open the Options screen.

Now let's look at Administrator, as shown below.

Screenshot acl tutorial 20110111-12a-en.png

Administrator has Allowed for Configure, so Administrators can edit this Options screen.

Both groups can create, delete, edit, and change the state of articles.

Now, let's look at the groups Publisher, Editor, and Author and see how their permissions are set.

Authors only have Create and Edit Own permissions, as shown below.

Screenshot acl tutorial 20110112-07-en.png

This means that Authors can create articles and can edit articles they have created. They may not delete articles, change the published state of articles, or edit articles created by others.

Editors have the same permissions as Authors with the addition of permission for the Edit action, as shown below.

Screenshot acl tutorial 20110112-08-en.png

So Editors can edit articles written by anyone.

Publishers can do everything Editors can do plus they have permission for the Edit State action, as shown below.

Screenshot acl tutorial 20110112-09-en.png

So Publishers can change the published state of an article. The possible states include Published, Unpublished, Archived, and Trashed.

All of these groups have Inherit permission for Configure and Access Component. Remember that Author is a child of the Registered group, and Registered does not have any default permissions except for Login. Since Registered does not have permission for Configure and Access Component, and since Author's permission for these actions is "Inherited", then Author does not have these permissions either. This same permission is passed from Author to Editor and from Editor to Publisher. So, by default, none of these groups are allowed to work with articles in the back end.

It is important to remember that these permissions are only default settings for categories and articles and for any child groups that are created. So they can be overridden for child groups, for categories, and for specific articles.

Also, note that there are no Denied permissions for any actions in the default settings. This allows you to add Allowed permissions at any level. Remember, once you have an action set for Denied, this action will be denied at all lower levels in the hierarchy. For example, if you set the Admin Login for Registered to Denied (instead of Inherited), you could not grant Publishers Allowed permissions for this action.

Article Manager & Actions Diagram

The diagram below shows how each action in the permissions form relates to the various options on the Article Manager screen.

Screenshot acl tutorial 20110111-16-en.png
  • Configure allows you to view and change the Options for the component.
  • Access Component allows you to navigate to the Article Manager. Without this permission, no other actions are possible.
  • Create allows you to add new articles.
  • Delete allows you to delete trashed articles. Note that the Delete icon only shows in the toolbar when you have the "Select State" filter set to "Trash".
  • Edit allows you to edit existing articles.
  • Edit State allows to you Publish, Unpublish, Archive, or Trash articles.
  • Edit Own is the same as Edit except that it only applies to articles written by you.

Allowing Guest-Only Access to Menu Items and Modules

Version 1.6 introduced the ability to create a View Access Level that is only for guests of the site (meaning a user who is not logged in). The example below shows how you can set up this new feature.

  1. Create a new user group called Guest. Make it a child of the Public group as shown below.
    Screenshot acl tutorial 20110112-01-en.png
  2. Create a new access level called Guest and grant only the Guest group access to this level, as shown below.
    Screenshot acl tutorial 20110112-02-en.png
  3. Navigate to User Manager→Options→Component and change the Guest User Group from the default value of "Public" to "Guest", as shown below.
Screenshot acl tutorial 20110112-04-en.png

Now, if we assign a menu item, module, or other object to the Guest access level, only non-logged in users will have access. For example, if we create a new menu item with access level of Guest, as shown below,

Screenshot acl tutorial 20110112-05-en.png

this menu item will only be visible to non-logged-in visitors to the site.

If required other user groups like Author can be granted access in the Guest access level, this would allow Authors to view articles in the front end for editing.

N.B. Login/logout in front end (for changing data in session) to see the change.

Using Permission and Group Levels Together

As discussed above, it is possible to define groups in a hierarchy, where each child group inherits action permissions (for example, the create permission) from its parent group. Action permissions are also be inherited from the permission level above. For example, a permission in the Article Manager is inherited from the same permission in the Global Configuration, and a permission in a child Category is inherited from the parent Category permission.

This dual inheritance can be confusing, but it can also be useful. Let's consider an example as follows. We have a school with a group hierarchy of Teachers → History Teachers → Assistant History Teachers. We also have a category hierarchy of Assignments → History Assignments. We want History Teachers and Assistant History Teachers to have the following permissions:

  • both groups can create new articles only in the History Assignments category.
  • only History Teachers (not Assistant History Teachers) can Publish or otherwise have Edit State permission.

This ACL scheme is very easy to implement. The diagram below shows how this would be set up for the Create Action.

Acl example diagram1 20091018-en.png

In the diagram, the Permission Hierarchy is shown down the left side and the Group hierarchy is shown across the top. Permissions are inherited down and to the right, as shown by the arrows. To implement the desired permissions, we leave the Global Configuration blank (Not Set) for all three groups. Similarly, in the Article Manager and Assignments Category, we leave the Create permission to Inherit for all the groups. As shown in the diagram, this means that these groups do not have Create permission for articles in general or for articles in the Assignments group.

To sum up so far, we have not set any special permissions to get to this point. Now, in the History Assignments category permissions screen, we set the Create permission to Allow for the History Teachers group. This setting overrides the Soft (Implicit) Deny that we had by default and gives members of this group permission to create content (articles and child categories) for this category. This Allow setting also is inherited by the Assistant History Teachers group.

Next, we need to grant History Teachers the Edit State permission while denying this permission to Assistant History Teachers. This is done as shown in the diagram below.

Acl example diagram2 20091018-en.png

This configuration is the same as the one above except that this time we set the Edit State permission in the History Assignments category to Deny for the Assistant History Teachers group. This means that Assistant History Teachers will not be able to Publish or Unpublish articles in this category.

Note that this was accomplished by setting just two permissions in the History Assignments category: Allow for the History Teachers group and Deny for the Assistant History Teachers group.

ACL Action Permission Examples

Here are some examples of how you might set up the ACL for some specific situations.

Back-end Article Administrator

Problem:

We want to create a group called "Article Administrator" with back-end permissions only for articles and not for any other back-end menu options. Members of this group should be able to use all of the features of the article manager, including setting article permissions.

Solution:

  1. Create a new group called Article Administrator and make its parent group Public, as shown below.
    Screenshot acl tutorial 20110112-10-en.png
    Because its parent group is Public, it won't have any permissions by default.
  2. In Users → Access Levels, edit the Special Access level to add the new group. That way they can get access to the back end menu items and modules (This assumes that the modules for the admin menu and quickicons have the Special Access level assigned to them, which is the default.)
    Screenshot acl tutorial 20110112-11-en.png
    By default, the back-end menu items and modules are set to Special access, so if you forget to add the new group to the Special access level, you won't see any modules or menu items when you log in as a user of the new group.
  3. In Site → Global Configuration → Permissions, click on the Article Administrator group and change the permissions to Allowed for the following actions: Admin Login, Create, Delete, Edit, Edit State, and Edit Own. The screen below shows what will show before you press Save.
    Screenshot acl tutorial 20110112-12-en.png
    After you save, the Calculated Permissions should show as shown below.
    Screenshot acl tutorial 20110112-13-en.png
    Note that the permission for the Access Component is Inherited, which translates to Not Allowed. This is important. This means that this group will only be able to access components if we give the group "Allowed" permission for Access Component. So we only have to change the one component we want to give them access to and don't have to change any settings for the components where we don't want them to have access. If we had a case where we wanted to give a group access to everything except for one component, we could set the default to Allowed and then set the one component to Denied. Also note that we did not give the group Site Login permission, so users in this group will not be able to log into the front end. (If we wanted to allow that, we would just change the permission to Allowed for Site Login.)
  4. In Article Manager → Options → Permissions, change permissions to Allowed for this group for the Access Component action, as shown below.
    Screenshot acl tutorial 20110112-14-en.png
    All of the other desired permissions are inherited.
That's all you need to do. Members of this group can login to the back end and do everything in Article Manager but can't do anything else in the back end. For example, the screen below shows what a user in the Article Manager will see when they login to the back end.
Screenshot acl tutorial 20110112-15-en.png

ACL View Access Levels Examples

A basic concept of using Access Levels is that all items with the same Access will be viewable by the same group of users. In other words, if two items have the same Access, you can't have one viewable by one user and not viewable by another user. On the other hand, it is easy to have one Group view any number of items with different Access levels.

Similarly, each Group has exactly the same combination of Access levels, but one User can be a member of more than one group. Depending on the situation, you may want to have users only in one Group or you may need to have a User in more than one Group.

This means that we may need to group our items so that items so that all items in a group have the same level of sensitivity. Here are some examples.

Hierarchical Example

In this example, Access levels are hierarchical, for example, like government security clearance codes. Say for example we have the following sets of classified documents: Classified, Secret, and Top Secret. Users have corresponding clearence codes. Users with Classified clearance can only see Classified documents and cannot see Secret or Top Secret. Users with Secret clearance can see Classified and Secret documents but not Top Secret. Users with Top Secret can see all documents.

In this case, you would create three Access levels: Classified, Secret, and Top Secret and the same three Groups. Users would only be members of one group, as follows:

User Group Access Levels
C1, C2, C3 Classified Classified
S1, S2, S3 Secret Classified, Secret
TS1, TS2, TS3 Top Secret Classified, Secret, Top Secret

In this case, all users are in exactly one group, but some groups have access to more than one Access Level of items. In other words, we have a one-to-one relationship between users and groups, but a one-to-many relationship between Groups and Access Levels.

Team Security Example

Another possible use case is a set of non-hierarchical teams. Let's say we have three teams, T1, T2, and T3. Some users are only on one team, but others might be on two or more teams. In this case, we could set up our Access Levels and Groups by team. Documents for each team have the access level for that team, and the Group for the team has only the one access level. When a User is on more than one team, they get added to the group for each team, as follows:

User Description Group Access Levels
U1 Team 1 member T1 T1
U2 Team 2 member T2 T2
U3 Team 3 member T3 T3
U1-2 Member of teams 1 and 2 T1, T2 T1, T2
U1-3 Member of teams 1 and 3 T1, T3 T1, T3
U1-2-3 Member of teams 1,2, and 3 T1,T2, T3 T1, T2, T3


Hybrid Example

In a real-world situation, you might have a combination of these two arrangements. Say for example we have Managers and Staff. Staff can only see Staff documents and Managers can see Manager and Staff documents. Both types of users can be assigned to teams as well, in which case they can see all of the documents for that team. In addition, say that Managers can access some, but not all, team documents. Staff can only access team documents if they are members of that team.

In this example, we could set up the following Access Levels:

Access Level Description Groups
Manager Non-team manager documents Manager
Staff Non-team staff documents Manager, Staff
Team1 Sensitive Team1 documents (no access outside team) Team1
Team1-Manager Team1 documents that can be accessed by all managers Team1, Manager
Team2 Sensitive Team2 documents (no access outside team) Team2
Team2-Manager Team2 documents that can be accessed by all managers Team2, Manager

Then, users could be assigned to groups as follows:

User Type Group
Manager on no teams Manager
Staff on no teams Staff
Manager on team 1 Manager, Team1
Staff on team 1 Staff, Team1
Manager on teams 1 and 2 Manager, Team1, Team2
Staff on teams 1 and 2 Staff, Team1, Team2

Access Control List Tutorial

I added the future marker for consistency with other pages. Tony Davis 21:54, 28 October 2009 (UTC)

Access Control List Tutorial

Joomla! 
3.x
series

Overview of ACL in Version Joomla

This section outlines any major ACL changes between versions 2.5 and the 3.x series (which will include future releases). The table below summarizes the changes from version 2.5.

Version 2.5 Version 3.4
Groups Unlimited user-defined Groups Same as 2.5
Users & Groups A User can be assigned to multiple groups Same as 2.5
Access Levels Unlimited user-defined Access Levels Same as 2.5
Access Levels & Groups Groups are assigned to Access Levels. Any combination of Groups can be assigned to any Access Level. Same as 2.5

Separate ACL for Viewing and Doing

The Joomla ACL system can be thought of as being divided into two completely separate systems. One system controls what things on the site users can view. The other controls what things users can do (what actions a user can take). The ACL for each is set up differently.

Controlling What Users Can See

The setup for controlling what users can see is done as follows:

  • Create a set of Access Levels according to the Categories and/or the combination of categories you wish only logged in users to see. N.B do not assign any user groups to the new Access Levels at this point.
  • Create a User Group, with 'Registered' as parent, for each Access Level. Using the same names for the User Groups as the Access Levels will prevent confusion later.
  • Edit your new Access Levels and assign the correct (new)User Group to each one. You may also wish to assign the Super User Group(and/or the other default User Groups but not 'Guest' User Group) to all your new Access Levels
  • Assign each item to be viewed to one Access Level. Items include content items (articles, contacts, and so on), menu items, and modules.

Any time a user is about to view an item on a Joomla page, the program checks whether the user has access to the item, as follows:

  1. Creates a list of all the Access Levels that the User has access to, based on all Groups that the User belongs to. Also, if a group has a parent group, access levels for the parent group are also included in the list.
  2. Checks whether the Access Level for the item (article, module, menu item, and so on) is on that list. If yes, then the item is displayed to the user. If no, then the item is not displayed.

Note that Access Levels are set separately for each Group and are not inherited from a group's parent group.

Controlling What Users Can Do

The system for setting up what users in a User Group can do -- what actions they can take on a given item -- is set up with the Permissions tab of Global Configuration and the Permissions tab of the Options screen of each component. Permissions can also be set up at the Category level for core components and at the Article level for articles.

  • If you wish logged in users to Create, Delete, Edit State or Edit Own for specific Categories then:
    • Create a User Group with the Parent as one of your User Groups that has Access to the Category(or Categories) you wish this new User Group to modify.
    • Assign your new User Group to the appropriate Access Level(s). Then change the required permissions for your new user Group either Globally or per Category/Article.
      • When creating a User Group it is good practice to select a parent group that has less permissions than needed for the new group. This is because it is easier to elevate permissions per Component/Category/Article that the extra permissions are needed for than it is to remove permissions from the other Components/Categories/Articles.
        • (example: You have 10 Categories but you want Create permissions for just 1. If you set Global permissions to Allow Create for that group you would need to remove Create permission for all those categories. And you would need to remove the Create permission for that group with any new Category that you add at a later date.)
    • Only create a User Group with one of the default User Groups as parent if none of them have the exact permissions that you need and you wish all Categories

Note that this set up is independent of the setup for viewing but a User Group needs to be assigned to the appropriate Access Level(s) in order for the user in that Group to use those Permissions.

When a user wants to initiate a specific action against a component item (for example, edit an article), the system (after checking the Group the user is in has access) checks the permission for this combination of user, item, and action. If it is allowed, then the user can proceed. Otherwise, the action is not allowed.

The remainder of this tutorial discusses how we control what users can do -- what action permissions they have.

Actions, Groups, and Inheritance

The other side of ACL is granting permissions to users to take actions on objects.

3.x series
Groups and Actions Actions allowed for each group are defined by site administrator.
Permission Scope Permissions can be set at multiple levels in hierarchy: Site, Component, Category, Object.
Permission Inheritance Permissions can be inherited from parent Groups and parent Categories

How Permissions Work

There are four possible permissions for actions, as outlined below:

  • Not set: Defaults to "deny" but, unlike the Deny permission, this permission can be overridden by setting a child group or a lower level in the permission hierarchy to "Allow". This permission only applies to the Global Configuration permissions.
  • Inherit: Inherits the value from a parent Group or from a higher level in the permission hierarchy. This permission applies to all levels except the Global Configuration level.
  • Deny: Denies this action for this level and group. IMPORTANT: This also denies this action for all child groups and all lower levels in the permission hierarchy. Putting in Allow for a child group or a lower level will not have any effect. The action will always be denied for any child group member and for any lower level in the permission hierarchy.
  • Allow: Allows this action for this level and group and for lower levels and child groups. This does not have any effect if a higher group or level is set to Deny or Allow. If a higher group or level is set to Deny, then this permission will always be denied. If a higher group or level is set to Allow, then this permission will already be allowed.

Permission Hierarchy Levels

Action permissions in version 2.5 can be defined at up to four levels, as follows:

  1. Global Configuration: determines the default permissions for each action and group.
  2. Component Options->Permissions: can override the default permissions for this component (for example, Articles, Menus, Users, Banners, and so on).
  3. Category: can override the default permissions for objects in one or more categories. Applies to all components with categories, including Articles, Banners, Contacts, Newsfeeds, and Weblinks.
  4. Article: Can override the permissions for a specific article. This level only applies to articles. Other components only allow the first three levels.

Global Configuration

This is accessed from Site → Global Configuration → Permissions. This screen allows you set the top-level permission for each group for each action, as shown in the screenshot below.

Screenshot global acl J3 tutorial-en.png

The options for each value are Inherited, Allowed, or Denied. The Calculated Setting column shows you the setting in effect. It is either Not Allowed (the default), Allowed, or Denied.

You work on one Group at a time by opening the slider for that group. You change the permissions in the Select New Settings drop-down list boxes.

Note that the Calculated Setting column is not updated until you press the Save button in the toolbar. To check that the settings are what you want, press the Save button and check the Calculated Settings column.

Component Options->Permissions

This is accessed for each component by clicking the Options icon in the toolbar. This screen is similar to the Global Configuration screen above. For example, clicking the Options toolbar icon in the Menu Manager shows the Menus Configuration below. Screenshot menu acl J3 tutorial-en.jpg

Access to Options is only available to members of groups who have permission for the Configure action in for each component. In the example above, the Administrator group has Allowed permission for the Configure option, so members of this group can access this screen.

Category

Category permissions are accessed in the Category Manager: Edit Category screen, in a tab at the top of the screen. This screen has five permissions, as shown below.

Screenshot category acl j3 tutorial-en.png

In these screens, you work on the permissions for one User Group at a time. In the example above, we are editing the permissions for the Administrator group.

Note that the Configure and Access Component actions do not apply at the category level, so those actions are not included.

Note also that Categories can be arranged in a hierarchy. If so, then action permissions in a parent category are inherited automatically by a child category. For example, if you had a category hierarchy of Animals → Pets → Dogs, then the full permission level hierarchy for an article in the Dogs category would be as follows:

  • Global Configuration
  • Article Manager → Options → Permission
  • Animals Category
  • Pets Category
  • Dogs Category
  • specific article

Article

Permissions for a single article are access in the Article Manager: Edit Article screen, again in a slider at the bottom of the screen. This screen has three actions, as shown below.

J3x acl tutorial article manager article permissions-en.png

Again, you edit each group by clicking on it to open the slider for that group. You can then change the permissions under the Select New Setting column. To see the effect of any changes, press the Save button to update the Calculated Setting column.

Note that the Configure, Access Component, and Create actions do not apply at the article level, so these actions are not included. Permission to create an article is set at one of the higher levels in the hierarchy.

Access Levels

Access Levels in 3.x series are simple and flexible. The screen below shows the Special Access Level.

J3x acl tutorial viewing levels-en.png

Simply check the box for each group you want included in that level. The Special Access Level includes the Manager, Author, and Super Users groups. It also includes child groups of those groups. So, Administrator group is included, since it is a child group of the Manager group. The Editor, Publisher, and Shop Suppliers groups are included, since they are child groups of Author. (Note that we could check all of the child groups if we wanted and it wouldn't hurt anything).

Once Access Levels are created, they are used in the same way as in version 1.5. Each object in the front end is assigned an Access Level. If the level is Public, then anyone may access that object. Otherwise, only members of groups assigned to that access level may access that object. Access levels are assigned to Menu Items and to Modules. Each one can only be assigned to one access level.

For example, the screen below shows the Edit Menu Item screen with the list of available access levels.

J3x acl tutorial edit menu item level dropdown-en.png

Default ACL Setup

When Joomla! is installed, these are set to their initial default settings. We will discuss these initial settings as a way to understand how the ACL works.

Default Groups

Version 3.x allows you to define your own Groups. When you install version 3.x, it includes a set of default groups, shown below are the basic default user groups. (Additional default user groups are installed with sample data)

Screenshot usergroupsl acl J3 tutorial-en.png

The arrows indicate the child-parent relationships. As discussed above, when you set a permission for a parent group, this permission is automatically inherited by all child groups. The Inherited, and Allowed permissions can be overridden for a child group. The Denied permission cannot be overridden and will always deny an action for all child groups.

Global Configuration

Joomla! version 2.5 will install with the same familiar back-end permissions as that of version 1.5. However, with 2.5, you can easily change these to suit the needs of your site.

As discussed earlier, the permissions for each action are inherited from the level above in the permission hierarchy and from a group's parent group. Let's see how this works. The top level for this is the entire site. This is set up in the Site->Global Configuration->Permissions, as shown below.

Screenshot global acl J3 tutorial-en.png

The first thing to notice are the nine Actions: Site Login, Admin Login, Super Admin, Access Component, Create, Delete, Edit, Edit State. and Edit Own. These are the actions that a user can perform on an object in Joomla. The specific meaning of each action depends on the context. For the Global Configuration screen, they are defined as follows:

Site Login 
Login to the front end of the site
Admin Login 
Login to the back end of the site
Super Admin 
Grants the user "super user" status. Users with this permission can do anything on the site. Only users with this permission can change Global Configuration settings (this screen). These permissions cannot be restricted. It is important to understand that, if a user is a member of a Super Admin group, any other permissions assigned to this user are irrelevant. The user can do any action on the site. However, Access Levels can still be assigned to control what this group sees on the site. (Obviously, a Super Admin user can change Access Levels if they want to, so Access Levels do not totally restrict what a Super Admin user can see.)
Access Component
Open the component manager screens (User Manager, Menu Manager, Article Manager, and so on)
Create 
Create new objects (for example, users, menu items, articles, weblinks, and so on)
Delete 
Delete existing objects
Edit 
Edit existing objects
Edit State 
Change object state (Publish, Unpublish, Archive, and Trash)
Edit Own 
Edit objects that you have created.

Each Group for the site has its own slider which is opened by clicking on the group name. In this case (with the sample data installed), we have the standard 7 groups that we had in version 1.5 plus two additional groups called "Shop Suppliers" and "Customer Group". Notice that our groups are set up with the same permissions as they had in version 1.5. Keep in mind that we can change any of these permissions to make the security work the way we want. Let's go through this to see how it works.

  • Public has everything set to "Not set", as shown below.
    Screenshot global acl public J3 tutorial-en.png
    • This can be a bit confusing. Basically, "Not Set" is the same as "Inherited". Because Public is our top-level group, and because Global Configuration is the top level of the component hierarchy, there is nothing to inherit from. So "Not Set" is used instead of "Inherit".
    • The default in this case is for no permissions. So, as you would expect, the Public group has no special permissions. Also, it is important to note that, since nothing is set to Denied, all of these permissions may be overridden by child groups or by lower levels in the permission hierarchy.
  • Guest is a 'child' group of the Public group has everything set to 'Inherited'
    Screenshot global acl guest J3 tutorial-en.png
    • This is the default 'Guest User Group' in the User Manager options and the Group that (non logged in) visitors to your site are placed in.
  • Manager is a "child" group of the Public group. It has Allowed permissions for everything except Access Component and Super Admin. So a member of this group can do everything in the front and back end of the site except change Global Permissions and Component Options.
    Screenshot global acl manager J3 tutorial-en.png
  • Administrator group members inherit all of the Manager permissions and also have Allowed for Access Component. So members of this group by default can access the Options screens for each component.
    Screenshot global acl administrator J3 tutorial-en.png
  • Registered is the same a Public except for the Allow permission for the Site Login action. This means that members of the Registered group can login to the site. Since default permissions are inherited, this means that, unless a child group overrides this permission, all child groups of the Registered group will be able to login as well.
    Screenshot global acl registered J3 tutorial-en.png
  • Author is a child of the Registered group and inherits its permissions and also adds Create and Edit Own. Since Author, Editor, and Publisher have no back-end permissions, we will discuss them below, when we discuss front-end permissions.
    Screenshot global acl author J3 tutorial-en.png
  • Editor is a child of the Authors group and adds the Edit permission.
    Screenshot global acl editor J3 tutorial-en.png
  • Publisher is a child of Editor and adds the Edit State permission.
    Screenshot global acl publisher J3 tutorial-en.png
  • Shop Suppliers is an example group that is installed if you install the sample data. It is a child group of Author.
  • Customer Group is an example group that is installed if you install the sample data. It is a child group of Registered.
  • Super Users group has the Allow permission for the Super Admin action. Because of this, members of this group have super user permissions throughout the site. They are the only users who can access and edit values on the Global Configuration screen. Users with permission for the Super Admin action have some special characteristics:
  • If a user has Super Admin permissions, no other permissions for this user matter. The user can perform any action on the site.
  • Only Super Admin users can create, edit, or delete other Super Admin users or groups.

There are two very important points to understand from this screen. The first is to see how the permissions can be inherited from the parent Group. The second is to see how you can control the default permissions by Group and by Action.

This provides a lot of flexibility. For example, if you wanted Shop Suppliers to be able to have the ability to login to the back end, you could just change their Admin Login value to "Allowed". If you wanted to not allow members of Administrator group to delete objects or change their state, you would change their permissions in these columns to Inherited (or Denied).

It is also important to understand that the ability to have child groups is completely optional. It allows you to save some time when setting up new groups. However, if you like, you can set up all groups to have Public as the parent and not inherit any permissions from a parent group.

Component Options & Permissions

Now, let's continue to see how the default back-end permissions for version 2.5 mimic the permissions for version 1.5. The Super Users group in 2.5 is equivalent to the Super Administrator group in 1.5.

Just looking at the Global Configuration screen above, it would appear that the Administrator group and the Manager group have identical permissions. However, in version 1.5 Administrators can do everything except Global Configuration, whereas Managers are not permitted to add users or work with menu items. That is also true in the default version 2.5 configuration. Let's see how this is accomplished.

If we navigate to Users->User Manager and click the Options button in the toolbar, we see the screen below:

Screenshot acl tutorial 20110111-09-en.png
Screenshot acl tutorial 20110111-10-en.png

This screen is the same as the Global Configuration Permissions screen, except that these values only affect working with Users. Let's look at how this works.

First, notice that the Administrator group has Allow permission for the Admin action and the Manager group has Deny permission for this action. Remember that the Admin action in the Global Configuration screen gives the group "super user" permissions. In this screen, the Admin action allows you to edit the Options values. So, the Administrator group can do this but the Manager group cannot.

Next, notice that the Administrator has Inherit for the Manage action and the Manager group has Deny permission. In this screen, the Manage action gives a group access to the User Manager. Since the Administrator has Allow for the Manage action by default, then the Inherit permission here means they inherit the Allow permission for the Manage action. Since the Manager group has Deny permission for the Manage action, members of the Manager group cannot access the User Manager and therefore cannot do any of the other user-related actions.

If you look at the Options for Menus->Menu Manager, you will see the same default settings as for the User Manager. Again, the Administrator group can manage and set default permissions for Menu Manager objects whereas the Manager group cannot.

In short, we can see that the different permissions for the Administrator and Manager groups are set using the Options->Permissions forms on the User Manager and Menu Manager screens.

It is also important to understand that this same Options->Permissions form for setting default permissions is available for all Joomla! objects, including Media Manager, Banners, Contacts, Newsfeeds, Redirect, Search Statistics, Web Links, Extensions, Modules, Plugins, Templates, and Language. So you now have the option to create user groups with fine-tuned sets of back-end permissions.

Front End Permissions

Default permissions for the front end are also set using the Options form. Let's look at Content->Article Manager->Options->Permissions. First, let's look at the permissions for Manager, as shown below.

Screenshot acl tutorial 20110111-11a-en.png

Manager has allowed permission for all actions except Configure. So members of the Manager group can do everything with Articles except open the Options screen.

Now let's look at Administrator, as shown below.

Screenshot acl tutorial 20110111-12a-en.png

Administrator has Allowed for Configure, so Administrators can edit this Options screen.

Both groups can create, delete, edit, and change the state of articles.

Now, let's look at the groups Publisher, Editor, and Author and see how their permissions are set.

Authors only have Create and Edit Own permissions, as shown below.

Screenshot acl tutorial 20110112-07-en.png

This means that Authors can create articles and can edit articles they have created. They may not delete articles, change the published state of articles, or edit articles created by others.

Editors have the same permissions as Authors with the addition of permission for the Edit action, as shown below.

Screenshot acl tutorial 20110112-08-en.png

So Editors can edit articles written by anyone.

Publishers can do everything Editors can do plus they have permission for the Edit State action, as shown below.

Screenshot acl tutorial 20110112-09-en.png

So Publishers can change the published state of an article. The possible states include Published, Unpublished, Archived, and Trashed.

All of these groups have Inherit permission for Configure and Access Component. Remember that Author is a child of the Registered group, and Registered does not have any default permissions except for Login. Since Registered does not have permission for Configure and Access Component, and since Author's permission for these actions is "Inherited", then Author does not have these permissions either. This same permission is passed from Author to Editor and from Editor to Publisher. So, by default, none of these groups are allowed to work with articles in the back end.

It is important to remember that these permissions are only default settings for categories and articles and for any child groups that are created. So they can be overridden for child groups, for categories, and for specific articles.

Also, note that there are no Denied permissions for any actions in the default settings. This allows you to add Allowed permissions at any level. Remember, once you have an action set for Denied, this action will be denied at all lower levels in the hierarchy. For example, if you set the Admin Login for Registered to Denied (instead of Inherited), you could not grant Publishers Allowed permissions for this action.

Article Manager & Actions Diagram

The diagram below shows how each action in the permissions form relates to the various options on the Article Manager screen.

Screenshot acl tutorial 20110111-16-en.png
  • Configure allows you to view and change the Options for the component.
  • Access Component allows you to navigate to the Article Manager. Without this permission, no other actions are possible.
  • Create allows you to add new articles.
  • Delete allows you to delete trashed articles. Note that the Delete icon only shows in the toolbar when you have the "Select State" filter set to "Trash".
  • Edit allows you to edit existing articles.
  • Edit State allows to you Publish, Unpublish, Archive, or Trash articles.
  • Edit Own is the same as Edit except that it only applies to articles written by you.

Allowing Guest-Only Access to Menu Items and Modules

Version 1.6 introduced the ability to create a View Access Level that is only for guests of the site (meaning a user who is not logged in). The example below shows how you can set up this new feature. (N.B. Steps 1 to 3 are not needed for Joomla! 3.x as they exist in the default install

  1. Create a new user group called Guest. Make it a child of the Public group as shown below.
    Screenshot acl tutorial 20110112-01-en.png
  2. Create a new access level called Guest and grant only the Guest group access to this level, as shown below.
    Screenshot acl tutorial 20110112-02-en.png
  3. Navigate to User Manager→Options→Component and change the Guest User Group from the default value of "Public" to "Guest", as shown below.
Screenshot acl tutorial 20110112-04-en.png

Now, if we assign a menu item, module, or other object to the Guest access level, only non-logged in users will have access. For example, if we create a new menu item with access level of Guest, as shown below,

Screenshot acl tutorial 20110112-05-en.png

this menu item will only be visible to non-logged-in visitors to the site.

If required other user groups like Author can be granted access in the Guest access level, this would allow Authors to view articles in the front end for editing.

N.B. Login/logout in front end (for changing data in session) to see the change.

Using Permission and Group Levels Together

As discussed above, it is possible to define groups in a hierarchy, where each child group inherits action permissions (for example, the create permission) from its parent group. Action permissions are also be inherited from the permission level above. For example, a permission in the Article Manager is inherited from the same permission in the Global Configuration, and a permission in a child Category is inherited from the parent Category permission.

This dual inheritance can be confusing, but it can also be useful. Let's consider an example as follows. We have a school with a group hierarchy of Teachers → History Teachers → Assistant History Teachers. We also have a category hierarchy of Assignments → History Assignments. We want History Teachers and Assistant History Teachers to have the following permissions:

  • both groups can create new articles only in the History Assignments category.
  • only History Teachers (not Assistant History Teachers) can Publish or otherwise have Edit State permission.

This ACL scheme is very easy to implement. The diagram below shows how this would be set up for the Create Action.

Acl example diagram1 20091018-en.png

In the diagram, the Permission Hierarchy is shown down the left side and the Group hierarchy is shown across the top. Permissions are inherited down and to the right, as shown by the arrows. To implement the desired permissions, we leave the Global Configuration blank (Not Set) for all three groups. Similarly, in the Article Manager and Assignments Category, we leave the Create permission to Inherit for all the groups. As shown in the diagram, this means that these groups do not have Create permission for articles in general or for articles in the Assignments group.

To sum up so far, we have not set any special permissions to get to this point. Now, in the History Assignments category permissions screen, we set the Create permission to Allow for the History Teachers group. This setting overrides the Soft (Implicit) Deny that we had by default and gives members of this group permission to create content (articles and child categories) for this category. This Allow setting also is inherited by the Assistant History Teachers group.

Next, we need to grant History Teachers the Edit State permission while denying this permission to Assistant History Teachers. This is done as shown in the diagram below.

Acl example diagram2 20091018-en.png

This configuration is the same as the one above except that this time we set the Edit State permission in the History Assignments category to Deny for the Assistant History Teachers group. This means that Assistant History Teachers will not be able to Publish or Unpublish articles in this category.

Note that this was accomplished by setting just two permissions in the History Assignments category: Allow for the History Teachers group and Deny for the Assistant History Teachers group.

ACL Action Permission Examples

Here are some examples of how you might set up the ACL for some specific situations.

Back-end Article Administrator

Problem:

We want to create a group called "Article Administrator" with back-end permissions only for articles and not for any other back-end menu options. Members of this group should be able to use all of the features of the article manager, including setting article permissions.

Solution:

  1. Create a new group called Article Administrator and make its parent group Public, as shown below.
    Screenshot acl tutorial 20110112-10-en.png
    Because its parent group is Public, it won't have any permissions by default.
  2. In Users → Access Levels, edit the Special Access level to add the new group. That way they can get access to the back end menu items and modules (This assumes that the modules for the admin menu and quickicons have the Special Access level assigned to them, which is the default.)
    Screenshot acl tutorial 20110112-11-en.png
    By default, the back-end menu items and modules are set to Special access, so if you forget to add the new group to the Special access level, you won't see any modules or menu items when you log in as a user of the new group.
  3. In Site → Global Configuration → Permissions, click on the Article Administrator group and change the permissions to Allowed for the following actions: Admin Login, Create, Delete, Edit, Edit State, and Edit Own. The screen below shows what will show before you press Save.
    Screenshot acl tutorial 20110112-12-en.png
    After you save, the Calculated Permissions should show as shown below.
    Screenshot acl tutorial 20110112-13-en.png
    Note that the permission for the Access Component is Inherited, which translates to Not Allowed. This is important. This means that this group will only be able to access components if we give the group "Allowed" permission for Access Component. So we only have to change the one component we want to give them access to and don't have to change any settings for the components where we don't want them to have access. If we had a case where we wanted to give a group access to everything except for one component, we could set the default to Allowed and then set the one component to Denied. Also note that we did not give the group Site Login permission, so users in this group will not be able to log into the front end. (If we wanted to allow that, we would just change the permission to Allowed for Site Login.)
  4. In Article Manager → Options → Permissions, change permissions to Allowed for this group for the Access Component action, as shown below.
    Screenshot acl tutorial 20110112-14-en.png
    All of the other desired permissions are inherited.
That's all you need to do. Members of this group can login to the back end and do everything in Article Manager but can't do anything else in the back end. For example, the screen below shows what a user in the Article Manager will see when they login to the back end.
Screenshot acl tutorial 20110112-15-en.png

ACL View Access Levels Examples

A basic concept of using Access Levels is that all items with the same Access will be viewable by the same group of users. In other words, if two items have the same Access, you can't have one viewable by one user and not viewable by another user. On the other hand, it is easy to have one Group view any number of items with different Access levels.

Similarly, each Group has exactly the same combination of Access levels, but one User can be a member of more than one group. Depending on the situation, you may want to have users only in one Group or you may need to have a User in more than one Group.

This means that we may need to group our items so that items so that all items in a group have the same level of sensitivity. Here are some examples.

Hierarchical Example

In this example, Access levels are hierarchical, for example, like government security clearance codes. Say for example we have the following sets of classified documents: Classified, Secret, and Top Secret. Users have corresponding clearence codes. Users with Classified clearance can only see Classified documents and cannot see Secret or Top Secret. Users with Secret clearance can see Classified and Secret documents but not Top Secret. Users with Top Secret can see all documents.

In this case, you would create three Access levels: Classified, Secret, and Top Secret and the same three Groups. Users would only be members of one group, as follows:

User Group Access Levels
C1, C2, C3 Classified Classified
S1, S2, S3 Secret Classified, Secret
TS1, TS2, TS3 Top Secret Classified, Secret, Top Secret

In this case, all users are in exactly one group, but some groups have access to more than one Access Level of items. In other words, we have a one-to-one relationship between users and groups, but a one-to-many relationship between Groups and Access Levels.

Team Security Example

Another possible use case is a set of non-hierarchical teams. Let's say we have three teams, T1, T2, and T3. Some users are only on one team, but others might be on two or more teams. In this case, we could set up our Access Levels and Groups by team. Documents for each team have the access level for that team, and the Group for the team has only the one access level. When a User is on more than one team, they get added to the group for each team, as follows:

User Description Group Access Levels
U1 Team 1 member T1 T1
U2 Team 2 member T2 T2
U3 Team 3 member T3 T3
U1-2 Member of teams 1 and 2 T1, T2 T1, T2
U1-3 Member of teams 1 and 3 T1, T3 T1, T3
U1-2-3 Member of teams 1,2, and 3 T1,T2, T3 T1, T2, T3


Hybrid Example

In a real-world situation, you might have a combination of these two arrangements. Say for example we have Managers and Staff. Staff can only see Staff documents and Managers can see Manager and Staff documents. Both types of users can be assigned to teams as well, in which case they can see all of the documents for that team. In addition, say that Managers can access some, but not all, team documents. Staff can only access team documents if they are members of that team.

In this example, we could set up the following Access Levels:

Access Level Description Groups
Manager Non-team manager documents Manager
Staff Non-team staff documents Manager, Staff
Team1 Sensitive Team1 documents (no access outside team) Team1
Team1-Manager Team1 documents that can be accessed by all managers Team1, Manager
Team2 Sensitive Team2 documents (no access outside team) Team2
Team2-Manager Team2 documents that can be accessed by all managers Team2, Manager

Then, users could be assigned to groups as follows:

User Type Group
Manager on no teams Manager
Staff on no teams Staff
Manager on team 1 Manager, Team1
Staff on team 1 Staff, Team1
Manager on teams 1 and 2 Manager, Team1, Team2
Staff on teams 1 and 2 Staff, Team1, Team2

Access Control List Tutorial

I would like to see the inheritance aspect better explained for a hybrid example. It is by default backwards than I anticipated. As in the standard Joomla setup focuses more on granting permissions, where as some may be more focused on denying permissions.

CrandellWS (talk) 09:30, 19 February 2014 (CST)

"It is by default backwards than I anticipated."
Please explain backwards
"As in the standard Joomla setup focuses more on granting permissions, where as some may be more focused on denying permissions."
Those who concentrate on denying Permissions are doing it incorrectly. It has been explained that If Permission is given Globally and denied for a category ... then every time a Category is created the Permissions in that category have to be edited. Giving minimal Permissions then Allowing the exceptions is the correct method.

--Topazgb 12:19, 19 February 2014 (CST)

Access Control List Tutorial/en

Joomla! 
3.x
series

Overview of ACL in Version Joomla

This section outlines any major ACL changes between versions 2.5 and the 3.x series (which will include future releases). The table below summarizes the changes from version 2.5.

Version 2.5 Version 3.4
Groups Unlimited user-defined Groups Same as 2.5
Users & Groups A User can be assigned to multiple groups Same as 2.5
Access Levels Unlimited user-defined Access Levels Same as 2.5
Access Levels & Groups Groups are assigned to Access Levels. Any combination of Groups can be assigned to any Access Level. Same as 2.5

Separate ACL for Viewing and Doing

The Joomla ACL system can be thought of as being divided into two completely separate systems. One system controls what things on the site users can view. The other controls what things users can do (what actions a user can take). The ACL for each is set up differently.

Controlling What Users Can See

The setup for controlling what users can see is done as follows:

  • Create a set of Access Levels according to the Categories and/or the combination of categories you wish only logged in users to see. N.B do not assign any user groups to the new Access Levels at this point.
  • Create a User Group, with 'Registered' as parent, for each Access Level. Using the same names for the User Groups as the Access Levels will prevent confusion later.
  • Edit your new Access Levels and assign the correct (new)User Group to each one. You may also wish to assign the Super User Group(and/or the other default User Groups but not 'Guest' User Group) to all your new Access Levels
  • Assign each item to be viewed to one Access Level. Items include content items (articles, contacts, and so on), menu items, and modules.

Any time a user is about to view an item on a Joomla page, the program checks whether the user has access to the item, as follows:

  1. Creates a list of all the Access Levels that the User has access to, based on all Groups that the User belongs to. Also, if a group has a parent group, access levels for the parent group are also included in the list.
  2. Checks whether the Access Level for the item (article, module, menu item, and so on) is on that list. If yes, then the item is displayed to the user. If no, then the item is not displayed.

Note that Access Levels are set separately for each Group and are not inherited from a group's parent group.

Controlling What Users Can Do

The system for setting up what users in a User Group can do -- what actions they can take on a given item -- is set up with the Permissions tab of Global Configuration and the Permissions tab of the Options screen of each component. Permissions can also be set up at the Category level for core components and at the Article level for articles.

  • If you wish logged in users to Create, Delete, Edit State or Edit Own for specific Categories then:
    • Create a User Group with the Parent as one of your User Groups that has Access to the Category(or Categories) you wish this new User Group to modify.
    • Assign your new User Group to the appropriate Access Level(s). Then change the required permissions for your new user Group either Globally or per Category/Article.
      • When creating a User Group it is good practice to select a parent group that has less permissions than needed for the new group. This is because it is easier to elevate permissions per Component/Category/Article that the extra permissions are needed for than it is to remove permissions from the other Components/Categories/Articles.
        • (example: You have 10 Categories but you want Create permissions for just 1. If you set Global permissions to Allow Create for that group you would need to remove Create permission for all those categories. And you would need to remove the Create permission for that group with any new Category that you add at a later date.)
    • Only create a User Group with one of the default User Groups as parent if none of them have the exact permissions that you need and you wish all Categories

Note that this set up is independent of the setup for viewing but a User Group needs to be assigned to the appropriate Access Level(s) in order for the user in that Group to use those Permissions.

When a user wants to initiate a specific action against a component item (for example, edit an article), the system (after checking the Group the user is in has access) checks the permission for this combination of user, item, and action. If it is allowed, then the user can proceed. Otherwise, the action is not allowed.

The remainder of this tutorial discusses how we control what users can do -- what action permissions they have.

Actions, Groups, and Inheritance

The other side of ACL is granting permissions to users to take actions on objects.

3.x series
Groups and Actions Actions allowed for each group are defined by site administrator.
Permission Scope Permissions can be set at multiple levels in hierarchy: Site, Component, Category, Object.
Permission Inheritance Permissions can be inherited from parent Groups and parent Categories

How Permissions Work

There are four possible permissions for actions, as outlined below:

  • Not set: Defaults to "deny" but, unlike the Deny permission, this permission can be overridden by setting a child group or a lower level in the permission hierarchy to "Allow". This permission only applies to the Global Configuration permissions.
  • Inherit: Inherits the value from a parent Group or from a higher level in the permission hierarchy. This permission applies to all levels except the Global Configuration level.
  • Deny: Denies this action for this level and group. IMPORTANT: This also denies this action for all child groups and all lower levels in the permission hierarchy. Putting in Allow for a child group or a lower level will not have any effect. The action will always be denied for any child group member and for any lower level in the permission hierarchy.
  • Allow: Allows this action for this level and group and for lower levels and child groups. This does not have any effect if a higher group or level is set to Deny or Allow. If a higher group or level is set to Deny, then this permission will always be denied. If a higher group or level is set to Allow, then this permission will already be allowed.

Permission Hierarchy Levels

Action permissions in version 2.5 can be defined at up to four levels, as follows:

  1. Global Configuration: determines the default permissions for each action and group.
  2. Component Options->Permissions: can override the default permissions for this component (for example, Articles, Menus, Users, Banners, and so on).
  3. Category: can override the default permissions for objects in one or more categories. Applies to all components with categories, including Articles, Banners, Contacts, Newsfeeds, and Weblinks.
  4. Article: Can override the permissions for a specific article. This level only applies to articles. Other components only allow the first three levels.

Global Configuration

This is accessed from Site → Global Configuration → Permissions. This screen allows you set the top-level permission for each group for each action, as shown in the screenshot below.

Screenshot global acl J3 tutorial-en.png

The options for each value are Inherited, Allowed, or Denied. The Calculated Setting column shows you the setting in effect. It is either Not Allowed (the default), Allowed, or Denied.

You work on one Group at a time by opening the slider for that group. You change the permissions in the Select New Settings drop-down list boxes.

Note that the Calculated Setting column is not updated until you press the Save button in the toolbar. To check that the settings are what you want, press the Save button and check the Calculated Settings column.

Component Options->Permissions

This is accessed for each component by clicking the Options icon in the toolbar. This screen is similar to the Global Configuration screen above. For example, clicking the Options toolbar icon in the Menu Manager shows the Menus Configuration below. Screenshot menu acl J3 tutorial-en.jpg

Access to Options is only available to members of groups who have permission for the Configure action in for each component. In the example above, the Administrator group has Allowed permission for the Configure option, so members of this group can access this screen.

Category

Category permissions are accessed in the Category Manager: Edit Category screen, in a tab at the top of the screen. This screen has five permissions, as shown below.

Screenshot category acl j3 tutorial-en.png

In these screens, you work on the permissions for one User Group at a time. In the example above, we are editing the permissions for the Administrator group.

Note that the Configure and Access Component actions do not apply at the category level, so those actions are not included.

Note also that Categories can be arranged in a hierarchy. If so, then action permissions in a parent category are inherited automatically by a child category. For example, if you had a category hierarchy of Animals → Pets → Dogs, then the full permission level hierarchy for an article in the Dogs category would be as follows:

  • Global Configuration
  • Article Manager → Options → Permission
  • Animals Category
  • Pets Category
  • Dogs Category
  • specific article

Article

Permissions for a single article are access in the Article Manager: Edit Article screen, again in a slider at the bottom of the screen. This screen has three actions, as shown below.

J3x acl tutorial article manager article permissions-en.png

Again, you edit each group by clicking on it to open the slider for that group. You can then change the permissions under the Select New Setting column. To see the effect of any changes, press the Save button to update the Calculated Setting column.

Note that the Configure, Access Component, and Create actions do not apply at the article level, so these actions are not included. Permission to create an article is set at one of the higher levels in the hierarchy.

Access Levels

Access Levels in 3.x series are simple and flexible. The screen below shows the Special Access Level.

J3x acl tutorial viewing levels-en.png

Simply check the box for each group you want included in that level. The Special Access Level includes the Manager, Author, and Super Users groups. It also includes child groups of those groups. So, Administrator group is included, since it is a child group of the Manager group. The Editor, Publisher, and Shop Suppliers groups are included, since they are child groups of Author. (Note that we could check all of the child groups if we wanted and it wouldn't hurt anything).

Once Access Levels are created, they are used in the same way as in version 1.5. Each object in the front end is assigned an Access Level. If the level is Public, then anyone may access that object. Otherwise, only members of groups assigned to that access level may access that object. Access levels are assigned to Menu Items and to Modules. Each one can only be assigned to one access level.

For example, the screen below shows the Edit Menu Item screen with the list of available access levels.

J3x acl tutorial edit menu item level dropdown-en.png

Default ACL Setup

When Joomla! is installed, these are set to their initial default settings. We will discuss these initial settings as a way to understand how the ACL works.

Default Groups

Version 3.x allows you to define your own Groups. When you install version 3.x, it includes a set of default groups, shown below are the basic default user groups. (Additional default user groups are installed with sample data)

Screenshot usergroupsl acl J3 tutorial-en.png

The arrows indicate the child-parent relationships. As discussed above, when you set a permission for a parent group, this permission is automatically inherited by all child groups. The Inherited, and Allowed permissions can be overridden for a child group. The Denied permission cannot be overridden and will always deny an action for all child groups.

Global Configuration

Joomla! version 2.5 will install with the same familiar back-end permissions as that of version 1.5. However, with 2.5, you can easily change these to suit the needs of your site.

As discussed earlier, the permissions for each action are inherited from the level above in the permission hierarchy and from a group's parent group. Let's see how this works. The top level for this is the entire site. This is set up in the Site->Global Configuration->Permissions, as shown below.

Screenshot global acl J3 tutorial-en.png

The first thing to notice are the nine Actions: Site Login, Admin Login, Super Admin, Access Component, Create, Delete, Edit, Edit State. and Edit Own. These are the actions that a user can perform on an object in Joomla. The specific meaning of each action depends on the context. For the Global Configuration screen, they are defined as follows:

Site Login 
Login to the front end of the site
Admin Login 
Login to the back end of the site
Super Admin 
Grants the user "super user" status. Users with this permission can do anything on the site. Only users with this permission can change Global Configuration settings (this screen). These permissions cannot be restricted. It is important to understand that, if a user is a member of a Super Admin group, any other permissions assigned to this user are irrelevant. The user can do any action on the site. However, Access Levels can still be assigned to control what this group sees on the site. (Obviously, a Super Admin user can change Access Levels if they want to, so Access Levels do not totally restrict what a Super Admin user can see.)
Access Component
Open the component manager screens (User Manager, Menu Manager, Article Manager, and so on)
Create 
Create new objects (for example, users, menu items, articles, weblinks, and so on)
Delete 
Delete existing objects
Edit 
Edit existing objects
Edit State 
Change object state (Publish, Unpublish, Archive, and Trash)
Edit Own 
Edit objects that you have created.

Each Group for the site has its own slider which is opened by clicking on the group name. In this case (with the sample data installed), we have the standard 7 groups that we had in version 1.5 plus two additional groups called "Shop Suppliers" and "Customer Group". Notice that our groups are set up with the same permissions as they had in version 1.5. Keep in mind that we can change any of these permissions to make the security work the way we want. Let's go through this to see how it works.

  • Public has everything set to "Not set", as shown below.
    Screenshot global acl public J3 tutorial-en.png
    • This can be a bit confusing. Basically, "Not Set" is the same as "Inherited". Because Public is our top-level group, and because Global Configuration is the top level of the component hierarchy, there is nothing to inherit from. So "Not Set" is used instead of "Inherit".
    • The default in this case is for no permissions. So, as you would expect, the Public group has no special permissions. Also, it is important to note that, since nothing is set to Denied, all of these permissions may be overridden by child groups or by lower levels in the permission hierarchy.
  • Guest is a 'child' group of the Public group has everything set to 'Inherited'
    Screenshot global acl guest J3 tutorial-en.png
    • This is the default 'Guest User Group' in the User Manager options and the Group that (non logged in) visitors to your site are placed in.
  • Manager is a "child" group of the Public group. It has Allowed permissions for everything except Access Component and Super Admin. So a member of this group can do everything in the front and back end of the site except change Global Permissions and Component Options.
    Screenshot global acl manager J3 tutorial-en.png
  • Administrator group members inherit all of the Manager permissions and also have Allowed for Access Component. So members of this group by default can access the Options screens for each component.
    Screenshot global acl administrator J3 tutorial-en.png
  • Registered is the same a Public except for the Allow permission for the Site Login action. This means that members of the Registered group can login to the site. Since default permissions are inherited, this means that, unless a child group overrides this permission, all child groups of the Registered group will be able to login as well.
    Screenshot global acl registered J3 tutorial-en.png
  • Author is a child of the Registered group and inherits its permissions and also adds Create and Edit Own. Since Author, Editor, and Publisher have no back-end permissions, we will discuss them below, when we discuss front-end permissions.
    Screenshot global acl author J3 tutorial-en.png
  • Editor is a child of the Authors group and adds the Edit permission.
    Screenshot global acl editor J3 tutorial-en.png
  • Publisher is a child of Editor and adds the Edit State permission.
    Screenshot global acl publisher J3 tutorial-en.png
  • Shop Suppliers is an example group that is installed if you install the sample data. It is a child group of Author.
  • Customer Group is an example group that is installed if you install the sample data. It is a child group of Registered.
  • Super Users group has the Allow permission for the Super Admin action. Because of this, members of this group have super user permissions throughout the site. They are the only users who can access and edit values on the Global Configuration screen. Users with permission for the Super Admin action have some special characteristics:
  • If a user has Super Admin permissions, no other permissions for this user matter. The user can perform any action on the site.
  • Only Super Admin users can create, edit, or delete other Super Admin users or groups.

There are two very important points to understand from this screen. The first is to see how the permissions can be inherited from the parent Group. The second is to see how you can control the default permissions by Group and by Action.

This provides a lot of flexibility. For example, if you wanted Shop Suppliers to be able to have the ability to login to the back end, you could just change their Admin Login value to "Allowed". If you wanted to not allow members of Administrator group to delete objects or change their state, you would change their permissions in these columns to Inherited (or Denied).

It is also important to understand that the ability to have child groups is completely optional. It allows you to save some time when setting up new groups. However, if you like, you can set up all groups to have Public as the parent and not inherit any permissions from a parent group.

Component Options & Permissions

Now, let's continue to see how the default back-end permissions for version 2.5 mimic the permissions for version 1.5. The Super Users group in 2.5 is equivalent to the Super Administrator group in 1.5.

Just looking at the Global Configuration screen above, it would appear that the Administrator group and the Manager group have identical permissions. However, in version 1.5 Administrators can do everything except Global Configuration, whereas Managers are not permitted to add users or work with menu items. That is also true in the default version 2.5 configuration. Let's see how this is accomplished.

If we navigate to Users->User Manager and click the Options button in the toolbar, we see the screen below:

Screenshot acl tutorial 20110111-09-en.png
Screenshot acl tutorial 20110111-10-en.png

This screen is the same as the Global Configuration Permissions screen, except that these values only affect working with Users. Let's look at how this works.

First, notice that the Administrator group has Allow permission for the Admin action and the Manager group has Deny permission for this action. Remember that the Admin action in the Global Configuration screen gives the group "super user" permissions. In this screen, the Admin action allows you to edit the Options values. So, the Administrator group can do this but the Manager group cannot.

Next, notice that the Administrator has Inherit for the Manage action and the Manager group has Deny permission. In this screen, the Manage action gives a group access to the User Manager. Since the Administrator has Allow for the Manage action by default, then the Inherit permission here means they inherit the Allow permission for the Manage action. Since the Manager group has Deny permission for the Manage action, members of the Manager group cannot access the User Manager and therefore cannot do any of the other user-related actions.

If you look at the Options for Menus->Menu Manager, you will see the same default settings as for the User Manager. Again, the Administrator group can manage and set default permissions for Menu Manager objects whereas the Manager group cannot.

In short, we can see that the different permissions for the Administrator and Manager groups are set using the Options->Permissions forms on the User Manager and Menu Manager screens.

It is also important to understand that this same Options->Permissions form for setting default permissions is available for all Joomla! objects, including Media Manager, Banners, Contacts, Newsfeeds, Redirect, Search Statistics, Web Links, Extensions, Modules, Plugins, Templates, and Language. So you now have the option to create user groups with fine-tuned sets of back-end permissions.

Front End Permissions

Default permissions for the front end are also set using the Options form. Let's look at Content->Article Manager->Options->Permissions. First, let's look at the permissions for Manager, as shown below.

Screenshot acl tutorial 20110111-11a-en.png

Manager has allowed permission for all actions except Configure. So members of the Manager group can do everything with Articles except open the Options screen.

Now let's look at Administrator, as shown below.

Screenshot acl tutorial 20110111-12a-en.png

Administrator has Allowed for Configure, so Administrators can edit this Options screen.

Both groups can create, delete, edit, and change the state of articles.

Now, let's look at the groups Publisher, Editor, and Author and see how their permissions are set.

Authors only have Create and Edit Own permissions, as shown below.

Screenshot acl tutorial 20110112-07-en.png

This means that Authors can create articles and can edit articles they have created. They may not delete articles, change the published state of articles, or edit articles created by others.

Editors have the same permissions as Authors with the addition of permission for the Edit action, as shown below.

Screenshot acl tutorial 20110112-08-en.png

So Editors can edit articles written by anyone.

Publishers can do everything Editors can do plus they have permission for the Edit State action, as shown below.

Screenshot acl tutorial 20110112-09-en.png

So Publishers can change the published state of an article. The possible states include Published, Unpublished, Archived, and Trashed.

All of these groups have Inherit permission for Configure and Access Component. Remember that Author is a child of the Registered group, and Registered does not have any default permissions except for Login. Since Registered does not have permission for Configure and Access Component, and since Author's permission for these actions is "Inherited", then Author does not have these permissions either. This same permission is passed from Author to Editor and from Editor to Publisher. So, by default, none of these groups are allowed to work with articles in the back end.

It is important to remember that these permissions are only default settings for categories and articles and for any child groups that are created. So they can be overridden for child groups, for categories, and for specific articles.

Also, note that there are no Denied permissions for any actions in the default settings. This allows you to add Allowed permissions at any level. Remember, once you have an action set for Denied, this action will be denied at all lower levels in the hierarchy. For example, if you set the Admin Login for Registered to Denied (instead of Inherited), you could not grant Publishers Allowed permissions for this action.

Article Manager & Actions Diagram

The diagram below shows how each action in the permissions form relates to the various options on the Article Manager screen.

Screenshot acl tutorial 20110111-16-en.png
  • Configure allows you to view and change the Options for the component.
  • Access Component allows you to navigate to the Article Manager. Without this permission, no other actions are possible.
  • Create allows you to add new articles.
  • Delete allows you to delete trashed articles. Note that the Delete icon only shows in the toolbar when you have the "Select State" filter set to "Trash".
  • Edit allows you to edit existing articles.
  • Edit State allows to you Publish, Unpublish, Archive, or Trash articles.
  • Edit Own is the same as Edit except that it only applies to articles written by you.

Allowing Guest-Only Access to Menu Items and Modules

Version 1.6 introduced the ability to create a View Access Level that is only for guests of the site (meaning a user who is not logged in). The example below shows how you can set up this new feature. (N.B. Steps 1 to 3 are not needed for Joomla! 3.x as they exist in the default install

  1. Create a new user group called Guest. Make it a child of the Public group as shown below.
    Screenshot acl tutorial 20110112-01-en.png
  2. Create a new access level called Guest and grant only the Guest group access to this level, as shown below.
    Screenshot acl tutorial 20110112-02-en.png
  3. Navigate to User Manager→Options→Component and change the Guest User Group from the default value of "Public" to "Guest", as shown below.
Screenshot acl tutorial 20110112-04-en.png

Now, if we assign a menu item, module, or other object to the Guest access level, only non-logged in users will have access. For example, if we create a new menu item with access level of Guest, as shown below,

Screenshot acl tutorial 20110112-05-en.png

this menu item will only be visible to non-logged-in visitors to the site.

If required other user groups like Author can be granted access in the Guest access level, this would allow Authors to view articles in the front end for editing.

N.B. Login/logout in front end (for changing data in session) to see the change.

Using Permission and Group Levels Together

As discussed above, it is possible to define groups in a hierarchy, where each child group inherits action permissions (for example, the create permission) from its parent group. Action permissions are also be inherited from the permission level above. For example, a permission in the Article Manager is inherited from the same permission in the Global Configuration, and a permission in a child Category is inherited from the parent Category permission.

This dual inheritance can be confusing, but it can also be useful. Let's consider an example as follows. We have a school with a group hierarchy of Teachers → History Teachers → Assistant History Teachers. We also have a category hierarchy of Assignments → History Assignments. We want History Teachers and Assistant History Teachers to have the following permissions:

  • both groups can create new articles only in the History Assignments category.
  • only History Teachers (not Assistant History Teachers) can Publish or otherwise have Edit State permission.

This ACL scheme is very easy to implement. The diagram below shows how this would be set up for the Create Action.

Acl example diagram1 20091018-en.png

In the diagram, the Permission Hierarchy is shown down the left side and the Group hierarchy is shown across the top. Permissions are inherited down and to the right, as shown by the arrows. To implement the desired permissions, we leave the Global Configuration blank (Not Set) for all three groups. Similarly, in the Article Manager and Assignments Category, we leave the Create permission to Inherit for all the groups. As shown in the diagram, this means that these groups do not have Create permission for articles in general or for articles in the Assignments group.

To sum up so far, we have not set any special permissions to get to this point. Now, in the History Assignments category permissions screen, we set the Create permission to Allow for the History Teachers group. This setting overrides the Soft (Implicit) Deny that we had by default and gives members of this group permission to create content (articles and child categories) for this category. This Allow setting also is inherited by the Assistant History Teachers group.

Next, we need to grant History Teachers the Edit State permission while denying this permission to Assistant History Teachers. This is done as shown in the diagram below.

Acl example diagram2 20091018-en.png

This configuration is the same as the one above except that this time we set the Edit State permission in the History Assignments category to Deny for the Assistant History Teachers group. This means that Assistant History Teachers will not be able to Publish or Unpublish articles in this category.

Note that this was accomplished by setting just two permissions in the History Assignments category: Allow for the History Teachers group and Deny for the Assistant History Teachers group.

ACL Action Permission Examples

Here are some examples of how you might set up the ACL for some specific situations.

Back-end Article Administrator

Problem:

We want to create a group called "Article Administrator" with back-end permissions only for articles and not for any other back-end menu options. Members of this group should be able to use all of the features of the article manager, including setting article permissions.

Solution:

  1. Create a new group called Article Administrator and make its parent group Public, as shown below.
    Screenshot acl tutorial 20110112-10-en.png
    Because its parent group is Public, it won't have any permissions by default.
  2. In Users → Access Levels, edit the Special Access level to add the new group. That way they can get access to the back end menu items and modules (This assumes that the modules for the admin menu and quickicons have the Special Access level assigned to them, which is the default.)
    Screenshot acl tutorial 20110112-11-en.png
    By default, the back-end menu items and modules are set to Special access, so if you forget to add the new group to the Special access level, you won't see any modules or menu items when you log in as a user of the new group.
  3. In Site → Global Configuration → Permissions, click on the Article Administrator group and change the permissions to Allowed for the following actions: Admin Login, Create, Delete, Edit, Edit State, and Edit Own. The screen below shows what will show before you press Save.
    Screenshot acl tutorial 20110112-12-en.png
    After you save, the Calculated Permissions should show as shown below.
    Screenshot acl tutorial 20110112-13-en.png
    Note that the permission for the Access Component is Inherited, which translates to Not Allowed. This is important. This means that this group will only be able to access components if we give the group "Allowed" permission for Access Component. So we only have to change the one component we want to give them access to and don't have to change any settings for the components where we don't want them to have access. If we had a case where we wanted to give a group access to everything except for one component, we could set the default to Allowed and then set the one component to Denied. Also note that we did not give the group Site Login permission, so users in this group will not be able to log into the front end. (If we wanted to allow that, we would just change the permission to Allowed for Site Login.)
  4. In Article Manager → Options → Permissions, change permissions to Allowed for this group for the Access Component action, as shown below.
    Screenshot acl tutorial 20110112-14-en.png
    All of the other desired permissions are inherited.
That's all you need to do. Members of this group can login to the back end and do everything in Article Manager but can't do anything else in the back end. For example, the screen below shows what a user in the Article Manager will see when they login to the back end.
Screenshot acl tutorial 20110112-15-en.png

ACL View Access Levels Examples

A basic concept of using Access Levels is that all items with the same Access will be viewable by the same group of users. In other words, if two items have the same Access, you can't have one viewable by one user and not viewable by another user. On the other hand, it is easy to have one Group view any number of items with different Access levels.

Similarly, each Group has exactly the same combination of Access levels, but one User can be a member of more than one group. Depending on the situation, you may want to have users only in one Group or you may need to have a User in more than one Group.

This means that we may need to group our items so that items so that all items in a group have the same level of sensitivity. Here are some examples.

Hierarchical Example

In this example, Access levels are hierarchical, for example, like government security clearance codes. Say for example we have the following sets of classified documents: Classified, Secret, and Top Secret. Users have corresponding clearence codes. Users with Classified clearance can only see Classified documents and cannot see Secret or Top Secret. Users with Secret clearance can see Classified and Secret documents but not Top Secret. Users with Top Secret can see all documents.

In this case, you would create three Access levels: Classified, Secret, and Top Secret and the same three Groups. Users would only be members of one group, as follows:

User Group Access Levels
C1, C2, C3 Classified Classified
S1, S2, S3 Secret Classified, Secret
TS1, TS2, TS3 Top Secret Classified, Secret, Top Secret

In this case, all users are in exactly one group, but some groups have access to more than one Access Level of items. In other words, we have a one-to-one relationship between users and groups, but a one-to-many relationship between Groups and Access Levels.

Team Security Example

Another possible use case is a set of non-hierarchical teams. Let's say we have three teams, T1, T2, and T3. Some users are only on one team, but others might be on two or more teams. In this case, we could set up our Access Levels and Groups by team. Documents for each team have the access level for that team, and the Group for the team has only the one access level. When a User is on more than one team, they get added to the group for each team, as follows:

User Description Group Access Levels
U1 Team 1 member T1 T1
U2 Team 2 member T2 T2
U3 Team 3 member T3 T3
U1-2 Member of teams 1 and 2 T1, T2 T1, T2
U1-3 Member of teams 1 and 3 T1, T3 T1, T3
U1-2-3 Member of teams 1,2, and 3 T1,T2, T3 T1, T2, T3


Hybrid Example

In a real-world situation, you might have a combination of these two arrangements. Say for example we have Managers and Staff. Staff can only see Staff documents and Managers can see Manager and Staff documents. Both types of users can be assigned to teams as well, in which case they can see all of the documents for that team. In addition, say that Managers can access some, but not all, team documents. Staff can only access team documents if they are members of that team.

In this example, we could set up the following Access Levels:

Access Level Description Groups
Manager Non-team manager documents Manager
Staff Non-team staff documents Manager, Staff
Team1 Sensitive Team1 documents (no access outside team) Team1
Team1-Manager Team1 documents that can be accessed by all managers Team1, Manager
Team2 Sensitive Team2 documents (no access outside team) Team2
Team2-Manager Team2 documents that can be accessed by all managers Team2, Manager

Then, users could be assigned to groups as follows:

User Type Group
Manager on no teams Manager
Staff on no teams Staff
Manager on team 1 Manager, Team1
Staff on team 1 Staff, Team1
Manager on teams 1 and 2 Manager, Team1, Team2
Staff on teams 1 and 2 Staff, Team1, Team2

Access Control List Tutorial/fr

Joomla! 
3.x
série

Résumé des ACL pour la Version Joomla

Cette section décrit les changements majeurs d'ACL entre les versions 2.5 et la série 3.x (incluant les futures versions). Le tableau ci-dessous résume les changements depuis la version 2.5.

Version 2.5 Version 3.4
Groupes Nombre illimité de groupes d'utilisateurs définis La même chose que pour 2.5
Utilisateurs & Groupes Un utilisateur peut être assigné à plusieurs groupes La même chose que pour 2.5
Niveaux d'accès Niveaux d'accès illimités pour les utilisateurs définis La même chose que pour 2.5
Niveaux d'accès & groupes Les groupes sont assignés à des niveaux d'accès. Toute combinaison de groupes peut être assignée à n'importe quel niveau d'accès. La même chose que pour 2.5

Des ACL séparées pour Voir et pour Faire

Le système ACL de Joomla! peut être appréhendé comme étant divisé en deux systèmes distincts. Un système de contrôle de ce que les utilisateurs peuvent "voir". Un autre système permettant le contrôle de ce que les utilisateurs peuvent "faire" (les actions qu'un utilisateur peut entreprendre). Les ACL pour chacun des systèmes sont configurées différemment.

Contrôler ce que les utilisateurs peuvent voir

Les réglages permettant de contrôler ce que les utilisateurs peuvent voir se font de la manière suivante :

  • Créer un ensemble de Niveaux d'accès selon les Catégories et/ou la combinaison de catégories que vous souhaitez rendre visibles aux utilisateurs connectés. Note : à ce stade, n'assignez aucun groupe d'utilisateurs à ces nouveaux Niveaux d'accès.
  • Créer un Groupe d'utilisateurs avec la qualité de 'Registered' en tant que parent, pour chaque Niveau d'accès. Utiliser les mêmes noms pour les Groupes d'utilisateurs et les Niveaux d'accès permettra d'éviter plus tard toute confusion.
  • Editer vos nouveaux niveaux d'accès et assigner le bon (nouveau) groupe d'utilisateur à chacun. Vous pouvez également souhaiter assigner le Groupe de Super User (et/ou d'autres groupes d'utilisateurs par défaut mais pas le groupe d'utilisateur 'Guest') à tous vos nouveaux niveaux d'accès.
  • Attribuer à chaque élément un niveau d'Accès. Les éléments comprennent les éléments de contenu (articles, contacts et ainsi de suite), les éléments de menu et les modules.

Chaque fois qu'un utilisateur est sur le point de voir un élément sur une page Joomla, le programme vérifie si l'utilisateur a accès à cet élément, comme suit:

  1. Il crée une liste de tous les niveaux d'accès auxquels l'utilisateur a accès, basé sur tous les groupes auxquels appartient l'utilisateur. De plus, si un groupe possède un groupe parent, les niveaux d'accès du groupe parent sont également inclus à la liste.
  2. Il vérifie si le niveau d'accès à l'élément (article, module, élément de menu et ainsi de suite) est sur cette liste. Si oui, l'élément est affiché à l'utilisateur. Si non, l'élément n'est pas affiché.

Notez que les niveaux d'accès sont définis séparément pour chaque groupe et ne sont pas hérités d'un groupe parent du groupe.

Contrôler ce que les utilisateurs peuvent faire

Le système pour déterminer ce que les utilisateurs d'un groupe d'utilisateurs peuvent faire - les actions qu'ils peuvent faire sur un élément donné -- se paramètre dans l'onglet des droits de l'écran de configuration et dans l'onglet des droits dans chaque composant. Des droits peuvent également être paramétré au niveau de la catégorie pour les composants natifs et au niveau article pour les articles.

  • Si vous souhaitez pour des catégories spécifiques que les utilisateurs se connectent pour créer, supprimer, modifier un statut ou modifier le leur, alors :
    • Créez un groupe d'utilisateurs avec comme parent un de vos groupes d'utilisateurs disposant d'un accès à la catégorie (ou aux catégories) à laquelle vous souhaitez que ce nouveau groupe d'utilisateurs puisse apporter des modifications.
    • Affectez à votre nouveau groupe d'utilisateurs le(s) niveau(x) d'accès approprié(s). Puis modifiez les autorisations requises pour votre nouveau groupe d'utilisateurs soit globalement, soit par catégorie/article.
      • Lors de la création d'un groupe d'utilisateurs, il est conseillé de sélectionner un groupe parent ayant moins de droits que ceux nécessaires au nouveau groupe. Il est en effet plus facile d'augmenter les droits par composant/catégorie/article plutôt que d'avoir plus de droits que nécessaire et de devoir supprimer des droits dans les autres composants/catégories/articles.
        • (exemple: vous avez 10 catégories, mais vous voulez créer des droits pour une seule. Si vous définissez les droits globaux sur 'Créer - Autoriser' pour ce groupe vous devrez alors retirer le droit Créer pour toutes ces catégories. Et vous devrez supprimer le droit Créer pour ce groupe pour toute nouvelle catégorie que vous ajouterez ultérieurement.)
    • Créer un groupe d'utilisateurs avec un des groupes d'utilisateurs par défaut en tant que parent uniquement si aucun d'eux n'a exactement les droits dont vous avez besoin ou que vous souhaitez pour toutes les catégories.

Notez que cette configuration est indépendante de la configuration pour l'affichage et un groupe d'utilisateurs doit être assigné à des niveaux d'accès appropriés pour que les utilisateurs de ce groupe puissent utiliser ces autorisations.

Lorsqu'un utilisateur veut lancer une action spécifique pour l'élément d'un composant (par exemple, éditer un article), le système (après avoir vérifié que l'utilisateur appartient à un groupe y ayant accès) vérifie l'autorisation pour cette combinaison d'utilisateur, d'objet et d'action. Si elle est autorisée, l'utilisateur peut agir. Sinon, l'action n'est pas autorisée.

La suite de ce didacticiel explique comment il est possible de contrôler ce que les utilisateurs peuvent faire -- de quelles autorisations ils disposent.

Actions, groupes et héritage

Un autre intérêt des ACL est l'octroi, aux utilisateurs, des autorisations d'effectuer des actions sur les objets.

Séries 3.x
Groupes et actions Les actions autorisées pour chaque groupe sont définies par l'administrateur du site.
Portée des droits Les droits peuvent être définis à plusieurs niveaux de la hiérarchie : site, composent, catégorie, objet.
Héritage des droits Les autorisations peuvent être héritées de groupes parents et de catégories mères.

Comment fonctionnent les droits

Il existe quatre droits possibles pour les actions, comme indiqué ci-dessous :

  • Non défini : "refuser" par défaut, mais à la différence de la permission "Refuser", cette autorisation peut être substituée dans la hiérarchie des autorisations par les paramètres "Autoriser" des groupes enfants ou d'un niveaux inférieurs. Cette autorisation s'applique uniquement à la configuration globale des autorisations.
  • Hériter : hérite de la valeur d'un groupe parent ou d'un niveau supérieur dans la hiérarchie des autorisations. C