There’s a nice shiny, fully-working Magento site and it’s running like a dream.   The only thing is it’s in the wrong place - maybe on a development server or an old server that’s fast running out of space!  You need to get that site out of there and fast!!

While looking into this I found a couple of suggested solutions - and some of them, although I’ve no reason to doubt they work were a little drawn out.  Here’s what worked for us and you’ll be glad to hear it’s the short and sweet option…

Create an sql script of the original site’s database that contains both the structure and data

Add the following code to the START of the sql script…

SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT;
SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS;
SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION;
SET NAMES utf8;
SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0;
SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0;
SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='NO_AUTO_VALUE_ON_ZERO';
SET @OLD_SQL_NOTES=@@SQL_NOTES, SQL_NOTES=0;

Add the following to the END of the sql script…

SET SQL_MODE=@OLD_SQL_MODE;
SET FOREIGN_KEY_CHECKS=@OLD_FOREIGN_KEY_CHECKS;
SET UNIQUE_CHECKS=@OLD_UNIQUE_CHECKS;
SET CHARACTER_SET_CLIENT=@OLD_CHARACTER_SET_CLIENT;
SET CHARACTER_SET_RESULTS=@OLD_CHARACTER_SET_RESULTS;
SET COLLATION_CONNECTION=@OLD_COLLATION_CONNECTION;
SET SQL_NOTES=@OLD_SQL_NOTES;

The sql script is most likely to be several megabytes in size so zip it up into a zip-file - this will mean you can later use a tool like phpMyAdmin to import the script without hitting the 2 meg file size limit for file uploads.

Create the new domain and an empty database

Copy ALL the site’s file over to the new domain and ‘chown’ files as required

Make the following directories writable by the web server user:
- app/etc/
- var/
- media/

and for MagentoConnect:
- /<magento-path>/
- /<magento-path>/downloader
- /<magento-path>/downloader/config.ini
- /<magento-path>/downloader/pearlib/config.ini
- /<magento-path>/downloader/pearlib/pear.ini
- /<magento-path>/downloader/pearlib/php

If the database details have changed, update them in app/etc/local.xml

Run the (zipped) sql script on the new empty database

In the database table ‘core_config_data’ change the two record fields ‘/web/unsecure/base_url’ and ‘/web/secure/base_url’ to the new domain name if it has changed

Finally, delete the files in the following directories to manually clear the cache:

- /<magento-path>/downloader/pearlib/cache/*
- /<magento-path>/downloader/pearlib/download/*
- /<magento-path>/var/cache/*
- /<magento-path>/var/session/*
- /<magento-path>/var/report/*
- /<magento-path>/var/tmp/*

Although a slightly unusual situation, after a little digging around we found that it was quite easy to create the additional pages and integrate them into the website without the usual creation of a web project in Visual Studio.NET.  Instead each web page was created manually, here’s what was required:

For each web page create two files…

page.aspx.cs

Simply create a class that inherits from System.Web.UI.Page.  This will be the class that represents the web page.

namespace MyNamespace {

public partial class _Default : System.Web.UI.Page
{

}

}

page.aspx

Include the following directive at the top of the aspx page (assuming the aspx file uses a C# code behind file)

<% @ Page Language=”C#” CodeFile=”page.aspx.cs” Inherits=”MyNamespace._Default” Debug=”true” %>

There is a way to include required namespaces directly within aspx files - in the event that namespaces need to be imported within aspx files you can use the <%Import %> directive.

Example:

<%@ Import namespace=”Enter.Namespace.Here” %>

Along with a new-look, the website has been redesigned to be simpler and easier to navigate.

When you see the new site, any feedback and suggestions would be most welcome.

Admittedly, there was some initial head scratching while table records were examined and compared to try and identify any inconsistencies.  This revealed nothing and the JIT debugger could not be enabled as the exceptions were being raised in a windows form that had not been compiled to allow JIT debugging.

The next approach was to see if the SQL commands the client was executing could be intercepted.  Then, the thinking went, the commands could be compared to see what was going wrong and what was going right when exceptions were and were not raised.  As it turned out SQL Server provide a tool called a Profiler that offers this functionality but this is not provided with the version we were working with - SQL Server 2005 Workgroup Edition.  However we did find this open source Profiler with which the cause of the problems was identified.  Such profilers are more commonly used to monitor database server workloads.

Analysis of the requirements provided a list of features to search for in suitable solutions that would help the team better deal with requests and ensure its integration with the existing suite of systems and tools used.

Early in our analysis we realised that bug tracking tools such as bugzilla, trac and mantis were not suited to our needs.  Instead the two issue tracking systems short-listed to be evaluated are OTRS and Request Tracker (RT).  These systems will be further investigated and trialed in the coming weeks and findings in our specific application will be reported here.

When we visited a client that was using the event management platform we found that although they were using the exported data, this had led to a very time-consuming, repetitive process to regularly copy updated delegate data into their office database system.

The client was copying the data into an Excel spreadsheet, and knowing about Office macros we knew it would be possible to create a macro within Excel to automate the work they were currently spending a lot of time doing manually.

By writing a Visual Basic for Applications (VBA) macro it was possible to not only save them a lot of time (and save someone in the office from a very tedious task!) but also it eliminated the possibility of human-error and any possible typos with it.  As the macro runs within a matter of seconds the client can also take more regular exports from the website and synchronise office data more reguarly.

Microsoft Office macros are versatile enough to provide a solution to many of the repetitive and time-consuming tasks that arise when dealing with data in documents, spreadsheets and databases.  If you have any processes within the office that are repeated and time-consuming contact Logicia and we can look at them and suggest a more efficient alternative.