Configuring Magento to use a Content Delivery Network (CDN)

Have you recently setup a Content Delivery Network (CDN) and are now looking to take advantage of the benefits a CDN offers via your Magento Store? If so, then you are in the right place! This short how-to will show you how to quickly configure your Magento store to use a CDN.

First and foremost, you want to verify that your CDN is functioning properly before reconfiguring your Magento store. The easiest way to do this it to check the URL of a few images on your site and compare them to the CDN URL to ensure the correct image loads. Once you’re certain everything is functioning properly, the following steps can be taken to complete the Magento setup.

  1. Login to your Magento Admin.
  2. Navigate to System > Configuration > Web > Unsecure.
  3. Under “Current Configuration Scope” select the store you would like to configure to use your CDN.
  4. Update your Base Skin URL with your CDN-URL + path-to-skin directory; ie CDN-URL/skin.
  5. Update your Base Media URL with your CDN-URL + path-to-media directroy; ie CDN-URL/media.
  6. Update your Base Javascript URL with your CDN-URL + path-to-js directory; ie CDN-URL/js.
  7. Save the settings and then refresh your Magento cache.

 

That’s it! Those 7 steps are the basics needed to configure your Magento Store for your CDN. You should now see images loading from your CDN when you visit your Magento Store!

If you do not have CDN service, stop by http://www.simplehelix.com/services/cdn for details on how CDN service can benefit you and your Magento Store!

 

Security Notice for Magmi Product Importer

The Magmi product importer is used by many Magento stores to quickly and easily import a large number of products. Unfortunately, a recent security vulnerability has been found in Magmi that can allow an attacker to upload malicious code if the Magmi installation is publicly available. This could allow the attacker to gain credit card information or other confidential data from your store. If you use Magmi, we strongly recommend that you remove the code from any publicly accessible directory immediately to limit your risk to this vulnerability. Below you will find instructions for securing access to Magmi using Apache/Litespeed and Nginx.

Apache / Litespeed Instructions


For Apache and Litespeed webservers, the following rules can be added to your .htaccess file in the /magmi directory to secure access to only your trusted IP address:

RewriteCond %{REQUEST_URI} ^/(index.php/)?magmi/ [NC]

RewriteCond %{REMOTE_ADDR} !^199\.199\.199\.199

RewriteRule ^(.*)$ http://%{HTTP_HOST}/ [R=302,L] 

You will need to change the IP 199.199.199.199 in the line “RewriteCond %{REMOTE_ADDR} !^199\.199\.199\.199″ to your actual IP. Once this has been added, only connections from your IP will be able to access the /magmi URLs!

*Note: The above assumes Magmi is installed in the document root. You may need to change the first line to match your Magmi installation path.

Nginx Instructions


 

For Nginx webservers, you can secure access to the Magmi URL to only your trusted IP by editing your site’s configuration file (typically sites-available/___.conf) and adding the following location block:

location ~* ^/(index.php/)?magmi {

 allow 199.199.199.199;

 deny all;

 location ~* \.(php) {

  include fastcgi_params;

 }

 try_files $uri $uri/ @bootstrap;

}

You will need to change the IP 199.199.199.199 in the line “allow 199.199.199.199;” to your actual IP. Once this has been added, only connections from your IP will be able to access the /magmi URL!

*Note: The above assumes Magmi is installed in the document root. You may need to change the first line in the location block to match your Magmi installation path.


 

It is important to note that most home internet connections are provided with a dynamic IP address, so if your IP changes you will need to update the rules with the new IP address. If you would like to apply this security tip to your store and need assistance, please open a support ticket and our technical support team will be happy to assist you.

Securing Magento’s Admin Dashboard

The Magento Admin Dashboard is the gateway into the core of your eCommerce store, so it is important that you protect this gateway from intruders and malicious activity. Fortunately, you can lock down the Magento Admin Dashboard by just using a few simple modifications.

Apache

To only allow access to the Magento Admin URL from your IP, use the following .htaccess rules:

RewriteCond %{REQUEST_URI} ^/(index.php/)?admin/ [NC]
RewriteCond %{REMOTE_ADDR} !^199\.199\.199\.199
RewriteRule ^(.*)$ http://%{HTTP_HOST}/ [R=302,L]

You will need to change the IP 199.199.199.199 in the line “RewriteCond %{REMOTE_ADDR} !^199\.199\.199\.199″ to your actual IP. Once this has been added, only connections from your IP will be able to access the /admin URLs!

Nginx

To only allow access to the Magento Admin URL from your IP, edit your site’s configuration file (typically sites-available/___.conf) and add the following location block:

location ~* ^/(index.php/)?admin {
 allow 199.199.199.199;
 deny all;
 location ~* \.(php) {
  include fastcgi_params;
 }
 try_files $uri $uri/ @bootstrap;
}

You will need to change the IP 199.199.199.199 in the line “allow 199.199.199.199;” to your actual IP. Once this has been added, only connections from your IP will be able to access the /admin URLs!

It is important to note that most home internet connections are provided with a dynamic IP address, so if your IP changes you will need to update the rules with the new IP address. If you would like to apply this security tip to your store and need assistance, please open a support ticket and our technical support team will be happy to assist you.

 

Routine Magento Maintenance

