1. Home
  2. Prices
  3. Guided Tour
  4. New Shop
  5. Shop Review
  6. Ecommerce Marketing
  7. Ecommerce TV
  8. Magento Developers
  9. Portfolio
  10. Blog
  11. Contact

Author Profile

Author Archive

Sagepay Server Change, Protx and Magento

Posted on: 2nd Sep 2010 By: Luci Smethurst No Comments

Occasionally, the folks at Varien are just a step behind the folks at places like Sagepay. When this happens, clients tend to get a little stressed – especially when they receive emails saying that servers are being changed and so their payment method needs to be updated. But don’t worry – the folks at the ecommerce web design are here to help!

This latest misstep is between Sagepay and Magento. The Sagepay payment servers are going to be moving at the end of September, so they’ve been very nicely letting their customers know that their modules need updating – and with plenty of notice, which I (for one) certainly appreciated!

At the time of writing, I couldn’t find an update for the Protx module for Sagepay built in to Magento 1.4.1. So, we updated it ourselves and decided to post it here on our Magento blog to help anybody else in a panic.

Find the file located at: App / Code / Core / Mage / Protx / Model / Standard.php

Then create a local copy (App / Code / Local / Mage / Protx / Model / Standard.php) and open it up in your favourite text editor (mine’s Dreamweaver CS5).

At about line 78 there’s a function called “getProtxUrl”. Presuming your site set to either Live or Test, change the respective URLs to

https://live.sagepay.com/gateway/service/vspform-register.vsp

and

https://test.sagepay.com/gateway/service/vspform-register.vsp

A quick note – this is for clients using the Sagepay Form method and Magento. If you’re signed up for the Sagepay Server method and are using the Protx Magento module, the links will be

https://live.sagepay.com/gateway/service/vspserver-register.vsp

and

https://test.sagepay.com/gateway/service/vspserver-register.vsp

Also – check out Rob and I in the new video from Creare!

Categories: Magento Tips Tags: ,

Magento URL Rewrites on a Windows Server

Posted on: 25th Aug 2010 By: Luci Smethurst No Comments

For the record, I don’t recommend running Magento on a Windows server – I have nothing against IIS, but Magento was really built for Linux servers. Things like URL rewrites become needlessly difficult when they could be as simple as changing a dropdown box in the backend to “Yes”…

However, if you or a client is running Magento on a Windows server – and there is no option to transfer to Linux – and you would like to get your URL rewrites working, would like to set the default page to index.php, remove index.php from URLs and get the site redirecting from non-www to www and from index.php to the root then todays post on the Magento blog is for you!

First – and this is required – you must get in contact with whoever is looking after of your server. You need to have a URL Rewrite Module like Helicon installed.

Next is your web.config file – it works similar to a .htaccess, except that a Magento website on a Windows server will definitly listen to it.

  1. Create a new file in your favourite text/html editor. Anything from Notepad to Dreamweaver will do.
  2. Save your file as web.config.
  3. Enter the code below:
<configuration>

<system.webServer>

<defaultDocument>
<files>
<add value="index.php" />
</files>
</defaultDocument>

<rewrite>
<rules>
<rule name="Redirect domain.co.uk to www.domain.co.uk" patternSyntax="Wildcard" stopProcessing="true">
<match url="*" />
<conditions>
<add input="{HTTP_HOST}" pattern="domain.co.uk" />
</conditions>
<action type="Redirect" url="http://www.domain.co.uk/{R:0}" />
</rule>

<rule name="redirect to root">
<match url="^index\.php$" ignoreCase="false" />
<conditions>
<add input="{QUERY_STRING}" pattern="^$" ignoreCase="false" />
</conditions>
<action type="Redirect" redirectType="Permanent" url="http://www.domain.co.uk/" />
</rule>

<rule name="Remove index.php from URLs" stopProcessing="true">
<match url=".*" ignoreCase="false" />
<conditions>
<add input="{URL}" pattern="^/(media|skin|js)/" ignoreCase="false" negate="true" />
<add input="{REQUEST_FILENAME}" matchType="IsFile" ignoreCase="false" negate="true" />
<add input="{REQUEST_FILENAME}" matchType="IsDirectory" ignoreCase="false" negate="true" />
</conditions>
<action type="Rewrite" url="index.php" />
</rule>
</rules>
</rewrite>

</system.webServer>

</configuration>

Now, I’ll try and explain everything you can see here – it looks a feels a lot like XML. To begin with you open up configuration and system.webServer tag’s, which tells a Windows server that you’re editing the configuration, and the the latter applies specifically to IIS7.

<defaultDocument>

The defaultDocument specifies the default page to load should no page be specified. In this case index.php will load.

<rewrite>, <rules>

The rewrite and rules elements are quite self explanatory – all child single rules within this are related to rewriting URLs.

Non-www to www

You can name each of your rules to make the code more user friendly by using the name=”" area, and then again patternSyntax and stopProcessing are self explanatory. Having an asterisk withing the <match url=”"> catches all the URLs and then <conditions> specifies the conditions of the rule – ie the domain you want it to apply to.

<action> then specifies what you want to happen next – in this case “Redirect” under type=”" and your domain (with www.) in url=”". You can also specify a redirectType – I’ve chosen Permanent here.

Redirect to Root (remove index.php)

<match> URL here should be set to the default file name that you would like removing – in Magento’s case this would be index.php. For example if users navigate to www.domain.co.uk/index.php, with this rule in place they would automatically redirect to www.domain.co.uk. Again you set <conditions> and then an <action> – again a Permanent Redirect and the destination URL.

Remove index.php from URLs

