The first thing you’ll notice is that this uses the API. To get access to the API, your account has to be approved by Google. You’ll need to fill in this form. Once Google has activated your account for API use, you’re good to go.

Next you’ll need to set a few things up – such as mapping a GTIN field etc, but most of the work is taken care of by the extension and you can quickly start syncronising content.

The client on this project specifically requested that their brandname appeared prefixed to the product title.

The problem is in the Title attribute- even though there the extension allows you to map Google’s ‘title’ with a custom attribute, Google automatically pulls product title info from ‘name’ attribute. The issue here is with Magento’s implementation.

For this implementation, another attribute was created and populated with the “brand-productname” convention, so that we could re-map it.

The only file you need to be interested in is: /app/code/core/Mage/GoogleShopping/Model/Attribute/Title.php

class Mage_GoogleShopping_Model_Attribute_Title extends Mage_GoogleShopping_Model_Attribute_Default
{
    /**
     * Set current attribute to entry (for specified product)
     *
     * @param Mage_Catalog_Model_Product $product
     * @param Varien_Gdata_Gshopping_Entry $entry
     * @return Varien_Gdata_Gshopping_Entry
     */
    public function convertAttribute($product, $entry)
    {
 
        $mapValue = $this->getProductAttributeValue($product);
        $name = $this->getGroupAttributeName();
 
        if (!is_null($name)) {
            $mapValue = $name->getProductAttributeValue($product);
        }
 
        if (!is_null($mapValue)) {
            $titleText = $mapValue;
        } elseif ($product->getName()) {
            $titleText = $product->getName();
        } else {
            $titleText = 'no title';
        }
 
        $titleText = Mage::helper('googleshopping')->cleanAtomAttribute($titleText);
 
        $entry->setTitle($entry->getService()->newTitle()->setText($titleText));
 
        return $entry;
    }
}

The lines we’re interested in, are:

if (!is_null($name)) {
   $mapValue = $name->getProductAttributeValue($product);
}

When happens here is, $name is null, so it tries to get a new mapping. It fails, and thus, you get the product name in the if statement below it.

Simply change this line to the below, and your titles will be sent to Google as you intended them!

if (!is_null($name) && !is_null($name->getProductAttributeValue($product))) {

An example

// File 1 - include_1.php
function foo($a) {
  return $a*2;
}
 
// File 2 - include_2.php
function foo($b) {
  return $b+9;
}
 
// File 3 - index.php
include "include_1.php";
include "include_2.php";

File 3 would throw: Fatal error: Cannot redeclare foo()

So, what’s the problem?

Put simply, they both have the same function. Whichever one comes first, PHP raises an error when the second one is defined. In the case of WordPress and Magento, they both have the function __.

How do I overcome this issue?

Deactivate a Magento function that conflicts with one in WordPress.

This is the easiest way to do it, as otherwise we’d need to modify core WordPress. Magento allows us to over-ride files using a “local” version.

The implemenation

Copy /app/code/core/Mage/Core/functions.php to /app/code/local/Mage/Core/functions.php – this file will now be used over the original, and will remain during Magento upgrades.

Open the file at /app/code/local/Mage/Core/functions.php and locate the function __ function. It should be around line 90, but can vary depending on your Magento version.

function __()
{
   return Mage::app()->getTranslator()->translate(func_get_args());
}

This should now become:

if (!function_exists('__')) {
   function __()
   {
      return Mage::app()->getTranslator()->translate(func_get_args());
   }
}

This tells Magento that it should only actually define the function if it’s not already been defined (by WordPress in our case).

So, how do I now include a CMS static block in my theme?

//include Magento
require_once '../app/Mage.php';
umask(0);
Mage::app()->setCurrentStore(Mage_Core_Model_App::ADMIN_STORE_ID);
$staticBlock = Mage::getModel('cms/block')->load('static-cms-block-identifier');
echo $staticBlock->getContent();

If you run a UK based Magento store you probably already know that the store times are wrong for half of the year as the timezone switches between GMT and BST.

Unfortunately, Magento doesn’t support BST at all and the only thing for store owners in the UK, is to use standard GMT for the whole year – obviously, not great.

Magento uses UTC to store all times in the DB and works out the offset from that to whichever timezone you have selected in the admin area. The idea behind this is to allow you to set different timezones per store and have them all work together because of how the dates are stored.

So what can I do?

Unfortunately the only way to allow support for BST is to change the default timezone from UTC to Europe/London. This means creating local override files, so if you’re wanting to use timezones other than Europe/London for a store in your installation, you’re probably just going to have to live with the issue.

Issues?

1) Any existing data will be stored in UTC (GMT), so it will always be an hour behind during BST. This is a useful amend to make at the beginning of a new build rather than to a store that already exists, but if you can live with it, then go ahead any way.

