The Aliro CMS is, like all substantial CMS, a framework in its own right.   As its original author, I’m aware that it can be further developed, and one important area is to improve database abstraction.  There is also interesting work on this topic in the Drupal project and doubtless many other places too.  But the notion of “peer classes” troubled me, and in the PHP world it seems to be largely confined to Symfony and the database object mapping it uses, Propel.

My immediate concern is that peer classes seem to be the very same thing as helper classes, whose drawbacks I wrote about earlier.  Let’s outline the context for peer classes.  The general idea is to have a class that corresponds (in a way yet to be defined in detail) with a database table, so that the objects of that class are equivalent to rows in the table.   Classes of this kind derive a lot of their behaviour by subclassing a standard class provided by the framework (Symfony/Propel).  In addition, each database table is also given a “peer class” consisting of static methods.

The methods of the peer class do things like providing metadata about the table and creating sets of objects that are instances of the ordinary class to which the peer class is related.  Given all the drawbacks of classes that consist entirely of static methods, it seems worth reviewing how the peer classes can be fitted into an object model.

One relevant question is to ask which of the methods could equally well be made static methods of the main class instead of being in the peer class at all.  If PHP treated classes as first class objects, then we would regard “static” classes simply as being class methods.  It seems that methods to create sets of objects could, logically, be class methods.  They may also count as helper methods, which are, unlike helper classes, a perfectly legitimate element in an OO system.  There is a major drawback to generalizing this scheme too much, and that is the lack of inheritance of static methods.  Any static methods have to exist in the class for which they are invoked, so we cannot build them in a standard class and then inherit.

Other methods are to do with metadata.  Where the results are simple values, it might be acceptable for them to be static methods of the main class.  It could be regarded as reasonable for the class to know what fields are in the relevant table, and what are their properties.  But it doesn’t make good sense to include methods for manipulating metadata as static methods either in the main class or the peer class.  The simple fact that such methods could easily be generalized means that inheritance is highly desirable, and hence static methods are unsuitable.

This brings us to what ought to be a critical question in an OO system, which is to ask exactly what is being modelled by our classes.  Digressing for a moment, every member (so far as I know) of the Mambo family has a standard class that can be subclassed to create objects, each of which corresponds to a row in a database table.  The standard class was originally named mosDBTable, giving the impression that the class is a model of a database table.

This seems to me a mistake.  The objects of these classes, and of the database table classes in Propel and Symfony, model the rows of a table.  Collectively, the class models the contents of a table.  It does not, however, follow that this exhausts the properties and behaviours of a table.  An actual database table can be operated on in ways that go beyond what can be done by SQL operations on the set of rows.  Significantly, the metadata can be altered to add or subtract fields, or change their properties.  It is not a good idea to build such operations as PHP class methods, since these would be static and therefore not inheritable.  From this, it follows that given the object resources in PHP, it does not make sense for the class of table rows to be thought of as a complete model of a database table.

If we need a model of the table, seen as a whole and with its metadata handling behaviours, then we need another genuine (not full of static methods) class, in addition to the class whose objects correspond to rows.  An instance of the new class would model one database table, not one table row.

There is not actually such a class in Aliro (or any Mambo derived CMS that I know of), leading to another question.  Do we need a class to model database tables?

At the moment, my inclination is to answer “no”.  The reason for this is that I cannot see any interesting behaviours that need to belong to an object that models a table.  Certainly there are properties of a table, but that in itself does not justify anything more than a data structure; it is not enough to justify a class.  And, so far at least, it seems that the behaviours we need to manipulate tables can quite naturally fall within the scope of the object that models a database - in the sense of a specific collection of tables, not in the sense of a database system that is capable of managing multiple databases.

The database object can (and does in Aliro) hold data structures (cached) that detail the metadata relating to the tables in the database.  The methods of the database object are able to operate on that information, and change the database itself where appropriate.

Also, given that a pragmatic approach suggests that when we want to create sets of objects it is usually as a result of a single SQL operation (albeit possibly a complex one), then it also makes sense for methods to do exactly that should count as a behaviour of the database object.

