We were advised by our Certificate Authority of choice (GeoTrust) some while back that they would be switching to new 2048-bit signing. Great, we thought. Now instead of it taking merely the lifetime of the universe to hack a certificate by brute force, it will take the lifetime of the universe squared. Big deal.

What we didn't realised was that in practice that would mean that the next time we renewed a certificate and installed it, the browser (in this case Firefox) wouldn't recognise it, and reports:

This Connection is Untrusted

www.site.com uses an invalid security certificate.

The certificate is not trusted because the issuer certificate is unknown.

(Error code: sec_error_unknown_issuer)

It worked with every other browser, but what's the point of shelling out for a bona-fide certificate if one of the world's most popular browsers doesn't recognise it? Good question.

We quickly searched for a solution, and discovered that we aren't the first people to whom this has happened. We also discovered, like them, that information from GeoTrust themselves is thin on the ground. We certainly didn't get any warning that something called an Intermediate Certificate might be required. Oh no, we had to work that out for ourselves.

The good news for anyone reading this is that we have discovered a useful page where you can download any Intermediate Certificate you might need. We're quite happy to advertise ssl247.com on this page because they really helped us out. Thanks guys!

Once you have your Intermediate Certificate, put it into a text file on your Apache server (we put it into /etc/apache2/certs and give it the suffix .crt) then add/modify the following directives in the relevant ssl VirtualHost:

  SSLEngine on
  SSLCertificateFile /etc/apache2/certs/site.pem
  SSLCertificateKeyFile /etc/apache2/certs/site.key
  SSLCACertificateFile /etc/apache2/certs/intermediate.crt

Restart Apache and your site's new cert should now be trusted. Problem solved.

Recently we had a case where someone changed the encoding on their Plone site using the portal_properties tool. This resulted in the site being unaccessible, even via the ZMI.

So, for posterity, here's how to recover from a fatal property setting:

1) Stop the instance (bin/instance stop or whatever)

2) Attach a python shell to the instance. There are a number of ways but in recent Zopes that ship with Plone (in this case Plone 3.3.1) the easiest is this:

bin/instance debug

This should run up a few lines and then settle down to a >>> prompt where you can type some python. You're now in a python shell and the ZODB is directly accessible via the "app" object.

3) Start a transaction. The right syntax had me foxed for a while, as it seems to have changed along the way, but the way to do it in recent zopes is like this:

>>> import transaction

It's important to do this before you start fiddling.

4) Make any changes you want. There are a few pages on things you might like to do to delete rogue objects etc, such as these:

http://www.zopelabs.com/cookbook/1054240694
http://wiki.zope.org/zope2/DebuggingWithIPythonAndOtherTips

However these are a bit old and don't help so much in this case as we need to change a property. So we do this:
 

>>> obj= app.unrestrictedTraverse("/Plone/portal_properties")

We can then look at a property like so:

>>> print obj.site_properties.default_charset
ASCII

Aha, so this is wrong. Let's change it:
 

>>> obj.site_properties.default_charset="utf-8"

And see if it's changed:

>>> print obj.site_properties.default_charset
utf-8

5) Very important step - if all went well don't quit the shell at this point, we need to commit like so:

>>> transaction.commit()

[If all didn't go well, then best to quit and not commit. That should leave things as they were before you started.]

6) You can then detach from the python shell with ctrl-d and see if your Plone site now works again.

We live in interesting times as regards fonts in browsers. For a long time the choice has actually been getting narrower as technology has advanced. Certainly with the advent of Linux, and the popularity of all things open-source and Public License, many (if not all) of the world's most famous fonts are now increasingly being left out of Operating Systems and Browser distributions. This is because they are heavily protected and can be used only under license.

In the past Microsoft, Apple, Sun, etc. have licensed fonts for use with their Operating Systems, so no-one else had to. These days however an increasing number of systems (and by 'system' we mean a computer, phone or any other generic computing device with a display) are being created that are entirely license- (and therefore royalty) free.

This is good news for the consumer, but as a website owner it makes it very hard to specify anything. You might want your next website to be in 'Verdana', but if the person visiting your website isn't using an OS that has licensed that font, then their browser will fall back to whatever else they have. There aren't even any sophisticated systems for automatically falling back to the closest alternative. We were therefore rapidly approaching the situation where only two fonts existed: serif and sans-serif. These were literally the only two fonts guaranteed to be on every device.

