So, how can the same be acheived in Joomla? Well, quite easily actually. Read on to find out how…

Modify the Template

For this to work we will need to make a simple logic change in the site’s template index.php file, which you can find in template/your_template directory of your site. First we’ll need to get the $user variable loaded into the template, so, near the top, add the following line of PHP:

$user =& JFactory::getUser();

This will load an array of variables into $user that we can use to determine who’s currently logged-on to the front-end of your website. The particular value we’re looking for is the User ID, contained in $user->gid (the current user’s Group ID) – this value is zero (false) if a guest is browsing the site, but will be a specific figure depending on which group they are assigned to when logged-on.

Add the logic code

Next step is to locate your GA tracking code, which should be right at the bottom of your index.php file, just before the tag. We need to wrap this in some PHP test code to selectively load the tracking script based on the outcome of our condition, so first locate your tracking code which will look like this:

Then add the PHP test to selectively load the scripts, which looks like this:

<?php if (!$user->gid == 25) : ?>




<?php endif; ?>

This example above will disable the GA tracking code only for Super Administrators logged-on to the front end. You can add your own test conditions depending on your requirements, by using the list below as a reference for the group to test:

• 18 – Registered
• 19 – Author
• 20 – Editor
• 21 – Publisher
• 23 – Manager
• 24 – Administrator
• 25 – Super Administrator

Disable tracking for anyone who isn’t a guest user (not logged-on):

if (!$user) :

Disable tracking for all back-end users:

if (!$user == 23 || !$user == 24 || !$user == 25) :

Disable tracking for all registered users:

if (!$user == 18) :

I’m sure you get the gist!

Got a better idea or know of a plugin that can do this for you? Please share it in the comments, we’d love to hear your ideas!

But what if you need to style entire sections of a site based on a handful of top-level (parent) menu items?

This article explores the methodology of styling sub-level pages respective of their common parent menu links.

Method 1: Modifying the mod_breadcrumb Module Code

The mod_breadcrumb module is native to Joomla, and by it’s core function maintains a trail of menu link hierarchy leading to the current page. This code can be utilized in order to obtain the top-level menu’s textual name (rather than an itemID number). This method expands the code further to reformat this text into a usable, readable format which can be used to style a page in an understandable way. It’s more code-heavy than method 2, but provides an easier-to-understand output that works in exactly the same way.

Let’s first examine the original code:

defined('_JEXEC') or die('Restricted access');

class modBreadCrumbsHelper
{
	function getList(&$params)
	{
		global $mainframe;

		// Get the PathWay object from the application
		$pathway =& $mainframe->getPathway();
		$items   = $pathway->getPathWay();

		$count = count($items);
		for ($i = 0; $i < $count; $i ++)
		{
			$items[$i]->name = stripslashes(htmlspecialchars($items[$i]->name));
			$items[$i]->link = JRoute::_($items[$i]->link);
		}

		if ($params->get('showHome', 1))
		{
			$item = new stdClass();
			$item->name = $params->get('homeText', JText::_('Home'));
			$item->link = JURI::base();
			array_unshift($items, $item);
		}

		return $items;
	}
	
	function setSeparator($custom = null)
	{
		global $mainframe;

		$lang =& JFactory::getLanguage();

		if ($custom == null) {
			if($lang->isRTL()){
				$_separator = JHTML::_('image.site', 'arrow_rtl.png');
			}
			else{
				$_separator = JHTML::_('image.site', 'arrow.png');
			}
		} else {
			$_separator = $custom;
		}
		return $_separator;
	}
}

We can immediately remove the second part of the code that sets the separator, since we don’t need that. Also, since we only need to return the parent item’s text, we don’t need the loop in place. We shall also use the Application Object since
$global mainframe will be removed in Joomla 1.6, so:

$global mainframe; 

Becomes:

$app = &JFactory::getApplication();

Which gives us the completed code below:

class getParentMenuTitle {
	function getList() {
		$getParent = &JFactory::getApplication();
		// Get the PathWay object
		$pathway =& $getParent->getPathway();
		$items = $pathway->getPathWay();
	return $items;
	}
}
$list = getParentMenuTitle::getList();
$count = count($list);
if ($count !== 0) :
	$parentmenu = $list[0]->name;
	$parentmenu = ereg_replace(" ", "-", $parentmenu); // replace spaces with a dash
	$parentmenu = ereg_replace("[^+A-Za-z0-9-]", "", $parentmenu); // strip special characters
	$parentmenu = strtolower($parentmenu); //set name to lowercase