I’m very interested to hear other views, either supporting or opposing what has been said here.  And where I’ve made mistakes, corrections are welcome!

semantic markup is intended to clarify the meaning of the document

To recap the basic principle, semantic markup means approaching HTML (usually XHTML nowadays) on the principle that it should not contain anything that is not to do with the meaning of the document.  Indeed, semantic markup is intended to clarify the meaning of the document, by such simple devices as identifying headings, and clearly indicating their level.  By contrast, semantic markup avoids, for example, the use of tables for purely positioning purposes, as opposed to display something that just is best described as tabular data.

All well and good so far, and the HTML document should be pretty readable, however it is communicated to the reader, including methods used by people who are unable to access a standard browser.  Things being what they are, most web sites certainly will not stop there though.  Presentation has never been more important, given the huge variety of competing material that floods the Web.

Naturally semantic markup puts more weight on CSS, since it aims to eliminate use of HTML for positioning or styling.  The whole layout of the screen is likely to depend critically on the CSS, for example to position a series of <div /> elements alongside one another, rather than allowing the default of each one appearing further below its predecessor.

CSS is fulfilling two purposes now

This is where I start to see a problem.  Although it is difficult to confidently draw a dividing line, it is fairly clear that CSS is fulfilling two purposes now.  One is to create the page layout by manipulating elements and positioning them in relation to one another.  The other is the traditional CSS role of specifying stylistic elements such as choice of font, color of text, decoration of links and such like.

Why is this a problem?  Because when material is aggregated on a single site, for example as part of a CMS, the aim is normally to impose a site design on everything, and therefore much of the styling CSS is expected to belong to the site as a whole, and not to the various elements that are being aggregated.  On the other hand, the positioning CSS is specific to an element, and will not normally be part of the overall site CSS.

What is more, if material that is being aggregated into a site was not designed specifically for that purpose, but was instead meant to be able to function stand alone, it is unlikely that any thought has been given to this issue.  It is very likely that the material will have a single CSS file (it may have a few, but they may not be split between positioning and styling CSS).  Indeed efficiency experts advocate the use of the fewest possible number of HTTP requests to make up a web page and therefore advocate use of a single CSS file.

later CSS overrides earlier

Some relief from the problem is provided by the fact that later CSS overrides earlier.  So, provided the site’s styling CSS is placed later than the CSS for individual portions of the page, then the site styling will override the more specific styling applied to the included material.  But this is not a very robust solution, and is liable to founder on more complex markups such as CSS images used to create attractive headings, where techniques used at one level may react badly to being overriden with another, different scheme.

Issues of this kind are particularly messy where the CMS has a theming system so that individual site administrators can choose to replace the default theme with a choice of many others.  In this situation the CMS designer who is attempting to integrate a variety of HTML resources has very limited control over the environment.

Clearly, one solution would be the introduction of more standards, and possibly further refinements in the way CSS is written and incorporated into pages.  How much we can pin our hopes to developments of that kind is uncertain.  CSS developments are currently uncertain, and in many cases hotly disputed.  Creating good standards and persuading people to adopt them both look like substantial problems.

RESTful services

One route that looks appealing to me does involve rather more work than any scheme that simply incorporates CSS/HTML into a wider scheme, such as a CMS.  That is to convert stand alone systems into RESTful services so that they can be utilised by a variety of different clients that can cope with the vagaries of widely different environments.  But this clearly involves finding an API within the target system and turning it into RESTful services, preferably maintaing a Resource Oriented Approach.

For the moment, my position is that I can do little more than describe what I see as the problem.  Maybe answers will be forthcoming.  I’ll certainly be interested to see.

Why broaden the scope?  Simply because the term “helper” seems to be getting used more and more widely, and that is one of my objections to it.  It all started out with helper methods, and I’ll come back to those.  But now there are helper classes and I’ve also seen talk of helper functions.  They were defined as “a function that performs part of the computation of another function”.

terms that don’t mean anything are a liability

