Archive for May, 2015


This was really annoying me as I found a nice lib which worked called jquery-outside-events , which I forked onto my own Github (could be tidier/easier imho) but it wouldn’t work! The reason I think was possibly it was conflicting with Prototype JS, which Magento uses.

The $ symbol is reserved for Prototype so I found I had to replace $(‘#etc’); with jQuery(‘#etc’); Since doing that however I’ve discovered you can call $j instead of $ or jQuery.

Anyway! Here’s the code you need:

$j('body').click(function (event)
{
    element = $j(event.target);
    if(element.parents('.skip-link.skip-cart').length == 1 || element.hasClass('skip-cart'))
    {
        return;
    }
    var parent = $j('.minicart-wrapper').parents('.skip-content');
    var link = parent.siblings('.skip-link');

    if (element.parents('.minicart-wrapper').length == 0) {
        parent.removeClass('skip-active');
        link.removeClass('skip-active');
    }
});

Now when you click show basket, the basket appears, but you can now click elsewhere on the page to make it close again!

Advertisements

I’ve done this a few times but always forgot and had to go into my files etc, so again I’m making a quick post to remind myself and possibly help others!

Quite simply, it’s just a matter of adding two lines to your application.ini. Use sendmail as the transport, not smtp, and change the port number to the same number set for mailcatcher in your puPHPet config.yaml (Usually 1025).

resources.mail.transport.type = sendmail
resources.mail.transport.port = 1025

Now you’ll find that the mail will send, and if you go to http://yoursitehere.dev:1080 it should be sitting in your mailcatcher inbox! Have a nice day!

Magento is pretty damned cool! I’m still getting used to it and so here’s another hint for you!

Anyway, the way the templating system is structured means that you can create a new folder and override the defaults by recreating the class/view/whatever in that folder.

For instance, our default customer login template resides in

/app/design/frontend/THEMENAME/template/customer/account/login.phtml

This template can be overridden with another module, and it will automatically use the THEMENAME in question, so you can have multiple versions of the same view.

This is where it gets confusing!

For instance, I was happily editing said login page, only to discover that nothing had changed! I was on the wrong template! Anyway, it turns out that if you log into the admin panel, you can click on the System > Configuration menu.

Once there, at the top left, there is a dropdown select menu called ‘current configuration scope. Select the theme you are working on, and the page will reload. (This is based on the Manage stores section of the admin panel, which I havent worked on yet, but the essence of it is that you have a base system, which can have multiple stores, which can have multiple views.)

Once the page reloads, scroll down to the bottom of the left-hand column, and look for ‘Developer’ in the advanced menu. In the ‘Debug’ panel, you can turn Template Path Hints on or off. Hit save, and you’re almost set to go. Lastly we need to clear the cache, so click on the System menu, and select Cache Management. I leave cache OFF in my dev environment, however you can click select all, and click refresh option in the dropdown next to submit (should alreday be selected), then submit.

OK, so what did all that do then? Well, if you refresh the page you are working on, you’ll notice it suddenly looks messy! However, you can see exactly where each part of the page came from! 😀 When you are working on a project of the kind of size I’m working on right now (i.e. huge) then there’s a lot of time to be saved!

Template Path Hints turned ON

Template Path Hints

Ever seen that message? I have, but thought I’d let you know what’s going on, as I just encountered it again in a Magento site I’m working on in my new workplace.

When this happens, it’s usually because of a clash between some other javascript library that uses the $ symbol. In Magento’s case, that’s Prototype JS (http://prototypejs.org/).

To sort it, you just need to replace all your $’s with jQuery, like so:

jQuery(document).ready(function(){
    // etc
});

You can also say var $j = jQuery, then use $j(‘#id’); instead 😀

There is an XML configuration folder located in app/design/frontend/PROJECT/THEME/layout. The main one is called page.xml. Within there, you add JS resources you do it like this:

<action method="addJs"><script>madskull/cookie/jquery.cookiebar.js</script></action>

When you add Css, you add it like this:

<action method="addCss"><stylesheet>css/styles.css</stylesheet></action>

Magento does some stuff in the background and auto tries to put you in the /js dir. There is a third way called addItem:

<action method="addItem"><type>skin_css</type><name>css/styles-ie.css</name><params/><if>lt IE 8</if></action>

You can say skin_css or skin_js, and it will set the path for the module.

Apparently, adding files stored in say bower_components just won’t work. The solution is either to hardcode the html into the head.phtml file (which they dont recommend), symlink the bower library to the JS folder you require, or just dont use bower and copy it straight in to your theme. lternatively, there is a class written by some guy that extends Mage_Page_Block_Html_Head. He hasn’t put it on Github, which I’m  uneasy with (I like stuff on Github and versioned!) but in the meantime you can get it here https://inchoo.net/magento/how-to-add-external-javascript-css-file-to-magento/

I’m still quite fresh with Magento, and today I’ve been tasked with updating the transactional emails with our rebranded design. The Magento docs for this are located here: http://devdocs.magento.com/guides/m1x/ce19-ee114/RWD_responsive_emails.html

The default transactional email templates are stored in app/locale/en_US/template/email/. You can edit these files directly, but I wouldn’t recommend it. The better way to do this is to override these templates, there are two ways of doing so.

First way: you can copy the app/locale/en_US/template/email/ into app/locale/en_GB/template/email/ the Magento Admin Panel. Doing so (this is providing your site is GB) means that the GB files will override the US ones. It also means you can have completely different templates for each locale.

However, you can alter each locales template through the admin panel too, and instead of using files, it pulls the override templates from the database.

To do this, log in to the Admin section, and go to System -> Transactional Emails. Click on add new template. Select one of the existing templates, and select the locale you wish to work with. Then click Load Template. The code will appear below. Give the new template a name, and start editing it! When you hit save, it goes into the DB. If you look you will see that the template file han’t been altered.

In the templates, there are placeholders such as

{{var logo_url}}

etc, some of these settings can be found in Configuration > General > Design > Transactional Emails

Transactional Emails Design Settings

Transactional Emails Design Settings

Css (or SASS) is kept in /skin/frontend/PACKAGE/THEME/scss/

Ok, so now I have about 40 emails to design, so I best be on with it! Catch you later! 😀

{{base_url}} is not recommended to use in a production environment to declare the Base Unsecure URL / Base Secure URL. It is highly recommended to change this value in your Magento configuration.

What this means is that you need to go into the Magento Configuration (System > Configuration > Web) and replace the unsecure AND secure Base URL values to http://yourdomain.com or whatever.

Nice and easy, this.

Set the url with ?XDEBUG_SESSION_START=PHPSTORM and set a header Cookie: XDEBUG_SESSION=PHPSTORM

If you aren’t using the built in php server for development, and like me you are using a vagrant box configured by puPHPet, this will save you a lot of wasted time wondering why you get 401s and 403s when you aren’t expecting them.

In your vhost section , under the setenv option, we add a new setenvif option:

setenvif:           
     - 'Authorization "(.*)" HTTP_AUTHORIZATION=$1'

Without this option, the Authorization header is being stripped! Run vagrant provision, and suddenly everything should be working correctly. Now get on with building that API!

This is a short little post, primarily just to remind me. We need to convert to html entities or symbols like $ and £ won’t print. There are lots of ways of getting the price from the product object, but getFinalPrice seems to be the simplest.

$raw_price = $this->getProduct()->getFinalPrice(); // string "£3,295.00"
$price =  htmlspecialchars(Mage::helper('core')->currency($raw_price,true,false));