Hi Everyone,
This is a longish question. but it refers to a very basic functionality that is elementary to many less-powerful CMS, and yet I seem not to be able to so that with Drupal. I hope that this is just because I am new to Drupal and that the community can teach me better. I would also like to encourage the developers to include the answer to my question into one of the introductory Drupal handbooks, as I am sure that very many people wonder how to achieve the same or similar thing.
My background (so that you know on what level to formulate your answers): I am quite experienced in web development and PHP, but I have played around for one day only with my test Drupal 6 installation, so I know almost nothing about Drupal.
Here is what I want to do:
I am building a site to represent an organisation (e.g. a sports club), i.e. not a community site.
My site has many pages ("nodes" in Drupal) that never expire and do not accept any comments. So I use content type "page". The pages shall be edited by editors who know nothing about HTML. All editors are "appointed", there will be no "community" editors who can just register. For simplicity, lets say that a page (node) can contain content sections of 3 types:
- simple text
- simple text with image
- game result
The CRUCIAL POINT here is that:
I am NOT talking about TYPES OF NODES. I am talking about TYPES OF SECTIONS. I.e. a node (page) can contain any number of sections (pieces of content that come one below the other).
For instance one node (page) may contain (in this order):
- simple text
- game result
- game result
- simple text with image
- game result
Some other node (page) may contain:
- simple text with image
- game result
- simple text
The point is that any node (page) may contain any combination of the above sections in any order.
Here, under a SECTION I understand the following:
A "piece" of node (page) content that has a structured input and a templated output. To make it clear, here are some examples:
- simple text with image:
In EDIT mode the editor sees a text field and an upload field to upload an image.
In VIEW mode a site visitor sees the text and the uploaded image in some way/layout defined by the site template.
- game result:
In EDIT mode the editor sees the following fields that must be populated:
- team A (text)
- team B (text)
- end score team A (number)
- end score team B (number)
- description (multiline text)
In VIEW mode a site visitor sees the information in some way/layout defined by the site template.
In most CMS an editor who is editing a page (node in Drupal) can do something like "add a section". Then he will select the section type. The EDIT form will appear and the editor will populate it. He will go on adding more sections as required and then save the page (node). When a visitor VIEWS the page (node) he will see all the sections one below the other formatted according to the template. Note, I am talking about the main content area of a node (page), i. e. this is all independent of any side-menus ("blocks" in Drupal) that may for instance appear according to the category of the node.
Now, of course a developer (i.e. me) has to write the PHP code that:
- displays the appropriate input fields for a section in the EDIT mode.
- saves the field input into the DB.
- retrieves the contents and outputs them in a way expected by the template engine in the VIEW mode.
I am happy to do all that. But what I expect from the CMS is:
- to provide a way to "install" the SECTION TYPES to make them available for use by an editor/administrator.
- to provide an API for the me (the developer) so I know the required names of the functions for the tasks above.
- (ideally, but not strictly necessary in my case) to provide access rights so some editors may only edit sections, while others can add new sections to nodes (pages).
This is all elementary functionality of a CMS. In fact, many simple CMS do not do much more than the above. Drupal, however, does a lot more, but I cannot (yet hopefully) find a way to do just that.
A possible solution would be:
Define a new NODE CONTENT TYPE for every different looking node. E.g. one NODE CONTENT TYPE may define a node containing: simple text - game result - game result - simple text with image - game result. Another NODE CONTENT TYPE may define a node containing: simple text with image - game result - simple text. As I said, I am new to Drupal, but I think that this is what CCK does. However, this is not practical as a page (node) may contain ANY combination of sections of different SECTION TYPES and creating a separate type for each page is not practical, far too complex and cannot be expected to belong to the skill set of editors.
Being new to Drupal I am only beginning to understand the "Drupal mentality", but my understanding of it suggests that one may attempt to do something like this:
1) Create a NODE TYPE for each SECTION TYPE (gives only 3 node types).
2) Instead of creating sections to be placed on a page (node), create a separate node for each section.
3) For each page with several sections that is to be created, create some sort of node that would list the bodies of each of the nodes created in step (2) in some specified order.
Each node created in step (3) would then correspond to a page consisting of several sections. This solution is more practical than the above, but still quite inconvenient. Besides, how to do step 3? I looked as the "View" module, but it seems too complicated to be used by an editor. In order to make this solution practical one would need a more simple module which just lets the editor specify an ordered list of nodes an displays the bodies of those nodes to a site visitor.
Anyway:
- Does this module exist? What is it?
- How else can one achieve what I described?
I have spent quite a lot of time looking for an answer. I believe that I am a good developer and that I can appreciate the advantages of the Drupal API and this system's power. But what I describe is an important and basic CMS functionality and if that is not provided I have to continue looking for an alternative.
I think that an answer to my questions will be useful to many people. Please, do no provide an answer like "see module XXX". Please, do provide a detailed step-by-step answer. I hope that a good answer to my question can be included in one of the handbooks on the Drupal website to help others to achieve this common functionality.
I thank everyone for your replies!
Cheers.
Comments
Though not ready for Drupal
Though not ready for Drupal 6 modules like views and panels are useful in constructing pages like you have described.
Good point
Good point. See here: http://drupal.org/node/259586#comment-852938.
Creating structured content in Drupal
Drupal supports arbitrarily structured content (nodes). There are two ways to do this:
1. Define your new content type by implementing a module. There are examples in the handbooks and at api.drupal.org.
2. Use the Content Construction Kit (CCK) to create a new node type with additional fields, or edit an existing node type. This requires no programming and can be accomplished by filling out a form with your web browser.
After you create your new content type and use it to store some content, you'll probably want to customize the output. The templating handbook has explanations, and the theme developer module is quite helpful.
But back up for a minute and consider how Drupal is developed and organized.
Drupal consists of a downloadable core application that meets the most common needs (basic content management, blogging, commenting, etc.) and provides a development API, PLUS a growing universe of contributed modules that extend that core. The core is kept quite slim. If you're developing a sophisticated site, you're likely to want to take advantage of many of the contributed modules.
CCK is a case in point. A small part of its functionality has migrated into the Drupal core (you can create new content types) but the juicy parts are all still in the contributed universe.
Because Drupal core and contributed evolve separately, at different paces, you may find that Drupal 6 is not quite ready to meet your needs. In particular, the CCK module is only in "alpha" condition. If you're an experienced developer who can help identify and fix remaining issues, your participation would be welcomed.
Another major component, the Views module and its many children, is not quite baked for Drupal 6. Views allows you to query the database and produce lists, summaries, grids (such as calendars), and other interesting data pulled from sets of nodes, all without writing code. Together, CCK and Views are the heart of what you need to complete your project without firing up a code editor and learning the Drupal API.
There are other important contributed modules that can extend the structure of node types, such as the Location module, which adds one to many sets of geo data (address, lat/long, etc.), and the Event module, which adds time-based information. These are separate from CCK but they work together.
These tools are mature and supported for Drupal 5. At our shop we are excited about the D6 core and its many enhancements and improvements, but we are sticking with D5 for projects that have to go into production because of the importance of the contributed modules, especially CCK and Views.
See this documentation:
http://drupal.org/handbook/modules/CCK
http://drupal.org/handbook/modules/views
Hope this helps.
Re: Creating structured content in Drupal
Hi,
this is really good info, many thanks.
But it does not quite answer my question. I tried to be be as clear about it as I could, but maybe not clear enough:
Creating NODE TYPES does not solve the problem directly. I need SECTION TYPES where a node can contain several sections. There many be very many nodes, each containing sections that belong to a few types. Creating a new type for each node is not feasible (see my post: http://drupal.org/node/259586). For instance, even if one had only 2 section types (simple text and game result) and even if a page would never contain more than 3 sections, one would need to define 8 different node types:
* simple text - simple text - simple text
* simple text - simple text - game result
* simple text - game result - simple text
* simple text - game result - game result
* game result - simple text - simple text
* game result - simple text - game result
* game result - game result - simple text
* game result - game result - game result
In addition to SECTION TYPES I need a way to add any number of sections of any types to a page.
Yes, I see that the Views module gives a hypothetical possibility to display all nodes resulting from a query on the nodes in the DB. But it does not quite solve the problem. I tried the Views version for D6:
- I cannot find a way to formulate a query of type "I want nodes x, y, ..., z", where "x, y, ..., z" is an explicit list.
- One cannot specify the display order by explicitly giving a list rather than some rule (date or whatever).
(If one CAN do these things, I would be very grateful if someone would tell me how!)
If the two above things were possible, one could achieve what I want with Views. But it would be very hard and not to be expected to be done by an editor (not developer).
I am surprised that this very common and basic functionality is not available id Drupal - if not in core, than as a basic module.
There must be a simple way - most CMS can do that. But how?
hmmm... thinking out loud here...
I think most problems people have with Drupal are conceptual, and based in wrong terms or vocabulary. I usually try to describe what I think people want to do, and use Drupal terminology. This helps in searches of the Drupal site, or in Google to get the wider Drupal community.
However, I am having a hard time figuring out what it is you need to do, and why the items need the kind of granularity you are talking of? Is there a "KISS It" compromise? Or maybe you would be better off with a bespoke system you build yourself?
Let's assume you are running on Drupal 5.7, with Views and CCK up to date, with nodereference module installed for CCK.
Let's say you make 2 new content types: subnode and metanode. Your site then has "views" showing "metanodes" displaying "subnodes" which contain "fields" information. A sub-node might contain any combination or number of custom fields. The subnode might be a game result for a specific team, and so contain just a Team Name and result, and any other data for that game which is specific to that team. Then you have a metanode in which you have "nodereference" fields. Now, the nodereference is a module that makes a custom CCK field which allows you to use a drop down menu or predictive text to select the right subnode.
How to have custom fields in your subnode. OK, so say you define a new content type: "subnode"
/admin/content/types/add
Fill in the basic info, titles, description, etc. Click "Save Content Type". Page reloads, and click edit to add a field to this content type.
/admin/content/types/subnode/add_field
- Create new field... let's say you want "Integer > Text Field" to keep track of game result. You can add as many fields as you you like, and if you make them not required, then you can use them or just ignore them when you make your content.
Now, you go create another content type called "metanode". Meta node contains the defualt title/body and a custom "node reference" field. Make sure you tick "multiple values" so that you can refer to as many nodes as you like.
When you make your content, you'd have to add in the subnodes before they could be referenced in the metanode. It's way too clunky, and now that I have typed it out, I think I must be nutty.
Anyway... that is ONE way you might be able to get your solution.
I bet someone else would have a better idea.
Re: hmmm... thinking out loud here...
Hey,
many thanks.
I was actually thinking along those lines too. Although I have not yet looked into Drupal's template engine yet I expect that it will be able to do the job of nicely formatting the meta-nodes. But, as you have pointed out yourself, this approach has some problems:
- Inconvenient: you have to first create the sub-nodes and if you want to add a sub-node to an existing meta-node you have to switch between the editing of the sub-nodes and the meta-nodes several times.
- Impractical: "editors" are normally only moderately computer literate people. Not many will comprehend this procedure.
What one really wants is a WYSIWYG style editing of a page (node, meta-node) that allows flexible adding (or removing, reordering etc) or sections (sub-nodes).
Why?
- Because this is provided by almost any other CMS and this is what people expect.
- Because it is the logical consequence of the content-layout separation: the editors work
only with forms that accept structured and validatable data only, layout is fully template driven. If one day the designer decides that all game results should look different, a change in the SECTION TYPE TEMPLATE will be enough to update only the relevant parts of the pages on all affected pages.
Right this minute I am installing Drupal 5 (my first attempts were with D6). D5 has more modules so I will see if I can something there...
Thanks to everyone, but I am still looking for a workable solution, so please keep posting!))
The problem ...
I don't know why you even want this information structured (if not, you could just put HTML into the body field).
You probably need to go to the whiteboard and do some entity relationship modeling. A Drupal node should be an entity, not a collection of entities. In general, one-to-many relationships should be handled either as node relationships (search for the various modules on this subject) or relationships with custom data tables that you implement through a custom module (as seen in the Location module).
> I don't know why you even
> I don't know why you even want this information structured (if not, you could just put HTML into the body field).
See here: http://drupal.org/node/259586#comment-847537
> You probably need to go to the whiteboard and do some entity relationship modeling.
> A Drupal node should be an entity, not a collection of entities.
I can code all this myself, but this is not the point. I do not know the relational model behind Drupal (yet). If I find the system suitable for my needs I will learn it (and other backend stuff), use it and hopefully contribute to the community. But before I can do that I must make sure that Drupal does meet my needs. Frankly, Drupal is the first serious CMS I have ever seen that does not offer what I am describing out of the box. That stuff is very elementary and expected by companies who want to have their websites built. I want to get into Drupal because I have heard a lot of great things about its backend and so I believe that the the functionality I want does exist, I just do not know how to use it.
But at this stage most helpful would be an answer of the kind provided by heather (http://drupal.org/node/259586#comment-847524), i.e. a specific answer. Advice like "look for a module related to node-relationship" is not very helpful. I did. If I would have found an answer I would not post here. Please help. Giving architectural reasons why basic functionality is not there also does not help. As I said - when D is good for me I will eventually become an expert (I want to) and understand all that. But first I need to build a basic test site.
Please keep posting!))
=-=
after reading entire thread, it sounds more like you aren't using the core taxonomy.module to its fullest to pull off what you are calling "sections".
how is your taxonomy set up ?
_____________________________________________________________________
My posts & comments are usually dripping with sarcasm.
If you ask nicely I'll give you a towel : )
How should it be? I see that
How should it be?
I see that a taxonomy function like "list all that belongs to category X" can be used to provide an overview of related articles. Of course one could assign all sections (aka sub-nodes) to some category and then have it listed, but:
- How do I set the order in which the results are listed?
- How do I make sure that the user sees the listing not as a list of teasers, but as a single coherent page?
If the two things above could be done, this could be an approach. How would I go about it?
Cant order taxonomy.
I've investigated this - cant order a taxonomy display in any other way then the default (unsuitable) :((
http://drupal.org/node/10839
Don't forget about
Don't forget about theme-ing... this is where you create a template to pull in different items and display them the way you like. There are so many options with theme-ing.
Have you gotten any closer to solving your task? Did you move onto another CMS?
Drupal doesn't do what you want 'out of the box'... (to add a "section" with varying types and numbers of text fields grouped together). I bet you could get someone to build a module for you though. Have you looked at getting another developer involved? You might be able to get some training in that way too, since you'll be able to work with what they've done.
http://drupal.org/services
http://drupal.org/forum/34
Cheers
Cheers,
I not on a commercial project, so I cant pay anyone to do this for me.
As for theming - it would work I guess, but I want someone like an editor to construct a site, not someone who can hack a theme by building a custom display. Thanks though))
...
That's quite a lot to ask from people. To provide that, I'd have to clean up my sandbox (which is a mess right now), download modules I'm not interested in, and spend quite a lot of time exploring, all for a feature that I've never needed myself.
I have a couple of suggestions, though, which hopefully can be useful starting points for your own exploration.
First a question: How distinct do the sections need to be? For your "simple text" and "text with image", I'd suggest just typing it all into the content part of the node, with suitable header tags and inline images. Admittedly, then you'd risk some editors including several images in a section which was supposed to have only one. I don't know if that's critical, or if it can be solved by instructing the editors.
The game section is a bit trickier, but you could create a simple markup for games, and then use CSS to format the results. Take a look at http://drupal.org/project/Modules/category/63. http://drupal.org/project/customfilter looks promising.
If this isn't distinct enough, I suggest you take a look at http://drupal.org/project/panels. It's not an easy module to use, and if you want to adapt it to non-technical users I suspect you'll have a lot of work in front of you in order to hide all the advanced options for your editors. But it's really, really flexible, and really, really nifty. See http://groups.drupal.org/drupal-education for an example, and http://groups.drupal.org/node/10445 for a video of the admin interface.
Finally, a friendly hint (at least it is meant to be friendly, I hope you read it that way): Posts claiming that some missing piece of functionality is "basic" and "elementary" are slightly annoying. If you read older posts, you'll find a lot of missing functionality that the poster thinks is really, really basic, and (s)he can't believe that it doesn't exist. Or if it does exist, it's so widely used that it should be in core (frequently someone says this about things that I, personally, have never needed and don't expect ever to need).
If you think others will need the same functionality, you are very, very welcome to write a handbook page about it after you've figured it out, though.
On the forum etiquette
I quite agree with you in most respects. I very briefly reply to your points on etiquette and answer the technical things in a separate comment.
>> Please, do no provide an answer like "see module XXX". Please, do provide a detailed step-by-step answer.
> That's quite a lot to ask from people. To provide that, I'd have to clean up my sandbox (which is a mess right now),
> download modules I'm not interested in, and spend quite a lot of time exploring, all for a feature that I've never needed myself.
I agree. However, as I am convinced that this is very commonly required functionality I am expecting that there will be people who already know how to do that. Those people can provide a detailed manual without too much trouble. Of course, I may be wrong.
> Posts claiming that some missing piece of functionality is "basic" and "elementary" are slightly annoying.
> If you read older posts, you'll find a lot of missing functionality that the poster thinks is really, really basic,
> and (s)he can't believe that it doesn't exist. Or if it does exist, it's so widely used that it should be in core
> (frequently someone says this about things that I, personally, have never needed and don't expect ever to need).
I very much agree. But honestly, can you name a single serious CMS that does not provide what I am looking for other then Drupal? I have worked with a number of CMS and I cannot. Of course, there may be some, but the fact that in years of work Drupal is the first I see does mean something, I believe. In the next comment I will explain why this is a really basic function. Looking at the Drupal philosophy, it may or may not be in the base or a module, but I am EXTREMELY surprised that this functionality is not available at all.
Why node sections are so necessary.
Here I'd like to explain why node sections are so necessary and why I believe that it is justified to call it fundamental functionality.
First of all I'd like to thank everyone for the really useful comments. For everyone's benefit I will explain later, what solution I settled on, but before that I'd like to make my fellow developers aware why is the functionality I need so important, why it is present in most other CMS, and why the solution I found so far is not ideal.
Drupal concentrates on community sites, but as it became one of the major CMS on the web, it also aspires to power corporate websites controlled by designated editors only. I am sure, people who, like me, have experience working with corporate clients will agree that they prefer a structured technical solution to having to train their staff to use HTML and other types of "programming" (I know, but that's what they call it). So some of the major requirements to a CMS from the point of view of a corporate client are:
- ease of use
- ease of maintaining the content
- appropriate management of access rights
Some very big corporate clients will be different as they have their own team of web-developers and maintainers and can afford to train stuff, but this is rather an exception.
Now, I must say, I am not really developing a site for a sports club, I only used the game-result section type as an example, but a sports club would be exactly the type of customer who would not be prepared to spend too much effort for learning how to use a CMS.
What one wants it to have certain section types (e.g. game-result, as explained above). One wants to give some users (editors) the right to only use or modify certain section types. You want to also use the section types in order to structure content. Imagine you have a page that first has some text, followed by 3 game results and then again some text. These game results may have nothing in common except that the editor chose to report on them in that article. So a Drupal Views-query would not help. Also, the order in which the game results are to be displayed may also only be defined by what the editor is writing about. So the only way to choose which game-results to display, is by explicitly listing them in the right order. But the editor cannot and will not know or understand anything about IDs. What he wants is to click a button or two (e.g. "Add content" >> "Add game-result") and then fill in a form by specifying the teams and the score and whatever else.
Of course, the editor could use some custom mark-up. But - what if he makes a mistake? And if some of my fellow Drupal developers have also experience in project management they will know that often editors have trouble understanding the easiest technical concepts, and even a simple mark-up may be far too frustrating for them to learn. Besides, it would hardly be possible to introduce access rights for using mark-up.
Mark-up would be a partial solution, but it is suboptimal for both - the developers and the editors. We have to write parsing code and, more annoyingly, meaningful error handling. The editors have to learn new mark-up FOR EVERY SECTION TYPE. Bad idea!
Consider another point. The company decided that from now on all game results have to be displayed differently. This will be possible with the mark-up solution but the people who supported simply coding HTML will as the very least here accept that HTML won't work here. We cannot expect editors to make proper use of styles.
Anyway, I think it should be clear by now that a solution based on forms for editing is the only way to go. This allows:
- Avoiding mark-up for editors.
- Specifying user permission on section types.
- Adding new fields to a section type without forcing people to learn more mark-up.
- Robust input validation.
- Consequent separation of content and presentation.
There are more reasons but that should be enough.
For any corporate client this will be much more important than built-in user registration, advanced taxonomy features or blogging support. I am not suggesting that the node sections functionality should be in core (it would not hurt, but the Drupal mentality of a slim core and lots of modules makes sense and works fine). But the fact that this is not an established module appears extremely surprising to me. If we want Drupal to be not just for community sites, but also for business clients, we need this very much!
In the next comment I will describe how I got this to work so far. My solution is not ideal in respect to the requirements described here, but this is the best I could find.
A possible (but suboptimal) solution
Here is what I did so far.
Actually, I have not done it all yet, I rust did some tests and it seems to work.
Please note, I am very new to Drupal and it is a hobby for me, not my job, so I am investing a limited amount of time.
I used to work professionally in web development a while ago, now I am just building sites privately.
Anyway:
I base my solution on:
- Drupal 5.7 (required modules not available in D6).
- Module Panels 5.x-2.0-beta3 [http://drupal.org/project/panels].
- Module CCK 5.x-1.7 [http://drupal.org/project/cck] (actually I tried this solution only with standard nodes so far, but I expect that CCK nodes should work the same).
I will be creating panel nodes, not panel pages, because I want to retain all the power of Drupal it gives me for nodes. As I am interested in structured content, not overriding the default layout this is the logical choice. Besides, if I was forced to use panel pages, I would loose some of the Drupal's power and then I may be better off with a different CMS.
First I create some nodes that will act as my panel sections. In a previous comment (http://drupal.org/node/259586#comment-847524) they were also called sub-nodes. So far I have only tried some simple page nodes, but I expect that with CCK I will be able to create things like game-result nodes and whatever else I need and then use them in the same way as described below.
Now I go to "Administer" >> "Create content" >> "Panel". I specify a one-column layout, the basic details, click on "submit", and in the resulting view I choose the "Panel content" tab.
Now, when I click on "+" I can add a node. I make sure that after clicking "+" I choose "Node content" from the section "custom" and NOT from the section "node context". (There is an important note about this below.)
So after "+" >> "custom" >> "Node content", a form opens in which I select the required node ID. The node gets inserted and I can see it on the panel. I can repeat this by adding any number of sub-nodes, and I can also easily reorder them. Done.
So, is this satisfactory? I'd say only partially:
(+) With CCK I can define structured content.
(+) I achieve separation of content and presentation.
(+) With CCK I archive using forms rather then mark-up.
(-) I still can only select my sub-nodes via ID. I need to have a second browser open with a list on my nodes where I have to look up their IDs by hovering the mouse over links. Very inconvenient for the editors.
(-) If I want to add a section I have not previously prepared as a separate node, I have to go to a different place in my admin menu, create the node and then go back to editing the panel. Same thing if I want to change an existing sub-node. Very confusing and inconvenient.
Well, more or less it works. Better than nothing. I think that the panel module developers could make a few very easy changes to their module to make it much better for this application. I think that they have simply not considered this use-case of their excellent module and that we should make them aware of it. I will post an entry to their site area later, but I would ask anyone who agrees with my reasoning in this thread to support my request.
Let me discuss these changes:
1. In the overlay form that lets me specify the node whose content should be inserted into the panel, I have to specify a node-ID. An additional possibility to search by title and/or category would be invaluable for editors who find numerical IDs confusing, as well as for everyone else.
2. (more important) You will notice that
"+" >> "custom" >> "Node content"
is only available if you enable
"Administration" >> "Site building" >> "Modules" >> "Panels" >> "Legacy node panes".
If you do not enable this you have to go though a very inconvenient, time-consuming, and non-intuitive procedure of adding an additional context to the panel node for EVERY sub-node you want to add (for details see: http://drupal.org/node/207381).
The developers of Panels say "[Legacy node panes] allows embedding specific nodes into panes without using contexts; this module is deprecated and should only be used if necessary". I find this a big pity. I can very well see that from the point of view of a back-end developer the stuff with the node-context makes a lot of sense. But it does not to an editor! As the approach of doing "+" >> "custom" >> "Node content" is already there, I think that the Panel module would immensely benefit if this procedure was moved to the main module and not be deprecated. Without this, the solution outlined above is simply not workable in practice.
Well, I hope this is useful to the community.
I also hope that this topic will continue and eventually an even better solution for the problem will be sound.
I may contribute to that, but I am not sure, since as I said at the beginning, I have another unrelated job which leaves me only very little time at the moment.
Hope to see more comments soon!
Jumping in...
I've read this entire thread with some interest.
I have 3 observations:
Given that there are hundreds of Drupal modules, developed over several years, by hundreds of very skilled web developers, for hundreds of different types of applications and clients, the lack of a module actually indicates to me that this functionality is not in much demand, regardless of its availability in other CMS. Is it possible (and this is just a suggestion, not a criticism) that there might be a different data model that would create an better product? What I'm suggesting is: instead of staying fixated on forcing Drupal to work the particular way you are used solving this problem, is it possible to step back and look for other types of solutions? It seems unlikely that you are facing a problem never before encountered by a Drupal developer, so I wonder what they did?
Those are the things that occurred to me as I read the thread (along with several that have already been voiced)... I'm fairly new to Drupal, so take this with a grain of salt - nonetheless, I hope it provokes more discussion for you.
Good luck in your quest - I hope you find what you're after.
Yes, but...
> Given that there are hundreds of Drupal modules, developed over several years, by hundreds of very skilled web
> developers, for hundreds of different types of applications and clients, the lack of a module actually indicates to
> me that this functionality is not in much demand, regardless of its availability in other CMS.
Very good point! But years of experience, dozens of happy customers and the opinions of my colleagues who are still in web-development suggest otherwise. I may be well-wrong here, but I speculate that this is due to the strong community-site focus of Drupal and that if modules exist, I either failed to find them (in which case I would appreciate advice) or they have not been published.
> Is it possible (and this is just a suggestion, not a criticism) that there might be a different data model that would
> create an better product? What I'm suggesting is: instead of staying fixated on forcing Drupal to work the particular
> way you are used solving this problem, is it possible to step back and look for other types of solutions?
Also very good point. I though of it, but so far I would not know where I could go on this path. Any suggestion would be greatly appreciated!
> I used a proprietary CMS that had this type of functionality in an organization I worked for - as far as I know, it was
> never actually used. Editors generally created articles with one "formatted" section and some simple text.
> I don't recall ever seeing pages where multiple sections where interleaved like the examples you provide (none
> of which make much sense to me in the context you provide). Perhaps if you could provide a more compelling
> use-case, someone could suggest something more helpful.
I have very different experiences here. You just need to show people. It is easy to show someone how to use a form, much easier then showing how to to mark-up or anything similar. Some "technically versed" users initially resist, but once with proper user rights this has been established, the site becomes much much easier to maintain.
> If I'm wrong, and in fact this functionality is essential to corporate CMS (I do community sites, so have no idea),
> then you'd be doing the Drupal community a huge service by creating a module specifically designed to do what you want [...]
I agree, and I'd like to. I help people where I can (track my posts if you like). But at the moment I simply cannot afford the time and I need something that works. I have an unrelated job and I am involved in other open-source projects (e.g. http://www.live-graph.org and others), where I belong to the lead group and which must thus have priority. :((
I either failed to find them
Drupal Modules http://drupalmodules.com/ has a FANTASTIC module finder - it is lightening quick and does an "as you type" refinement on your search terms, making it really easy to try a bunch of different searches. Easiest way to find modules, hands-down.
It also provides a module rating system - something that I would find very useful to separate the wheat from the chaff - but it is brand new and there are few reviews in yet, but it looks promising.
Again, best of luck - merlin (Panels maintainer) is a seriously sharp developer, I suspect if you show him a good idea, he'll work with it.
I'll try that
Thanks, I'll try the site.
I have also already posted corresponding feature requests for Panels (http://drupal.org/node/259586#comment-852972).
Let's see what they say))
Links to Panels module feature requests discussed here
I have submitted the feature requests mentioned above to the Panel module developers.
Everyone who thinks that it is idea is welcome to report the requests:
http://drupal.org/node/261383 (moving the "wrongly deprecated" easy way to add nodes into the main module).
http://drupal.org/node/261385 (adding a node search facility when choosing nodes to add to a panel).
imagining things
I'm pretty confident in saying your functionality does NOT exist already, but I can imagine something like it. Now, mind you, this is just crazy talk here:
Anyway! What if it was built with AJAXy style responsive fields. The User selects to make a node; and then they can choose dynamically what types of fields to add. Add a text field here, add an image field next, or select any number of whichever other types of fields.
SO- a WORK-AROUND kinda of solution might be to create a custom content type with CCK; and set it up with loads of text and image fields. Like, alternating image and text fields, say 20 times. Then, by customizing the form with some kind of AJAXy form magic (I am talking out of my ear here), they could choose to reveal the fields. But of course they would be limited to the number which you maxed out at when you set up the content type. So in the sense the users are just choosing to leave whichever ones blank in any order. And when you theme, the empty fields won't display.
Am I making sense?????
Now if you have another CMS which does something like this loads better, the question begs... why not stick with the tool you have already?
-----
Well, not sure if you're the very first person or not to tackle this technical problem, but you aren't the first person to come and wonder why something you were looking for didn't exist, or why things weren't done as you expected them to be. This handbook document is actually good advice: "How to Enact Change in the Drupal Community" http://drupal.org/node/36602
Honestly, any advice about etiquette stuff is really just mentoring, as they say we all try to AssumeGoodFaith.
Best of luck to you!
hm... quiz module?
i haven't tried this module, so i have no idea how it works-- but i have a notion it might point you in the right direction. you could install it and see how it works.
http://drupal.org/project/quiz
the quiz module allows an editor to create a series of "questions" which could just be test fields... and i'm assuming then they don't have to say exactly how many text fields. anyway... solves one part of your problem... maybe?
The discussion seems to be dying
The discussion seems to be dying :((
I'll post here again when I am done building the site and report what I have done.
But I will probably use the panels approach described earlier.
Cheers!
Keep us posted
I would certainly be interested in hearing about your progress and agree that the ability to create content in the manner you describe is a fairly standard feature of many CMS applications.
hows it going?
i am curious how things are coming along...
i talked about your problem with a friend, because it is now similar to something i want to do- and this was his recommendation. however, i only need to repeat one particular node type, so it makes it easier.
Good luck!
------------------------------
"Knowledgeable in Some Matters" http://nearlythere.com/
Anybody know how to use
Anybody know how to use http://drupal.org/project/related_subform. There is zero documentation, and installing doesn't give any pointers for getting started.
Old thread, I know, but
Old thread, I know, but interesting.
First, Gragus, I think your mind-map and requirements are totally reasonable. Most of what you are wanting makes a certain amount of sense. However, I personally can't name a CMS I've worked with that achieved exactly that in a user-friendly way successfully or without a lot of custom tricks. So your expectations are clearly different from mine.
The idea of content re-use or content modularization is also right (I think). From this is follows (to my mind) that each set of results (for your example) is a node type in itself, and your core page is a composite. Among other things, this means that 'results' can be indexed independantly, or (If I imagine your case correctly) the same 'result' could be posted on both competing teams pages.
All good info-structure so far.
Much of it could even be done with node_reference and some theming.
The problem, which I think you've partially acknowledged, is the UI.
Either those chunks are created beforehand and glued together later (frustrating and unintuative) or you create some mad AJAX form which expands to include unlimited, arbitrary content-type chunks as sub-content of your page edit form.
It could be attempted without AJAX also, but would still be scary.
It's not impossible, but it's probably hard to do well. And simply, hasn't been done yet.
If I was coding it, I'd start with node_relation, and extend the widget to embed (part of) the linked sub-node form into the node edit form. You'd get a result. It wouldn't be the most elegant, but it would be 80% of the way there.
Note you also need to support ordering of the attached content blocks, and that's boring to code a UI for.
ALTERNATIVELY
.. and more practical for a small budget, is to take the first option (making the content blocks beforehand) then refer to and embed simple views directly into the HTML using a filter with markdown - like reptag.module.
... That's a little harder on the editors, but You may even be able to add a WYSIWYG widget to assist in that. Heck, even a JScript pop-up that helps you create content chunk node on-the-fly.
Y'see, for me, your challenge is all about the UI.
The data management tools are there in Drupal. It's pulling them together in a way that suits your editors workflow that's hard.
.dan.
How to troubleshoot Drupal | http://www.coders.co.nz/
.dan. is the New Zealand Drupal Developer working on Government Web Standards