Maybe that gives a clue to a major objection.  “Helper” often doesn’t mean anything at all in many cases.  And terms that don’t mean anything are a liability when it comes to clear thinking about design.  Meaningless terms have a number of nasty effects.  They give you an unpleasant feeling of not having quite grasped what is going on, because you don’t understand what they are.  They make you think there ought to be something they have in common.  Also, they encourage people to believe they have given a description when really they have said nothing.  Stripping away meaningless words makes it clear that some better words are needed to explain what is going on.

Think about those helper functions.  They perform “part of the computation of another function”.  Well.  It’s been around for a long time, and top down design works by determining a top level function and relegating everything else to sub-functions.  On that basis, every function in a system except one performs a part of the computation.

It’s not as if we could decide which functions, classes or methods are helpers on account of them being helpful.  Where are we going to find unhelpful parts of the system?

So one part of the problem is that “helper” doesn’t convey any useful information.  But how did the terminology ever get started?  For that we need to go back to helper methods, and they will give us some ideas about why over generous use of “helper” is not only meaningless but also bad, “evil” maybe!

The goal has always been good design

There is a danger of getting the cart before the horse in discussing design techniques, such as object orientation.  The goal becomes to achieve a class hierarchy, or inheritance, or encapsulation.  All those things have virtues, but they aren’t themselves the goals we should be seeking.  The goal has always been good design - something that we can’t define except by its virtues when it is experienced.  Good design has clarity and economy of expression.  It is flexible and relates naturally to the problem that is being solved.

Of course the reason many of us are committed to the techniques of object orientation is that they have been shown time and time again to contribute to the desirable properties of a good design.  But the overarching objective of object orientation is to find a good object model exactly because it models the problem well.  If we achieve that, our design discussions are far more fruitful, the code can be related to the problem and provides an efficient working system.  It takes hard work to do that, but the goal is simply stated.

So if we accept those basic principles, then we want to find a way to break down the problem into cooperating classes with no residue.  Everything that goes on will ideally be a capability that we see evidently belongs to one of the objects within our problem.  Unfortunately, life is not always so obliging and helper methods started out as methods that were included in a class because, although they were not essential behaviours of the class, they were useful to other parts of the system in utilising the class.

There’s always room for debate about what is essential to a class and what is ancillary.  One example that might be classified as a helper method could be the abililty to produce a tidy display of the information contained in an object.  Displaying object properties is not essential to the behaviours that make the object model our problem, but is a useful facility for other classes to use.

Possibly validation methods might be seen as helper methods, when they are peripheral to the main responsibilities of an object.  But that seems a more arguable case, as the ability to validate inputs might be seen as an essential capability for an object.  Decisions need to be made on a case by case basis.

Extending “helper” to private methods … meaninglessness

On that definition of a helper method, it is obvious that it cannot be a private method, since the whole notion being advanced here is that a helper method provides additional assistance to other objects, over and above the core capabilities of the object.  Extending “helper” to private methods seems once again to be an example of descending into meaninglessness, where a method is a “helper” just because it is useful.  Surely we shouldn’t have any methods that are not useful!

Armed with a more palatable definition of what is to be counted as a helper method, it is easier to make the key criticism of the excessive use of “helper”.  It is that building systems with numerous helper methods, functions or classes is a failure to build a decent object model.  It is an attempt to cover up a lack of object orientation by the use of seemingly OO jargon.  And that is a bad thing to do, since there is so much to be gained by continuing design work until we have a good OO design and most of the helpers fall away.

Take another example of unnecessary helpers.  Some people have decided to write web related code starting with some kind of template, filling in the variable values by reference to a helper class.  This is usually the kind of helper class that is nothing but static methods, which means that it is not really a class at all, but merely a kind of namespace.  But why go this way when there is almost certainly a perfectly good object model that can be applied?

For a web application, we can assume that there is a dispatcher of some kind that fields the actual request and decides what needs to be done to fullfil it, possibly many things.  We can associate this situation with a classic principle, that of a controller.  In the web application environment, a controller may present an interface that is used to act upon information submitted by a site visitor; it may also present an interface that provides elements of the browser page that will be the response to the visitor.  It may also have other relationships within the web application.  And it will particularly have a relationship with the classes and objects that model the problem.