A common problem when you turn on URL rewrites in Magento that’s running on a Windows server is that your URL rewrites happen – but the links are broken. A little annoying. This rule fixes this issue!

<match> should be set to all URLs after “.” and then <conditions> sets what you want it to apply to. <action type=”"> is this time set to Rewrite (rather than redirect – that’s already happening) and the url should be set to index.php.

Then hey presto! A working Magento site (hopefully) – URL writes and all, which is a must really if you are interested in magento seo. Thanks for visiting our blog at ecommerce web design!

Product Images Not Showing After Import

Posted on: 17th Aug 2010 By: Luci Smethurst No Comments

If you’ve tried to import images into magento at the same time as your products using the ‘Import Products’ profile, you may have come across a few errors. Whilst trying to import multiple products sing Magento’s ‘Import Products’ profile, I recently ran into one problem after another – though the products imported just fine, my images were either mysteriously absent, or mysteriously broken.

One of the initial problems is that the export profile puts a path in front of the image names, which is incorrect for new products. So if you’re importing products from another store, you’ll need to edit the image paths first. Exported products with images, when exported, with have image paths like this:

/i/m/imagefile01.gif

However, when importing multiple products with images, the csv needs to be directed to the media/import folder – this can be done with a simple, single forward slash:

/imagefile01.gif

Now, make sure all the product images you want to import are uploaded to: media/import and that the file permissions are set to 757 for the media directory & all files/subdirectories.

The next issue I had was that, even when the filepaths were correct, all of the image links were broken and set to ‘Exclude’. To fix this and get your image import working, simply do the following:

Create a local copy of:

app/code/core/Mage/Catalog/Model/Convert/Adapter/Product.php

Find

foreach ($imageData as $file => $fields) {
try {
$product->addImageToMediaGallery(Mage::getBaseDir('media') . DS . 'import' . $file, $fields);
}
catch (Exception $e) {}

and replace with

foreach ($imageData as $file => $fields) {
try {
$product->addImageToMediaGallery(Mage::getBaseDir('media') . DS . 'import' . $file, $fields,
true,         /* defaults to false - tells Magento whether to move the file or not */
false);         /* defaults to true - tells Magento whether to exlclude the file or not */
}
catch (Exception $e) {}

I hope this helps you with your importing product images issues – thanks for reading our Magento blog at Ecommerce web design!

Upgrade Magento to 1.4.1: Part Two

Posted on: 14th Aug 2010 By: Luci Smethurst No Comments

In conclusion to my earlier post on Ecommerce Web Design, and now the dramatics are over and the chapter is closed: how to get it all working again.
When we left our poor, slightly upgraded website we had a blank frontend, and so, to the third and final lesson I learned from the recent (attempted) upgrade:

Lesson Three:

For some rhyme or reason, importing what is supposed to be an upgraded 1.3 database into a new 1.4.1 installation (with it’s own clean database) just doesn’t work: Bad Things happen when importing an older database into a clean and empty new database -as soon as the cache is cleared, the entire thing collapses – after three attempts, the upgrade was abandoned.

In the end, I argued that upgrading from 1.3.anything will mean getting a new version of your theme or a new theme altogether anyway as you cannot use a 1.3.something theme on a 1.4.something Magento installation – Bad Things will happen, maybe not straight away – but they will happen. Checkouts break, payment methods fail and emails fail to send (to say the least).

In order to make it as painless as possible, I documented the process – the only thing that is a pain to loose on live shops is the order history, which I hope to one day discover how to export.

  1. Export your customers and products csv’s from your current installation
  2. Download your media folder
  3. Purchase a test domain
  4. Set up a new database
  5. Install the latest Magento version on the new domain
  6. Theme your new magento 1.4.1
  7. Create your categories
  8. Edit the products csv from your previous installation – check your category id’s correlate with the new installation
  9. Edit the product images to just /imagename.jpg
  10. Move the images from /category/product in your media folder to /import
  11. Upload your products and customers csv files
  12. Upload your media folder
  13. Set up your payment and shipping methods

I hope this helps if any of you reading our Magento blog is planning an upgrade!

Upgrade Magento to 1.4(.1.1): Part One

Posted on: 4th Aug 2010 By: Luci Smethurst 3 Comments

This week at ecommerce web design, I’ve had the dreaded task of upgrading an existing, live Magento site to 1.4.1.1 – and not just any upgrade, it’s from 1.3.2.1. I don’t think I was envied in the office.

After much research, several discussions, and a deep breath, I began the process of backing up literally anything and everything and dived in.

Lesson One: Don’t upgrade using Magento Connect – in short, it didn’t work at all. It said successful, despite there being several errors. The backend loaded alright, but was still the original version but the frontend displayed nothing but a white, blank page.

Lesson Two: A solution that seems to work for many did not work, but that didn’t work in this case was to do as follows:

  1. Create a copy of your existing database, rename it to something different.
  2. Create a subdirectory in your domain, for example “dev”
  3. Go to the core_config_data table in your copied database and update the relevant URLs to your new subdirectory
  4. Put the Magento files onto the new subdirectory and run the installation – using the details for your copied database
  5. Sit, Wait, Hope

During this installation there were a few nail biting moments – including a couple of timeouts that led to a few SQL errors, but it actually seemed to go alright. The backend worked like a dream, running 1.4.1.1, retaining all the previous customer data, previous sales, searches, pages and so on. For a minute, I thought my Magento upgrade had worked, and indeed it had (kind of) – the database upgraded just fine!

Alas… all was not well on the front page – still nothing but a blank page. After a bit of debugging, we found that, for some reason, the last line of code was failing, with apparently no fix 4 hours in:

Mage::run($mageRunCode,$mageRunType);

Coming Next on our magento blog: How to get it all working again!