This is the documentation for concrete5 version 5.6 and earlier. View Current Documentation

Stacks

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.

From concrete5 for Drupal Developers and Designers by Chris Hvizdak

Attributes

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 resouces 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');

Page Types

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:

First, define Page Types for differing content.

Then, 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.

Lastly, 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.

Loading Conversation