A controller… is well able to be a proper object

But we have no need of static methods for the most part.  A controller knows things (it has properties) and it knows how to do things (it has methods) and is well able to be a proper object.  The situation certainly does not seem to require us to have much if any residue left over from a genuine object design.  And, once again, it is worth saying that the aim is not an object design per se, but a good design that serves the purposes of a sound system.

Should static methods be anathema?  Often, the answer to that must be “yes”.  The real justification for a static method is that it is another name for a class method - it runs against the class rather than any particular instance of the class.  (The distinction between class and object becomes one of perspective in those subtle languages where classes are themselves first class objects).

The first questions to be asked about a static method is whether it is truly a class method, some behaviour that belongs to the whole class (such as knowing how many objects of the class are currently instantiated)?  If it is not, then what we really have is actually just a function.  If it is a function, then we need to ask the second question, which is whether there really is a need for an isolated function, or whether it is a defect in our object design and the “function” should really be a behaviour of some class.

I’d see it as really rather incidental, since it is rarely worth allowing efficiency considerations to overrule good design, but it so happens that PHP rewards us for avoiding static methods.  Instantiating an object and using its methods are nearly always faster in PHP than making references to static methods that are lumped together in a “helper class”.

It looks to me as if it would be no bad thing if the word “helper” were to largely disappear from the software development lexicon.  It does have a legitimate use, although maybe someone could coin a better expression for the true helper method.  “Helpers” sound such nice, friendly things that they seduce people into bad designs.  Really, though, it’s time they were put out to pasture.

Since I wrote the above, there have been some further developments. On 28 July 2008, Magazine City had stated “Your order was submitted to the publisher soon after you placed it on our website”. After further exchanges, on 2 September 2007 the following was received: “After researching your complaint I have learned that for some inexplicable reason, your order was not received by the publisher.” It was said that the order could now be processed or a refund given. I opted for a refund. Further emails prevaricated about when the refund would be made.

Despite assurances, my credit card statement dated 9 October 2008 still does not show any refund.

Shared hosting has been familiar for some time, and often resource limits on processing or memory have not been particularly apparent to the user of the service.  Lately, the use of a Virtual Private Server (VPS) has rapidly gained in popularity.  Prices have fallen dramatically, virtualization is trendy and there are some perceived advantages.  However, the available resources are rather more tightly controlled than in most shared hosting.  Although there are other considerations, my focus here is on questions of resource management in a VPS.

Before we go into the detailed issues, though, let us consider the gains to be made through use of a VPS.  One gain is said to be having root access to the server, or at least to the virtual server that is being rented.  This is obviously a mixed blessing.  It does mean that many aspects of the server can be tuned to suit the purpose for which it is being used, and the user of the VPS is free to make changes without considering anyone else.  The downside is that you need to know what you are doing in order to benefit from this, and a good number of people buying a VPS have little or no idea where to start.  Significant time and effort needs to be spent to see any gain.

Another gain, and the one that most attracted me, is that a VPS should be relatively protected from resource overloads caused by other people on the same server.  On the basis of my personal experience, this advantage is only partly realised.  The more extreme incidents where a server almost grinds to a halt, dragging down every site, seem to be avoided.  On the other hand, there are still significant variations in performance that appear to be caused by factors outside my own VPS.

Let me explain how I came face to face with some quite complex resource issues in VPS management.  My reseller account for shared hosting was working quite well, providing for both my own sites and a few client sites.  The provider was a US based host, which suited me quite well as US hosts seem to be able to provide good value for money as well as being a suitable location for material that is being delivered globally.  But the issue of performance troughs caused by other sites on the same server was irking me.  The host had apparently done quite a lot of work to improve SQL that was the cause of the problems, but there were still concerns.  So I started looking around.

After a few experiments with shared schemes, a VPS started to look attractive.  As I am based in the UK, it seemed worth looking to see if a European host could provide a good service.  Following a brief selection process, I signed up with a UK host for a managed VPS at the lowest level that was claimed by the host to be suitable for use with cpanel.  I wanted cpanel for the benefit of clients whose site hosting was my responsibility.

