Drupal and concrete5 both offer flexible ways to store content and display it on pages. Let’s compare some of the basics and look at how you can adapt common Druapl approaches to concrete5.

Concrete5 Blocks Vs. Drupal Blocks

In concrete5 you will be storing most of your page body content in blocks, probably using the Content block. This is a big departure from Drupal where the core blocks are used mostly for supporting content that appears in sidebars, footers, etc.

Concrete5 includes a variety of blocks for storing different types of content. The Content block features Tiny_MCE and is the go to block for text content. Controls that allow editors to embed images, files or links to other pages are also baked into the Content block.

Concrete5 Block Areas Vs. Drupal Block Regions

Block Areas in concrete5 are the containers that blocks are added to and arranged in. In Drupal, block regions are defined in the .info file for a template like so:

regions[header] = Header

This block region would then be output in a layout template, such as page.tpl.php or node.tpl.php:

print render($page['header']);

In concrete5, block areas are defined and output at the same time. If you’re starting with a minimal theme your page template file will likely be default.php.

Concrete5 offers two types of block Areas. Regular Areas establish a container that will hold a unique set of blocks for each page. You define a regular block Area like so:

$a = new Area('Main');
$a->display($c);

Global Block Areas are new to concrete5 and work more like Block Regions in Drupal. Any blocks you add to a Global Area in concrete5 will appear on all pages that use a template that includes that Global Area. You define Global Areas like this:

$ga = new GlobalArea('Header Nav');
$ga->display();

Defining a Global Area in a template file also creates an entry for that Global Area in the Global Areas section of the Dashboard Stacks page. We’ll talk more about Stacks later but for now just understand that this allows you to manage the content of that Global Area “out of context” on the back end of the site if you want to.

concrete5 Attributes Vs. Drupal Fields

concrete5 allows you to add custom attributes to Page, File and User objects. The content of these fields is edited through a modal you can access either from the persistent tool bar on the front end or on the back end Dashboard from the context menu that appears when you click the name of any page in the Sitemap.

concrete5 ships with a nice set of base attribute types:

• Text
• Text Area - Choose from either plain text or several flavors of
• WYSIWYG
• Boolean
• Date Time - Includes calendar widget
• Image File - Think node reference to an image object
• Number
• Rating
• Select List - Allows user submitted values and multiple values

If you need to store and validate data that goes beyond the basic attributes there are resources to code your own custom attributes.

To display a custom field value in a Drupal template we might do something like this:

print $node->field_the_digits[0]['view'];

In concrete5 it’s just as easy to display a custom attribute value. We can do it like this in our template:

echo $c->getAttribute('the_digits');

Concrete5 Page Types Vs. Drupal Content Types

Concrete5 Page Types serve the same purpose as Drupal Content Types.

• Both systems allow you to create new types and add new custom attributes / fields types to those types
• Both Drupal and concrete5 require you to define a machine name or handle for your custom types.
• Both Drupal and concrete5 have a template hinting system that allows you to override the base template file by creating a new template file and naming it correctly

If we created a Content Type in Drupal 6 with the handle “dinosaur” and we wanted to make a custom template for it, we’d create a new file named node-dinosaur.tpl.php and stick it in our theme directory.

If we created a Page Type with the handle “dinosaur” in concrete5 we would just need to create a new file named dinosaur.php and stick it in our theme directory.

concrete5 Page Type Templates + Global Areas Vs. Drupal Panels Node Templates

Let’s say part of your Drupal workflow goes something like this:

1. You define Content Types for
   differing content.
2. You setup Panels Node Templates for each of those content types.
3. You setup sidebar content in each of those Content Type Node Templates that will be shared across all nodes belonging to each of those content types.

If you’d like to adapt this workflow to concrete5, you can go at it like this:

1. Define Page Types for differing
   content

2. Create Page Type template files in your theme directory for each of those Page Types. Be sure to use Global Block Areas in your template files and give them unique names in each template. For example, If you’ve got a “dinosaur” page type and it features a right sidebar, you’ll want to define it like this:

   $ga = new GlobalArea('Dinosaur Right Sidebar'); $ga->display();

Keep in mind:

• If you were to define this as a regular Area it would store unique content for each individual page.
• If you were to give this Global Area the same name in all your Page Type templates, the same blocks would appear in the Global Area no matter what Page Type template you displayed that Global Area in. This may actually be what you want to do for a Global Area that WILL be shared across all pages, like your header Area.

3. Visit pages on the front end of your site and add content “in context” and see how it’s going to look to visitors as you work. You could also visit the Global Areas section of the Stacks page in the Dashboard and add content on the back end.

concrete5 Stacks Vs. Drupal Mini-Panels

Let's say you are using the Panels Node Template approach so you can setup unique sidebar content for each of your content types BUT you also have certain content that will be shared across all pages no matter what Content Type they belong to. We mentioned the possibility of defining Global Areas that span Page Type templates above but you might be after something more akin to Drupal’s Mini-Panels. Concrete5 has you covered.

concrete5 Stacks allow you to create groupings of blocks that work alot like Mini-Panels. Stacks are created on the Stacks page of the Dashboard. Once you create a new stack you can add blocks to it through the Dashboard as if it were a Block Area on a public facing page. Like Global Areas, Stacks allow you to have global control of blocks and the order those blocks are displayed in. Stacks go a step further and can be added to both regular Areas and Global Areas in almost the same way as individual blocks.

Concrete5 Single Pages: Use Them For Custom Application-y Tasks you Might Code a Module for in Drupal

While exploring the concrete5 forums and documentation you will definitely encounter the concept of Single Pages. Blocks are great for creating reusable sections of content and elements that offer basic interaction like contact forms built with the core Form block. Single Pages are the way to go when you need to implement custom, complex CRUD tasks that can or should have a fixed URL on your site.

At their most basic, Single Pages allow you to execute code at a fixed URL in a concrete5 site. If you have developed a Drupal module you have most likely implemented menu hooks to execute functions at specific URLs. Both concepts have essentially the same goal.

A lot of concrete5’s core functionality is built using Single Pages:

• Public facing pages like the Login page and the Registration page are Single Pages.
• The administrative Dashboard is composed almost entirely of Single
  Pages.

Here are some good example candidates for custom Single Pages you might build:

• Complex content creation forms*
• Fixed pages that display data from external databases
• Multi-step public facing forms
• Forms that offering varied fields based on user input

*About those content creation forms:

Composer was added to concrete5 in 2011 and allows you to leverage Page Types, Page Type Defaults and Page Attributes to setup nice content creation forms not unlike the Add / Edit content form in Drupal. Single Pages were the best solution for creating basic content creation forms before Composer. If you find that you need more complex , application-y forms that go beyond what Composer can offer, Single Pages are the way to go.

Check out the concrete5 core team’s eCommerce Add-on and developer ChadStrat’s ProEvents Add-On to see good examples of complex forms implemented with Single Pages.

Building Single Pages

Prior to the introduction of Composer, concrete5 CTO Andrew Embler put together a detailed article on creating a Single Page Powered Page Editing Interface. While today you could achieve almost the same results with Composer, this article remains the go to resource on coding a single page that will allow you to create and edit conventional pages using a form interface.