Magecredit was just Acquired!

The popular eCommerce store credit system I built that worked for the Magento eCommerce platform called Magecredit was just acquired by a German consulting company.

I’d rather not disclose the acquisition amount but I can say that I am very happy with the result.

The acquirer does have technical expertise so I’m confident they will continue work for the current Magecredit clients to improve and grow the product with new features. I will remain available for the next 6 months on an “on-call” basis.

It’s more than a Magento store credit extension…

Last week I announced my latest obsession: Magecredit. Magecredit is a store credit extension for Magento. It all started a few months ago when I decided to tackle the problem that eCommerce stores experience a large amount of refunds in their lifetime. For some stores, this kills their performance. In fact, analysts have seen eCommerce store return rates of up to 25%¹, especially in the clothing industry.  That’s a 1/4 of all sales!

So what are merchants doing right now to combat this issue? Well, they’re basically giving customers back their money and hoping that the customer decides to chose another product… In my calculations I’d consider this a lost customer unless you can find a way to keep the money in your store. From an accounting stance, returns look ugly as well (especially with the credit memo system native to Magento).

Magecredit helps solve these issues. If you can create credit memos and returns that go directly to store credit, you can incentivize customers not only to continue to shop at your store, but to also potentially increase their purchase size (as suggested by Tony Hsieh of Zappos in Delivering Happiness).

The first step of this journey to retaining customer value is to build the store credit extension for Magento. I’m focusing on Magento store owners simply because I know the Magento ecosystem very well and I can keep close to the merchants using store credit in their store so I can learn and adapt the system to be the best that it can be for merchants. Later I’m going to look at implementing the system for Shopify and BigCommerce, and even some of the larger platforms like Demandware.

So you see see, it’s much more than a Magento module to me. Magecredit is about increasing customer happiness and loyalty. I’m excited to see merchants succeed with it on their side.


¹ Old school vs shiny new technology

Check if a website is running Magento Community or Enterprise Edition

To check if a website is running Magento the first thing you want to do is view the page source and search for “Varien”. If you find a match then the website is *probably* running Magento. If you do not match anything, next view the source of the JS files and look for “Varien”. Some websites merge their javascript files into one file, so that should be easy.

After you know if the website is running Magento, you can detect if a website is running Magento Enterprise Edition by hitting *website_base_url*/giftcard/customer in your browser. If you get a 404 Page Not Found error then that means they are NOT running MEE (Magento Enterprise Edition). If you get redirected to a login page that means they ARE most likely running MEE.

You can get browser extensions like Chrome Sniffer that will also tell you if they are running Magento, however the above method is great if you need to do it programmatically for some reason.

How to temporarily disable cache for Magento scripts

If you are running Magento scripts that are bootstrapped for reasons such as asynchronous processing, syncs, indexing, etc, then you’ll want to disable all Magento cache when Magento is loaded. This will avoid cases where old model data is being used, especially when you have two executions of the Magento script running at the same time.

To disable all Magento cache programmatically add the “global_ban_use_cache” option to your Mage::app initialization. Your Mage::app initialization would look like this:

Mage::app(‘admin’, ‘store’, array(‘global_ban_use_cache’=>true));

Any modules you have running that also use the native Magento cache system should also stop using cache when this flag is set.

Hope this helps some people!

Magento CMS Tutorial/Reference

I was helping someone learn how to use Magento CMS static blocks and pages and I couldn’t find a great reference. I’ve decided to write my own. 

Pages – Pages are what shows up in the front-end. The URL key is what you use to access the page (yoursite.com/urlkey) and the content is what appears in the page. Title shows up in the title bar. Simple.

Static Blocks – These can be inserted into any page and repeated. For example, if you had a page that had a block of text that you want to appear on another page but you didn’t want to rewrite it and have to sync between both pages then you would want to create a static block and include that static block in each page’s content. The static block si referenced by the Identifier field. Here’s an example of how this would be used. Static blocks and contain other static blocks too. 

Page Content Codes

When working in the Magento CMS you can enter any HTML into the content box, but you can also put in these special things:

  1. Store URLs: {{store url=”path_to_your_media_file_goes_here”}}
  2. Skin Image URLs: {{skin url=”path_to_your_media_file_goes_here”}} 
  3. Media Image URLs: {{media url=”path_to_your_media_file_goes_here”}}
  4. Static Block Content: {{block type=”cms/block” block_id=”page_identifier_goes_here”}}
  5. Other Data Blocks (advanced): {{block type=”module/blockclass” block_id=”choose_a_name” template=”template_file_path”}}

Now I’ll go into a bit more detail:

