FAQs Frontend-User-Access

Installation / update

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:

• administrator/components/
• administrator/language/en-GB/
• components/
• plugins/
• plugins/content/
• plugins/system/
• plugins/user/
• tmp/

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?

1. Download the component.
   free- and trial-version
   pro-version
2. Install the component over the old component (no need to uninstall first).
   This will also install the Frontend-User-Access plugins.

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.

How to migrate from Joomla 1.5 to 1.6/1.7?

Migration instructions to migrate Frontend-User-Access from Joomla 1.5 to 1.6/1.7.

End faq

Configuration

I'm hiding a module but the module-title still shows (Joomla 1.5, FUA < 3.4.4 only)

You are probably using a 3rd party template which uses a module-override which is not parsing the module css-class-suffix properly. Templates by YOOtheme and some Artiseer templates seem to have this issue.

In case you are wondering if this is a template issue, set your site-template to Joomla's default 'rhuk_milkyway' and check if modules are hidden.

What some templates do wrong is that they often totally ignore the css-class-suffix as set in the module configuration (try it!). To make Frontend-User-Access hide modules, this must be fixed in your template.

read more

show/hide menu-items and menus

FUA can hide individual menu-items, using the menu/page access restrictions together with the FUA menu-module. The menu-module is an altered clone of Joomla's mod_mainmenu.

As of FUA version 3.5.0 for Joomla 1.5, the menu-items are also hidden in Joomla's mod_mainmenu, so you don't need the FUA menu module anymore. The old FUA menu module will continue to work. Please note that currently for Joomla 1.6 you still need the FUA menu-module.

If you want to use another menu-module AND hide menu-items as set in FUA, read more.

To hide the whole menu, use module access restrictions.

How do I get to the configuration-page?

Can I set restrictions for users instead of groups?

Not all of the restriction/configuration-settings are saved?

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 = 300   (default 200)
suhosin.request.max_vars = 300 (default 200)

What might also work is to set:

SecFilterEngine Off
SecFilterScanPOST Off

in .htaccess

Where to edit the 'no access' messages?

In the FUA configuration you can edit the messages for the different access restrictions.

Will users not connected to a usergroup have access?

Yes and no, depending on your configuration. In the default install is a usergroup called 'logged in'. Which are all logged in users not assigned to any usergroup. You can set any access-restrictions to that group, just like any other group.

Yootheme-templates break HTML when hiding articles (Joomla 1.5, FUA < 3.4.4 only)

In Yootheme-templates, when hiding an article on a blog-page, the HTML could break and the page will show wrong. This is because FUA uses the Joomla plugin-event 'afterDisplayContent', which is suppose to be loaded after the content is displayed. Yootheme does not load the event after the content is displayed, so the html breaks.

Here is how to fix that:
files:
templates/yootheme_template_name/html/com_content/section/blog_item.php
AND
templates/yootheme_template_name/html/com_content/frontpage/blog_item.php
AND
templates/yootheme_template_name/html/com_content/category/blog_item.php
line: about 142-149 (at the end of the code)

<?php echo $this->item->event->afterDisplayContent; ?>
</div>
</div>

change to

</div>
</div>
<?php echo $this->item->event->afterDisplayContent; ?>

So the 'afterDisplayContent' is actually loaded after the content is displayed.

For the Corona template in Joomla 1.5

files:
templates/yoo_corona/layouts/com_content/sectionsection/blog_item.php
AND
templates/yoo_corona/layouts/com_content/section/frontpage/blog_item.php
AND
templates/yoo_corona/layouts/com_content/section/category/blog_item.php

about line 17

<div class="item">

change to:

frontend_user_access_article_hide_start
<div class="item">

AND

at the bottom of the page

<?php echo $this->item->event->afterDisplayContent; ?>

</div>

change to:

</div>
<?php echo $this->item->event->afterDisplayContent; ?>

'frontend_user_access_article_hide'-tags in content (Joomla 1.5, FUA < 3.4.4 only)

You are advised to update (its free).

These tags where used in the older versions of FUA, in the content plugin. This plugin is deprecated and no more needed. With the install of a current version of the FUA component, the content plugin is uninstalled automatically. However, there have been a few reports where the uninstall failed. In that case, uninstall the deprecated content-plugin. Go to the extensions-manager > 'plugins'. Then filter on 'content' plugins. Uninstall the FUA content plugin.

Users get 'no access' when they should have access

First check if the user is really assigned to the correct group.

Second, in the FUA configuration, disable FUA completely. Then check if the user has access. If the user still has no access, it is not FUA restricting access. The user probably has no sufficient Joomla-group rights to see the content. For example, in Joomla 1.5, a user of Joomla group 'registrered' can not view content assigned to 'special'. In Joomla 1.6 the user has got to be assigned to the correct accesslevel to view the content.

Third. Check which restriction type is restricting access and double check the rights settings.
Check in the FUA 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.