It was not long before I started to experience problems.  Services were repeatedly failing.  Contacting technical support resulted in little improvement, and claims that I was using too much memory.  It was suggested that a higher level of hosting plan was needed, involving higher cost.  This seemed to me unreasonable, since there were no active sites loaded at the time, and the VPS had yet to do any useful work.  This was the first indication that hosts were selling VPS packages that are inherently unstable.

The technical support was so negative that the simplest solution seemed to be to ditch the account and claim on the 30 day money back guarantee (it actually took 3 months and many complaints to get the money back!).  I talked to an American friend and decided to take my hosting to the US once more.  Oddly, the VPS chosen this time had a nominally lower memory specification, but it seemed to work somewhat better.  I had loaded up a number of sites and got them active before problems started.

But then the problems began again.  The whole VPS seemed to be down for significant periods, and I was told that too much memory was being used, and that a higher level of hosting plan was needed.  Sounds familiar?  I was still resistant to the suggestion, not only on grounds of cost, but also on principle.  If someone sells me something, I like it to do what it is claimed to do for the price offered.  It was time to start getting technical.

Let’s review the position.  Although I talked earlier about a VPS constraining resources, it turns out that there is usually only one critical resource that matters.  Memory.  Unless your sites are doing exceptionally heavy processing, or the server is grossly overloaded or under specified, then the server will have plenty of processing power to handle a reasonable VPS load.  Although hosting plans specify disk space limits, these are rapidly becoming academic.  Disk space is now so readily available that the host I am using has decided to make it free – if you run out, you simply have to ask for more (provided it is actually being used for hosting, not for something like an archive).  And most people can easily buy a plan that has ample bandwidth for their needs.  But for a VPS, memory is often a critical issue.

Now the obvious first step is to ask what tools are available for monitoring memory usage.  The short answer is that, for a VPS, practically none are normally supplied.  My host offered a script that would provide a spot figure for the memory currently in use.  In terms of analysing where the memory is being used, that is useless, and in the overall context of VPS memory management, it is of very limited use.  The only readily available way to break down memory use is to run the “top” utility that lists running processes and watch to see which processes have large memory use.

This is a hit and miss process, and could be greatly improved by a monitor that stored the breakdown between processes to produce averages and trends, I have not had time to write such a thing.  If anyone does create an open source program of that kind, please let me know!  There is an obvious need for easy to use tools in this area, given the large number of VPS plans being sold and the almost total availability of good memory monitoring tools.

To observe the general trends and to monitor any incidents, I have found the “loadavg” software from http://www.labradordata.ca/home/37 extremely valuable.  It provides graphs of incoming and outgoing traffic, server load, and also the key memory parameters.  The standard version generates quite a few warnings and notices, and I can offer a corrected version to anyone who needs it.

Although I cannot offer tools to analyse the situation,  I can offer some general conclusions from my own experiences.

Mail ought to place very little load on a server, but it can run away with a lot of memory, particularly for handling anti-virus and anti-spam processes.  Fortuitously, I had a solution for this.  All my mail handling had been moved to a different hosting provider, mainly to take advantage of a managed Postini anti-spam service.  It was cheaper and easier to buy the whole hosting service than to buy Postini accounts.  Simply moving the mail elsewhere did not reduce the load on my VPS, it was still consuming large amounts of memory.  After a fair amount of pressure on my host, and largely by making changes myself, the VPS configuration was modified to remove most of the mail load.  The only services left were those required to allow web sites to send mail.

After that, MySQL is likely to be a major user of memory.  There are many configuration variables available to control how MySQL operates, and in a VPS you have the freedom to tweak them to your heart’s content.  On the plus side, this can significantly improve performance, on the minus side you have to be careful about how much memory is consumed in the process.