1. Store URLs
{{store url=”path_to_your_media_file_goes_here“}}

If you want to link to a CMS page or some other page on your site you should use this code.

Example: Click here for customer service

2. Skin Image URLs
{{skin url=”path_to_your_media_file_goes_here“}} 

Skin image urls can be inserted into a page as paths to a skin image or file. These are relative to the skin/frontend/*package*/*theme*/ directory in your website.

Example: Here is a picture of our company logo: <img src=”{{skin url=’images/logo.png’}}” />

3. Media Image URLs
{{media url=”path_to_your_media_file_goes_here“}}

Skin image urls can be inserted into a page path to point to an uploaded image or file. These are relative to the media/ directory of your website.

Example: Here is a picture of a duck: <img src=”{{media url=’ducks/duckpicture.png’}}” /> and click here for a PDF that we created for you.

What’s the difference between skin images and media images?

Great question! Skin images are store layout/theme dependent and may change depending on the store view, but media images are static and don’t care about what theme is currently being displayed to the user. Media images are typically files that are very likely to change over time where skin images 

4. Static Block Content
{{block type=”cms/block” block_id=”page_identifier_goes_here“}}

Static block content can be inserted into the content of one or more pages. This allows you to have repeated content in your pages without having to manage multiple content page coppies every time you make an update.

Example: Here is your navigation menu: {{block type=’cms/block’ block_id=’my_navigation_menu’}}

5. Other Data Blocks (advanced)
{{block type=”module/blockclass” block_id=”choose_a_name” template=”template_file_path}}

If you are coding template files nad custom block classes, you can include any block class as a singleton using this method .The type attribute is the code to create the block class and the block ID is a custom name you can choose for the block. This block name is used in caching sometimes. Finally, the template file path is a reference to the template file from the app/design/frontend/*package*/*theme*/template directory.

TIP: You can also set the the blcok type to core/template to create a simple block that does not have a specific block class.

Example: Here is my footer block content: {{block type=’core/template’ block_id=’footer_block’ template=’page/html/footer.phtml’}}

 

Static_block_within_static_block

 

Making Magento load a custom database depending on domain

We needed to make Magento to run a different database depending on the subdomain specified. Here’s how we did it VERY basically. doing so allows you to have separate Magento databases dynamically loaded depending on route. This also makes scaling a lot easier, and usage of systems like beanstalk from Amazon or PHP fog possible.

Magento_multidb

Keep in mind the following things:

  1. This is not a secure method mentioned below. You should have different passwords for each DB. doing so however will require you to store somewhere the passwords to access.
  2. This was tested on Magento 1.6 CE and 1.11 EE in a unix environment.
  3. This method assumes you don’t store any custom data in the config.xml. You should make your XMLs read-only to ensure this. 
  4. You should spend time with your own environment, so I’m not too specific in these instructions. 
  5. These require some core changes. If anyone has any suggestions on how to do it without the core changes, be my guest and comment below.

The Steps

Step 1: Edit the index.php. Somewhere before loading Magento, pull the subdomain using your favourite method. We used $_SERVER[‘SERVER_NAME’]. Set this to $subdomain.

Step 2: Within index.php, find Mage::run near the bottom. The last paramater allows you to specify custom directories. Make the media and var/ directories custom depending on the domain. We did something like this:

    Mage::run($mageRunCode, $mageRunType, array(
            ‘upload_dir’  => $dir.‘/media/upload’.$subdomain,
            ‘tmp_dir’     => $dir.‘/var/tmp’.$subdomain,
            ‘cache_dir’   => $dir.‘/var/cache’.$subdomain,
            ‘log_dir’     => $dir.‘/var/log’.$subdomain,
            ‘session_dir’ => $dir.‘/var/sessions/’.$subdomain,
            ‘export_dir’  => $dir.‘/var/export’.$subdomain,
    ));

 

 

Step 3: I know global variables are bad, but set global $subdomain; Now you can access it anywhere.

Step 4: Edit app/code/core/Mage/Core/Model/Config.php or move it to app/code/local/ After line 279, add something like:
     global $subdomain;
       $this->_xml->global->resources->default_setup->connection->dbname = $subdomain;
 

You may want to also add some checks here to see if the DB actually exists.

Step 5: Edit app/Mage.php and after line 689 add:
       global $subdomain;
       $localConfig->global->resources->default_setup->connection->dbname = $subdomain;
       $xml = $localConfig->global->resources->default_setup->connection->dbname;
  

Step 6:  Name each new database you create by the subdomain.

Try it out

Try it out. Assuming you’ve done everything correctly you should get Magento to load now depending on the subdomain. Definitely do your own tweaking, but I really hope this helps someone.