So - excuse my ignorance - what is the difference between writing a module that does exactly what you say (i.e. packages logic that helps a magic field of some sort that could be used with any type of node) - via node form altering and the forms api?

Ignore CCK and Flexinode or what Drupal 5.x does. Consider, for a moment, a module that oh, I dunno, allows you to define your emotion when you're writing something. After the user has Written Something, they can say they were Happy, Angry, or Sad. Now, for the purposes of this thread, the "old" way is: * a brand new node type that includes Title, Body, and Emotion. * you use hook_update, hook_insert, hook_form, etc., etc., to define a new node type called "Emotional Story". With the above added to Drupal, we now have the core/default Story node type with Title and Body, and a new Emotional Story, with Title, Body, and Emotion. To add an emotion, you MUST use this new Emotional Story node type you've created. It has no correlation with other node types. Following so far? It doesn't matter what you do with the Emotion field. You could program some logic in to get all Emotional Stories that were Sad, or to delay publication of Angry Emotional Stories until the next morning, when you have a chance to reread them a little calmer. This is what makes your module cool: not only by having this great Emotion field, but also Doing Something with it. Now, for the purposes of this thread, the "new" way is: * in admin/settings/modulename, show a list of all node types. * allow the user to choose which node types the module applies. * using hook_nodeapi to add your Emotion field to those node tyspe. This is quite a different design. Instead of enforcing your own Emotional Story node type, you're now allowing the user to pick which node types they want your Emotion field to be applied to. With 4.7 or 5.x, they could say "you know, I want Emotions to apply to both Story AND Page". Then, when they create a Story or Page, they see the provided Title and Body by core, but also your Emotion field, as inserted via a hook_form_alter. Your data is saved via hook_nodeapi 'insert' or 'update', assigned to the node with 'load', deleted with 'delete', etc. You'd still continue to provide all the same logic as above (with Pages and Stories with "Angry" Emotion being delayed until tomorrow, Pages or Stories with "Sad" being viewable at a custom URL, etc.). You're just going about it a slightly different, but far more flexible, way. Now, consider if every module started doing things this way. I can name three off the top of my head that do: Event, Case Tracker, and Organic Groups. Consider the following: * I start off with a default Page node type provided by core. * I value-add the Event module to it - now Pages are also Events. * I value-add the Case Tracker module - now they're also Cases. With a few mouseclicks, I have taken a default core type (Page, though it could also have been any other node type, or one created by CCK, etc.) and increased its capacity two fold: it is now a Case and gets all the logic (and fields) of Case Tracker, but is also an Event and gets Start/End times, and shows up in the calendar and is filterable with Event's dropdown filter. Adding Event Repeat, a plugin to Event, isn't a problem either - now Page is a Event Repeat(ing) Event that is also a Page that is also a Case. Later on, I install your module, choose that I want "Emotion" to apply to Page, and now have a Page that is an Event Repeating Event, a Case, and Emotional. You can't do this under the "old" way, because the user is stuck using only your Emotional Story node type. Sure, "new" way modules could be used to expand upon Emotional Story (making them also an Event and also a Case Tracker Case), but when the flexibility exists to add fields + logic to /any/ node type, as opposed to shipping one, you should use it. It's quite rude to think that I have to use just YOUR node type when all 900 of my other nodes are "Story", and now I have to abandon them and use "Emotional Story" instead. This is the heart of what Jaza was getting to, and why it showed up in a discussion upon hook_nodeapi(), which is the central Drupal hook that allows us to pull all this off. -- Morbus Iff ( the power of grayskull compels you! ) Technical: http://www.oreillynet.com/pub/au/779 Culture: http://www.disobey.com/ and http://www.gamegrene.com/ icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus

This possibility is in Drupal since I work with it (at least since 2003). There is no "new" or "old" way. It was possible since a long time to write node extending modules, like scheduler for example. The sad

You'll note that I very specifically: * said "for the purposes of this thread" * put "old" and "new" in quotes. I did this because: I Know Already. -- Morbus Iff ( worship the computer and continue to live ) Technical: http://www.oreillynet.com/pub/au/779 Culture: http://www.disobey.com/ and http://www.gamegrene.com/ icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus

On Thu, 4 Jan 2007, Gabor Hojtsy wrote:

On Thu, 4 Jan 2007, Morbus Iff wrote:

...

You can't do this under the "old" way, because the user is stuck using only your Emotional Story node type. Sure, "new" way modules could be used to expand upon Emotional Story (making them also an Event and also a Case Tracker Case), but when the flexibility exists to add fields + logic to /any/ node type, as opposed to shipping one, you should use it. It's quite rude to think that I have to use just YOUR node type when all 900 of my other nodes are "Story", and now I have to abandon them and use "Emotional Story" instead.

This possibility is in Drupal since I work with it (at least since 2003). There is no "new" or "old" way. It was possible since a long time to write node extending modules, like scheduler for example. The sad fact that event and some other modules were not written this way from the start does not imply that they do anything new by morphing to be node extensions. Even core modules like taxonomy and upload build on this feature. Poll is one example of a core node type, which is often asked to be programmed as a node extension instead :)

I looked it up, because I was interested in finding this out :) Kjartan added the nodeapi hook in version 1.185 of node.module (Sun Feb 16 14:57:35 2003 UTC). This is nearly four years ago (but of course it was not as powerful at the start as it has grown from then on quickly). The change Kjartan has done: http://cvs.drupal.org/viewcvs/drupal/drupal/modules/node.module?r1=1.184&r2=... Gabor

Hello, What is the process to 'fix the situation' when the module developer does not respond to any posts about his/her module via the 'issues' process and does not do anything when users contribute patches to fix bugs or add features? And, to make it more difficult, some developers have set their profiles so that they cannot be contacted via email, meaning there is no direct way for a user to communicate with them. I understand not wanting to be bothered, of course...but how does one know if they have 'lost interest' or are 'just busy'? I did find a good thread entitled "Encouraging Collaboration" here: http://lists.drupal.org/archives/development/2005-11/msg00505.html and also some useful info in the Drupal handbook: 'joining forces': http://drupal.org/node/23789. And the CVS account application states: "If you have been asked to co-maintain an existing module, please link to an issue where the current maintainer explicitly states so." But none of these resources tell an eager user what to do to help maintain a contributed module when there is no apparent way to contact the 'official' developer. I see from several posts that some *new* contributed modules are created...in spite of the fact that they create a "duplication of effort "...for this very reason: unable to communicate with the developer of a similar module. I know there might already be some process by which contributed modules are 'dropped' or 'put up for adoption' when they are unmaintained, but I could not find any documentation on the subject. Please forgive me if I have posted to the wrong list with this topic. Guidance on where else to go for help is appreciated! Thank you for your input, Jill Elaine

On Thursday 04 January 2007 2:31 pm, Morbus Iff wrote:

With a few mouseclicks, I have taken a default core type (Page, though it could also have been any other node type, or one created by CCK, etc.) and increased its capacity two fold: it is now a Case and gets all the logic (and fields) of Case Tracker, but is also an Event and gets Start/End times, and shows up in the calendar and is filterable with Event's dropdown filter. Adding Event Repeat, a plugin to Event, isn't a problem either - now Page is a Event Repeat(ing) Event that is also a Page that is also a Case. Later on, I install your module, choose that I want "Emotion" to apply to Page, and now have a Page that is an Event Repeating Event, a Case, and Emotional.

You can't do this under the "old" way, because the user is stuck using only your Emotional Story node type. Sure, "new" way modules could be used to expand upon Emotional Story (making them also an Event and also a Case Tracker Case), but when the flexibility exists to add fields + logic to /any/ node type, as opposed to shipping one, you should use it. It's quite rude to think that I have to use just YOUR node type when all 900 of my other nodes are "Story", and now I have to abandon them and use "Emotional Story" instead.

This is the heart of what Jaza was getting to, and why it showed up in a discussion upon hook_nodeapi(), which is the central Drupal hook that allows us to pull all this off.

