I noticed something this week while looking at the latest CMS usage statistics from BuiltWith Trends that surprised me. BuiltWith Trends provides information on the usage of various technologies across the web — including CMS’s, — and it’s of little surprise that they have Wordpress up there at no#1 and Joomla! a little way behind in second. What came as a surprise to me was that up in third was a CMS called “Website Tonight”. That’s ahead of Drupal, which I had always considered one of the “Big Three”. Perhaps tellingly, in separate statistics for the Top Million sites (according to data from Quantcast) it drops down to seventh, and out of the top ten CMS’s altogether when you get to the “top ten websites”. I’ll be honest — I’d never heard of Website Tonight. On its inauspicious website, Website Tonight to be: “an Internet-based Web site creation tool that enables users to build and publish Web sites in a few simple steps. An easy-to-use turnkey solution, WebSite Tonight guides the user through the entire process of outlining, building, analyzing, optimizing, and, ultimately, publishing a Web site to the Internet.”. I suspect what’s key on this site is the button entitled “Become a Reseller” — presumably they provide white-label website creation tools for these “build your own website” websites. It does appear that, amongst others, the product is available as a service through the likes of GoDaddy. Either way, it’s a surprising statistic yet one which I don’t believe will affect my decision as to what technology to concentrate on for now — on my head be it! If you happen to know any more about Website Tonight, do let me know in the comments.
On the first of October, Facebook will make another change which could have a significant — and potentially costly — impact to your applications and pages. As part of its latest moves to increase security across the platform, in addition to OAuth adoption they will expect that your canvas applications to be hosted at a secure address (https). If a user browses to your page via https — and millions are beginning to change their settings so that they are — instead of your lovingly crafted content, they’ll see the following warning:
Laravel is the new kid on the block of PHP frameworks, and whilst in its early stages of evolution (the author wrote it, he says, in the early part of 2011) it does promise — and delivers, from what I can tell — an expressive syntax and an elegant (indeed, you might say eloquent) ORM. Laravel is a fully Object Oriented MVC framework which makes extensive use of features new or recent to PHP — you can forget about running it on PHP4. With PHP5.3 compliant namespacing mechanisms as opposed to, for example, Zend Framework’s pseudo-namespacing, it’s certainly what you might call a modern framework.
In Laravel you define routes — which, staying true to the RESTful paradigm, are defined not just as URI’s, but according to the HTTP operation they are to react to. Thus, instead of defining a route such as
I needed the means to add a quote to a website I was working on — a simple task, which could be acheieved by simply adding a text or HTML block. However this can be taken a step further by implementing a simple block type specifically for quotes, with the markup generated for you.
To mark up a quote semantically, we’ll want a
blockquote for the content and a
cite for the source (or author), so the HTML needs to look something like this:
<blockquote> <p>It is the mark of an educated mind to be able to entertain a thought without accepting it.</p> <p><cite>Aristotle</cite></p> </blockquote>
…which will give us something a little like this:
In this simple tutorial, I’m going to show how Concrete5 can be extended to integrate a third-party JQuery plugin to enhance an existing module, and then how this can be encapsulated in a package. I’m going to allow the slideshow module to display images using the clean & lightweight Craftyslide plugin, pictured below.
Concrete5 comes shipped with simple slideshow functionality in the form of a block called, imaginatively enough, slideshow. As this is part of the core you can find it in
/concrete/blocks/slideshow. It’s in the concrete directory to keep it separate from custom code. And some custom code is what we’re going to produce — to override the output of that block, and then to encapsulate this into a package.
In the first part, I looked at creating the database schema for a simple Drupal module designed to allow you to associate colours with taxonomy terms. In this second part, I’ll look at the administration aspects of the module. In essence, what we need to do is as follows:
- Since colour-coding may only be appropriate to certain vocabularies (e.g. categories) and not others (tags, perhaps). We need to provide the user with the option to specify which vocabularies are applicable.
- The user needs to be able to specify a colour when adding or editing a term, where appropriate.
- We need to provide a mechanism which allows the colour associated with a term to be stored, retrieved, and to be displayed.
There are so many Content Management Systems (CMS’s) out there that due to the sheer volume of choice it’s easy to plump for the best known options, such as Drupal, Joomla! and Wordpress. However there are times when these “flagship” CMS’s might not be the best option. Drupal, for example, can be overly complex and bloated for fairly simple websites (personally I’ve often thought of it more as a framework anyway), or Wordpress might be too specific for a site that’s not strictly a blog. I’ve long wanted a good, easy-to-use, stripped-down but extensible — alternative, and one such option I’ve looked at recently is Concrete5. Concrete5 has gone from being a commercial product to MIT-licensed Open Source and makes some pretty bold claims about being easier-to-use and better coded than Drupal or Joomla. But does it live up to these lofty ambitions? And how does it compare to Drupal, Joomla and so on?
Drupal’s permissions system provides sufficient flexibility to create an Editor role or similar, enabling a site user to review or optionally edit content prior to publication. But what if you simply want to allow someone to view unpublished content on an ad-hoc basis — perhaps you wish to get a colleague to look over a new blog post, for example — without having to create a role, or you simply wish to restrict it to one particular item of (unpublished) content? Step forward Peek, which allows you to do just that. Simply designate a content type “peekable”, then depending on the settings per-content type, set your node as “peekable” too. You can then grant a “peek” — a window of time during which a specified user can, by following a special link, gain read-only access to that node. You can configure an expiry time, the length of time it’s valid for and opt to be notified when the content is accessed. It’s a great little module.
If you’ve looked after a Drupal website for any length of time you’ll know that you should regularly update modules, themes and most importantly the Drupal core as-and-when updates become available — security updates, at the very least. The Update Status module (now in core) is great for summarising what needs updating (if you haven’t enabled that module, you really should do), but if you really want to stay on top of those updates then there’s a fairly simple way in which you can get them sent to your iPhone (or indeed iPad) as a push notification. Here’s how. First, you’ll need to download Prowl from the App Store — at the time of writing it costs Â£1.79, or $2.99 in the US. Next up, you’ll need to create an account on the Prowl website. Then, you will need to generate an API key — you can create as many of these as you wish, and there’s no additional charge for doing so. As you can see from the screenshot below, the API Keys tab shows any existing keys, and the form at the bottom is used to create a new one — all you need is a note to remind yourself what it’s for. Enter something to do with the site you’re adding, e.g. “My Drupal Website” and hit Generate Key
With a few handy contributed modules, creating a mobile version of a Drupal website can be surprisingly painless. In this series of posts, I’ll run through one approach for doing so, using a few of those modules and themes.
Why create a separate mobile version?
You don’t always need to create a separate version at all, of course. Using responsive web design techniques — including media queries — sites can be re-worked to display better on mobile devices; however to do so may not fully utilise the benefits of certain mobile features, has a number of key inefficiencies and a one-size-fits-all approach ignores the fact that mobile users might have different motivations for accessing and using your site. (I’ve written about this before.) Instead, it’s relatively easy to channel your content to mobile devices without just using responsive design techniques — which might help you tweak how you’re showing your site content, but not what you’re showing.