Then go to the FUA admin-page for the restriction type and double check that the group has the correct rights.

Note that restrictions can be reversed per restriction-type. So that a selected content-usergroup becomes a restriction instead of a access right.

There could be overlapping restrictions ('article access' and 'category access'). So read carefully in the FUA configuration > tab 'article access' at the bottom of the page, about using content-rights together.

Note that users can be assigned to more then one group. You can configure per restriction-type how FUA should deal with access in those cases. So read carefully in the FUA configuration, on each tab at 'multigroup access requirement'.

Where do I start? I don't understand how to start configuring this.

1. create a usergroup
2. assign a user to the group
3. go to the FUA config and enable 'article access' restrictions and select 'reverse access'
4. get out of the config to the 'article access'-page
5. select one article for that group
   As access is reserved, the group will NOT have access to the article
6. logout
7. login as the user
8. go to the page which displays the article
   note that the user has no access to the page with the article in 'article'-view, and the article will be hidden on all other pages (category-blog etc.)

How to filter articles in RSS feeds? (Joomla 1.5, FUA < 3.4.4 only)

This is included as of version 3.5.0. So you are advised to update (its free).

Unfortunately, the RSS feeds in Joomla do not have their own template, so there is no template override possible to filter the feeds.

This is no problem as long as you are using Search Engine Friendly url's. If you don't, users can manipulate the url to read the restricted content via the RSS feed.

The only way to filter articles in RSS feeds is to hack the Joomla core, which we advice you not to do. We advice you to use the workaround, which is to use different feeds per FUA group (so no articles need to be filtered) and to use 'menu access' to prevent access to the page.

If you absolutely want to hack the Joomla core to be able to filter the articles, here is how:

For category-blog feeds

file:
components/com_content/views/category/view.feed.php

line 45:

foreach ( $rows as $row )

replace with

    //start filter articles as set in component Frontend-User-Access
        if(file_exists(JPATH_ROOT.DS.'components'.DS.'com_frontenduseraccess'.DS.'menuaccess.php')){
            require_once(JPATH_ROOT.DS.'components'.DS.'com_frontenduseraccess'.DS.'menuaccess.php');
            $frontenduseraccessAccessChecker = new frontenduseraccessMenuAccessChecker();
            $rows = $frontenduseraccessAccessChecker->filter_articles($rows);            
        }
        //end filter articles

        foreach ( $rows as $row )

For section-blog feeds

file:
components/com_content/views/sections/view.feed.php
line 42

$rows         = &$this->get( 'Data' );

replace with:

$rows         = &$this->get( 'Data' );
        
        //start filter articles as set in component Frontend-User-Access
        if(file_exists(JPATH_ROOT.DS.'components'.DS.'com_frontenduseraccess'.DS.'menuaccess.php')){
            require_once(JPATH_ROOT.DS.'components'.DS.'com_frontenduseraccess'.DS.'menuaccess.php');
            $frontenduseraccessAccessChecker = new frontenduseraccessMenuAccessChecker();
            $rows = $frontenduseraccessAccessChecker->filter_articles($rows);            
        }
        //end filter articles

For frontpage feeds

file:
components/com_content/views/frontpage/view.feed.php
line 44

$rows         = & $this->get( 'Data' );

replace with:

$rows         = & $this->get( 'Data' );
        
        //start filter articles as set in component Frontend-User-Access
        if(file_exists(JPATH_ROOT.DS.'components'.DS.'com_frontenduseraccess'.DS.'menuaccess.php')){
            require_once(JPATH_ROOT.DS.'components'.DS.'com_frontenduseraccess'.DS.'menuaccess.php');
            $frontenduseraccessAccessChecker = new frontenduseraccessMenuAccessChecker();
            $rows = $frontenduseraccessAccessChecker->filter_articles($rows);            
        }
        //end filter articles

Please note that when hacking the Joomla core, the alteration might be overwritten when you update your version of Joomla.

Restrictions do not work with Artiseer template, but do work with any of the default Joomla templates.

Please make sure the template you create with artiseer has a name in lowercase. So not 'MovieTags' but 'movietags'.

Module do not hide, menu-items do not hide, articles in modules do not hide (Joomla 1.5 only)

You might be using another extension which deals with hiding of modules.

• module2url
• older versions of BreezingForms
• Modules2Pages
• VM VirtueMart (see this post)

Each of these system plugins conflict with the FUA system plugin.

Advanced-Module-Manager and Metamod can work together with FUA as long as the FUA system plugin is loaded first in order.

To solve this issue:

1. Make sure the FUA system plugin is loaded first.
   So go to the plugin manager, select type 'system' and make sure the FUA system plugin is first in order (not just on top of the list, sometimes plugins can have the same order number, so really make sure the plugin has order number '-30001').
   After the FUA system plugin is loaded first, all functionality of the other extension to hide modules might not work.