There do seem to be considerable difficulties in carrying out effective MySQL tuning.  Please correct me if I am wrong, but my impression so far is that many utilities that purport to interpret the run time statistics from MySQL and make recommendations for improvement operate in much too simple a fashion.  It is easy enough to look at isolated aspects of database operation and suggest that some buffer should be larger.  However, the various mechanisms in MySQL interact with one another, and problems are not always as simple as they appear.  Nor do they really deal with the issue that extra memory is quite costly, and so the goal may not be simply maximising MySQL performance, but may instead be getting the best performance that can be achieved within memory constraints.

One service that I have not yet been able to control is the DNS, which is normally the BIND program, running as the process “named”.  Even when it has little data to manage, it seems that BIND allocates a substantial amount of memory.

But I haven’t explained what was meant earlier by saying that an off the shelf VPS is quite likely to be inherently unstable.  It took me a while to figure out how memory was controlled for a typical VPS that is running under Virtuozzo, so I will try to summarise it here to save others some trouble.

The terminology is pretty confusing, and in my experience, many technical support people at hosting companies do not properly understand the workings of memory controls.   Much VPS hosting is offered with two figures quoted for memory: a guaranteed level with a common basic figure of 256 Mb, and a burstable level, quite often 1024 Mb.  Few people seem clear what these numbers mean.

In a Linux system, there is a distinction between memory that has been allocated and memory that has actually been used.  The system tracks these separately, and Virtuozzo applies constraints to them in separate ways.  There are Virtuozzo configuration variables, and they are confusing because some of them simply have static constraints associated with them, and some of them also have a current value that measures the VPS use of memory.  And there are actually two distinct guarantees relating to memory, although they are often (and unreasonably) set to the same value.  Just to confuse matters further, all the Virtuozzo variables work in units of 4 Kb blocks, so you have to do some arithmetic to get megabytes.

Virtual (allocated memory, whether used or not) is measured by privvmpages.  This also has a barrier, and it is the barrier on virtual memory that is usually described as the burstable limit.  Normally, there is one barrier that will result in warning alerts being generated, and a slightly higher barrier that will always result in requests to allocate memory being refused.

Note that you are very unlikely to ever use memory to the burstable limit, since the level of allocated memory is normally substantially higher than the level of used memory.  The used memory is monitored by the Virtuozzo variable oomguarpages.  This is another confusing factor, since the primary function of oomguarpages is to carry a guarantee, but we will return to that in a moment.

If a server is provided with a lot of memory in relation to the number of installed VPS, then you could think about your own VPS simply in terms of allocated memory, which would be allowed to run up to the specified barrier, the warning level for which equates to the burstable memory quoted in sales material.  But to get good hardware utilization, hosts will not provide so much memory, and then the configuration of guarantees comes into play.

One of the guarantees is straightforward, the other is not.  There is a Virtuozzo variable called vmguarpages which is the figure up to which a request to allocate memory is guaranteed to be met.  Remember, this is allocated memory, not used memory.  If you have a guarantee of 256 Mb, then you do not have a guarantee of being able to use 256 Mb, only a guarantee of being able to allocate 256 Mb.  Because of the way many software processes work, the memory actually used is likely to be significantly lower than the allocated memory.

When memory is requested beyond the level of vmguarpages, it will be allocated if it is available, but it may be refused.  So, at any point beyond the guarantee, an allocation request may be refused.  A process that has a memory allocation refused will usually fail.  The second guarantee is more convoluted: the guarantee on oomguarpages relates to memory actually used, but what the guarantee says is that provided your actual memory usage is within the oomguarpages level, none of your processes will be terminated if the server is running out of memory.  Contrarily, if actual memory usage is above the oomguarpages guarantee, memory may actually be claimed back, with a near certainty of the relevant process failing.

It is now possible to see why it is common for a VPS to be inherently unstable.  As delivered, and before any web sites or mail boxes have been added, many VPS plans are running with actual memory usage within the oomguarpages guarantee, but the allocated memory well outside the vmguarpages guarantee (with both guarantees often being the same figure, that figure being quoted in sales material as guaranteed memory for the plan).  The consequence is that every request to allocate memory is at risk, and therefore processes may fail at any time.  No process will be terminated to grab back memory, but any new request has a possibility of failure.  How often failures occur will depend on the provisioning of the whole server.  It seems a fair assumption that the VPS that I ditched was less generously provisioned than the one I am currently using.

