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:

  1. login as a super administrator on the backend of your site
  2. go to 'help' >'system info' > 'PHP information'
  3. Search for 'suhosin'

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

SecFilterEngine Off 
SecFilterScanPOST Off

in .htaccess

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:

php_value max_input_vars 15000


If that gives you an error 500, copy the php.ini to the root and add 

suhosin.simulation = Off

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.

Or

  1. 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).
  2. 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.

  1. login at the backend
  2. go to the Ohanah component > configuration
  3. go to menu 'Module injector'
  4. select 'Resolve JModuleHelper conflicts (click when the module injector creates problems / white pages in the frontend)'
  5. save the configuration

T3 framework module layout issue

Some T3 framework templates insert styles outside the Joomla module-style framework. Access-Manager renders the modules using the normal Joomla module-styles, so the extra inserted class-names of the module wrappers are lost. You can copy paste the classnames the template uses into the module classname field. Here is how:

  1. disable Access-Manager
  2. check in the html output the classname of the div which is wrapping the module
  3. enter the classname in the module field 'Menu Class Suffix', adding a space before the name (' classname')
  4. enable Access-Manager

For most of the menu-modules, the classname is ' nav'. 

I'm sorry I can't add each of the classnames for each of the modules for each of the templates which insert the styles outside the Joomla framework.

Menu-style issues

When Access-Manager is enabled the horizontal top menu looses its style and becomes a unstyled unordered list.

To fix the style:

  1. go to the module manager
  2. find the menu module on position 'mainnav'
  3. set module property 'Menu Class Suffix' to ' nav' (space and 'nav')
  4. 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!)

  1. In 'mainmenu' make sure the first menu-item is 'home' and has 'access' set to 'public'.
  2. set the second menu-item access for 'public'.
  3. create a submenu-item under the second, and assignit to 'public'.
  4. view at the frontend as a not-logged in user (public). When hover over the second menu-item the drop-down should show.
  5. set the second menu-item access to 'registered'.
  6. 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:

  1. go to 'templates' > 'innate' > 'html'.
  2. create a folder 'mod_menu'
  3. go to 'modules' > 'mod_menu' > 'tmpl'
  4. copy 'default.php'
  5. paste this file to the folder you created
  6. open the file
  7. go to line 14
    <?php // The menu class is deprecated. Use nav instead. ?>
  8. replace with:
    
    <?php // The menu class is deprecated. Use nav instead. ?>
    <div class="t3-module module " id="Mod<?php echo $module->id; ?>">
     <div class="module-inner">
     <div class="module-ct">
    
  9. at the bottom of the file, find
    </ul>
  10. replace with:
    
    </ul>
     </div>
     </div>
    </div>
    

 

Virtuemart error 'Model class virtuemartModelCategory not found in file'

When FUA is enabled VM shows this error in the category view.

Solution on VM forum.

 

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.
file: plugins/system/languagefilter/languagefilter.php
line: 58

 $router = $this->app->getRouter(); $this->mode_sef = ($router->getMode() == JROUTER_MODE_SEF); 

change to

 $this->mode_sef = 1;//or 0 when not using SEF urls 

I reported this bug on the Joomla ticket system and they fixed it march 2015. Then in Joomla 3.5.1 this issue was back again. Unfortunately there is no quick fix this time. So sorry I can't help making this work.

 

Incompatability with Akeeba Admin-Tools workaround

There is a small incompatability issue with Akeeba AdminTools, with certain settings you might get a white adminscreen in the backend in Access-Manager > menu/page access.

To fix this issue alter this file:
plugins/system/admintools/admintools/main.php line 630

$menu = JFactory::getApplication()->getMenu()->getItem($Itemid); 

replace with
return array($option, $view); 

Just make sure you keep a note of this alteration, so when you update Akeeba Admin Tools, you can do this fix again.

 

End faq

 
spicy-sacerdotal