To date this year, I have inherited several Magento stores to perform web updates on. I thought I’d write a small post on my experience and thoughts in using the system and how that system translates to real world, non technical clients.
As a bit of background, I’m by no means a fully fledged Magento developer in the least. After a few hours of experimenting I managed to get a template based upon my design, up and running.
It’s common knowledge that Magento is touted as the best thing since sliced bread – you constantly see companies selling the (what I call), “Magento experience”. Sales based pitches such as “you’ll never need to upgrade again”, “Magento can do everything out of the box” and “Magento will infinitely scale with your business” are very common from web companies. The latter does not apply to all businesses in my experience. To illustrate, I’ll use the example of a client who came to me in despair at their current web company and Magento based website – I won’t be using any real names.
By default, when installing CodeIgniter (CI), all the important files i.e. all files withing the application and systems folders are installed within the main web directory, that is visible to anyone. This is fine to an extent because all folders have a htaccess file that denys all incoming requests. The CodeIgniter developers did this intentionally to make things easy for people trying the framework out.
However, a much more secure method is to store the application and systems folders within the server webroot. This location is not directly accessible and helps with all around application security. Personally, I feel a lot safer knowing core files are not directly accessible. The latter is doubly as important when using a well known PHP framework, as anyone has a starting point to figure out your folder structure, simply by downloading the framework.
Here is how a typical CodeIgniter install looks on a production server:
In previous posts full page, block level caching with pear cache lite have been discussed. Full page level caching is fine under a lot of conditions. However, sometimes it is desirable to cache the contents of an array to a file. PEAR Cache Lite makes this very easy.
The array used in the following example is for illustration only and very basic. On a real site the array may be the result of several database queries, or even a recursive function to display the full category structure on a website E.g. something a lot more database intensive and costly than a simple array!
The setup using PEAR Cache Lite is exactly the same, the only difference is within the constructor. There is an option called ‘automaticSerialization’ (set to false by default) that enables the caching of none string data E.g. arrays. It is possible to achieve what following by using PHP’s serialize and unserialze functions, but it’s preferable and neater to use what functionality the author of the PEAR Cache Lite class has provided. The code is very simple.
Firstly, include the PEAR Cache Lite class and pass the associative array of options (including the automaticSerialization key) to the class constructor (line highlighted):
Read more …
Sometimes, you have small experiences that really make you appreciate your chosen web host. They leave you glad you spent the time doing your homework, testing out their support, features and generally ensuring everything is easy as possible with them. If it isn’t easy, then your job will be made all that much harder, unnecessarily.
I experienced such a feeling last week with a client who wanted to use their own web hosting. I had updated a small website to include a blog and gallery, both updateable by the client. This wouldn’t usually be an issue at all if using my own hosting – simply upload the files, add in my custom htaccess file for some mod rewriting goodness and away we go.
However, the host in question was 1and1.co.uk. Now, I’ve read some absolute horror stories about this company in the past – all such experiences seem very typical of a very large company, with their support teams based offshore.
So, back onto uploading the updated site in question. I had expressed initial concerns about the clients current 1and1 hosting package, noting that they’d most likely need to upgrade with 1and1, even though they were on an intermediate hosting package entitled the “1and1 Standard package”. I had also personally been forced to use their support about a year ago, which was hard work to say the least. Moving forward, I carried on and uploaded the site to 1and1′s servers and then visited site. Instant internal server error 500. Straight away I knew this was the hosting as I had previously given the client a link to a staging area on my preferred web host, that worked flawlessly. I’m aware 1and1 have some restrictive hosting on their basic packages (which seems to be inherant of such a large company, with thousands of customers in my experience), so I immediately headed towards to the .htaccess file (it’s essentially a variation of the HTML5 Bolierplate template with some of my own magic included, nothing out of the ordinary though) and renamed the htaccess file. Whallah – the site loaded, thus isolating the issue straight away. Great, I can inform 1and1 and find out what htaccess directives are allowed, it should be a run of the mill support request for any support department.
At the start of the year I wrote a custom invoicing system for a client, using PHP and Smarty (hope to convert to use Twig at some point). The client has since come back to me to built in extra functionality – namely a reporting section. I thought I’d share my solution to the issue I was faced with.
The client required some fairly involved reporting facilities, here is a sample of some of the requirements from the client:
- Aggregated report, split between two dates of our choosing, with totals split by either month, day or week (we want to choose)
- A list of invoices for a day of our choosing with aggregated totals of for the day selected
- Annual invoicing report – we want to show a summary of the total for the items sold, the total vat charged and summaries for average invoice values
- Invoices totals grouped by customer
There were several more, but they were all similar to the above.
Firstly, I’ll explain the database setup, for the invoicing, of the current system I built. It was basically two tables – one for the invoivce header and one table for the invoices items – nothing un typical there at all.
Content source ordering or SOC (source ordered content) is the idea that content nearer the top of the raw HTML source code has greater weight and meaning for search engines. For instance, a paragraph of text right at the top of the HTML source has more meaning than the same passage that may appear in the footer. It is very useful for those all too common generic menus (home, about, contact etc.) that has no SEO benefit at all, yet appears at the top of every page of your site. With SOC and absolute positioning of DOM elements, it is possible to position this HTML at the very bottom of the source code, thus gicing greater weight to your page content.
The latter is not a new idea by any means, but is generally considored to be a positive practice to implement on any site.
Yesterday I was doing a tiny bit of web realted freelancing for a friend – simply involving doing a bulk, conditional update of his entire stock for his ecommerce website. The site itself was simple in design and used PayPal with a sprinkle of IPN. So, after a bit of MySQL magic, I updated all of his prices, for all ~700 products in one fell swoop – all good so far, easy money.
However, after an hour or so of emailing the store owner I got a very worried phone call. In short, the bulk price update to had caused all archived order invoices to become incorrect. Why – due to bad database design by the original developer, let me explain.
Recently, I’ve completed a fairly large project that involved an invoicing system and electronic time cards. As the system was based in house, I decided to make extensive use of JQuery UI. After taking some time to reflect on this I decided to show JQuery UI some love and write a short list of reasons whyit totally rocks, as it made my life as a developer a lot easier. Yes, it is overkill importing the whole Jquery UI library and using a single, none essential widget, on a one page smaller site. However, when you have a medium sized system, that requires a large range of interactions, there really isn’t anything else I’d rather use, personally.
The Range of Widgets Available
Firstly, I made use of nearly all the widgets available – this resulted in the final system being highly interactive and useable. For instance, having the ability to sort items simply via dragging and dropping when down extrememley well on the useability front with users. JQuery UI made it very easy to save these sorted positions to my database. Having to write something like this from scratch would have been impossible (for me anyway ) and been very time consuming.The dashboard/portal area was another area, where the requyirement to personalise the location of various content boxes was made easy.
The use of mod_rewrite to create SEO friendly URLs is common place now. However, if an application is not coded correctly they can have potentially negative effects.
Take the fowllowing URL, this is the URL the developer intended – the news story is fetched from the ID in the querystring:
Sometimes, it’s very useful and a lot cleaner to store the result of an AJAX request into a variable – that can used in your script. For instance, say you’re using some sort of calander plugin that takes an array of exluded dates. It is highly likely that these dates will come from an database. You could echo them out manually by mixing PHP, HTML and JQuery, but this is very messy.
Instead, you could create an AJAX request that queries a database for the dates and stores them in a variable. This is fairly simply when using JQuery: