I would like to create a content type which splits a page content into sections and creates actions upon those sections. This would provide a way to structure a page of content when using sub-pages or a WYSIWYG editor is not an option. I think that this could be really useful.

I am wondering whether this is available as a module (I have looked, but can't see it, and you never know - I could have been looking in the wrong place!), or whether someone has created something similar.
I realize this is probably possible using cck fields and fieldgroup - but wonder whether it could be done in a less hackish/simpler way - perhaps with a custom module?

The problem:

A page contains a lot of data, which could be split into sections to make it easier to read and navigate. Sub-pages and using a WYSIWYG/html is not an option.
When the user goes to create the page, they see:

Page title field:      __________________________________

Section 1 title field: __________________________________
Section 1 body field:  __________________________________

Section 2 title field: __________________________________
Section 2 body field:  __________________________________


Section n title field: __________________________________
Section n body field:  __________________________________

The user fills out as many sections as is required, and the page is created. This finished page looks like:

*** PAGE TITLE ***

In this section:
- title 1 (as a link to anchor tab below)
- title 2
- title n

Li Europan lingues es membres del sam familie 
lor separat existentie es un myth, por scientie.
Li Europan lingues es membres del sam familie 
lor separat existentie es un myth, por scientie.

                                      back to the top ^

Li Europan lingues es membres del sam familie 
lor separat existentie es un myth, por scientie.
Li Europan lingues es membres del sam familie 
lor separat existentie es un myth, por scientie.

                                      back to the top ^


Li Europan lingues es membres del sam familie 
lor separat existentie es un myth, por scientie.
Li Europan lingues es membres del sam familie 
lor separat existentie es un myth, por scientie.

                                      back to the top ^

So when the page is created, the list of links ("in this section") is dynamically created from the section titles, as are anchor tags for all of the titles on the page. I have a wish list of functionalities:

  1. Users can add as many sections as they like - a pre-determined number of sections would be available to start with, then more added if required after node is previewed/submitted.
  2. First section on edit form is visible, the rest are in collapsible fieldsets (to stop the edit form from growing huge).
  3. Ability to add extra fields to the sections e.g. image fields or other cck field plug-ins. Add one field to one section and it's available to all sections.
  4. Ability to add extra fields to the page - i.e. a master description field/image field that appears above the sections/in this section area.

Has anyone come across this, or can anyone recommend anything which is similar?

Many thanks,


Shai’s picture

CCK is not a hackish way at all to approach this. If the page is significantly complex, then there might be performance issues, but I don't get why CCK would be considered hackish.

Understanding the use case would help.

Regarding actions, you might need the workflow or workflow_ng module to go with it.

Best of luck,


baronmunchowsen’s picture


Thanks for your response. I guess 'hackish' is the wrong word, but I can certainly see limitations to using CCK - or perhaps I am wrong?! Namely the performance issues. Say for each section I require not 2 fields, but 6... or more:
- Title
- Introduction paragraph (multi-line textfield)
- Body (multi-line textfield)
- File field (multiple attachments)
- Image field (using image cache and multiple values)
- Node Reference field

Then combine this with the fact that some pages will have 2 3 sections and others will have 9.

Using CCK I would have to create 9 groups (sections), all of which contain the same 6 fields. That's 54 fields for one content-type (minumun as some have multiple values), and in certain situations I might only be using 2 sections (12 fields out of 54).

2 possible solutions to this:

Create a number of different content-types with increasing # of sections, e.g.:
- two-section-page
- four-section-page
- six-section-page
- eight-section-page

or, in a magically ideal world:

Create a content type that has one group (section) with all the desired field in it, and somehow make this group of fields allowed to have multiple values - so you'd be able to keep adding and adding groups at the content creation level.

Does anyone know how/if this would be possible?

Shai’s picture


It would really help to visualize a solution if you gave a specific use-case, not a generic use-case. For example, "We have a site for little-league administration and each family needs to sign-up.... etc."

Are your "sections" repeating instances of collecting the same kind of data, or are they for collecting different data but only show up based on certain conditions?

When you say the "same six fields" -- in CCK-speak a "field" is really a field definition independent of its attachment to a particular point in the data model. A more typical sense of a "field" includes its "definition" as well as its placement in a data model. If you mean "the same six fields" in this latter sense, then it sounds like your "sections" serve to collect data for multiple nodes, of the same type, on the same page. What you want is multiple node/add forms to show up on the same page. If that is the case, Drupal can certainly do it, possibly with a little custom coding needed but not much.

As I said, a more specific use-case example would really help us help you.




baronmunchowsen’s picture

I can give you an example for sure:

Consider a website for a local government website.

There is a page about garbage.

Within that page there are sections:
-Garbage Collection Dates
-Recycling Resources
-Landfill Fees

Each of these sections have their title, a couple of paragraphs of text, an image and some links.

In another section of the website their is a page about the sports centre. This has the following sections:
- Gym
- Swimming Pool
- Ice Hockey
- Drop in Soccer
- Creche Facilities
- Outdoor Pitches
- Curling League

Each of these sections have the same fields as above.

Your multiple nodes on one edit form sounds intriguing, can you tell me more about this?

As an example, this is the sort of thing that I have been looking at as an example for the end result:


Note how the top of the page has links to the anchor tags below - but the blocks below are not teasers, but just blocks of relevant content.

Shai’s picture


Okay, now I can get my brain around what you are talking about.

The first question you need to ask in approaching a problem like this is, "What parts of my content are dynamic (change often) and what are static or relatively static (don't change very often).

On the New York government web site, the various listings of "Academic powerhouses" and "Whos here" are not meant to be complete listings. The web managers unlikely have the goal (at least for the purposes of that page) to maintain a complete database of academic powerhouses or companies that do business in New York. Rather those lists serve to illustrate a point being made in the article as a whole. So that page is actually an example of a page whose content is NOT dynamic. Simply using the "body" field that comes with every content-type in Drupal would be a fine place to put that whole article, including the listings that illustrate the various examples. If the article content or the examples need to change, then an editor with the sufficient privileges edits the article and makes the changes. Just because a list may be involved doesn't necessarily mean that the data, when used for a particular reason, is dynamic.

Let's use the other example for content that might be more dynamic and require a somewhat more complex solution. Let's imagine that up-to-date listing of facilities, their hours, usage, availability etc is indeed a data set that needs to be comprehensive and current. I'm thinking of the gym, curling, etc. example now. So you create a content-type called "Sports facilities" and you create relevant fields: address, hours, cost, rules, etc. That information is available to be displayed in any number of ways on your Drupal web site, with the help of the Views module and the Insert View module (you can also embed a view programmatically). So let's say I'm creating a web page about the advantages of living in this city. And some place in the narrative I want to include a listing of the sports facilities. I don't want to include the rules, or even the hours, just the name of the facility and its street address. I go to views and I create a View that show just the fields I want. That "view" has a name. Using the Insert_view module I put the simplest of "code" in the body of a node (e.g. [view:sports_facilities_names]) and when that page gets rendered it will include the listings of the names and addresses of the sports facilities. Somewhere else on the site I'll collect a list of the full nodes for each of the sports facilities which will include many more of the fields. The data set for each facility is maintained via the same individual node. No multiple maintenance of data. And that data is just waiting for someone to propose its presentation in a different possible way.

Hope this helps,


baronmunchowsen’s picture


Thanks so very much for taking the time to respond to my post.

I am familiar with both the suggestions you have put forward.

My Content is static.

I want to avoid creating multiple nodes of the same-content type and using a view primarily because I want the client to be able to go to one page and edit all the data on that page. For example, I want them to navigate to the 'garbage' page, click 'edit' and for them to be able to change all the various sections within that page - recycling, landfill, pick-up times etc. Using a node-type (dynamic) solution would mean that they would have to navigate to all the sub-pages and edit those sections. individually, to see the garbage page change. This would also create individual nodes in the system for recycling, landfill, etc when ideally all I want is one, big garbage node.

I don't want to use only the body content field as I want to avoid using a WYSIWYG editor, and my client doesn't know HTML.

I also don't want to use only the body content field as I want to dynamically create a list of sections which are created within that page (in the case of the NY link I sent you can see these links at the top which link to the sections within the page).

In short, I would like a dynamic solution to a static problem.

I realize that this probably seems like overkill, but I do think that this is valid and does have applications.

-------- Edit ---------

I drew a picture:


Shai’s picture

I hate Dreamweaver.

But it is a LOT better than TinyMCE -- I feel your pain regarding a web-based WYSIWYG.

You might respond, "Too many steps, 1. click on node/edit, 2., copy all text, 3. Open DreamWeaver, 4. Go into source mode, 5. Paste text, 6. Go into WYSIWYG mode, 7. Edit doc, 8. Go back into source mode, 9. select all, 10., copy 11, go back to browser node/edit, 12. Select All 13. Delete, 14. Paste. 15 Submit."

But this is the way to go. A training screencast for the client would really help. I could make one for you if you want (for a fee -- that isn't why I recommended it though).

It might be possible that there are interactive javascript or other client side solutions, but I don't know much about them.

You certainly don't want to mess with your data architecture for the sake of working around a WYSYWYG problem for static content. My 2 cents.



baronmunchowsen’s picture

Hi there,

Thanks, but dreamweaver won't automate the process as I'd like and also the client won't want to go through that many steps to create their content. There are workflow issues involved also, with content being created and then edited and then approved and then published to the website.

Seems like CCK would be the easiest way, but may well impact performance.

Does anyone have any advice/recommendations/thoughts on how a custom module which used CCK could be created to achieve my goals?


askibinski’s picture

found this older thread via Google when I was looking for something similar, and others may too, so:

I think this functionality now is easily realized with CCK 3.0 and it's multigroup module (currently only available as a -dev).
see also http://mostrey.be/cck-3-introducing-multigroup-module

Another option would be flexifield

Albert Skibinski - ezCompany