It is into this situation that several new technologies have emerged that aim to solve this problem, and they are really a breath of fresh air. These solutions are invariably highly technical, not very easy to set-up, and not very reliable either (in our experience so far) but they do work. We shall investigate two of them on this page: sIFR and Cufón, as well as a much simpler alternative just using CSS.

Scalable Inman Flash Replacement (sIFR)

This text has been replaced using Scalable Innman Flash Replacement (sIFR)

This way of replacing text employs Javascript, CSS and Flash, and was the first prominent text-replacement technology to appear on the scene. It is now up to version 3 (in beta, but well worth the risk). Since it requires both Javascript to be enabled and the Flash Plugin to be installed, it will not work for every visitor. However it falls back very gracefully to just display the original text, and is also good for accessibility. Better still is that sIFR Vault offers many funky fonts for free download.

A nice feature is that the replaced text can still be highlighted with a mouse character by character (try it!) should people want to cut and paste it. However, it is not suitable for large sections of text, just for menu items and headings. One huge technical problem we have noticed is that support for transparent background excludes users of Linux. If your website design requires this, which many do, then you will be out of luck.

Cufón

This text has been replaced using Cufón

Cufón aims to be 'a worthy alternative' to sIFR, and manages to do so without any reliance on Flash. That's one fewer Plugin to worry about, and therefore a larger viewing audience for all your hard work. The solution they have dreamt up is stunningly imaginative, but this blog entry aims only to sum-up the differences to the end-user, not dwell on the technical wizardry.

For the end user the text looks the same, but cannot be selected one character at a time as with sIFR. The authors are working on this, we are told, so it sounds like they have a solution in mind. Better still Cufón is fast enough to be used on blocks of text. Most Truetype fonts can be used, but the issue of licensing is still very much a grey area. In using this technology you are revealing everything about the font to the end user. If it turns out you aren't entitled to use the font (highly likely!) then it is possible you could end up facing legal action.

However, from our point of view the biggest problem with Cufón is that it doesn't seem to work all the time. At least not on this page! This is most likely the result of some strange reaction between Cufón and Plone, but it does highlight quite nicely how precarious these new technologies can be. Our advice might be to 'wait and see'.

Good Old CSS

This text has been replaced using CSS

Ultimately, do not let technology be your master. If your requirements are simple, the text doesn't change, you don't need to highlight letters one at a time, and you want a 100% reliable cast-iron solution, just use CSS. From an Accessibility point of view there's no problem (since it is a background image), and you can have high-quality transparency with no compromises. Why seek complication?

In Conclusion

The other technologies are well-worth keeping an eye on, as is the upcoming @font-face, and CSS3. My personal recommendation would be sIFR3, but only for headings and menus, and only without transparency. In any case, it's definitely an exciting time to sit back and spectate, and wonder what might be coming next.

Plone (first released in 2001) is an application that runs on Zope (first released in 1998) and here at Openia we have been developing on Zope and Plone since 1999. We have therefore been in the privileged position of seeing how the two of them have developed in tandem over the years. Developments in Zope, specifically as it has progressed from Zope2 to Zope3, have driven profound changes in the way that Plone works, starting from the very lowest layer.

At times it has been quite a roller-coaster ride as we have had to relearn how we do even the basics every couple of years, often much to our annoyance. Why does software evolve so quickly? More importantly, are newer versions actually any better, or do they just adhere to stricter and more abstract philosophies? After all, if you obey a stricter ruleset, surely the end result must be better? Or is it just harder work for the same end result?

It is against this that we observe newer competitors in the open-source CMS market really coming to the fore. Drupal (first released in 2001) and Joomla (first released in 2005) are foremost amongst these, and they have many things in common. They are both based on PHP/MySQL, and they both place a great emphasis on extensibility via plug-ins or modules, and inspire a huge level of community involvement. Since PHP is the most widely used website scripting language in the world, the number of potential plug-in and module developers is enormous. This huge strength of community involvement will surely wipe Plone from the CMS map of history - or will it?

Whilst developing on Drupal we have been struck by the number of similarities between it and Plone. CCK is just like Archetypes. ImageCache is just like Plone Images. Taxonomy is just like Categories. Views is just like... well, nothing on Earth! The point is that to a certain level of approximation the functionality of the two CMS platforms is converging. True, you actually have to install CCK, ImageCache and Views in order to make Drupal more like Plone, but many people do. It's not just us who regard those three (plus the rather eccentric Views module) to be the 'Fantastic Four' without which Drupal is simply incomplete.