Another point is important in relation to VPS offerings.  Absolutely any failure that can be linked to memory is likely to provoke a response from technical support that tells you to buy a higher plan.  But if the failures are resulting from running into the limit on allocated memory (the privvmpages barrier) then the critical factor is the “burstable” limit.  Often, plans with different so-called guaranteed levels have the same burstable limit, so upgrading the plan will not solve this particular problem.

It would make sense to configure a VPS with a higher figure for the guarantee on allocated memory (vmguarpages) while leaving the oomguarpages guarantee referring to used memory unchanged.  However, I have seen little sign of this being done in practice, and it would require hosts to be quite careful in their provisioning.

Partly because of its complexity, there is a trend towards hosts replacing this memory management scheme with something simpler.  It is likely to be some time before this becomes universal.  The memory scheme known as “SLM” simply controls allocated memory.   This removes the uncertainty that exists in the grey area between the guaranteed and burstable limits.  In a comparison, for similar expenditure, one expects a higher SLM level than “guaranteed” level, although possibly not as high as the burstable limit.

Well, I never intended to get involved in all this detail, but found that I could not effectively manage a VPS to control both its reliability and its cost without doing so.  So I hope that describing my experiences and the technical issues will help others to travel the same path more quickly and less painfully.

Copyright © Martin Brampton 2008

While spending six months as leader of the Mambo development team creating version 4.6 I came to know a lot about the code internals. Despite that, there were plenty of gaps in my knowledge of how to use Mambo. Books on Mambo seemed superfluous if they didn’t get into a lot of detail and what I saw of the blurbs sounded quite superficial. All the same, when I was invited to review the latest edition of Douglas Paterson’s book “Learning Mambo” (aimed at version 4.6) it seemed a good opportunity to check out the reality.

Flicking through the contents, I was impressed with the coverage. While the emphasis is on the user experience, and particularly operation of the “content” facility, Paterson goes into enough detail in enough areas to give the reader a good understanding of much more of Mambo than I had expected. Starting to read, I was initially rather put off by the light, even flippant, tone of the text. At the same time, the Zak Springs Golf Club project sounded complicated and confusing.

As I worked through the book over a week or so, my opinion changed. The chatty style grew on me, and began to lighten what would otherwise be some rather dry material on the ins and outs of building a web site that is not inherently very interesting. In the end, I was enjoying the style more than the substance as I struggled through the technicalities of template modification. And as it turned out, the individual Golf Club examples were simple enough to be good illustrations of the points being explained.

Very good explanations they are for the most part, too. Occasionally Paterson is frustrating, especially for a reviewer, when he fails to cover some important information, only to deal with it a little later. Some clearer forward references in those cases would be very helpful. For example, the discussion of the front page on pages 47 to 50 gives no idea how to control the details of layout, and gives only the barest hint that the information will be given just a bit later on page 60. Otherwise, though, the approach to introducing features is progressive and very effective.

I was surprised and gratified by how much I learned

In general, I was surprised and gratified by how much I learned or in some cases put into a better context. Paterson thoroughly reviews the workflow aspects of content development, including making cogent criticisms of the Mambo implementation. Having worked mainly on sites where I had to write everything myself, his descriptions were illuminating. Although evidently defeated by a few of the obscurities of Mambo (I still don’t know why some things have both a title and a name, or sometimes a title and a title alias) few aspects of Mambo content are left unexplained. “Content” has been an unfortunate name for what are effectively “articles”. One is left having to point out that there are other kinds of content than “content”.

Likewise, the administrator side of handling “content” is thoroughly explained, using practical examples. There is just one important point that Paterson omits. Every experienced user knows about it (although they often continue to suffer), but beginners need to be warned against taking too long over online composition of content. Mambo will only permit a session to be idle for a certain length of time, commonly 15 minutes. And Mambo thinks the session is idle when it does not see any data being submitted – it has no idea that you are working very hard on the creation of a first class article on an important topic. When you come to save it, Mambo is liable to tell you that you have been logged out for inactivity. In this situation, everything you have written is totally lost. So, although this review is designed for web publication, it is being written offline!