2) You’ll need to make a single core file change to app/Mage.php.

What steps should I take?

Firstly, you need to ensure that your server is set up as Europe/London, otherwise altering Magento isn’t really going to have any baring on getting things working. To fix this, depending on your Linux OS, you want to be doing something like: this handy guide.

What to change with Magento

Start by copying the following files into their respective “local” folder.

   app/code/core/Mage/Core/Model/Locale.php
   app/code/core/Mage/Core/Model/Date.php
   app/code/core/Mage/Cron/Model/Schedule.php

to

   app/code/local/Mage/Core/Model/Locale.php
   app/code/local/Mage/Core/Model/Date.php
   app/code/local/Mage/Cron/Model/Schedule.php

Open the first file – app/code/local/Mage/Core/Model/Locale.php and replace the following lines (note these lines aren’t together):

   const DEFAULT_TIMEZONE  = 'UTC';
 
   @date_default_timezone_set($timezone);
   $date = date('Y-m-d H:i:s');
   @date_default_timezone_set($currentTimezone);

with

   const DEFAULT_TIMEZONE  = 'Europe/London';
 
   @date_default_timezone_set(Mage_Core_Model_Locale::DEFAULT_TIMEZONE);
   $date = date('Y-m-d H:i:s');
   @date_default_timezone_set(Mage_Core_Model_Locale::DEFAULT_TIMEZONE);

What we’re doing here is altering the default timezone, and then calling that setting when we call date_default_timezone_set. You could use self::DEFAULT_TIMEZONE instead of Mage_Core_Model_Locale::DEFAULT_TIMEZONE if you were so inclined.

Nex, you should open up the app/code/local/Mage/Core/Model/Date.php file and locate the calculateOffset() function.

Change the following two occurances – again, making reference to the constant we’ve just set up:

   $result = date_default_timezone_set($timezone);
 
   date_default_timezone_set($oldzone);

with

   $result = date_default_timezone_set(Mage_Core_Model_Locale::DEFAULT_TIMEZONE);

The only other amend left to do is to make sure that the cron system still knows what time it is! To do this, we edit app/code/core/Mage/Cron/Model/Schedule.php and change the following line:

   $d = getdate(Mage::getSingleton('core/date')->timestamp($time));

to

   $d = getdate();

Unfortunately – and I’m not quite sure why I’ve left this till last, but… – you need to make a core Magento change. Fortunately, this is straight forward and only requires one change. For some reason, the guys that made Magento decided to hard-code in a UTC call within the main app/mage.php. It’s not a good idea to make core changes, as when you come to update Magento (if you ever do), you’ll have to re-make this change, but it needs to be done.

Open up app/mage.php and find the line:

   date_default_timezone_set('UTC');

to

   date_default_timezone_set('Europe/London');

And that’s it! Your store should now be working to BST/GMT. Congratulations!

I tried adding a height attribute to my opening div in my page. I tried amending the height in Facebook’s attributes too, but unfortunately no luck. The only thing I could think was to change the height onload. Luckily, a quick google came up with this article on stackoverflow which covers most of the code needed (specificially FB.Canvas.setAutoGrow())

Depending on your app/page, create: <div id="fb-root"></div> and immediately below it, put the following. you may need to tweak true/false depending on your circumstance.