So, to a certain level of approximation it doesn't matter which of the three you choose. That's good news, approximately. However it is worth bearing in mind that one of the greatest weaknesses of PHP as a website scripting language is its complete lack of strictness. It is very hard to write totally secure PHP code, so hard that it is almost a fruitless exercise. The aphorism "I wouldn't start from here if I were you" certainly comes to mind. Why choose PHP to try and write something secure? Choose something else - anything else!

The truth is that it's only a matter of time before some kind of loophole is found in whatever PHP you have written, no matter how carefully you write it. Attacks using extra parameters fed in using POST or GET are on one level, but cross-site scripting (XSS) is on another level entirely. Here I would say that Drupal and Joomla are better off than other open-source projects, due to their high level of community involvement to spot the errors, but even here there are limits. You might think a few attacks are not much to worry about, but you will think very differently when the front page of your website has been defaced by a hacker, and you still can't work out how they're getting in!

Against this Zope is starting to look like quite a sound technology choice. It was designed from the ground up with a totally different concept of security in mind. It does not rely on a filesystem to store information, where that information is vulnerable to being read by any user with sufficient access. Instead it stores all its objects in an Object Database - a single, monolithic and unreadable file to all intents and purposes. We trust Zope implicitly, and do not know of any situation wherein the underlying technology itself has been breached.

It does take more server resources to host this monolithic Zope Instance - it is a real heavyweight application - but the payback comes when your website is handling thousands of hits instead of just hundreds. By that time a Drupal site's underlying PHP technology, even with caching, is starting to struggle, whereas a Zope instance simply keeps on going. So does this mean that Zope is only suitable for medium to large scale enterprises? I would argue that it isn't, and we have plenty of clients who agree. Even to a small enterprise, the cost of any website security problems that occur can be punitive, and completely swamp any considerations over technology choice.

The final question comes down to size of community. Will Plone cease to grow and develop if it has a smaller community than Joomla or Drupal? Does not the larger community always win? Won't Plone simply cease to exist? The answer to all of these questions is 'no'. It doesn't actually take a huge community to run a successful project - just a sufficiently committed community of just the right size to keep on top of things, and that is what Plone has. Plone has shown no signs of running out of steam, or of running out of community. But even that's not the issue. The point is that the world is quite big enough for all of these CMS projects to coexist, and there is no real need to ensure that your website is developed using 'the winner'.

It's a clichéd example, but in the end VHS won out over Betamax, even though it was technologically inferior in every way. So am I saying that Plone is like Betamax, and then advocating that all our clients buy Betamax? Yes I am, because Content Management Systems are not like video-recorders. Betamax video-recorders ceased to be, but Plone is not going anywhere.

Apache comes with a directive to allow administrators to customise the error message for any error, as specified by its number. For example, the error number for a Bad Gateway is 502, therefore the directive:

should change the Bad Gateway message to whatever is specified in the file error502.html.

All would be well, you would think, except for the fact that all of our Plone hosting uses mod_rewrite, which would produce an apache vhost config such as this:

Unfortunately if you try this out you will (rather ironically) get another 502 error message whilst trying to serve the 502 error message:

"Additionally, a 502 Bad Gateway error was encountered while trying to use an ErrorDocument to handle the request."

The reasons for this are rather obvious: the request error502.html is also going to be rewritten, and since nothing under http://192.168.131.85:13080 is going to work (because the Zope instance is down!) this produces another 502.

One workaround is to use an absolute URL in the ErrorDocument directive, e.g.

but we didn't like this because this causes a browser redirect, so the visitor loses the URL they entered into their browser, which is very annoying if you want to keep refreshing to find out when the site comes back up. Also the redirect code is confusing for search engines:

"the client will not receive the original error status code, but instead will receive a redirect status code. This in turn can confuse web robots and other clients which try to determine if a URL is valid using the status code."

Therefore we wanted a workaround that avoided this. The solution we came up with is to add a RewriteCond to exclude error502.html thus:

in words this means "Rewrite all URLs to the zope instance, unless the URL is error502.html". This now works perfectly. Problem solved. It's odd I haven't seen this solution elsewhere on the web.

