Quick tips for: Hide a Magento Test Site

With every Magento e-commerce website I create for my clients, I create a carbon copy for use as a test environment that is accessible on the web.

There are a number of benefits associated with doing this before making changes on a live environment:

• The ability to upgrade on the test server as updates become available.
• Test extensions from Magento Connect.
• Developing, testing and implementing new features.
• Get sign off from the client while still in a test environment.

I can then quite easily and efficiently role out these enhancements without fear of complication.

What is vital though is that search engines don’t crawl and index the test environments. This can be done quite easily from within the Magento Dashboard.

Navigate to Configuration -> Design -> HTML Head and set the Default Robots option to ‘NOINDEX, NOFOLLOW’. This should add a ‘NOINDEX, NOFOLLOW’ meta tag to your site.

 

7 common mistakes in Magento SEO

1. Homepage title “home”

If I had a dollar for every Magento store out there I’ve seen with a homepage title “home” I’d be a rich man. The homepage is usually a CMS page. Go in there and change the title of the page into something more suitable such as “Blue Widgets Online Store – Example.com”.

2. Using “default description” field

System > Configuration > General > Design > HTML Head > Default description – Leave this blank or you’ll have such a mess of duplicate descriptions on your store that don’t really describe the given URL that it will be unbelievable. Also, please make sure your meta keywords are not “magento, magento commerce” etc.

3. Not turning on rel=canonical

Save yourself from lots of duplicate content issues. Turn canonicals on for both products and categories.

4. Logo title and/or alt “Magento Commerce” 

Logo, usually in the top left of your website. Don’t have it say “Magento Commerce”. I’ve seen that a lot of times.

5. Forgetting to turn meta robots to “index, follow” and remove robots.txt disallow after a move from staging/dev site to the live site

System > Configuration > General > Design > HTML Head > Default robots “INDEX, FOLLOW”.

Sometimes people leave this as noindex, nofollow on dev server and forget to change it when they migrate to the live server.

6. Having a default layered navigation

Layered navigation is a hell for the SEO.

7. Building a sitemap with sample products and sample categories

I’ve seen this one as well. Check what’s in your sitemap.xml before you submit it to Google. No sample products please! 

How Multiple Websites & Stores Work

One of Magento’s advanced features allows for management of multiple websites and stores within one installation, and we have an amazing system to support this:  GWS – aka “Global, Website, Store.”

• Global: This refers to the entire installation.
• Website: Websites are ‘parents’ of stores.  A website consists of one or more stores. Websites can be set up to share customer data, or not to share any data
• Store (or store view group): Stores are ‘children’ of websites.  Products and Categories are managed on the store level.  A root category is configured for each store view group, allowing multiple stores under the same website to have totally different catalog structures.
• Store View: A store needs one or more store views to be browse-able in the front-end.  The catalog structure per store view will always be the same, it simply allows for multiple presentations of the data in the front.  90% of implementations will likely use store views to allow customers to switch between 2 or more languages.
• 

• Example scenario

  Let’s say you want to sell appliances, consumer electronics, and DVD’s and CD’s.  For the purpose of this example we’ll separate the catalog into two stores and three websites.  The appliance line will be sold on its own website, and the remaining items on another website.  You bought appliances.com and coolstuff.com for this purpose.  You don’t want customer data and order data to be shared between the two websites, so data sharing will be turn off in the configuration between them.

  Under coolstuff.com you create two stores – Electronics, and Media.  Consumer electronics will be sold through the electronics store, and the media items through the Media store.  Since each line of items is very extensive, it makes sense to create a separate category structure for the Media store and the Electronics store… otherwise the category tree would be large and cumbersome.  When the stores are created, you simply assign a different root category to each store.

  In addition, you want to feature your catalog for both websites in English and Spanish.  To do this, you will create an English and Spanish store view for each of the three stores.  When entering catalog data you can switch store views in the admin to create the additional product titles, descriptions etc…

  Configuration

  The configuration of Magento uses GWS as a kind of tree when setting up the stores.  When it is initially installed, all configuration settings point to “default”, meaning the global installation.  A check box next to each configurable item can be un-checked in a particular website or store view, to indicate that this item will be specific to this website or store view.  For example, you will offer authorize.net as a payment module on both websites, but you only want to offer google checkout on coolstuff.com.  In the configuration, you’d select coolstuff.com in the store view drop-down, find the google API settings, and un-check “use default” in the google checkout tab.  For this specific website you can now enable or disable google checkout.

  All modules in the configuration function the same way.

  Moving on to store views – after a store view has been created, you can configure the layout and visual settings of the store view however you’d like – a drop-down allows customers to switch between store views.  This will reload the current page with the alternate view.  This can be used for multiple languages, but can also be a way to easily do A-B testing between several design packages to see if one yields more conversions.  The possibilities are endless!

  The above is meant as a basic overview of this functionality – the best way to learn how to set it all up is to install Magento and get in there and start playing around.

