Overview of Drupal Content Layout Modules

Posted by idcm on October 19, 2010 at 9:02pm

When you build pages in Drupal, you typically plan your layout and assemble your pages within the structure defined by your theme. This concept is discussed in the Planner's Guide chapter Create a Design Plan.

In this short tutorial (http://planningdrupalsites.com/training/overview-drupal-content-layout-m...), we will expand on these concepts and explore how you, as a builder, can change your structures and layouts without editing your theme.

Once you have taken this short tutorial, sign up for Hands-on Intro to Drupal Content Layout Modules at http://planningdrupalsites.com/products/hands-intro-drupal-content-layou...

Comments

Does it cover how you move

Posted by valeriod on October 20, 2010 at 12:31am

Does it cover how you move all these settings from development to production or does it assume that you are working on a live production site?

Does it cover ... I assume by

Posted by idcm on October 20, 2010 at 3:13pm

Does it cover ...

I assume by "it" you mean the course? Yes and no. Because so much of this layout configuration is stored in the database, you would need to plan for that. Here are some strategies:

Some of the modules referenced are one or two clicks and you are set to go. I would simply do those manually.
But for a module like Panels where you can spend a lot of time configuring, I would use its export/import feature.
Then I would look at using the export/import features of the other modules you might be using to transfer from dev to prod
Lastly, I would look at the Feature module to see if it can bundle up the remaining items.

Side note - As for Composite, if you don't have the same nodes in dev as you do in prod, I don't see what you would be transferring.

Without knowing how all these modules work alone and with other modules, the formula for migrating from dev to prod will vary.

I hope that helps.

Thanks, very helpful. I

Posted by valeriod on October 20, 2010 at 8:37pm

Thanks, very helpful.

I always look for good ideas on how to improve the dev->qa<->prod process.

While code can be under version control the database settings are always an issue. I think we should look at creating an API so that a module that wants to implement a promote-to-production process can get/set configuration data to/from other modules.

I'm not a fan of manual processes and unless you update version controlled files with the export content there is no way to revert back to a known state.

database backup

Posted by idcm on October 21, 2010 at 10:37am

I'm not a fan of manual processes and unless you update version controlled files with the export content there is no way to revert back to a known state.

If understand this correctly, I would there is an option. It isn't fun but it is called a database restore. Put the site into maintenance mode before adding a module (which is good practice anyway), take a snap shot of the database, update the site. If it goes wrong, do an uninstall on the module in question and if need be, revert back the backup database.

BUT, yes, manual is not fun.

Most of my sites wouldn't

Posted by valeriod on October 21, 2010 at 2:21pm

Most of my sites wouldn't tolerate an hour of downtime... or even 30 minutes Furthermore what happens if you find a problem after a day or two?

We do changes on a continuous basis so we really need to have a version controlled, automated and reversible system.

The way I implement this now is to stay away from any module that stores data that will need to be changed often in the DB. Views are transferred by exporting them into a sitename_views.module that is disabled in dev and enabled in production so all the views go into svn and are version controlled. All the functionality is implemented in custom modules.

It works well but it would be nice to be able to use more modules, that's why I think an API or hook would be great. It would also help with getting some other things under better control like the user permissions that right now are a nightmare.

Looking at your previous answer though I think that you pointed me in the right direction! How about using and extending the import/export facilities so we can script them?

it's hard for me to imagine

Posted by idcm on October 21, 2010 at 4:25pm

it's hard for me to imagine the API but I am not one to argue about stuff I don't know.

Please don't forget to explore Features. The guys at developmentseed are always working to improve the modules they create and they are all about productivity. Features is the next module I will be exploring.

VERY INTERESTING! I'll

Posted by valeriod on October 21, 2010 at 7:45pm

VERY INTERESTING! I'll definitely look into Features.

Thanks.

Check out video on using features for deployment

Posted by nessumsara on October 26, 2010 at 2:03pm

Check out this session by Jeff Miccolis from Development Seed at Drupalcon San Francisco which shows how features can be used to do exactly what you're talking about. It includes the capability to revert to earlier versions and stores your configuration settings in a module which can then be incorporated into your version control system.

http://sf2010.drupal.org/conference/sessions/managing-and-deploying-conf...

THANK YOU, THANK YOU, THANK YOU!

Posted by valeriod on October 26, 2010 at 3:51pm

"No distinction between configuration & content"

This is exactly the problem that I had for years and apparently I haven't been the only one. I have implemented a portion of that functionality with views but they have really developed the whole workflow.

BTW the lack of distinction between configuration & content is not actually a design flaw because there is a gray line between the two. For example on some sites I consider a taxonomy a configuration. The beauty of the features approach is that lets you define what is configuration and what is not.