else :
	$parentmenu = "home"; // Set parentmenu to "home" if there are no items
endif;

How To Use The Code

This block of code can be inserted directly into your active template’s index.php file before the HTML is started. Remember to enclose the code block in PHP tags. Alternatively you can include it from an external file.

Once working in the template, you can apply the variable $parentmenu to a top-level container to initiate a CSS hook. Where you add this will depend on what you need to influence in the design, but the further up the hierarchy the more things you will be able to affect in the design – for example:

<body id="<?php echo $parentmenu; ?>">

…will allow you to influence the design across the whole template, such as:

body#menu-link-name a {color:red;}

…which will change all links on the page to red for that particular top-level menu link.

Method 2: Using the Jsite Object

This method is by far the simplist of the two methods, and unless you need a more human-readable format for the menu class/ids then it’s by far the recommended method of the two. It uses the Jsite object to obtain the parent menu’s ItemID and stores it in a variable which can then be applied to any class/id in the template:

$parentmenu = JSite::getMenu()->getActive()->tree[0];

You can obtain the ItemID of any menu links in the pathway by altering the value of tree[0].

How To Use The Code

Again, this code needs to be inserted into the template. The ItemID is stored in the $parentmenu variable, just as it was before, so you can use a similar method to above – but prefix the class/id with something or else you may have problems, for example:

<body id="menuID-<?php echo $parentmenu; ?>">

Why Would You Need To Use Method 1?

The first method could be useful in instances where you (as the developer) might want to pass more control onto someone who is less technically-minded – the class/id names which are generated using this method are very easy to predict, whereas method 2 requires the administrator to lookup the itemID for each menu item that requires styling.

Something to Share?

Have an alternative technique, or have you used this (or something similar) on a site before? Please do share it in the comments.

We recently worked on a development which already had a complex hierarchy of menu links set-up on the system (approx. 200 links), but realised later in the development that the “SSL Enabled” flag in the menu settings needed to be set to the “Off” setting in order to force the majority of the site to run in non-SSL mode:

The obvious solution is to go through each menu item one at a time at set this manually – but there’s a risk that some may be missed, and of course, the time it would take to do this to 200+ links would be considerable.

So, instead, we set about using simple find & replace commands, we can run a query directly on the database to do this for us in one step. The query we will be using has this structure:

NOTE: Please ensure you make a full backup of your database before proceeding – if there’s a problem, you will easily be able to restore the database and try again.

update TABLE_NAME set FIELD_NAME = replace(FIELD_NAME, ’string to find’, ‘new string’)

Use a program such as PHPMyAdmin to easily make edits to your database. Most hosting providers give easy access to this via your hosting control panel – this will allow you to find the table/field names and run the query easily.

So, in our case, it’s fairly obvious we’ll find the setting we need to adjust in the jos_menu table, so, browse the table, then click the edit icon to open up the contents of one of the rows:

You’ll see I’ve indicated the bit we need to change on the image above – it’s in the field named params. So, we now know the name of the table, and the field that we need to modify. The text to search for (in this case) will be “secure=0″ (so, any menu SSL settings that are set to “ignore”), and the setting we need to change to (like on the diagram) is “secure=-1″ (”Off). If you’re in any doubt as to the setting that’s needed, just change it in Joomla and view the string in PHPMyAdmin.

This now allows us to construct the final query that we will run on the database:

update jos_menu set params = replace(params, 'secure=0', 'secure=-1')

Simple, isn’t it?

To run the query, simply click the “SQL” tab in PHPMyAdmin, paste your query into the box, and click go. Once it’s run successfully, log into the Joomla administrator and check that everything was changed as expected.

So what happens when you want to launch the site and you’re stuck with dozens of undesirable test orders? Well, read on to find out how…

The first thing you need to bear in mind is that, whilst this is possible using a load of MySQL queries, that kind of thing on a working site is pretty scary and risky if you’re not sure what you’re doing. For this reason, I would recommend purchasing the Yireo extension Delete Any Order which will do the job for you. It will also scan the database for orphaned sales data and remove, something which would take significant time by hand.

The extension costs a mere EUR20 and is worth it just for the piece of mind. Whatever you choose, please ensure you backup your database first.

Deleting the Orders

Once you’ve purchased the extension, upload it to the root of your Magento site.

This will give you an additional option in System->Tools called “Delete Any Order”. Select it to run the extension.

