Worfolk 18 is pleased to announce we’re expanding our existing range of adult entertainment websites with our first gay offering – Gay Men 365. Updated with a new photo every single day!
Mustache is a logic-less templating system, written by people who apparently can’t spell moustache correctly.
It has been ported to almost every popular language ranging from PHP to C++, though it has its origins in Ruby. It isn’t just useful for HTML either – you can also use it for things like config files.
The idea behind it is that templates are logic-less. It divided the traditional view into two parts – a view which is a class in your host language, and a template which is the Mustache markup. The view class can also be an associative array, like you would pass with a traditional templating system, but using a class allows you to easily make use of functions.
It produces very clean mark-up – you simply place your variables in curly braces (or double moustaches if you will) like {{so}} and they are swapped out. Repeating sections are handled by {{#sections}} that repeat based on lists {{/sections}} or are just used once to display or not, instead of using if statements.
The advantage is that you get templates which are almost logic free. I saw almost because of course you do still have repeating elements and tags in there designed to replicate if statements. But there are no logical statements in there – just tags!
The disadvantage is that it means doing a bit more work with your views. MVC already splits out the stack into three components and Mustache divides the view one step further.
Symfony2 has a very nice Validator component for data validation. As with most of the components, it can be used outside of the framework, but unfortunately, the documentation on how to do this is rather lacking. Indeed, even using it within Symfony but outside the controller can be difficult and this is made especially difficult if you’re using Propel because you can’t use annotations.
However, it can be done, and this tutorial will show you how.
When using the validation component somewhere other than in a Symfony2 controller (be that in an entirely different project, or just in a custom class inside the framework), the problem is that you don’t have access to the service container. So we need to create the object for ourselves.
Lets start by importing the namespace into our class.
use Symfony\Component\Validator as Validator;
This will give us quick and easy access to the Validator classes. Now we can use the ValidatorFactory to generate a validation object.
$factory = Validator\ValidatorFactory::buildDefault(); $validator = $factory->getValidator();
This is good. It means we now have a validation object that we can run against annotated classes. But what if we are using Propel and need to specify our validation rules in a YAML file?
$yamlFile = "../src/Acme/DemoBundle/Resources/config/validation.yml"; $factory = Validator\ValidatorFactory::buildDefault(array($yamlFile), false); $validator = $factory->getValidator();
Now we can use the rules we specified in the YAML file to validate our Propel classes.
$violations = $validator->validate($model);
Splendid, we’re done. One further trick I’ll throw in with this post – what happens when you need to validate multiple objects and give a combined list of errors back? Because the list we get back is a custom object, we can’t just array_merge the two $violations list. But luckily, there is a function in the object to do this.
$violations = new Validator\ConstraintViolationList;
$firstViolations = $validator->validate($firstModel);
$secondViolations = $validator->validate($secondModel);
if ( count($firstViolations) > 0 ) {
$violations->addAll($frstViolations);
}
if ( count($secondViolations) > 0 ) {
$violations->addAll($secondViolations);
}
That will return you a single ConstraintViolationList that you can iterate through, containing errors from both models.
I’ve recently written about Flight and Silex, so continuing the PHP micro framework theme, this post is looking at Limonade.
I had heard mixed reviews about it before I first began exploring the framework, and that pretty much sums up how I feel about it too. It does what it needs to, but there is nothing spectacular about it and given the choice, I would rather work with something like Flight.
It offers similar functionality, with an integrated views system, though without the object orientation you would expect, which makes it more similar to Sinatra. It also has a good range of hooks to allow you to extend functions by inserting code before and after.
Documentation for Limonade is a little hit and miss. There is quite a lot of it but it isn’t very well organised. If something isn’t in the main readme, you often have to go hunting around the examples folder until you find what you want. In its defence though, there is a lot of ground covered in the readme.
You can download it and have a play around from the Limonade website.
Recently I wrote about the Flight PHP micro-framework. One of the challenges I ran into when launching one of our sites in it was that we had some database information that needed to be pulled out in the layout.
It was the same information on every page so it didn’t make sense to pass it in as a variable as this would have meant using the same code on every route to do the same thing. Instead, it was simpler to create a view helper which would pull out the information needed.
class Helper {
public static function menuTags () {
$tagModel = Flight::tagModel();
return $tagModel->findDistinct();
}
}
Nothing fancy here, just a static method on a class which hooks into one of the model classes I has already registered with Flight and returns the result. I then just needed to reference this from the layout view.
<?php foreach (Helper::menuTags() as $tag) { ?>
<?=htmlspecialchars($tag["tag"])?>
<?php } ?>
Now it appears on every page without me having to pass it in as a variable.
Flight is another micro framework written in PHP and bills itself as being extensively extensible.
Like other such frameworks, you begin (and arguably end) by creating a series of routes and adding closures to those routes that present the actions and outputs of said route. The quintessential example being as follows.
Flight::route('/hello', function(){
echo 'Hello, World!';
});
The routing works really well using the simple format that allows you to name and route and add a regular expression match in one simple statement.
Flight::route('/article/@id:[0-9]+'
You don’t have to use closures either – any callable object can be used, so you can write a separate function and call it from multiple routes – useful if you have multiple, entirely separate patterns to match where it doesn’t make sense to do it all in one regular expression.
Flight has a simple built-in views system which allows you to render a view (which just uses PHP files to keep things simple) and pass an associative array of variables in which then translate to variables which you can use in the view. Layouts are also supported.
Its real power though is in how you can extend it. You can easily write your own classes and call them into your Flight methods using its register function.
Flight::register('db', 'Database');
$db = Flight::db();
This doesn’t just apply to new classes – you have override the Flight classes with your own if you wish to as well. Flight goes far deeper though, allowing you to do what it describes as filtering, a system which allows you to insert hooks before and after functions.
Flight is a great little framework, and one to rival Silex.
The Symfony2 framework comes with a really nice validation library and on top of the built in constraints that you can use you also have the ability to add your own custom constraints to perform any other validation checks you need to do.
The Cookbook has an article on how to create such a custom constraint, but unfortunately, as has happened a few times with the Symfony2 documentation, it misses out some fundamental and sometimes rather obscure step in order to get it working.
The problem is, it doesn’t tell you where to put the files. That leaves two options – either you have somewhere they need to be in order for Symfony to find them, or you need to fell Symfony where they are.
After hours of digging around, we eventually found the answer – in your validation.yml file you need to register the namespace and then reference that name when you call the validation rules.
Start by registering the namespace at the top of your validation.yml file.
namespaces: myValidator: Acme\ExampleBundle\Validator\
Lets say you have added a custom validation constraint called Postcode. When you want to invoke that from your validation rules, you need to reference the namespace you have just created.
postcode:
- myValidator:Postcode: ~
You can then use this namespace with your custom validation rules, place them in the appropriate directory (in this case src/ExampleBundle/Validator, but you can store them somewhere else if you change the namespace – remember that Symfony2 will extract the path from the namespace).
Silex is a PHP microframework based on Symfony2 components.
With the shift in recent years to leveraging more JavaScript and front-end code in fat clients, a lot of server-side processing has been reduced to simple data relay and APIs. As a result, there have been a number of microframeworks arisen, which allow you to serve out content in a really simple and easy way.
One of the most popular is Sinatra, a micro-framework for Ruby, which is what we built Village Chief on. Indeed, Silex is inspired by Sinatra, but is PHP-based and uses some of the great components that can be found in the Symfony2 framework.
As you would expect from a microframework, it’s really easy to get started.
<?php
require_once __DIR__.'/../vendor/autoload.php';
$app = new Silex\Application();
$app->get('/hello/{name}', function ($name) use ($app) {
return 'Hello '.$app->escape($name);
});
$app->run();
It relies heavily on Composer, a PHP dependency manager. This is a bit of a pain if you’re not already using Composer as it means you have to have yet another piece of software on your computer, but unfortunately, you’re somewhat railroaded into it as there is virtually no documentation on how to install things like Twig without it. Luckily, once you have it, it does make things easy and pain-free, so it’s probably worth going through the initial setup.
Once you’re up and running, it’s a snap to add content. We recently re-launched Maze Finance and the entire process of getting Silex up and running and migrating our existing website into it took less than two hours!
Drupal is a great PHP-based CMS (content management system), but its true power is only unleashed when you use the modules system. Out of the box, Drupal provides basic functionality for creating and publishing content with additional functionality that can be added by installing modules, you have a far more powerful system.
In fact, most of the core functionality of Drupal is provided via modules as well. Drupal ships with a series of “core” modules which, should you wish to, you can disable. So if you don’t want the menu system, search, taxonomy or the help system, you can turn all of these off.
Beyond that though, Drupal can be extended significantly thanks to its reach ecosystem of modules (or plugins if you will) that provide significantly more functionality than the core system ships with. While you’ll need to find the right modules to match your needs, there are several that are considered the staple diet of Drupal developers.
Chaos Tool Suite
It may not look like anything special to get started with, but CT Tools provides an expensive range of APIs and systems which make developing with Drupal easier. It’s a platform to use when developing your own modules but also serves as a dependency for many other modules.
Views
The most installed module of any on the Drupal website, and it’s easy to understand why. Views is an incredibly powerful module which allows you to create custom pages that do various tasks – such as listing out a content type, sorting things a certain way, creating archives and many other tasks.
Entity Reference
At some point you will probably want to reference one entity to another. For example, on the Know Leeds website we have places and we have restaurant reviews. For each restaurant review we write, we want that to be linked to a certain restaurant (a place), and we do this with Entity Reference.
Pathauto
If you think you’re getting an exciting Greek named module, think again – it’s just the words path and auto put together. But it’s still a very useful module as it automatically creates friendly URLs without you having to type something in.
By default, Drupal won’t create a node reference for an article, it will just use the ID. You can override this by typing in something like article-title, but Pathauto will do this automatically. It’s good to install this from the start as it allows you to set up patterns for articles, categories and other systems so that you have uniform URLs across your site.
CAPTCHA and reCAPTCHA
reCAPTCHA is a fantastic took that stops spam and helps translate books at the same time. Using these two modules you can add reCAPTCHA to your site to stop spam bots registering accounts.
Taxonomy menu
This allows you to build an automatic menu out of a taxonomy set. So if you have categories as part of your taxonomy and you want to create a menu that automatically lists each category, this module will do it.
Drupal is probably the best PHP-based CMS (content management system) on the market today. However, because it has a somewhat steeper learning curve than other systems, where you can just install and start creating content, it is easy to get frustrated with it and give up.
However, a short amount of time getting your head round the basics should be enough to show you that Drupal has some really powerful features which make it a far better CMS than those that simply allow you to drop text into pages.
We used Drupal to build Know Leeds and it allowed us to quickly and easily put together a functional site that allowed the non-technical contributors to get to grips with the system.
Content types
Because most people are familiar with WordPress, I’m going to use that as a comparison throughout this article. If you’re not familiar with WordPress, don’t worry, because most, if not all of the terms used are generic concepts that you will be able to understand anyway.
In WordPress, you have two types of content – posts and pages. Posts are the bread and butter of what was traditionally a blogging only system. Pages, are similar, but are static and don’t go into the date-based archives.
In Drupal, you get to define your own content types. It comes pre-configured with an article (similar to a post) and static page content types, but where you go from there is up to you. There are two good examples of where we used this in Know Leeds.
Firstly, we added a content type for “Restaurant Review”. This is similar to the Article content type, but we wanted to add some additional fields to Restaurant Review that didn’t want to be in Article – a star rating and a categorisation of what type of food the restaurant served.
Secondly, we added a content type for “Place”. We offer listings of local bars, clubs and restaurants on the website and if you think about it, an entry for one of these is basically just a piece of content. But with different needs than an article – we need address, phone number, email address, etc. So we created a custom content type for that too.
Fields
As I discussed with our custom content types, we wanted to customise the field types on our content types. In WordPress there are a number of fields – title, body, published date, categories, etc. In Drupal, you have the same thing, but you can create your own fields and match them to each content type.
So for the Restaurant Review content type we added a star rating field. This allows the editor to enter a numeric value between one and five. We also added a Cuisine content type which allows them to pick what kind of food it is. This works just like the WordPress categories system, except we can have multiple types of categories and we can pick which content types they apply to!
Taxonomy
In WordPress, there are two types of taxonomy – categories and tags. In Drupal, surprisingly enough, you can define your own. As I’ve already discussed, we created a Cuisine taxonomy and added a list of different terms (or categories if you will) such as French, Italian and Steak House.
Drupal allows you to create as many different categorisation systems as you wish and apply them to the content types as appropriate. We only wanted Cuisine to apply to the Restaurant Review content type for example, but Category might apply to both Article and Restaurant Review.
Blocks
Units of content which can be placed somewhere in your layout are called Blocks. The nearest equivalent to this in WordPress is the “widgets” system where you can drop widgets in and out of the sidebar.
Drupal comes with some standard blocks such as user login and search form, and many of the modules you can add into Drupal will add some blocks too – adding the forum module will add an “active forum topics” block for example. Of course, you can create your own custom blocks too.
You can then define where these appear – first sidebar, second sidebar, footer, navigation menu, etc, by selecting their position from the blocks menu. You can even do this on a theme by theme basis – on one theme you may want the search form to go in a sidebar for example, in another theme you may want it to go at the top or bottom of the page.
Unlike the widgets system in WordPress though, everything is a block in Drupal! Even the main page content so for some reason if you wanted to make your footer text display in the centre of the page and your main content display in your sidebar – you’re just a couple of clicks away from that!
Menus
Menus probably need the least explaining of all – it allows you to create menus which people can navigate around the site with. It is worth noting though, that items don’t appear in the menu automatically – you have to request that a piece of content (usually a static page) is given a menu link when creating or editing that piece of content.
Of course, you can create as many different menus as you want, assign different content (or any other links you want to add!) to different menus, and have the menus display in different places around your layout using the blocks system.
Conclusion
I hope this has presented you with a quick introduction to the fundamental concepts of Drupal. It is far more customisable that most other popular content management systems and as such has a steeper learning curve, but far more flexibility once understood.