Frequently Asked Questions - mojoBlog

PERMISSIONS ERRORS and ADMIN ISSUES with MojoBlog

Or,"You do not have sufficient permissions to access!" warning.
Or, when you get into the mojo Dashboard but, have no main menu.
Or, when stuff that should work in mojo.. doesn't!

A factorial of sorts.

The following is a short, compiled list of "things to try and sort out" before posting a request in the forums. If, after trying these options things still aren't mojo, post your results and joomla settings so folks with similar issues might learn from our mistakes.

Issue #1: COOKIE MONSTER..

Without going into a long winded description on what "cookies" and "session ids" are let's just say that both of these techniques are used to associate a logged in visitor/member to your joomla/mojoblog website. Both Joomla and MojoBlog use `em and, both are unique *(in that they're NOT shared between each other) to their specific tasks.

Having "debugged" a fair share of both joomlify member sites as well as our own clients sites, I've found that often the root of the "permissions" problem lies not with mojoBlog but rather with incorrect joomla/webhost settings specifically, making sure canonical URLS match and are consistent throughout.

As both Joomla and WordPress are designed to maintain a high level of security while allowing multiple users to access and in some cases administrate site content and functions, there's continually been a strong effort from both camps to find and close latent "choke points" where script kiddies might gain access to sensitive data on, or in your website. Since the release of joomla 1.0.13 the core-devs have significantly hardened security and vulnerabilities prone to malicious injection attempts and cross site scripting. As such, there's less tolerance for inaccurate or conflicting configuration settings, especially when it comes to globals and cookies that contain those globals. Both Mojo and Joomla do this with a combination of user "cookies" and session IDs and save your current path, login and user info which, if you've got conflicting canonical URLs, can cause unnecessary cookie/session ID creation and generally foul up your login.

TO WWW. or not to WWW..

THE FIX part 1
Make sure you've configured both your joomla global configuration (JOOMLA ADMIN MENU | SITE->CONFIGURATION) and mojoBlog configuration (MOJOBLOG DASHBOARD MENU | OPTIONS->GENERAL OPTIONS) pointing to either http://www.yourjoomlawebsite.com -or- http://yourjoomlawebsite.com. If you've got both going on, well... There's a problem and you'll need to fix it as both joomla and mojo see these as two unique web-addresses and therefore create and register 2 sets of unique cookies, each!.

THE FIX part 2
If you're handy with your text-editor, you can modify your public-root .htaccess file and create a 301 redirect which will in effect repoint all requests to http://yourjoomlawebsite.com to http://www.yourjoomlawebsite.com. You can use the example .htaccess snippet below as a starting point, add it to the beginning of your current .htaccess file and remember to change the "yourjoomlawebsite.com" to your domain name. To find your .htaccess file you'll need either a FTP application or, if your host supports cPanel, use file-manager. If you've access to neither, there's a joomla component called joomlaXplorer which you can install through your joomla admin installers menu. Once you've got a window into your website directory, navigate to your root directory (/public_html/) and your .htaccess file should be the first file listed. If you don't see it, you may need to configure your file directory app or component and click/turn on "show hidden/invisible" files to actually view the otherwise normally hidden .htaccess file.

########## Begin - Rewrite rules to force non-canonical requests to www.
RewriteCond %{HTTP_HOST} ^yourjoomlawebsite.com$
RewriteRule ^/?$ http://www.yourjoomlawebsite.com [R=301,L]
########## End - Rewrite rules to force all non-canonical requests to www.

If you currently use OpenSEF, there's an option to point (OpenSEF actually creates the additional code for your .htaccess) all FURLS to either canonical or non-canonical (www or none).

Issue #3: SUPERADMIN - USERID 62..

If you are logged into the public side of your joomla site as a non-superadmin (as many of us often do) you will continue to occasionally bump uglies when trying to access your mojoBlog Dashboard. This is due to mojo currently looking for a userID of 62 (the default joomla superAdmin created during joomla install.)

This is being addressed and will become a non-issue in an upcoming release of mojo, until then I'd advise you always login to your mojo from the front-end as your superAdmin, add or edit the post you want and save the post under the alias/author you want (your public side username for example.)

Issue #4: CACHED FILES/CLEAR CACHE..

If you're like me, you've got your browser up all day, left the default settings (remember the last xxx days history) and, constantly bop back-n-forth between admin and public.

Step 1 From Admin (if you've got cache turned on in your global configuration settings) go to your top menu, select "system" and select "clean all caches".

Step 2 Log out, close all tabs/windows and exit your browser. P.S. you -may- want to change your browser prefs to reflect a more modest "history".

Step 3 FTP over to your joomla site, go to /components/com_mojo/wp-content/cache and you see a group of files and folders. Those comprised of a string of long, random numbers and letters can be deleted.

The folders "userlogins" and "users" if they exist should not be deleted. Instead, open these directories and delete the files within (again, files with hash5 namespaces are deletable.) I know, it's a PITA but, if you follow the superAdmin and your global configs match, you shouldn't have to do this more than once.

Issue #5: 3RD PARTY LOGIN MODULES..

Both Community Builder and Fireboard allow folks to login through their login space -vs- joomla login module. Both create their own sets of cookies so, while both should play friendly with the standard joomla ACL (and mojoBlog) if you're using either I'd recommend you check the configurations of both and make sure they point to the proper global canonical URI as I outlined under cookies.

That should cover the majority of issues with permissions and logins *(i hope) but, if others arise, I'll list `em here.