window.fbAsyncInit = function () {
    FB.init({
        appId: 'YOURAPPID', // App ID
        channelUrl: '/channel.html', // Channel File
        status: true, // check login status
        cookie: true, // enable cookies to allow the server to access the session
        xfbml: true  // parse XFBML
    });
    FB.Canvas.setAutoGrow(); //Resizes the iframe to fit content
};
// Load the SDK Asynchronously
(function (d) {
    var js, id = 'facebook-jssdk', ref = d.getElementsByTagName('script')[0];
    if (d.getElementById(id)) { return; }
    js = d.createElement('script'); js.id = id; js.async = true;
    js.src = "//connect.facebook.net/en_US/all.js";
    ref.parentNode.insertBefore(js, ref);
} (document));

Looking into it a bit further it appears it isn’t brilliant – for example, there is a lack of support for NOT compressing the archive – but it did exactly what I required.

I put together a little function to take care of it and make it re-usable. Take a look below.

The solution function

protected function createZipFile($files = array(), $destination = '', $overwrite = false) {
 
	// sanity check
        if (file_exists($destination) && $overwrite === false) { return false; }
 
	// should probably add something to ensure that the files exist?
 
	if (count($files)) {
		$zip = new ZipArchive();
		if ($zip->open($destination, $overwrite ? ZIPARCHIVE::OVERWRITE : ZIPARCHIVE::CREATE) !== true) {
			return false;
		}
 
		foreach($files as $file) {
			// use basename so that we don't keep the directory structure
			$zip->addFile($file, basename($file));
		}
 
		$zip->close();
 
		return true
	}
	else
	{
		return false;
	}
 
}

Making the call

$files_to_zip = array('path/image1.jpg', 'image2.jpg');
$destination = getcwd() . '/files/filename.zip';
$result = $this->createZipFile($files_to_zip, $destination);

For the main part, this was easy. I put the Magento installation into a seperate folder, and the WordPress folder into a seperate and then wrapped the lot in a Zend Application.

The .htaccess file looked much like any usual Zend Application.

RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-l
RewriteRule ^(.*)$ zendApp/public/index.php [NC,L]

This sits at the main httpdocs level, knowing that the application .htaccess files would pick up for their tasks.

That’s pretty much it. Unless you want to use sessions.

The main issue here, is sharing the Magento session. It likes to store session information in its own folder. Whereas PHP would usually store session information in something like /tmp/, Magento stores it in it’s application directory /var/session/.

In order to grab session information within the Zend app for example, we need something like the following:

/**
* Initialise the Autoloader
* 
* @access protected
* @return void 
*/
protected function _initAutoloader()
{
    /*
     * Set up the session handler / save path to be the same as Magento
     * so that they can share session data
     */
 
    ini_set("session.save_handler", "files");
 
    if (array_key_exists('frontend', $_COOKIE)) {
 
            if ($_COOKIE['frontend']) {
                    session_id($_COOKIE['frontend']);
            }
 
    }
 
    $sessionOptions = array('save_path' => getcwd() . "/../../var/session");
 
    if (!Zend_Session::isStarted()) {
            Zend_Session::setOptions($sessionOptions);
            Zend_Session::start();
    }
    ...
}

This causes Zend to use the same directory as Magento, and also merges the session data with Magento at the same time by merging with the $_COOKIE. We put this code in the bootstrap to make sure it’s set early on and doesn’t interfere with anything within Zend, and we make Zend do the work so that we don’t interfere with anything Magento is offering.

I’ll be putting up a longer post, with details on how to integrate with WordPress on the Branded3.com blog soon!

Edit: This post is now up! View it here http://www.branded3.com/b3labs/zend-framework-magento-and-wordpress-sitting-in-a-tree/

I had this exact issue recently where I needed to store a colour swatch for a product and load it on a specific page.

The code for this is actually nice and straight forward:

if ($_helper->productAttribute($child, $child->getColourSwatch(), 'colour_swatch') != 'no_selection' ) {
     echo '<img src="' . $this-/>helper('catalog/image')->init($child, 'colour_swatch')->resize(163, 100) . '" />';
}

However, when you click through to Google Checkout, the free option is missing. Google Checkout seems to see this option and discard it. Or does it?

In fact, this is Magento being helpful(?)

To cure this, you just need to edit /app/code/core/Mage/GoogleCheckout/Model/Api/Xml/Checkout.php

You should be able to create a local version of the file (/app/code/local/…) if you don’t wish to edit the core file.

You’re looking for the following loop:

for ($xml='', $i=1; $i< =3; $i++) {
  $allowSpecific = Mage::getStoreConfigFlag('google/checkout_shipping_flatrate/sallowspecific_'.$i, $this->getQuote()->getStoreId());
  $specificCountries = Mage::getStoreConfig('google/checkout_shipping_flatrate/specificcountry_'.$i, $this->getQuote()->getStoreId());
  $allowedAreasXml = $this->_getAllowedCountries($allowSpecific, $specificCountries);
 
  $title = Mage::getStoreConfig('google/checkout_shipping_flatrate/title_'.$i, $this->getQuote()->getStoreId());
  $price = Mage::getStoreConfig('google/checkout_shipping_flatrate/price_'.$i, $this->getQuote()->getStoreId());
  $price = number_format($price, 2, '.','');
  $price = (float) Mage::helper('tax')->getShippingPrice($price, false, false);
 
  if (empty($title)  ){# || $price < = 0) {
    continue;
  }
 
  $xml .= <<<EOT
  <{$nodeName} name="{$title}">
    <shipping -restrictions>
      <allowed -areas>
       {$allowedAreasXml}
      </allowed>
    </shipping>
    <price currency="{$this->getCurrency()}">{$price}</price>
 
  EOT;
}

The only bit you’re really interested in though, is:

if (empty($title) || $price < = 0) {
	continue;
}

Change this to:

if (empty($title)) {
	continue;
}

And there you go - a free delivery option that you create will appear.

echo Mage::getModel('catalog/category')->load($catId)->getImageUrl();

However, by default, it doesn’t provide the facility to get the thumbnail category image. You’d expect to be able to use getThumbnailUrl(), but, you can’t.

In order to enable this functionality, you need to make some modifications to Magento.

The file you need to edit is /app/code/core/Mage/Catalog/Model/Category.php. Due to the nature of Magento, you’d be best copying this to /app/code/local/Mage/Catalog/Model/Category.php before amending the file. Once copied, you can edit this new file.

Around line 481, you’ll find the getImageUrl function. Below this, we’re going to add a new function. This function is slightly modified from others I’ve seen, where you can pass it a parameter to get just the file name, or get the full path if you’d prefer.

 
/**
 * Retrieve thumbnail image URL
 *
 * @return string
 */
public function getThumbnailUrl($fullpath = false)
{
 
  $url = false;
 
  if ($image = $this->getThumbnail()) {
 
      if($fullpath == true)
      {
          $url = Mage::getBaseUrl('media').'catalog/category/'.$image;
      }
      else
     {
          $url = $image;
     }
  }
 
  return $url;
 
}

Upon restarting the box, mysql wouldn’t respond.

hq-lnx-001:~# /etc/init.d/mysql start
Starting MySQL database server: mysqld.
Checking for corrupt, not cleanly closed and upgrade needing tables..
/usr/bin/mysqladmin: connect to server at ‘localhost’ failed
error: ‘Access denied for user ‘debian-sys-maint’@'localhost’ (using password: YES)’
hq-lnx-001:~# ERROR 1045 (28000): Access denied for user ‘debian-sys-maint’@'localhost’ (using password: YES)

debian-sys-maint is Debian’s user for interacting with MySQL. In order to rebuild it, you need to –skip-grant-tables. You can’t do this just running mysqld, you need to edit your my.cnf file.

hq-lnx-001:~# nano /etc/mysql/my.cnf