Magento, Customized theme not using overridden images

Q: I have created a new skins folder beside my default theme’s skin folder, and placed some images that I want to override into an images sub folder. I have changed the ‘Skin (Images / CSS)’ setting in System -> Configuration -> Design -> Themes to point to my new skins, I have cleared the magento cache about 10 million times, but magento still won’t use my new images, it keeps using the originals…. what do I do?

 

A: This has caught me out once or twice and I have always forgotten about it by the time it happens again! The problem stems from the fact that the theme css file calls in images using a relative path, e.g.:

 


body {background-image:url('../images/bg.gif');}

 

So because the css file that uses your images remains in its original location it will still use your original images, to get it to use your overridden images you must create a css folder in your new skin folder and copy any css files that reference the images into there and clear the cache a further 20 times – hopefully magento will then use your new images!

 

Have a look here for some more details:

 

http://www.magentocommerce.com/boards/viewthread/2445/

 

Google App Engine, DeadlineExceededError snow storm in _warmup and module load

A Google App Engine cloud application that we have been involved in developing suddenly started getting snowed under by a storm of GAE’s most excellent DeadlineExceededError exceptions.

 

The app never really suffered from this before (unless a rogue task actually took too long that is) but suddenly these errors started happening on a huge number of requests during the module load or _ah/warmup phases, they didn’t even get to run any of our code before they were killed with this most beautiful of error messages. It literally brought the app to its knees…

 

For example, we kept finding stuff like this in the logs:

 


class 'google.appengine.runtime.DeadlineExceededError'>:
Traceback (most recent call last):
File "/base/data/home/apps/appname/9993.355980156233423494/warmup.py", line 1, in module>
import appengine_config # Cache by import
File "/base/data/home/apps/appname/9993.355980156233423494/appengine_config.py", line 27, in module>
....

 

After a little research it seems that this has started happening to loads of GAE users since December 2011, have a look at this thread:

 

http://groups.google.com/group/google-appengine/browse_thread/thread/369a9a76c394c99e/976722e37ad07d0c

 

Loads of annoyed people out there having the same type of problem. The general recommendation was to move to a high replication datastore (rather than master/slave), this move is not always simple however and I believe will incur higher costs!

 

To cut a long story short, our app was dead in the water so we had no choice other than to migrate it to a high replication datastore and hope that this fixed the problem (and hope that the migration didn’t create too many new problems). Once we carried out the migration the DeadlineExceededError excpetions went away, so that was good but we were a bit peeved that our hand was forced in such a way.

 

So I don’t know what google changed but it seems that they want people on high replication or else! Once again we find ourselves seriously questioning whether google app engine is a sutibaly stable platform for deploying real-world apps – the jury is still out…

 

Anyway if you find yourselves with the same problem they you may be headed the HRD way!

 

Drupal 7 – Undefined variable: output in drupal_var_export() in dvm()

If you get the following error when using devel’s dvm() in drupal 7 (or indeed, if you see it when not using dvm()):

 


Notice: Undefined variable: output in drupal_var_export()

Then try putting this line into you settings.php file:

 


ini_set('error_reporting', 'E_ALL ^ E_NOTICE');

 

It worked for us – thanks to citytree for the fix!

 

Drupal 7 – Programatically setting Link field value

The method for Programmatically setting a link field value (see the Link module) in drupal 7 is slightly different from how it was set it in drupal 6. Here is some code for creating a new node and setting its link field (called field_url):

 


$node = new stdClass();
$node->type = 'website';
node_object_prepare($node);

$node->title = $site_name;
$node->language = LANGUAGE_NONE;

$node->field_url[$node->language][0]['title'] = "ridgesolutions.ie";
$node->field_url[$node->language][0]['url'] = "ridgesolutions.ie";

node_submit($node);
node_save($node);

 

Drupal 7 – Programmatically creating nodes

Here’s a decent article that I found about programmatically creating content in drupal 7:

 

www.group42.ca/creating_and_updating_nodes_programmatically_in_drupal_7

 

Dries on Drupal 8

Here is an interesting article about Dries’ vision for Drupal 8:

 

http://www.cio.com.au/article/411440/dries_vision_drupal_8/

 

I like the focus on the editorial experience to help people mange content on-line, drupal is great CMS but it can sometimes be quite difficult for non webbies & techies to effectively manage the content on their drupal websites – in fact this really could have been given more attention in d7 (oh well)!

 

What is also interesting is the recognition that drupal has become more of a web platform than just a CMS alone – that’s how we use it!

 

Microsoft to take over Nokia? – what would Jim Hacker say?

Recent denials by Nokia that they are about to be taken over by Microsoft brings this line from Yes Minster to my mind:

 

James Hacker: First rule in politics: never believe anything until it’s officially denied.

 

;)

 

Using OpenCV from .NET C++/CLI

I am happy to report that I have had a reasonably easy run of using OpenCV from a .NET C++/CLI project, I was initially worried that the two might not play well together, but so far – so good! I am wrapping some machine vision code that uses OpenCV in a C++/CLI assembly so that I can call it from C# code. I have kept the rather creepy CLI stuff to a minimum it just implements the interface, everything else is vanilla C++ using the standard library.

 

The only thing I had to do to get rid of build errors was to make sure that each _proper_ C++ file in the project had the following value for the ‘Common Language RunTime Support’ build setting -> ‘No Common Language RunTime Support’!

 

So if you are toying with the idea of developing some OpenCV based software from within C++/CLI, I say give it twirl it makes interacting with .NET much easier than (say) using COM or similar!

 

Google Cloud – App Engine SDK v1.6.1 Released

Just catching up with things after Christmas, one thing that escaped my notice in December was that Google released version 1.6.1 of their Cloud App Engine SDK on 13th. of December. There’s not a huge amount of interest really in this release, but two items did catch my eye:

 

You can now select how much CPU power and memory is available for your fronted instances, you can select this from a small set of presets in the app dashboard – however google warns that selecting a higher preset will incur extra cost! We sometimes run into soft memory limit problems on our frontends so this may be of great use to us, but I do worry about the $$ !

 

Google have also released a new experimental document conversion API which they say contains OCR functionality – I look forward to testing this and will be very interested to see how well the OCR preforms as it can be a very tricky thing to get right! I suppose that this is an API to the same OCR functionality that they have in google docs….

 

Oh and they have added an API for programmatically reading the application logs, this may come in handy for automated testing!

 

More details about the release can be found here:

 

http://googleappengine.blogspot.com/2011/12/app-engine-161-released.html

 

Realex & Magento – New Return URL for Payments Module v2.0

If you are hooking magento up to realex for payment on your eCommerce website then you will most likely be using the payments module kindly provided by StudioForty9 in Cork.

 

As part of configuring this you will need to tell realex what your cart’s ‘return URL’ is, this URL has changed since the introduction of the newer version of this module (v2.0) which it seems is for use with magneto v1.5 and greater. The new URL format for use with the newer module is:

 

http://www.yourdomain.com/realex/response/

 

In case you are still using the old module, the url format for that is:

 

http://www.yourdomain.com/Realex/standard/success