This blog post is intended to explore the importance of routine Magento maintenance. Keeping your Magento store clean and maintained is an important step to ensuring that your store performs as optimally as it can regardless of the platform you host it on. This also ensures that, should something happen with your store, you are well equipped to handle it. Below are some simple tasks you can take to make sure you are getting the most out of your Magento store. These tasks are available in your Magento administration panel under System-> Configuration -> Advanced -> System. For these tasks to work, you must have your Magento Cron set to run. For instructions on how to do this, please see our previous blog post on enabling the Magento Cron.
mage_backups

 

You can schedule automatic backups via the Magento administrator panel. It is always a good idea to have backups. Backups will be stored in var/backups (this is relative to your Magento install). To enable the backups. click the context menu under the “Enable Scheduled Backup” and select “Yes”. Under “Backup Type” you will have several options as shown below:

backup_type

 

The options are fairly self explanatory, but we will discuss them anyway!

 

* Database – This option will only backup the database for the store. This means all media files as well as your store files will be excluded from the backup. This will allow you to restore only the database from this backup.

* Database and Media – This option will allow you to backup your database as well as your media files. This will not allow you to restore things like your product image files and database, but not your core system files or themes.

* System – This is all of your files. This is the most complete backup you can schedule. This will include your media files, your database, and your system files.

* System (excluding Media) – This option is like a System backup without the media folder. This will not allow you to restore your Media files in the event you restore this backup.

 

The next consideration to make is when your backups will begin:

backup-schedule

 

The default time is midnight (this is in 24 hour format). This is fine for most, but keep in mind your store’s particular client base and when will be the most optimal for you. Generally you should schedule your backups to take place within your lowest period of traffic. Larger stores may want to plan on 2 hours or more (depending on your system resources and backup type) to allow the backup to run without affecting the store’s performance. Select the proper time you wish for this to take place from the drop down boxes. This is HH:MM:SS being hours minutes and seconds. Be sure to understand the 24 hour format before proceeding. If you select 11 under the hour box, this is going to be 11 AM. If you were to shoot for 11 PM you would want to select 23.

 

The second half of choosing when your backups run is controlled by the next option:

backup_frequency

 

The frequency option. Under this option you have the options for daily, weekly, or monthly. Again, this is fairly self explanatory but we will discuss it anyway. This option works in tandem with your start time setting. If you choose 11PM for your start time, and daily for your backup, every day at 11 PM your backup will begin. If you choose weekly, then 7 days will pass between your backups. They will still start at 11 PM, just with seven days between them. This same logic applies to the monthly backups. The caveat to this method of backup versus other methods (like our CDP backup system) is that this will actively take space within your account or server’s quotas, and it also has a very narrow scheduling capability. There is no such thing as an “incremental” backup with the built in Magento backup utility. You also cannot schedule several different types of backups on different schedules. You get one scheduled backup of one type. Keep this in mind when working out a disaster recovery plan for your business.

 

 

Log clearing:

log_clearing

 

There is an automated feature to clear some of the logs Magento keeps by default on all installations. The tables this will clear are listed below:

 

 * log_customer

* log_visitor

* log_visitor_info

* log_url

* log_url_info

* log_quote

* report_viewed_product_index

* report_compared_product_index

* report_event

* catalog_compare_item

 

You can configure the number of days to keep logs before they are truncated from the database. If you do not check them often (or ever) you should aim to keep this very low. If you are an established store this task could take some time, and like the database utility you will want to schedule this for off peak hours regardless of the amount of days you decide to keep. The start time works exactly like the backup function does. You can choose a time and frequency for this task to occur. The added consideration here is, your frequency for launching this task should be shorter than the time you save your logs. For instance, let’s say you want to keep your logs for 7 days. You will then want to schedule your “frequency” for daily, and not say weekly – as you could end up keeping logs for up to 14 days. This is because the first time the “frequency” runs, you may not have 7 days of logs to truncate. That means you would need to hit 2 cycles of ‘frequency’ for the 7 day threshold to be met. Remember this function is tied to the cron as well, so that will also have to be scheduled accordingly. This task is important because over time these tables will bloat, and if left unchecked your queries will slow as these tables grow. In addition to these tables you can clear (truncate, do not drop) the following tables manually via the command line or phpMyAdmin (a subject for a different blog post):

 

dataflow_batch_export

dataflow_batch_import

log_customer log_quote

log_summary

log_summary_type

log_visitor_online

 

Of course, before doing anything like this – be sure to have a backup dump of the database handy just to be safe.


This will conclude our introduction to Magento maintenance. If you’d like to discuss these tasks in more detail or if you would like more information on how to speed up your store, please feel free to contact our support staff via your client portal. Simple Helix is always interested in helping our clients improve their store efficiency! 

Magento Maintenance Mode

magetip

Magento 1.4 and newer allows the ability to set your site in “maintenance mode” by creating a blank ‘maintenance.flag’ file in the document root of your webserver (public_html). This is ideal if you need to take the public site offline for developmental changes. The downside to doing this is that you also lose access to the site, which can make checking site changes difficult. By slightly modifying the index.php code, we can change this behavior to maintain access to the site for certain IP addresses. This would allow the site developer, for example, to maintain access while presenting the maintenance page to all other visitors.

(more…)

    • Recent Posts