Commentary and insight on web development and the Internet at large written with a wry smile and a hungry look.
sorting carriers in Prestashop - Mon Oct 10, 2011
Prestashop 1.4 has some very customization friendly features. In particular the new concept of class overrides adds an immense amount of flexibility to the system without compromising the integrity of the core codebase.
As of this writing, Prestashop does not sort shipping carriers before displaying them to the customer . . . they will show up in the order they have been added to the system which may not be ideal. Changing this behaviour used to mean modifying core files but thanks to the override system, this is now possible without breaking upgradeability.
The following override class changes the default behaviour to instead sort the carriers by ascending price. To use it, save the file as "/overrides/classes/Carrier.php" in the root folder of your Prestashop install.
<?php
class Carrier extends CarrierCore
{
public static function getCarriersForOrder($id_zone, $groups = NULL)
{
$carriers=array();
$result=parent::getCarriersForOrder($id_zone, $groups);
if($result)
{
if(count($result)>0)
{
$sort=array();
foreach($result AS $k=>$v)
{
$sort['_'.$k]=$v['price'];
}
asort($sort,SORT_NUMERIC);
foreach(array_keys($sort) AS $k)
{
$carriers[]=$result[(substr($k,1))];
}
}
}
return $carriers;
}
}
?>
topics: PHP, Prestashop
CMS Made Simple - a web developer's review - Wed Feb 16, 2011
When starting on a new project one of the choices to be made is whether to start from scratch or to go with an existing platform. Starting from scratch means more flexibility but this comes at the expense of requiring more development time. These days I will almost always try to find an existing solution that can be extended so that the client's budget can be spent on customization instead of on re-inventing the wheel. For content management, the recursively named CMS Made Simple is one such option.
When working with a CMS I feel that the single most important criteria is the difficulty of integrating a client's design within the CMS's framework. Many CMS systems fail this requirement right from the get go by either embedding layout into difficult to work with PHP functions (commonly seen with legacy table based layouts) or using a confusingly laid out and / or poorly documented MVC approach (which leads to head scratching situations of having no idea where the layout is coming from).
Note: this is not a knock against the MCV paradigm, just some unnecessarily convoluted implementations of it
The most common workflow is to start with a pure HTML / CSS mockup and then integrate that into the CMS. This means that at the very least any potential CMS application needs to provide:
While not the solution for all cases, CMS Made Simple is one of the most straight forward solutions I have come across. To start with, it nails my requirements for true template support and a straight forward rendering pipeline. Template support is handled via the competent 3rd party library Smarty. Smarty is well documented and by using its built in "{debug}" command, it is for the most part trivial to reverse engineer what is available to the template at rendering time. Smarty also covers all common escaping and conditional layout flow without having to resort to inline PHP.
Within CMS Made Simple, Smarty's built in functionality is extended via a "custom tag" mechanism. Custom tags are a way of creating special use logic which can then be referenced within templates without having to rely on gross and kludgy inline PHP or hacking in new functions to the codebase itself. An example would be a custom tag I created for a client which sets up an array of PDF filenames pulled from an arbitrary directory on the web host based on the page alias of the current CMS document. This mechanism is very handy as it allows for quick and re-usable extension of site functionality without having to delve too far into codebase's internals or modifying core files.
The rendering flow in CMS Made Simple is also reasonably obvious and flat:
template -> page
At the top level you have templates and style sheets. Each template can have one or more style sheets associated with it and can via Smarty tags can also include sub-templates and / or other dynamic content. Templates will normally include one or more "{content}" placeholders which represent editable sections of layout under the user's control (there are other placeholders that provide similar functions for images and other content types). Once a template has been setup and associated with any desired CSS files, the next step is to create a "page".
A page represents an accessible spot on your website, most commonly a page containing content ("About us" or "Our Homepage"). Each page will have a spot in the global menu hierarchy and will have a template associated with it. The template dictates what the editing process looks like - you might have multiple content sections for example or your template may call in an external module (a web calendar for example). It is fairly simple for the designer to create a relatively safe environment for the client to be able to edit content without completely messing up unrelated layout. Since the stacking of the layout generation is relatively flat, it is also quick to get from mockup to finished page and easy to track down the source of any problems encountered.
For the basic requirement of creating a website which a client can update themselves relatively safely, CMS Made Simple does exactly what its name claims. So far I have yet to find a comparable codebase that is as easy to work with. For more advanced functionality however the situation is a bit murkier.
How CMS Made Simple deals with anything outside of the core functionality is via modules. If you want to do anything beyond basic content management (static pages) or posting date based articles (news), you will need to use a 3rd party module. For example, the stock system provides a permissions based account system designed around content control which is not intended for public facing functions like adding comments to articles. If you want to setup a blog with CMS Made Simple, you will need to use 3rd party modules to implement everything beyond the basic date based article listing.
On the plus side, there are a wide range of modules available from the platform ranging from "front end users" (unprivileged accounts which can be used for allow comments on articles) to an event calendar to image galleries. On the negative side, this means that some functions that one might consider central to a CMS are not part of the core codebase. The most significant fallout from this design decision is that the modules are not guaranteed to work with future updates and also vary in quality and integration. Personally I see this offloading of maintenance to module developers a significant limitation of CMS Made Simple which reduces its viability for use with community centric websites.
It should also be noted that CMS Made Simple has fairly light server requirements. Unlike huge sprawling systems like Movable Type, CMS Made Simple should function fine on the majority of LAMP web hosts.
I have looked around a fair bit and there are surprisingly few current codebases out there which meet my primary requirement of straight forward templates. One possible alternative is Concrete5. Concrete5's approach to design is to use an inline AJAX heavy editor which allows the user to modify content by browsing the site the same way any regular web user would. It does have a reasonably flexible template system though the granularity is definitely increased and some may find it overly convoluted to get from mockup to usable template. On the plus side it is less dependent on modules for what is arguably core functionality these days. On the negative side, the inline editing scheme can be complex at times and may simply be too time consuming to use in some environments.
While not a content management system, for e-commerce focussed sites Prestashop does include rudimentary CMS function which may be enough to suffice if the majority of your site is dedicated to store functionality. It also uses Smarty as its template engine and is comparatively easy to theme. The codebase is current, actively updated and in general well written and easy to follow.
I have spent about 30 hours working with CMS Made Simple and so far have been able to solve any issues I have come across. It will not be ideal for all situations but for simpler cases where a client needs to manage content on an informational website it is definitely worth a look.
topics: CMS Made Simple, content management system, PHP
MonerisHPP payment module for Prestashop (Canada only) - Fri Sep 03, 2010
For those looking for a potential shopping cart Prestashop is a cleanly written and actively supported codebase which is a compelling alternative to the other FOSS cart options. From this programmer's point of view it is the nicest internally and generally much easier to modify than other aging systems like osCommerce or Zen-Cart. However, being newer and originating from Europe means that Canadian merchant processors like Moneris are not supported out of the box either as a free or paid module.
To help with this situation I am making available the Moneris HPP (Hosted PayPage) module that I have written. This module allows shops to accept of payments using Merchant Processor Moneris' "Hosted PayPage" service. This module has been confirmed to work with Moneris Canada. The module is available free of charge but donations are also welcome if you feel like the module has helped you out.
Please note that this module DOES NOT WORK WITH THE US MONERIS service. For whatever silly reason, the US Moneris uses a different API which is similar functionally but requires different variables and only supports a single return URL. If you would like me to write a payment module for the US service, drop me a note for a quote.
The module also will work with Prestashop 1.4 if you add an include for "init.php" to the top of "order-confirmation.php". Remove the two existing include lines and replace them with:
require(dirname(__FILE__).'/../../config/config.inc.php');
require (_PS_ROOT_DIR_.'/init.php');
require(dirname(__FILE__).'/monerishpp.php');
If you require support or want assistance with integration then my normal consultation rates apply (contact me for a quote).
Download Moneris HPP Payment Module For Prestashop (tested with Prestashop 1.3.1)
As an aside, this module has also been submitted to the Prestastore site but as the approval process is taking inordinately long, I am posting locally here in case anyone needs to get a Moneris site rolling and cannot wait.
topics: demo reel, payment module, PHP, Prestashop, programming
jargon wars: URI versus URL - Wed Sep 16, 2009
Sometimes reference documentation can do more to confuse than to help. Take the terms "URI" ("Uniform Resource Indicator") and "URL" ("Uniform Resource Locator"). You will often see these acronyms tossed around like they are radically different beasts and this can lead to confusion when sorting out what the authors intent is.
For those just wanting the quick answer, a URL is just a specific type of URI. They are not different things. Now for the long answer. . .
Back in ye olde days of the early World Wide Web there was a different view of how web pages (and other services) were going to be found. A URI represented the entire heirarchy of methods for finding resources and these were broken into 3 discrete types (with the option to add more later). The 3 types were URL, URN and URC (with the latter "Universal Resource Characteristic" never gaining common use). URLs were to be the addresses that machines would use to locate services and then there were URNs ("Universal Resource Name") which humans would use to find these services. The intent was that humans would never see URLs at all and much like how DNS maps human readable host names like "codegrunt.com" to numerical IP addresses, browsers would hide URLs behind more readable URNs using some external service to do the conversion between then.
Well, this approach never really took off as people (and programmers) started using URLs directly. While URNs still have a place in modern infrastructure, they are no longer thought of as a discrete type of URI. The W3C covers this pretty well:
URIs, URLs, and URNs: Clarifications and Recommendations 1.0
. . . according to the contemporary view, the term "URL" does not refer to a formal partition of URI space; rather, URL is a useful but informal concept: a URL is a type of URI that identifies a resource via a representation of its primary access mechanism (e.g., its network "location"), rather than by some other attributes it may have. Thus as we noted, "http:" is a URI scheme. An http URI is a URL. The phrase "URL scheme" is now used infrequently, usually to refer to some subclass of URI schemes which exclude URNs.
Unfortunately, even documentation writers do not always get the distinction fully right which does not help with the confusion of this issue:
PHP Documentation: parse_url()
Note: This function is intended specifically for the purpose of parsing URLs and not URIs. However, to comply with PHP's backwards compatibility requirements it makes an exception for the file:// scheme where triple slashes (file:///...) are allowed. For any other scheme this is invalid.
The above note suggests that URIs and URLs are not the same thing which is not true. What they should be saying is:
Note: This function is intended specifically for the purpose of parsing URI schemes "http" and for backwards compatibility reasons, "ftp".
Ah, jargon. How I hate love you.
simple MySQL handler class - Mon Aug 31, 2009
MySQL has come a long way since its early days what with stored query support and such. That said, the usage you will find in the average web application is still going to be limited to basic INSERT, UPDATE and SELECT queries. While there are no shortage of MySQL abstraction classes, all of the ones I have come across tend to either add too much overhead or do not really make the process of retrieving data from the backend any quicker or easier. Thus the creation of this MySQL handler class.
The intent with this class is not to be pretty or completist. It's goal is to provide the core functions needed for the average web application while keeping it simple. Query results are returned as multidimensional array using associative column names. It offers a few "magic" values by default ("insert_id" and "numrows") and has some utility functions thrown in for dealing with the result set.
I do not claim this is the most beautiful MySQL class out there. I can say however that it makes life a lot easier in many situations compared to either dealing with the database directly or using a full scale database abstraction layer.
topics: MySQL, PHP, programming
Experienced PHP web developer.
$35 an hour, no job too small.
There is no replacement for integrity and experience.