Magento Free Shipping -> Click and Collect Observer

Recently encountered an issue with Magento and a basic implementation of a “Click and Collect” feature.

We’d set up a system using the “Free Shipping” option within Magento to act as a “Click and Collect” option, modifying the page template for the appropriate part of the one-page checkout to include the information about the click and collect service – where it would be available from, what the opening hours are, that sort of thing.  Now there are plugins that handle store collection but they all tend to focus on retailers with multiple stores, and we’ve just got the one.

When you go to print out the order, postage cost is £0.00 and it clearly says “click and collect” but the shipping address is still the one the customer entered during checkout and that was going to cause problems with the system we’ve got for picking, packing, and shipping orders.

So….  Enter the Observer.  Observers are cool.  They’re Magento’s equivalent of Drupal’s hooks, allowing you to watch what’s going on and dive in when something specific happens.

As things go in Magento, this is a relatively straightforward hack, only took me a couple of days to work out.

Step 1.  Create a module to do the work.  SSH onto your server and…1

cd <magento install dir>/app/code/local
mkdir Satcol
cd Satcol
mkdir Clickandcollect
cd Clickandcollect
mkdir etc
mkdir Model

‘course, you can do this via FTP as well.

You don’t have to call the folders “Satcol” and “Clickandcollect”, it just made sense for me to do that.  Remember what you did call them, though, you’ll need it later.

Inside the “etc” folder, create config.xml

<?xml version="1.0"?>
<config>
 <modules>
  <Satcol_Clickandcollect>
   <version>0.0.1</version>
  </Satcol_Clickandcollect>
 </modules>
 <global>
  <models>
   <satcolclickandcollect>
    <class>Clickandcollect_Model</class>
   </satcolclickandcollect>
  </models>
  <events>
   <checkout_controller_onepage_save_shipping_method>
    <observers>
     <sales_order_place_after>
      <type>singleton</type>
      <class>Satcol_Clickandcollect_Model_Observer</class>
      <method>satcoltest</method>
     </sales_order_place_after>
    </observers>
   </checkout_controller_onepage_save_shipping_method>
  </events>
 </global>
</config>

And if you’ve called your directory anything other than “Satcol” and “Clickandcollect” you need to change the lines where those words are found.

Under “events”, we’re specifying that we’re looking for the exact moment when Magento saves the shipping method – checkout_controller_onepage_save_shipping_method – catchy name, I’m sure you’ll agree, but it does exactly what it says on the tin.  If you’re not using the onepage checkout, then you’ll need to determine what the event you’re observing is called.

The “method” line is important for the next file as it’s the name of the php function you’re going to call in Observer.php

cd back to Model and create Observer.php

<?php
  class Satcol_Clickandcollect_Model_Observer {
    public function satcoltest($observer) {
      $quote = Mage::getSingleton('checkout/session')->getQuote();
      $shippingAddress = $quote->getShippingAddress();
      $shippingMethod = $shippingAddress->getShippingMethod();
      if($shippingMethod=='freeshipping_freeshipping'){
        $address1 = $shippingAddress->getStreet(1);
        $shippingAddress->setStreet(array('Collect From Your Shop','66-78 Denington Road'))
          ->setCity('Your City')
          ->setRegion('Your County')
          ->setPostcode('Your postcode')
          ->save();
        Mage::log('Click and Collect order placed');
      }
    }
  }

Obviously change the setStreet, setCity, setRegion, and setPostcode values as appropriate.  And the Mage::log is there for debug purposes, it can be removed – or left if you want to check the system log periodically and see how many orders have used this method.

And if you’ve used a different shipping method for your Click and Collect solution,  you’ll need to change the if statement that’s looking at shipping method.

Once these files are in place, you need to turn the module on.  In Drupal, this would be a simple tick box.  In WordPress, you’d enable the plugin in the lovely friendly GUI.  In Magento we’ve got to go to another location on the server and add in another xml file.

SSH to your server, and…

cd <magento install dir>/app/etc/modules
vi Satcol_Clickandcollect.xml

(Or whatever you called your directories back at the start).

<?xml version="1.0"?>
<config>
 <modules>
   <Satcol_Clickandcollect>
     <codePool>local</codePool>
     <active>true</active>
   </Satcol_Clickandcollect>
 </modules>
</config>

cd back to magento’s /var/cache and clear the cache (or flush it from the admin console) and you’re golden.  Now whenever someone places an order using the Free shipping method you’ve assigned to “Click and Collect” the delivery address will be automagically updated to the address you specify.

And if you know of a simpler, easier, better, way of doing this – please let me know.  Just as long as it isn’t “buy this plugin for only $79”.

Synology and Drush 8.1.16 – Finally Working

Yep, it’s Tech Monday on a Wednesday again…