If you are preparing a store for launch and want to remove all orders and reset the sales reference numbers, select all orders and choose the “Delete” option from the drop-down menu (top-right).

Reset the Counters

You don’t really want your new store starting orders, invoices, shipment and credit memos from some random number do you? Do the following to reset these counters to the default (1000001).

1. Use PHPMyAdmin to view your database.
2. Click the “SQL” tab.
3. Paste the following query into the code entry window:

TRUNCATE `eav_entity_store`;
ALTER TABLE `eav_entity_store` AUTO_INCREMENT=1;
SET FOREIGN_KEY_CHECKS=1;

4. If all goes well, the system will display a message stating that the query was a success.

The next order placed will now use the default number to start.

I recommend testing these steps out on a test site rather than your live environment, if that’s possible – just so that you are comfortable with the steps before deploying on a live site.

1. Package up and/or download the site files

I used my Control Panel’s “site backup” feature here for two reasons: a) you have less to download, and b) you can be sure you have all the files intact when you deploy the other end.  If you don’t have this feature with your host, you can manually download the files – but be sure to check you have everything and that there were no errors during the downloading process!

Also, if you have shell access to the server, you can zip up the whole lot and download in one go – this will make it easier to deploy on the receiving end, and will ensure none of the files are corrupted and/or go astray during the upload.

Once I had my package downloaded, I deployed to the new server – again, if you can, upload the zip package and extract via the server.  If you are unable to do this, extract the package locally and upload the files manually (cue: cup of tea).

2. Take a backup of the original site’s database

Using PHPMyAdmin, take a full backup of the site database that Magento was using.  This should be in the form of a .sql file.  Make sure you take a full backup of all the database tables. If the database is particularly large, use compression on the export (built-in to PHPMyAdmin) which will help keep within the file upload limits.

3. Import the SQL file into the new database

Working in PHPMyAdmin on the target server, simply import the SQL file into an empty database (you may need to create one first).

4. Update the live site URL data in the database

This needs to be done in two places in the database.  Using PHPMyAdmin, select the table named core_config_data and locate the following database rows:

web/unsecure/base_url
web/secure/base_url

Note the text value for each entry – this corresponds to the root URL of the site.  This should be confirmed as the data should reflect the current site’s root URL.  To change, simply click the edit button for each of the two rows and input your new base URL value into the text box, saving when you’ve finished each one.

5. Update local.xml with the new configuration details

You can find your local.xml file in the app/etc directory.

Look through the file until you see the database connection information.  If will look similar to the following:

<default_setup>
  <connection>
     <host><![CDATA[localhost]]></host>
     <username><![CDATA[my_user]]></username>
     <password><![CDATA[my_pass]]></password>
     <dbname><![CDATA[my_database]]></dbname>
     <active>1</active>
  </connection>
</default_setup>

Then change the values in the square brackets after the CDATA tags to your new database server settings, for example:

<username><![CDATA[mynewusername]]></username> 

Once done, save the file.

6. Delete the cache data

Simply locate your var folder and delete all content within.

You may also need to manually deploy the .htaccess file from the old site to the new site – so if your links do not work on the new server, make sure .htaccess is present and correct.

Problem 1: MagentoConnect No Longer Works

If you are planning to update Magento Core, any modules, or add new extensions to your Magento site, you will need to correct this since the Connect Manager (/downloader on the server) references the old site, and the links are hard-coded into the files, making it practically impossible to update manually. There is also a real risk of accidentally updating files on the old server if running MagentoConnect (if the old site still exists).

The best way to sort this problem is this:

1. Delete or Rename the /downloader directory
Probably safer to rename this for the time being. You will need to do this via FTP or your control panel file manager.

2. Obtain a fresh copy of Magento
The version number will need to be the same as the version you are running on your site. Download the .zip file and extract locally to your computer.

3. Upload the “clean” /downloader directory
Once you have the extracted files from step 2, find the /downloader directory and upload it to your Magento installation.

4. Run MagentoConnect and perform a core update
You can leave this step for now if you prefer not to update your installation. This will check all core modules and update as necessary, and will also add the missing list of core modules back into MagentoConnect. Paste the following extension key into MagentoConnect Manager:

magento-core/Mage_All_Latest

You can also do this for any extensions you have installed, which will also add them back into the list.

Problem 2: “Notice: Undefined index” Error when running the site

This could be caused by an error during the MySQL import and is possibly related to auto-increments on certain rows in the database.