2. If there is an error on the frontend like
   'Fatal error: Cannot redeclare class JModuleHelper'
   the other plugin probably uses code like this to include the module-helper:
   

   require_once(dirname(__FILE__).'/../../libraries/joomla/application/module/helper.php');

   
   which should be replaced with:
   

   jimport('joomla.application.module.helper');

End faq

Pre/post sale

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?

free-version pro-version, what is the difference?

I purchased this extension, how to download?

Joomla 1.6/1.7 has some ACL. Why use Frontend-User-Access?

Because in 1.6/1.7 you can only set access for ONE accesslevel per article/module/menu-item/etc. In FUA you can assign those to as many groups as you like.

The classic workaround would be to create double content, which is a nightmare for administrators and for users assigned to more then 1 accesslevel (as they will see double content).

What is the difference between Frontend-User-Access and Admin-User-Access?

FUA restricts the VIEWING of content at the frontend of the site.
AUA restricts the EDITTING of the content from the backend of the site (and when editting articles from the frontend).

Download access rights?

FUA 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.

End faq

Known issues

What are the system requirements?

• Joomla 1.5/1.6/1.7 fully and correct installed
• No restrictions in the number of posts (read more)
• PHP 5 or later
• Cache needs to be disabled in Joomla global configration

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 = 300   (default 200)
suhosin.request.max_vars = 300 (default 200)

What might also work is to set:

SecFilterEngine Off
SecFilterScanPOST Off

in .htaccess

3rd party templates (Joomla 1.5, FUA < 3.4.4 only)

Some 3rd party templates use a module-override with ignores the css-class-suffix as set in the module configuration. Read more.

Wordpress component access restrictions do not work ?

Component com_wpadmin by CorePHP is a component for frontend editting of wordpress intergrated in Joomla. For some reason this component does not load the system event 'onAfterRender' which is required for Frontend-User-Access to restrict access.

Here is how to fix this issue.

file:
/components/com_wpadmin/wpadmin.php

line 19:
Code:
if(!defined('WP_JPATH_ROOT'))
define('WP_JPATH_ROOT', JPATH_ROOT . '/components/com_wordpress');


replace with:
Code:
if(!defined('WP_JPATH_ROOT'))
define('WP_JPATH_ROOT', JPATH_ROOT . '/components/com_wordpress');

//load system event onAfterRender
JPluginHelper::importPlugin( 'system' );
$dispatcher    =& JDispatcher::getInstance();
$results = $dispatcher->trigger('onAfterRender', array ());

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".

Conflict with Ja Flash News Module from Joomlart (Joomla 1.5, FUA < 3.4.4 only)

You are advised to update (its free).

The Joomlart module seems to call the system plugins within the content (wrong), thus creating a loop like structure which Frontend-User-Access can not work with.

Can not hide Iyosis Facebook Module (Joomla 1.5, FUA < 3.4.4 only)

You are advised to update (its free).

Like true facebook spyware, this module does not let itself be hidden ;-)# The iframe-injection seems to be difficult for the module restrictions to rip out.

The workaround is to use FUA parts restrictions.

1. go to FUA > 'parts' and create a new part which you call 'facebook'.
2. look at the id of the part you just created and remember that number.
3. create in you template folder:
   templates/template_name/html/mod_iyosis_facebook/default.php
   This is a template override for this module.
4. in default.php add this code:
   

   <?php
   /**
    * @package Iyosis Facebook Module for Joomla! 1.5
    * @author Remzi Degirmencioglu
    * @copyright (C) 2011 www.iyosis.com
    * @license GNU/GPLv3 http://www.gnu.org/licenses/gpl-3.0.html
   **/
   
   // no direct access
   defined( '_JEXEC' ) or die( 'Restricted access' ); ?>
   
   {fua_part id=2}
   <?php echo $html; ?>
   {/fua_part}

5. where you change 'id=2' to the id of the 'facebook' part you just created.
6. set rights to the part in FUA on page 'part access'.

Conflicts with other Joomla extensions

There are some Joomla extensions which conflict with the FUA system plugin. If you get an error like:
'Fatal error: Cannot redeclare class JModuleHelper'
that is because the FUA 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 FUA 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 FUA system plugin would be the plugin with the conflict. (at this point the FUA restrictions 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 FUA has already laoded their classes.

FUA conflicts with just about all extensions which deal with hiding modules.

See also this FAQ:
http://www.pages-and-items.com/extensions/frontend-user-access/faqs?faqitem=config13

Conflict with plugin emiIE6warning

This badly programmed plugin causes other system plugins to crash. Here is how to fix that.

AEC micro-integrator for Frontend-User-Access might not work properly

If you experience any problems in AEC with the FUA MI, please read these posts:
http://www.pages-and-items.com/forum/37-frontend-user-access/6165-aec-microintegration-support-for-multiple-user-groups#6176

End faq