Okay, so I’m lumbered with these Fisher Price “My First Server” things.  They run Linux (Yay!) but a strangely butchered and hobbled version (Boo!) and as I need them to run Drupal, I need to get some things working properly.  And, of course, they don’t have APT or RPM on there, that would be too easy.  And by “things”, I mean Drush – essential for command line maintenance of all your Drupal sites.

Apologies for the technical nature of this post, I didn’t have time to paint it or build it to scale.

First thing needed is php7.  Synology has a package for php7, so that’s not a big problem.  It’s currently stuck at 7.0 but I expect we’ll see 7.1 and 2 soon (for a certain definition of “soon”, it took them long enough to get MariaDB 10 on there).  Install that package and you’re good to go forward.  Once the package is installed, nip into the configuration website and enable ALL THE EXTENSIONS EVER.

Drush itself.  First off, I had to create my own home directory as somewhere to put things that stay vaguely safe between DSM updates.  Weirdly, my Synology boxes didn’t create home directories for users (you know, the way normal operating systems do), so there were chunks of things always throwing errors.   Do this for your username…

sudo mkdir /volume1/homes/<username>

Sorted.  Golden.  Etc.  You’ll probably need your root password to do this, then you’ll need to chown it to your user before you can use it properly…

cd into that directory, head over to http://docs.drush.org/en/8.x/install/ and grab the latest 8 release from GitHub.  At time of writing, it’s 8.1.16

Okay.  This is where it gets technical.  More technical, sort of.

Sure, you could just run

php70 ~/drush.phar pm-update

But (a) it’s tedious to type that in all the time and (b) it’ll fail because pm-update calls php pm-updatestatus and that’ll fail because php is not the same as php70 and doesn’t have all the extensions installed.

So we need to perform some surgery in /bin.

Step 1.  Get /bin/php to point to the *right* php.

sudo su
<password>
cd /bin
mv php php56
which php70
(assuming /usr/local/bin/php70, if not then substitute appropriately)
ln -s /usr/local/bin/php70 php
exit
php --version

Now when you run php –version you’ll see a lovely, shiny, 7.0 there instead of the dull, old, tedious 5.6.

Step 2, get Drush in place.

sudo su
cd /bin
cp /volume1/homes/<username>/drush.phar drush
chmod a+x drush
exit

Now you can run drush from anywhere on the server, without having to specify a version of php or a location for the drush.phar file.  Ain’t that a treat!

And if you’re being clever, you’ll see that you could have both drush 8 and 9 installed at the same time – just have different filenames in /bin – you could have “Doctor” running drush 8 and “Master” running 9.  Jeeves and Wooster.  Armstrong and Miller.  Bonnie and Clyde.  Any pairing you like, really.  Or you could be boring and have “drush8” and “drush9”.  Up to you, really.

Word of warning 1 – If you do this to /bin/php it will alter your default command line php for everything.  Shouldn’t be a problem, in fact it will probably make life easier.  But worth bearing in mind if you suddenly start getting weirdness with scripts you’re triggering through cron jobs (and don’t get me started on Synology’s implementation of cron, that makes no sense).

Word of warning 2 – There will come a day when, totally unexpectedly, you’ll type “drush” and your Synology box will reply with “What the f*ck is drush?” Or the Linux equivalent, usually a bit more polite – imagine Jeeves stepping smartly yet unobtrusively forward, coughing politely, whispering “I’m terribly sorry, sir, but I can’t find that command”, then stepping back into the butler’s pantry.  This means your Synology box has updated the Disk Station Manager software and reset ALL of your configuration tweaks.  Go back into php.ini and reset that max_upload_size from 32M again.  Fix those timeout values.  And redo steps 1 and 2, above, assuming you’re lucky enough to still have a home directory with drush.phar in it.

If this has helped you, good.  And I hope you find a way to get to a real server sooner rather than later!

Magento – Sorry no quotes are available for this order at this time

Tech Monday comes back for a Friday specia on Magento 1.9.  Coming at this interesting piece of software from a Drupal background, lots of stuff make no sense at all.  The themeing system.  Modules.  The “Insert credit card here” approach to community support.  And the helpful error messages.

The error message

Sorry, no quotes are available for this order at this time

which came up on a new site using table rate shipping this morning was a new one and none of the answers I found worked, but they did get me thinking of where to look.

So the setup is as follows:

  • Multi-store installation
  • Issue occurs on newly launched store using default values for all shipping fields.

Turns out, the Table Rate settings don’t persist between stores.  Or they didn’t on this setup.

So, in System > Configuration, you select the store you want, re-import the table rate shipping values, clear the caches, and you’re good to go.  Or at least I was.  Your mileage may vary.  You’ll probably have to clear the caches again.  Magento likes it when you do that.

Have I mentioned that I don’t like Magento?