Often I'm asked by friends with little knowledge of the world of computers to recommend a laptop or desktop machine for their home use. Although I'm still a fan of Linux, these days I nearly always suggest that they pick the Mac they most like the look of. A long string of questions and answers then ensues. Generally the enquirer's husband/mother/friend/uncle will have suggested some brand of PC running the latest incarnation of Windows, so my suggestion can come as a bit of a shock. Why would someone that appears to know what they're talking about even think about suggesting a computer that doesn't run the the programs that Auntie Betty's machine can?

It's into this world that Google Chrome has burst on the scene. Its tantalising open source goodness means that all us techies are itching to try it out, but does Auntie Betty want to use it? Will she even notice it?

In recent times the "netbook" has become a bit of a breakaway from the general home computing scene - often these things (generally the cheaper ones) are powered by alternative OSes (usually a shade of Linux). Strangely non-windows netbooks do sell, sometimes to ordinary people. When I went into the shop to buy one for my daughter I was summarily informed that I didn't want one of these because it didn't run Windows. When I retorted that this was one of its major selling points, I got a strange look as if to say that I know nothing about these things.

Maybe I do know nothing about what the average person wants. Maybe the ideal world would be one where everyone runs Microsoft and we all share the same viruses, sorry, I mean "binary compatible code". Probably when the ChromeOS netbooks appear the salesman I enountered will still try to push buyers onto a more expensive machine with "better compatibility".

Sadly, for all us geeks out there, this is where marketing can do what years of volunteer effort has failed to do - package up the advantages of open source for the uninformed user and gain market share in the face of a competitor who starts with a huge advantage.

After the launch of Android, Google should have a fair idea whether or not Auntie Betty will be getting a ChromeOS machine next and whether she will like it. I hope for her sake, and everyone else's, that they get it right.

Without desecrating our professional altars by suggesting that we 'dumb-down', I believe that the 'message' needs to be communicated better in both content and in style. I don't just mean straight-talking or randomly using 'cool', 'slick' and 'next-generation' when describing something as potentially life changing as neural computation or nano-technology. But rather stepping back to re-assess what we say (and do) in context of its impact on our immediate professional and social environments before going for world domination!

Clients are people too

Clients are everyday people with everyday problems and mostly basic, sometimes boring, requirements and it is our job to support them without fuss or having to suffer the waffle or sing-along the gospel of Open-Source, Fair Trade or any other belief. And that comes from spending a lot of time listening to our clients, fixing their problems and meeting their expectations.

If psychologists could only communicate with other psychologists, the world would be a very troubled place indeed (yes, even more so than it is already..). Of course, the counter-argument is the devaluation of a profession, such with psychiatry, by the likes of Dr. Phil, Jeremy Kyle and Paul McKenna and this is not what this is about.

We are all trying to do 'the right thing' but I believe that more effort is needed from us as professionals to establish the true value of what we do against the needs of everyday Joe before finding a way of communicating such value in a shared language.

As information technologists, some of us seem to lack the skill to inform... it is not quite as simple as printing a slick brochure or having a Christmas-tree of a website but it is understanding the market well from both the vendor and consumer sides. Before we inform, we need to listen carefully and hopefully offer relevant products and services and communicate such in such a manner that gets the message across.

Just to be clear, I am not advocating that people such as regulargeek.com need to communicate with my mother no matter how they try to phrase statements such as;

"The general idea is that programmers should be writing unit tests using TDD and refactoring as they continue development."....

... but I think she may stand a better chance with our friends at Plone.org who introduce their website by saying,
 

"A powerful, flexible Content Management solution that is easy to install, use and extend, Plone lets non-technical people create and maintain information using only a web browser. Perfect for web sites or intranets, Plone offers superior security without sacrificing extensibility or ease of use."
 

Openia took its name as a leading advocate of Open Source and we did not mince our words and decided to take on a brand that clearly delivers the message.

Beyond the name however, Openia lives and loves Open Source with its values placed at the heart of everything we do. But what about the client? do they have to 'love' what we do too? and why should they? When it matters and if it matters, we will tell clients about the benefits of using a 'Free Public License' and besides the 'free' part, we tell them how their businesses can benefit from all things Open Source including the freedom to design and develop technology that grows with them, the peace of mind that they are supported by continuous improvements delivered by thousands of professional programmers worldwide.