I fully agree that value-add nodes offer a great deal of flexibility and are, in general, more powerful. I'm launching a site on Monday where we don't have any nodes that aren't CCK-defined. Even page.module and story.module are disabled, and then we value-add with event.module. That's been a huge boon for us, especially because CCK auto-supports Views and Views runs half the site. :-) My question boils down to edge cases and HOW that value-add works. For example, event.module. In the current system, AFAIK, event value-adds via form_alter some select boxes and radio buttons to a node-edit form and then via FAPI magic (or _nodeapi magic, I honestly don't know) validates those select boxes to a valid date, ensures that the start date/time is before the end date/time, etc., and then saves them to its own event table as unix timestamps. Then on _nodeapi#load, it adds those fields back onto the node object and all is well. But, now there's this great date.module that offers a self-validating date field for CCK nodes. A time.module or even datetime.module that offers time/date-and-time validation is certainly feasible, and would allow even greater flexibility in terms of how its rendered (select boxes, textfield, JS popup, etc.) If event.module could value-add a rich field like that, that simplifies its code considerably, simplifies the database, and opens up all sorts of other fun options I can't even think of. But how does one value-add a CCK field? Or would you have to tell the user to add it and then select which field is the "start" and which is the "end"? I don't know of a way right now. That could be because there isn't one, or could be that I just don't know what it is. :-) Or take my one contrib module of actual significance <g>, nodereview. Right now it's a fully module-defined node that leverages votingapi.module. Each node consists of a reference to a node being reviewed plus an admin-defined number of "sets" of fields, where each set consists of a textual review plus a votingapi rating. Yes, that makes a variable number of fields on a node, depending on what the type of the node being referenced is. Kinda funky. :-) For upgrading it to Drupal 5, I've been debating how if at all I can leverage the semi-CCK in core now, or even full CCK. I could easily replace the reviewed_nid field with a nodereference that gets form_altered. What about the others, though? Define a custom field type that is an aggregate "axis" with 2 internal widgets? And then how to do I piece those together without requiring the user to then custom build each review node on their own according to specific rules before it becomes useful? (No, this isn't a plea for help on the module; it's just an example I'm very familiar with.) That's one reason I said earlier that CCK import/export a la views was important, and I plan to look into the content_copy.module Moshe mentioned earlier sometime this weekend. But hopefully you see my point. I *want* to be able to leverage rich field types from CCK and just plug-and-play content types. I just don't see how that works for complex and conditionally-configured nodes. If there's some vision (no, I won't say roadmap <g>) for how that can happen now or will happen in the future, please let me know. I like the direction nodes are moving and want to stay with the curve; I just don't see how the edge cases are going to work. -- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson

Thanks for the detailed and clear explanation, Morbus. But it sounds like this "new" flexibility is a result of hook_nodeapi() and hook_form_alter(), not CCK. Is that right? Rest assured I won't be trying to define any new node types when there are better ways to do it (e.g. Mark Fredrickson's comments). Perhaps I'm confusing two issues here. I'm worried more about having all nodes burdened with CCK's overhead than I am about not being able to have module-defined node types -- as long as there is a way to do what I need to do. For example, I have an old module which defines a new node type where every field in the node is new and unique to my module. It sounds like from Morbus' description, I can still do that without being able to define my own node types -- I can do it instead by "value adding" with hook_form_alter() and hook_nodeapi() my data and _behaviors_ onto an existing basic core node of some sort. That works for me -- if those basic nodes won't be dog slow when we start talking about proximity searching 10 million of them, for instance. Feel free to further "educate" me. :-) ..chrisxj

On 1/5/07, Chris Johnson <cxjohnson@gmail.com> wrote:

Feel free to further "educate" me. :-)

My pleasure. :-) If you find yourself just trying to wrap common data (text, node ids, dates) considering using CCK widgets. Widgets are the user interface that get data into a well formed state for storage in a field. A field can have many widgets (they are easy to add via additional modules). Eg. for nodereference, there is a select form widget and an autocomplete based on title widget. I recently created a widget to use Views to select nodes - way cool. It's an easy way to add value to existing data types, without writing your own field from start to finish. So, is your data unique (ie. it nees special storage) or is the user interface to your data unique (ie. you could use widgets to replace your custom behavior)? -M