Installation / update
Joomla 3.1.4 error 500 on administrator page
If you see an error 500 in Joomla 3.1.4 on administration pages 'edit access menuitems' and 'edit access plugins', please install this hotfix to make them work again. This Joomla bug will be fixed in Joomla 3.1.5.
What are the system requirements?
- Joomla 2.5 or 3 fully and correct installed
- No restrictions in the number of posts (read more)
- PHP 5 or later
Error: 'Could not create directory, Warning! Failed to move file'
Check your directory premissions:
'help' > 'System info' > 'Directory Permissions'
All least these folders should be writeable:
You can also enable the FTP layer and try to install again.
Error: 'Path does not point to a valid folder' 'Could not find a Joomla! XML setup file' 'File...does not exist'
You are probably dealing with a corrupt download. Both Symantec and McAfee are known to corrupt downloads with certain settings. They can also corrupt the extensions send and received by email. So try this: go to the download area, disable the firewall/virusscanner, download the file, enable the firewall/virusscanner.
How to update?
- Download the component.
free- and trial-version
- Install the component over the old component (no need to uninstall first).
This will also install the Access-Manager system plugin.
Do I lose my settings and configuration when updating or upgrading?
No. All configuration and settings will remain in the database.
If you are updating from free- to trial-version, or trial- to pro-version, just install the new version over the old version.
Import rights from Frontend-User-Access
These instructions are for if you used Frontend-user-Access before and want to import the rights into Access-Manager.
- Update Frontend-User-Access to the latest version.
This is to make sure the database tables are up to date.
- Make sure you got the latest version of Access-Manager installed.
If Frontend-User-Access is installed on another website then Access-Manager, you will need to import these Frontend-User-Access tables:
and alter for each table the prefix ('jos_') to the prefix of the other tables of your Joomla installation.
- Make a backup of your database.
- Go to Access-Manager > 'tools' > 3rd tool.
- Select which restriction-types are to be imported.
Per restriction type, all rights will be overwritten on import. If the import goes wrong, restore the backup you made at 3.
- Select for each of the FUA groups to which usergroup/accesslevel the rights should be imported.
If you see Joomla usergroups, but want to assign to accesslevels, go to the Access-Manager config and change this at 'access based on'.
- Click on 'import access'.
Can I set restrictions for users instead of groups/accesslevels?
No. Rights can only be applied to Joomla groups/accesslevels and not to individual users.
Not all of the restriction/configuration-settings are saved?
You saved restriction-settings or the configuration-page, but not all settings are saved.
please read this FAQ:
Your server might be configured to limit the number of posts
Users get 'no access' when they should have access
First check if the user is really assigned to the correct groups/accesslevels on page 'users'.
Second. Check which restriction type is restricting access and double check the rights settings.
Check in the Access-Manager configuration which of the restriction-types are activated. Disable one and try again. If the user still has no access, disable another restriction-type. Keep going untill the user gets access. Keep enable/disable-ing restriction types until you know which restriction-type is preventing access.
Double check if the group/level has the correct rights.
Note that rights can be reversed per restriction-type. So that a selected content-group/level become a restriction instead of a access right.
There could be overlapping restrictions ('article access' and 'category access'). So read carefully in the configuration for the restriction type.
Note that users can be assigned to more then one group. You can configure per restriction-type how Access-Manager should deal with access in those cases. So read carefully in the configuration at 'multigroup access requirement'.
Do not just refresh the page with the no-access message to test page-access. That page won't change when the user has access to whichever page you were redirected from. So better test with visibility of menu-items in a menu.
Where do I start? I don't understand how to start configuring this.
There are so many different ways you can configure Access-Manager, it is just impossible to create a step by step manual for each of them. Start with only one restriction-type ('article access') as access rights can overlap and get really complicated. So build up rights one at a time and read the configuration options very carefully. It is easy to totally disable your site with a few clicks. However, this is a basic example to see how this works:
- Go to the frontend of the site and view the frontpage when not logged in. Take note of the title of one article.
- Go to 'configuration' and set 'based on' to 'usergroups', if that is not set already and click 'save'.
- Go to 'article access'.
- In the configuration-slider, enable the access-type and select 'reverse access' and click 'save'.
- Select the one article from the frontpage for usergroup 'public'.
As access is reserved, the group will NOT have access to the article.
- Go to the frontpage and refresh the page (F5). Note that the article is not displayed anymore.
Component access backend
You can use Joomla ACL to restrict access to components admin pages. These rights need to be set per component.
- login as a superadministrator
- go to the components admin page
- click in the toolbar on 'options' > tab 'permissions'
- set rights to 'Access Administration Interface' per group
- do that for each component you want to restrict access to
If you find this too much work AND for the component which do not have the Joomla ACL integrated yet, you can use Access-Managers edit-component-restrictions.
These rights do respect and not override Joomla. Backend component access only restricts access additionally to the Joomla ACL and component restrictions. If the group has no access rights from the component and Joomla, Access-Manager can not give access.
If the user has no access to the component from Access-Manager, the component will still show in the Joomla menu under 'components' as long as the user has Joomla ACL access.
To create a custom admin menu for your administrators, you can use Admin-Menu-Manager and show the Joomla admin menu only to group 'super users'.
Users get access when they should have 'no access'
First check if the user is really assigned to the correct groups/levels. See AM > 'users'.
Then go to the AM admin-page for the restriction type and double check that the groups/levels have the correct rights.
Note that in some restriction-type the access can be reversed. So that a selected group/level becomes a restriction instead of a access right.
'article access' and 'category access' do overlap if both of these restriction-types are enabled. So read carefully in the AM > articles/categories > configuration at 'article-access and category-access used together'.
Note that users can be assigned to more then one group/level. You can configure per restriction-type how AM should deal with access in those cases at 'multigroup access requirement'.
Show a menu-item the user has no access to
Access-Manager hides all menu-items in the menu the user has no access to. If you want to show such a menu-item anyway, create a menu-item of type 'alias' and make it go to the restricted menu-item. Set rights so the user can see the alias.
Downloads access rights
Access-Manager does not deal with restricting access to downloads. You can set access to the article with the download-link, but the direct download link to the actual file will not be restricted.
On how many websites can I use the pro-version?
There is no limit. Use it on as many sites as you like.
Is the pro-version encrypted?
Does the pro-version need Ioncube?
No. The pro version is un-encrypted and does not need Ioncube. Only the trial version is encrypted. The free and the pro-version are not encrypted and do not need Ioncube on the server.
Is there a trial-version available?
Yes. You can download the trial-version on the project page. You can use this extension unlimited on localhost. If used online it can be used for a few weeks.
free-version pro-version, what is the difference?
|frontend viewing access|
|module access (hide modules when user has no access)||x|
|article access (specific articles)(hide article when user has no access)||x||x|
|articles by category||x|
parts of articles and templates
|backend editting access|
I purchased this extension, how to download?
After payment is confirmed you login and click in the right column on 'my extensions'. Then click on your purchase and download the files.
Joomla 2.5 has some ACL. Why use Access-Manager?
1. so you can set rights on groups instead of levels.
2. so you can reverse rights (selection has NO access)
3. Because in Joomla you can still only assign access to only ONE accesslevel per article/module/menu-item/etc. not multiple. You can create custom accesslevels, sure, but its a nightmare for schools and universities where the users are students and the groups are the courses they take. If there are 20 courses and each student takes on avarage 5 courses you need to make access-levels for EACH COMBINATION of groups. 1-2, 1-3, 1-4 etc. 2-3, 2-4, 2-5 etc. 1-2-3, 1-2-4, 1-2-5 etc. You get the picture, that is 100+ accesslevels, that is totally unworkable. And you would still need double content, which is a nightmare for administrators and users.
In Access-Manager you can set access to as many groups (or levels) as you like. So in the above case you would need only 20 groups.
4. To do ACL stuff that is not in the Joomla core (yet).
5. Access-Manager can set custom actions if the user has no access.
6. Joomla usergroups ALWAYS inherit rights, which can be a pain in the rear, in Access-Manager groups don't inherit, so you are in control.
What is the difference between Access-manager and Frontend-User-Access?
Access-Manager overrides the Joomla accesslevels, FUA does not.
FUA only restricts the viewing of content. To view content, the user needs Joomla viewing access. FUA thus creates an extra viewing-access-level underneath the Joomla levels, whereas Access-Manager overrides the Joomla accesslevels.
Access-Manager uses native Joomla usergroups and accesslevels.
FUA uses its own FUA-usergroups.
Your server might be configured to limit the number of posts
You saved restriction-settings or the configuration-page, but not all settings are saved.
This happens when you have a PHP-plugin on the server which limits the number of post-variables being parsed. For example, there are 60 input fields on a page, but it only parses 50. So some fields get saved, others are not. A PHP-plugin known to cause this behaviour is 'suhosin'.
How to check if you have this plugin:
- login as a super administrator on the backend of your site
- go to 'help' >'system info' > 'PHP information'
- Search for 'suhosin'
Disable this plugin or change settings so it allows large numbers of post-variables.
Changed parameters in suhosin.ini to:suhosin.post.max_vars = 15000 (default 200)
suhosin.request.max_vars = 15000 (default 200)
What might also work is to set:
If you can not find any 'suhosin' on the php-information page, the problem might be the limit to the number of posts for PHP to handle. To override that add this line to your .htaccess file in your root:
If that gives you an error 500, copy the php.ini to the root and add
404SEF access to no-access menu-items
In 404sef check for double sef-urls to the same page, but with a different "Itemid"-value in the url. Delete those with the wrong or no "itemid".
Conflicts with other Joomla extensions
There are some Joomla extensions which conflict with the AM system plugin. If you get an error like:
'Fatal error: Cannot redeclare class JModuleHelper'
that is because the AM system plugin has loaded some class first, and another system plugin is trying to load it again. If you disable the FUA system plugin and the error goes away, that is likely to be the case.
To solve these conflicts you can contact us and we will see if there is a workaround or a fix.
- Try and find which plugin is conflicting
Go to the plugin manager, filter on 'system'-plugins. Then click on 'ordering'. Reorder so the AM system plugin goes 1 step down in order. Then check the frontend of the site if the error is still there. If not, order one down again. Keep going untill the error goes away. When the error is gone, the plugin loading above the AM system plugin would be the plugin with the conflict. (at this point the AM access rights might not work at all).
- Fix the plugin
Open /plugins/system/plugin_name.php and find the code which is loading the file (which contains the class). Comment those lines out. The plugin does not need to load those files, because AM has already laoded their classes.
AM conflicts with just about all extensions which deal with hiding modules.
Conflict with plugin emiIE6warning
This badly programmed plugin causes other system plugins to crash. Here is how to fix that.
White page in component Ohanah Events
When Access-Manager is disabled, the calender shows, when Access-Manager is enabled, the calender page just shows white.
- login at the backend
- go to the Ohanah component > configuration
- go to menu 'Module injector'
- select 'Resolve JModuleHelper conflicts (click when the module injector creates problems / white pages in the frontend)'
- save the configuration
T3 framework menu layout issue
When Access-Manager is enabled the horizontal top menu looses its style and becomes a unstyled unordered list.
To fix the style:
- go to the module manager
- find the menu module on position 'mainnav'
- set module property 'Menu Class Suffix' to ' nav' (space and 'nav')
- save the module settings
If that did not work, you might be using a template which renders the menu-items incorrectly (example 'New Lifestyle' version 2.0.2 from JoomlaBamboo). The module might show submenu-items which should not be shown at all. When Access-Manager takes over the access, it displays the correct menu-items, but the template assignes the wrong styles to the sub-menu-item wrappers (ul).
Here is how to reproduce this template bug
(with Access-Manager completely disabled!)
- In 'mainmenu' make sure the first menu-item is 'home' and has 'access' set to 'public'.
- set the second menu-item access for 'public'.
- create a submenu-item under the second, and assignit to 'public'.
- view at the frontend as a not-logged in user (public). When hover over the second menu-item the drop-down should show.
- set the second menu-item access to 'registered'.
- view at the frontend, refresh the page. The second menu-item should disappear. Now hover over 'home', the sub-menu-item still appears. Instead of under the second menu-item, it just moved under 'home'.
The workaround would be to configure the template to use t3's 'megamenu' instead of 'joomla module'. Because that renders the menu correctly, even when Access-Manager takes over the access-stuff.
'template manager' > template name > set 'navigation style' to 'megamenu'.
If that did not work, you might be using the Innate template, which adds module specific tags to the menu module output via the module helper (wrong!). To add those tags to the menu-module, you can make a template override. This is how:
- go to 'templates' > 'innate' > 'html'.
- create a folder 'mod_menu'
- go to 'modules' > 'mod_menu' > 'tmpl'
- copy 'default.php'
- paste this file to the folder you created
- open the file
- go to line 14
- replace with:
- at the bottom of the file, find
- replace with:
Virtuemart error 'Model class virtuemartModelCategory not found in file'
When FUA is enabled VM shows this error in the category view.
Incompatible with plugin 'System - Language Filter'
The plugin 'System - Language Filter' can not be used together with the overriding of menu-items in the Joomla menu-module in 'menu/page access'. Disable 'System - Language Filter' or disable at 'menu/page access' the override for menu-items.
Joomla version 3.4.0 has changed something so that the language filter plugin is calling the jmenu class before the access-manager plugin is loaded, even if the access-manager plugin is first in order. This is fundamentally different then previous Joomla versions, particulary because this is documented Joomla functionality to override a Joomla class via the system plugin. So technically the Joomla language filter plugin is incompatible with Joomla itself.
Here is a fix for the language filter plugin, but note that when updating Joomla, this fix might be overwritten. So you will have to make sure it stays there after every Joomla update.
I reported this bug on the Joomla ticket system and hope they fix it soon.