In essence, many professionals enjoy bearing the standard for a variety of concepts or technologies such as Open-Source in the case of Openia. Yet we must always communicate to the market the benefits of joining the march or it may be a lonesome trek.

The basic answer to this is Resizeability. All browsers from the humble IE6 onwards allow the visitor to resize the font, and recent browsers also (attempt to) resize the graphics as well. IE7 is rubbish at this and Firefox 3 is totally superb, as per usual.

However, HTML has never really been very good at coordinating the positioning of resizeable text and (potentially) unresizeble graphics. One place that this crops up over and over again are form buttons. The design has rounded ends and a nice gradient from top to bottom, so how do you make this button resize itself to fit the text?

Answer: The following is a simple technique that works well. The trick is to avoid being overly specific about the height of the button, i.e. let the graphics fade away to transparency at the bottom, and align everything by their top edges. The above button gets cut into 3 pieces:

of which the middle bit will be a repeating background, thereby stretching to any length. Next the HTML:

<span class="roundblackleft" ></span><a class="roundblack" tal:attributes="href string:${here/portal_url}/get-to-know-us" >Get to know us</a><span class="roundblackright" ></span>

Here we have used two empty span elements to hold the left and right ends, and the middle element is just the anchor itself (note that this means that you cannot click on the very ends of the button, but hey).

Now finally the CSS:

The important things to note here are:

• display: inline-block. This allows us to specify a width and height for the span tags, but ensures they still appear inline. Not all ancient browsers support inline-block, but IE6 does.
• vertical-align: top. This is the crucial directive which makes everything line up. Because the anchor is being displayed inline, its height is unpredictable and uncontrollable. Therefore we align it by the top edge, and allow it to become any height it likes.
• If you still have problems with vertical alignment, try applying line-height: normal to the anchor tag. A competing directive can be inherited from CSS elsewhere on the site (especially Plone sites).

This technique only works if the graphics don't have a defined bottom. If they do you can re-do everything aligning with the middle, but this only works with bigger buttons.

The end result:

 Get to know us 

 Get to know us 

 Get to know us 

It's a rare moment at Openia when we stop what we're doing to watch the same video on Youtube, and an 80 minute long one at that. Google's Wave presentation has such an air of occasion about it, that it would seem churlish not to take the time to watch. But is there any substance behind the understated-but-we-know-we're-good Google glitz? There are some pretty powerful applications out there, including many excellent web-based ones, so what exactly is it that makes Google Wave the "killer app" that so many claim it is?

First, it's important to recognise what Wave isn't - it's not one single new idea, it's a bunch of very small, but important, changes to a lot of other ideas which have been brought together. So the first thing we realise is that Wave owes a lot to other technologies. In so doing it stands on the shoulders of giants such as email, blogs, forums, social networking and instant messaging. (Even some of the "new" ideas, such as the ability to watch your correspondent as they are typing the individual letters and words of their message are not that original - "Phone" on VAX/VMS had such a feature back in the 1980s.)

Secondly, although it's a great piece of work, expertly delivered (from what we can tell from the video) it is in many ways completely inevitable. It was only a matter of time before blogs and email and messaging were integrated in some way - it is a technology waiting to happen. That it has happened in one big jump makes it more exciting, but you can rest assured that we would have got there eventually. That said it is reassuring to have Google at the helm at moments like this, rather than some of the alternatives.

But the part which makes this the app which will replace email, IM and many other messaging tools in all our lives is the fact that it is released as a protocol, and an open one at that. So anyone can write their own Google Wave compatible applications and talk to anyone else's. This is what makes Email the current primary choice for messaging - there is no need for everyone to use the same provider. Provider choice is key for planning communications, and Google are big enough to know that they can't be the only provider in the world without poisoning the well for all of us. One has to wonder whether if this technology had been constructed by Microsoft or Apple (for example) that it would have been used as a tool to try to secure market share, rather than making the world a better place for us all.

As a microblog, Wave might only be an incremental change from Twitter, and as a Forum/Social Network it's only a few thought processes removed from Multiply or Facebook, and as an Instant Messenger it might be practically the same as Jabber, MSN or Yahoo; it's the combination of these facets and, more importantly, the openness and ubiquity of them that makes Wave unique, as will be evident when the makers of Twitter, Facebook and others present their offerings in a Wave-like way.

And if this all works out as it should, Wave will become the "glue" of the web.