Towards the end, Paterson makes a valiant attempt to describe how to modify a template. Although his suggestions are sound enough, I found this the least successful chapter. Once you engage with this level of development, life becomes very messy and potentially frustrating, as I know to my personal cost! Certainly it is advisable to proceed with caution, making frequent backups of the relevant files. It is quite easy to make a few changes, especially to CSS, only to find that the whole appearance of the site is messed up. Another huge problem for most people is that having created a beautiful layout in one browser, it is quite common to find that it doesn’t work at all in another. Few are equipped to carry out comprehensive testing across a range of browsers. For example, the CSS hover and visited techniques suggested by Paterson are liable to fail in some versions of Internet Explorer. A useful addition to the chapter would have been mention of the World Wide Web Consortium’s validation site at http://validator.w3.org which will check the validity of a site’s HTML. Another small point is that it is generally better to omit the XML declaration that appears on the eighth line of the index.php file of the template described.

The final chapter describes deployment of a web site using a hosting service. As usual, the advice is generally sound. A few supplementary points worth making are:

• FTP is not always reliable for handling large numbers of files – it is better to upload the entire Mambo distribution to the server and expand it in place – most File Managers can do this
• It is tidier and more secure to delete all unnecessary files from the site’s base directory – that includes all the files with no extension, changelog.php, configuration.php-dist and install.php – they help hackers to identify the kind of site that is being run which can invite attack
• Mambo 4.6 and 4.6.1 do not use the values in configuration.php for mosConfig_absolute_path or mosConfig_live_site – instead they are derived automatically in order to attempt to adapt to changing circumstances
• File permissions are complex and while Paterson’s description is good as far as it goes, there are liable to be further issues – hosting varies a great deal and it is impossible to give universal advice – and there are special problems with components such as galleries or file repositories
• The suggested .htaccess changes are liable to damage any module that has its own images
• Mambo’s statistics gathering facility can be a very big overhead and is best switched off – good hosting services provide much better tools for getting site statistics

Given the importance of security on web sites, it is perhaps worth pointing out some issues that are not fully covered by Paterson, possibly because of the timing of the writing of the book.

• The most important is that extCalendar 0.91 is vulnerable to exploits, and you should always use the revised 0.92 version or later
• MD5 on alphanumeric strings is actually quite easily decoded using brute force – it is a pity that Mambo restricts passwords to alphanumeric (for no particularly obvious reason)
• If you really dislike a user, it is better to leave them disabled than to delete them, as this will prevent them from simply signing up all over again (assuming the more secure choice of insisting on unique email addresses has been chosen)
• Personally, I’d prefer Mambo to email administrators even on the creation of users by the administration side, just as a security precaution
• Preventing access to a component by setting the level of access for the associated menu entry was insecure prior to Mambo 4.6 and attempting to make it secure created a good many other problems which some people have solved by defeating the security fixes
• Although tightening up on file permissions may be a good idea, if a hacker has reached the point of being able to execute arbitrary PHP, the site (and possibly the server) is lost

I’d recommend anyone who is serious about building a Mambo based web site to buy the book.

Each chapter ends with a summary. It is quite short and obviously didactic in intent. But it is a good idea to review what a chapter has covered, and helps to commit more of the material to memory. There is also a reasonably good index so that it is possible to refer back to significant points later. By the time I reached the end of the book, I had learned quite a lot, and will continue to refer back to Paterson’s descriptions. I’d recommend anyone who is serious about building a Mambo based web site to buy the book. It is the nearest thing I’ve yet seen to a Mambo user manual.

Martin Brampton
1 March 2007
Copyright © 2007 Martin Brampton

“Learning Mambo – A Step-by-Step Tutorial to Building Your Website” by Douglas Paterson
Published by Packt Publishing http://www.packtpub.com

ISBN 1-904811-62-0