Magento Remove index.php from url

Magento by default added the index,php in url .So,As per the SEO page will not get indexed properly SO here we have try to Remove index.php in url from both End Access Magento URL without index.php
For example:
http://domain.com/index.php/category to
http://domain.com/categoryThen Just follow steps
1) Login to admin section by using the URL http://domain.com/index.php/admin
2) then go to “System >> Configuration >>Web >> Search Engines Optimization” Use Web Server Rewrites : YES
3) Go to “System >> Configuration >>Web >>Secure” Use secure URL Frontend: YES
4)Then create the .htaccess file under your the magento installed folder.

If the magento installed under document root ( /home/username/public_html) then add follogig rules into .htaccess file

RewriteEngine On

RewriteBase /

RewriteRule ^index\.php$ - [L]

RewriteCond %{REQUEST_FILENAME} !-f

RewriteCond %{REQUEST_FILENAME} !-d

RewriteRule . /index.php [L]

and If the magento installed under /shop or directory then add the following rules into ” /home/username/public_html/shop/.htaccess ” file.

RewriteEngine On

RewriteBase /shop/

RewriteRule ^index\.php$ - [L]

RewriteCond %{REQUEST_FILENAME} !-f

RewriteCond %{REQUEST_FILENAME} !-d

RewriteRule . /shop/index.php [L]Thst's it just refresh the cache .Hope this will help!

 

Magento’s Default Files and Folders Structure

This part of the Magento tutorial will provide detailed information regarding the Magento’s default files and folders structure.

You will learn more about the functions of main files and folders included in the Magento package.

The files and folders included in the main directory are as follows:

• .htaccess – contains mod_rewrite rules, which are essential for the Search Engine Friendly URLs. There you can also find standard web server and php directives that can improve your web site performance.

• .htaccess.sample – this is a backup of the .htaccess file. If you modify .htaccess it can be used in order to get the default settings.

• 404 (directory) – The folder stores the default 404 template and skin for Magento.

• app (directory) – This folder contains the modules, themes, configuration and translation files. Also there are the template files for the default administrationtheme and the installation.

• cron.php – a Cron Job should be set for this file. Executing of the file on a defined time period will ensure that the complicated Magento caching system will not affect the web site performance.

• downloader (directory) – This is the storage of the web downloader files. They are used for the installation and upgrade of Magento through your browser.

• favicon.ico – the default favicon for Magento. A small icon that is shown in the browser’s tool bar once your web site is loaded.

• index.php – the main index file for Magento.

• index.php.sample – A backup of the default index file. It can be used to revert the changes in a case of a index.php modification.

• js (directory) – Contains the pre-compiled libraries of the JavaScript code included in Magento.

• lib (directory) – The Magento core code is located in this folder. It contains the software’s PHP libraries.

• LICENSE_AFL.txt – The Academic Free License under which the Magento software is distributed.

• LICENSE.txt – The Open Software License under which the Magento software is distributed.

• media (directory) – This is the storage of the Magento media files – images out of the box, generated thumbnails, uploaded products images. It is also used as a container for importing images through the mass import/export tools.

• mage (in versions older than 1.4.2.0 this tool was called pear)- The file controls the automatic update through the downloader script and SSH. It handles the update of each individual Magento module.

• php.ini.sample – This file contains sample php directives that can be used in order to modify your PHP setup. If you want to alter the default setup edit the file and then rename it to php.ini.

• pkginfo (directory) – Contains files with information regarding the modules upgrades’ changes.

• report (directory) – This folder contains the skin of the Magento errors reports.

• skin (directory) – There are located the themes files – images, JavaScript files, CSS files, Flash files. Also there can be found the skin files for the installation of skins and administration templates.

• var (directory) – Cache, sessions, database backups, data exports and cached error reports can be found in this directory.

If you want to modify an existing template or set a new one you should know that the template files are separated in 3 folders:

• /app/design/frontend/default/YOUR_TEMPLATE_NAME/layout/ – Contains the .xml files that define which modules should be called by the template files and loaded in defined areas on the site.

• /app/design/frontend/default/YOUR_TEMPLATE_NAME/template/ – Contains files and subfolders that structure the final output for the users using the functions located in the layout/ folder.

• /skin/frontend/default/YOUR_TEMPLATE_NAME/ – Contains the CSS, images, JavaScript and Flash files related to the template.

 

7 Reasons Why WordPress Made PHP Popular, not PHP Frameworks – PHP Classes blog

7 Reasons Why WordPress Made PHP Popular, not PHP Frameworks

1. WordPress is the Most Popular PHP Application

Counting the number of search results on several popular search sites may seem to be a way to measure the relative popularity of a technology, language, application or a product.

However, that way does not seem to be very reliable method. When a search site changes its algorithms, you may see changes in the results that really do not have to do so much changes in the popularity of those technologies.

A more reliable way to measure the relative popularity of a technology is to resort to Google Trends. This is a site that Google provides to show the evolution of the relative number of searches done by given keywords over time.

As you may see in the following Google Trends chart, WordPress is much more popular than other PHP applications like Joomla, Drupal, Magento (which is Zend Framework based).

Google Trends: WordPress, Joomla, Drupal, Magento, Zend Framework

2. WordPress alone is much more popular than any PHP framework

Using Google Trends you can also compare the popularity of different PHP frameworks. If you compare the popularity of WordPress with Zend Framework, Symfony PHP and CakePHP, as you may see in the chart below, WordPress is much more popular than all these PHP Frameworks together.

Google Trends: WordPress, Zend Framework, Symfony PHP, CakePHP

3. WordPress does not use third-party PHP frameworks

WordPress has been using some third-party components but they are not really full-stack frameworks. This implies WordPress never needed a full-stack framework to be built. The use of such frameworks would hardly make a difference to its popularity.

4. Applications make technologies popular, not components

In the chart above you may  notice that Magento is much more popular than Zend Framework. Magento is built on Zend Framework. This seems to imply that what makes applications popular is whether they solve users problems, not the components that they are built on.

WordPress is also popular because it is useful to many users. When users need to host a WordPress installation they need to seek a PHP hosting service. So they know at least superficially what is PHP and that they need PHP hosting.

This means that WordPress helped making PHP even more popular. The more installations there are of WordPress, the more PHP becomes popular.

5. The Extensible WordPress plugin ecosystem

One of the most important reasons that made WordPress popular is the myriad of plugins that were developed to provide additional features.

There are WordPress plugins for practically everything, including those that can turn it into other applications besides being a blog system. There are plugins that can turn it into forums, e-commerce sites, trouble ticket systems, etc., anything.

If WordPress as blog application was already popular, it became even more popular as a platform that can be turned into any type of application.

6. Non-Programmers develop in PHP just because of WordPress

If you need a site that requires certain features that WordPress does not have, you can develop new plugins to extend WordPress further and taylor it to your needs.

Many of the WordPress users were not really programmers. They started programming because they needed to have features in WordPress for which there was no suitable plugin providing them.

This means that many non-programmers had to learn PHP to be able to develop new WordPress plugins. That helped making PHP more popular even among non-programmers.

7. Pragmatism is better than Purism

In sum I could say that WordPress and PHP in general became popular because they can be used to address practical needs of many users.

Neither WordPress nor PHP are examples of software projects that are technically beautiful, are consistent, always follow well-thought project plans and adopt praised design patterns.

But that does not matter. They were created by people with a very pragmatic sense. They were focused on solving real world needs.

As for many of the PHP frameworks, they seem to have been developed in a totally different planet. They are often developed by purist people that seem to be more concerned with the number of design patterns they employ in the framework components than with being pragmatic and solve real PHP application needs.

To make it worse, many PHP frameworks systematically adopt practices of other frameworks developed for other languages. That raises totally unnecessary difficulties for PHP developers that try to use them.

One example of this problem is the configuration formats. In the Java world it is still usual to use XML as format for storing configuration values. XML is a portable format that can be written by humans. It was certainly a progress when compared with binary formats used to serialize data structures by C++ applications in the past.

This was a fine solution in the year 2000 but the fact is that XML is a drag. You need to keep opening and closing tags for every value. Sometimes values are stored as tag attributes, other times as tag values. It is often a pain to use.

Then Ruby On Rails came with the promise to get rid of some of the pains of the Java world habits. Instead of using XML, they decided to use YAML, which is a simplified markup language. It is simpler than XML but it is yet another format that you need to learn.

Several PHP frameworks were built copying Ruby on Rails practices, including the use of YAML as configuration format. Many years have passed and they still used YAML.

If you are a PHP developer, the format you are most familiar with is PHP. Why don’t these PHP frameworks make the lives of PHP developers better and adopt PHP scripts as configuration formats? PHP scripts can even be cached and so be loaded much faster.

In the worst case, if you need to use a more portable format, why these PHP frameworks do not use the JSON format to store configuration values? JSON is JavaScript. Every PHP developer knows JavaScript. It is only natural to adopt JSON nowadays.

Unfortunately many PHP frameworks as still stuck with formats that are not a natural choice for PHP developers, like XML, YAML or even INI (a legacy format of the Windows world).

I always get this feeling that PHP frameworks are not meant to please PHP developers. They seem to have been thought to please Java or Ruby developers. To make it worse, many of the newer PHP frameworks keep copying the same mistakes of older frameworks.

Obviously there are exceptions. There are indeed some PHP frameworks that were developed in a more pragmatic way for PHP developers. You can easily learn them without having to learn about Java or Ruby frameworks first.

Unfortunately those seem to not be the PHP frameworks that get more visibility. Maybe it is time for the PHP framework developers rethink their approach and think more about the PHP developers than about developers of other languages.

Shall I develop My Sites with WordPress or with a PHP Framework?

One frequent dilemma that PHP developers have is whether they should develop sites on top of WordPress or develop them from scratch based on a existing PHP framework?

This is a tough call. If the site is a blog, it may be an obvious choice to create it based on WordPress and save lots of development time. If the site is more than a blog but there are plugins for the functionality you need, WordPress may still be the best option.

Now if your site is very different than a blog, the amount of code that you would reuse from WordPress would be much less when compared to the whole project size. In that case, it may be better to start the development of the site from scratch.

If you still need a blog, you can use WordPress in a separate domain or a separate directory of your site.

For the bulk of the functionality you need to develop, you can use a existing PHP framework to gain some development time, or use your own framework if you have a good capable framework to address your needs.

Personally I tend to go for the last option. I can have more control of my project, but I am well aware that this route can take me more time to develop and fix eventual bugs in the code.

Frameworks are good when they enforce a productive method

Despite of the problems described above that many PHP frameworks have, for some people adopting a framework is probably the best solution, especially if it is what is called a “opinionated framework”.

That is what are called frameworks that impose a certain development methodology. This means that there is only one way to develop applications with those frameworks.

The reason why this is a good solution for some developers is because they do not have a well defined development methodology. This means that they do not know how to start, how to progress and how to deploy an application, unless somebody tells them how to do it.

Since opinionated frameworks impose a certain development method, the developers learn how to develop their applications following the methodology imposed by the framework.

One example of opinionated framework is Ruby on Rails. PHP frameworks that are inspired in Ruby On Rails tend to be also opinionated.

Opinions are not Facts

Well this article is just about my opinion and my experience of as developer that has been creating software for several decades now.

But opinions are just that, points of view of specific people. Expressing an opinion does not mean it is the only way to interpret the facts.

Just like the Tiobe Index people expressed their opinion stating that PHP popularity growth was due to Zend Framework 2 release last year, other people may express a different interpretation of the facts.

What do you think? Do you have a different opinion about what was discussed in this article? Post a comment to tell what you think.