Flash(tm) has a place on the internet, but being used to move the odd bit of text about is definitely not it! Sledgehammer, nut, smash. However, doubtless much to Adobe's glee, the idea that all animations on the web are obliged to use Flash has somehow become deeply ingrained into the public psyche, and more importantly those members of the public who ask us to develop websites for them.

But then along came the iPhone, a device for the near exclusive use of trendy-young-things, awash with plenty of that indispensible disposable income that keeps businesses in business. Now all of a sudden that Flash animation becomes invisible to the very market sector you most want to influence. Is it time perhaps to fall back (yet again) to the tried and trusted technologies that work on all devices?

As a quick example I have created an example here:

But the really interesting thing to note is what happens if you switch the javascript off. It stops moving, but your banner remains:

No nagging message telling you your plug-in is out of date, and that you really ought to spend the next half an hour downloading a 20MB file and getting Wizard Fatigue.

Now, I don't want this to sound like a lecture, but instead I want it to be a message of hope. HTML5 is around the corner, and a whole plethora of new technologies are about to come on-line, such as scalable vector graphics, opengl and so forth. Sorry, did I say new? I mean a whole plethora of technologies we should have had years ago might finally arrive at a browser near you, and what on earth kept them?

What this means is that both the simple javascript animation I show you here and Flash may soon (I mean eventually) be consigned to the dustbin of history, and the tried and trusted technologies will expand to fill their shoes. We can't wait.

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.

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.

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