Try this and see if it fixes the problem:

1. Logon to PHPMyAdmin.
2. Locate the following tables: “core_store”, “core_store_group” & “core_website”.
3. Note the “website_id” value for the admin code. It should have a 0 (zero) value; if not, change it to zero and save. Repeat this for all three tables.

What I would normally do in this situation is add an index.html file to the site root, then the following code into .htaccess to ensure the HTML file takes priority over WP’s PHP version of the same file:

DirectoryIndex index.html index.php

However, this won’t work with WordPress; it rewrites the URL to the domain root (as specified in the WP Settings panel), leaving me with access to my HTML holding page only.

So I set about a different technique. How about only allowing access to the WordPress files to my IP, and displaying the traditional HTML if the IP does not match? Well, that’s what I did.

By adding a simple snippet of code to the WordPress template, you can deny access to the WP site to everyone except you (or, to be more specific, your IP address). The code looks like this:

<?php $ip=$_SERVER['REMOTE_ADDR'];
if ($ip !== "111.222.333.444") : ?>
    <!-- HTML holding page code -->
<?php else : ?>
    <!-- WordPress template code -->
<?php endif; ?>

Since my WP site used a static page for the landing page, this code needed to be inserted into my page.php template file. If you’re showing posts on your landing page, add the code to the index.php template.

If you move to a different internet connection or use a dynamic IP, you will need to update the file with your current IP address.

Please BACKUP EVERYTHING before proceeding, and use the following information at your own risk!

I recently purchased a decent VPS for hosting a handful of demanding Magento sites (my shared hosting is just not up to scratch unfortunately).

I like to be able to offer comprehensive backup solutions to clients for complete peace-of-mind – relying on your host to do this is a big no-no – they will only make sure their backups cover themselves in the event of a hardware failure, so will be of little use if you or your client makes a mistake and breaks the site, or if, God forbid, your site gets hacked or maliciously attacked.

Joomla has a few options for auto-backing up your database and sending an email – so I started hunting around for Bash Scripts that I could run via CRON to do this for multiple databases on my VPS.

After visiting a few dozen pages, I finally managed to put everything together in my own Bash script and deployed it to the VPS, scheduled to run every day – and it works perfectly! So, without further ado, here’s the process and script you need to implement this on your own server.

My VPS runs the Plesk control panel, so the process may be slightly different for your server, but the method should be the same. You will need root access via SSH in order to test the script.

STEP ONE: Setup your Server Folders

I set my folders up on the server root. You will need two folders:

• scripts
• mysqlbackups

The names are just suggestions; you can use whatever you want for these.

You can create these folders via FTP (use the root account for the server) or via the control panel file manager.

STEP TWO: Create your Script

Using a plain text editor (I used Coda for this), create the following script:

#!/bin/sh
mysqldump -udatabase_user_name -pdatabase_password --opt database_name >
/mysqlbackups/mysql_backup.sql
cd /mysqlbackups/
tar -zcvf mysql_backup.tgz mysql_backup.sql
uuencode mysql_backup.tgz mysql_backup.tgz > mysql_backup.uuc
mail -s "MySQL Backup" myemail@domain.com < mysql_backup.uuc
rm -f mysql_backup.uuc
rm -f mysql_backup.tgz
rm -f mysql_backup.sql

...and save it as mysqlbackup.sh.

mysqldump -udatabase_user_name -pdatabase_password --opt database_name >
/mysqlbackups/mysql_backup.sql

You can easily add more MySQL databases to the backup list by duplicating the above and changing the filenames (so that you can tell them apart, of course!).

STEP THREE: Upload and Test

You should now upload the saved script to your server. Upload it to the "scripts" directory you created in Step One.

To test, logon to the server via an SSH terminal, and go to the scripts directory:

cd /scripts

Now run the script - this command may vary, so if it does not work for you, you may have to investigate the correct command for your server environment.

bash -x mysqlbackup.sh

The terminal window should output the results (no errors with any luck), and if you check your email inbox you should have been emailed the .tgz backup file!

The original files created (the .sql, .tgz and .uuc files) are all deleted from the server via the script after it has run successfully.

STEP FOUR: Schedule Via CRON

Now that you've confirmed the script works correctly, you can schedule it to run whenever you like. I set mine to run every day at 1pm:

And that's all there is to it - you now have an auto-backup schedule for your MySQL database!

(Thanks to Paul Bradley for the original starting point for the Bash script)