I defined two content types. One can be seen as the parent node and the other would be a child node. For each parent node, one will always have many children node. Those content types share many taxonomies and CCK taxonomy fields definitions. Children nodes have a nodereference to their parent node.
I'd like to save time by making children nodes inherit and store automatically terms of most the CCK taxonomy fields filled in their parent node. The main idea is not only to display those inherited terms on each child node (Views could be helpful for that), but above all to have them recorded as own metadata in each child node. And eventually, to make those "children nodes" directly searchable through a faceted search based upon my taxonomies.
As a non coder, I have spent a lot of time searching a solution with D6 contributed modules, but I didn't find any honest answer yet. I don't dare using Computed field for that, since I feel that a taxonomy field is a very particular kind of data. Do you know a way to achieve that ? Any idea ?
[Edit: title changed on 06/28/2009]
Comments
Inheriting taxonomy
Hi,
I've been looking at doing something similar. I was looking more at a code solution, as I haven't seen an existing module that does this, although a modification to an existing module might do it.
Taxonomy defaults - http://drupal.org/project/taxonomy_defaults - does something similar, but not quite what I need, as the new node gets a pre-defined term attached. There's also the prepopulate module - http://drupal.org/project/prepopulate - but you'd need to modify the links that create the node-reference.
And there's still the question of syncing taxonomy changes when the parent is updated... The only issue I found about that (http://drupal.org/node/59156) dates back to 2006! If you only need to display the taxonomy terms of the parent, then you probably use Views relationships to do this, but I really want the child nodes to inherit a 'section' taxonomy term so that the taxonomy-based navigation maintains the active trail. I'm all ears, if anybody has any advice...
Thanks
Thanks for your reply, matkeane. Those modules are interesting, but they won't fit my own needs, I'm afraid. And you're right, the Views solution doesn't fix the inheritance problem. I miss something like Field Thief or Field Copy modules but for D6 and with cck taxonomy fields support. I was also thinking about Nodereferrer Create ("When creating related content, it is possible to use fields of the original node as default values for other fields in the newly created content"), but it's in development stage and I still need to be sure that it supports CCK taxonomy fields... I posted my question in the issue queue.
Field thief
Ah, that's interesting - I didn't know about the FieldThief module (I sometimes think that scanning for new and existing Drupal modules is a full-time job in itself!).
Looking at the code, it does automatically what I usually end up doing manually - that is, adding some extra data to the node/add/ path and then using the form_alter hook to plug that data into the node form. It shouldn't be too hard to modify it to work with a taxonomy field, I guess. The slight complication is that I'm already sending the parent node id over in the url in order to prefill the node-reference field, and combining the two might get messy! I'm just wondering whether it might be better to try and modify this module - http://drupal.org/project/nodereference_url - to inherit taxonomy terms when it auto-creates the node reference.
[Edit] OK, so now I'm wondering whether it might be better to check each time a node is saved - if the node has a node-reference, copy the taxonomy terms of the parent. That would at least mean that child nodes would be synced when updated, rather than just when created (and would also work if the node-ref is manually created), but it still leaves the question of updating child nodes automatically when the parent is modified.
No an expert, but...
... I wonder if after a parent node update, child nodes - and their cck taxonomy fields - could be updated separately, simply by batch re-publishing them thanks to the Views bulk operations module? I still have to explore the capabilities of this module.
[Edit: there's a D6 patch for de Field Copy module: http://drupal.org/node/362435 ]
Views bulk operations
I haven't used Views bulk operations yet, but that's an interesting idea. My mind was starting to wander towards a triggers/actions approach, but I guess VBO might allow you to do pretty much the same thing.
Thanks for the heads-up about the Field copy module. I need to find a solution for a few sites now where the navigation is driven by taxonomy and node-references, so I'm still wondering about a custom module that would allow me to specify which content-types and vocabularies need syncing.
Actions in VBO
Actions also sound like a good idea, though I haven't used them yet. Actually we are not talking about different ideas, since VBO is able to execute actions. I also notice an interesting new VBO feature:
Some other features in this part may be interesting: using Rules module, or a predefined PHP script...
VBO
Wow, just when I thought Views wasn't the answer to everything, up pops VBO! I think I'm going to have to install it, and then read the docs carefully, as I'm starting to get confused about how it integrates with triggers, actions and node operations, but it certainly looks promising. And, as a bonus, it can send jobs off to the batch process or job queue module, so things won't grind to a halt if there are large numbers of nodes being processed. I'm not sure whether VBO can pull the current taxonomy terms from the parent node, or whether it only works with predefined lists of terms ... so I guess it's time to dive into the docs.
VBO and CCK fields
I think you're right, I'll take a look on VBO from my side.
"I'm not sure whether VBO can pull the current taxonomy terms from the parent node, or whether it only works with predefined lists of terms". It may be possible to achieve this in another way, by combining Views and Nodereference in order to select many child nodes and bulk modify them. Not precisely what we are looking for, but...
I found this thread about modifying CCK fields through VBO (VBO feature request and work in progress): http://drupal.org/node/358617#comment-1301716 . Maybe we should post a feature request about our own needs?
FYI...
Hi matkeane,
FYI, reply of the VBO module maintainer about this: http://drupal.org/node/456568
(Note: I'm on holidays tomorrow for a week, but I'd be glad to work further on this in any way with you when I'll be back.)
VBO and actions
Hi,
Thanks for pointing that out. Since it looks like this is going to require some custom code anyway, I'm wondering whether this can be done without in a little custom module, without being dependent on VBO. Of course, wondering is a lot easier than coding it!
Contributed module
(Last message before leaving:) Ok for the need of a custom contributed module; I guess it would be easier to create, maintain, test, etc. Do you feel able to write such a module? If not, we should consider paying someone for doing this. I'm ready for that, since the more I think about it, and the more this module would help to save a lot of time and effort. But of course, the bill must be reasonable.
Some thoughts:
- It would be great if this module could eventually be left available for all and for free on drupal.org;
- This module would be particularly useful if capable to bear multilingual contents and to provide some help on auto-creating multilingual nodes strongly based upon various cck taxonomy fields (am I asking too much? Possible... I suppose this needs further explanations);
- This module should be also maintained some time, that's a very important point we should carefully think over. Maybe we should search a coder already familar with Drupal Taxonomy content, CCK fields, Nodereference?
What do you think about all of that? If we agree on an amount, principles and licence, then I suggest we write a very generic document on wich we put our requirements. Maybe we could get some help among the drupal documentation + community? A template document?
(PS: I noticed you are living in France? Where? I'm from Paris.)
Module thoughts
Hi,
Not sure if I'll catch you before you head off on holiday, but anyway, here are a few notes on what I was thinking...
I really need to find a solution for this, as I have a couple of sites which use taxonomy to build the navigation menu, and node-references to link nodes together. Unless the child nodes inherit their parent's taxonomy terms, they don't show up properly under taxonomy views, and the active menu trail collapses when a child is viewed. This can be fixed by manually adding terms to the children, but it's a pain, and doesn't help for the existing nodes (several hundred of them). So I need someway for child nodes to inherit their parent's taxonomy terms and ensure that changes to the parent are reflected in their children.
My first thought was that it would be enough to use hook_nodeapi to check for a node insertion or update and, if a node-ref parent is specified, look up the parent's taxonomy terms (perhaps limited to certain vocabularies) and add them to the current node. That would cover new or updated child nodes.
The next problem is how to deal with updates to a parent node, although this is mostly a question of performance. When a node is updated, if it is of a type that can be referenced as a parent node, build a list of child nodes with a reference to it. If there are a small number of children, it would probably be OK to treat them immediately but, for large numbers it would be better to hand them off to the batch system or batch_job module for cron processing. That would mean that updates would not be immediate though.
So that we're not wasting time checking nodes that don't need processing, the admin configuration should allow only certain content-types to be checked and probably specify which vocabularies are associated with each of them, as parents may have terms that are unnecessary for the children, or the children may use vocabularies that don't need syncing.
Initially I had thought about just using the hook_nodeapi to intercept any node creation or updates, but it occurs to me - after reading the comment from the VBO maintainer - that it would be more flexible to create an action, which could then be triggered on node creation & update, but also run on a batch of already-existing nodes (using VBO for example).
So, as a small module that only deals with syncing taxonomy for node-ref content, I think it's achievable. There are probably some use-cases that I haven't thought - dealing with other field types than taxonomy, different ways of relating nodes (other node heirarchy modules) and so on... I hadn't thought about i18n support, but that's important to me too. Although I assumed that parent and child nodes would always share the same language, but maybe other sites wouldn't always stick to that.
I think the problem with a lot of modules is that they fall victim to bloat as more and more features are crammed in, so I'd be tempted to keep things very simple. So, for example, I'd be tempted to look at another module for auto-creating nodes, rather than try and make one module that did two different things.
So, yes, let's try to make a detailed specification, so we can see where any problems might lie, and how complex it might be to create. I've already build a few custom modules for sites, but they tend to be very specific hacks to particular requirements, but I'd be more than happy to be able to contribute something back to Drupal if it got that far. My only slight worry is about adding yet another module to the already overcrowded list of modules out there - especially ones linked to taxonomy!
And, yes, I'm also in Paris (and already looking forward to DrupalCon this september!)
Back
Hi Mat,
Thanks for your notes. I think I have catched everything, though some concepts remain a little "dark" to me as a non developer and quite new Drupal user (I'm still not very familiar with "hook_nodeapi", for instance). Some reactions:
A general thought, first. You wrote "My only slight worry is about adding yet another module to the already overcrowded list of modules out there". To be honest, ten days after, I still wonder if our needs couldn't be fullfilled thanks to one or more already made, widely used and efficient module(s). We should probably keep carefully this possibility in mind while writing our detailed specifications, since the main lack in Drupal appears to be an (up-to-date) documentation. If a new module still appears to be a necessity or simply the best way, I'll go for a module. But if some strong modules and a simple / little piece of code appears to be sufficient? And anyway, a new contributed module could be better with a wisely chosen dependancy. In this case, we need to find the better module(s) to rely on. For instance, I have found this interesting comment about the Rules module yesterday, while I was looking for something else (source, to be checked):
Please note that the Rules module have D6 documentation available... I need to dive into this quickly!
I'll go back to CCK fields in a moment, but be sure I obviously agree with you about the main need to "keep things very simple". This idea, among some others, should guide our choices. I also guess that this module (if we eventually go for a new module) or solution could be very helpful for people wanting to have a try with Semantic Web (that's another point, I know, but this could explain that we may not be alone working on this for a long time ; and we can't ignore that D7 is coming soon...).
Let's go back to your last comment:
§ 2 ("I really need to find a solution for this... reflected in their children."):
I think we share almost the same needs, except that your taxonomy terms associated to a (parent or child) node may not be stored in various CCK fields? I would define my (our?) needs like this or close to this (from your own words): "(...) I need someway for child nodes to inherit their parent's taxonomy terms and ensure that changes to the parent are reflected in their children and in each proper CCK field of these children (if required)".
This leads me to a need you may not have as much as me (?): parent and child nodes should/must (?) share not only a nodereference, but also field definitions in order to copy contents from one content type to another properly. This could be partially achieved thanks to a CCK Content submodule named "Content Copy". I guess this could be important above all in case you try to add many text contents in a field that was conceived to store a number (and one number only), for instance. Sharing a common field definition could be helpful for quality or quantity errors detection/limitation, though it is not a garantee (from one content type to another, one can change some aspects of a definition: required or not, for instance). That's a possible source of complexity: before inheritance, some things should probably be checked. And some warnings should be displayed to us as users if needed.
§ 3 ("My first thought was... That would cover new or updated child nodes."):
Ok except you are talking about taxonomy terms only, while you are also talking about "dealing with other field types than taxonomy" further (§7). And I realised it could be very helpful to batch copy/update some other kinds of CCK fields too (the basic ones, at least: text, numbers...).
§ 4-5 ("The next problem...or the children may use vocabularies that don't need syncing."):
I suppose that a cron job is the best solution: one could weither execute a cron job immediately or on a specified time, right?
§ 6-7 ("Initially I had thought about just using the hook_nodeapi... but maybe other sites wouldn't always stick to that."): About this: "There are probably some use-cases that I haven't thought - dealing with (...) different ways of relating nodes (other node heirarchy modules)". This probable source of complexity sounds useless for the moment, since we both use nodereferences, don't you think so? ;-)
§ 8-9 ("I think the problem with a lot of modules is... - especially ones linked to taxonomy!"):
about this particular sentence: "(...) I'd be tempted to look at another module for auto-creating nodes, rather than try and make one module that did two different things." I agree on the general principle, but I think I miss some further explanation; you want to auto-create nodes?
§ 10: I'd be glad to meet you in Paris some day. I suggest I try to think over a template for our document, then we'll soon think together about it in front of a beer?
Action on actions
Hi Erwan,
Sorry for being slow to get back to you, but I've been busy on other projects... and thinking about things you said in your last message.
Rules is an interesting idea. If I've understood correctly, Rules is an extension of, or replacement for, the built-in Triggers/Actions in Drupal, but with Rules making it possible to add conditions to Triggers so they can be fired in more specific circumstances. So, we've seen VBO, Triggers/Actions and now Rules - and they all have one thing in common, which is Actions, which actually do the work, and which makes me think that a custom Action is probably the best way to go.
Just to clear up a tech point - hook_nodeapi is a Drupal hook which is called whenever a node is created/updated/deleted, so it's a good way to track any node changes - but Triggers/Actions allow you to do the same thing via the Drupal UI, so again, it looks like Actions are the solution.
The reason I mentioned "dealing with other field types than taxonomy" is that I see you mentioned CCK Taxonomy, and maybe also Content Taxonomy in addition to the core Taxonomy module. I have to admit that I'm a little hazy over the exact differences between these modules - if you could enlighten me, that would be great (Actually, it would be really useful to understand in what cases these other Taxonomy modules might be useful)! Anyway, that was why I thought that, ideally, any code to synchronize Taxonomy would have to be flexible enough to work with other modules (although that might get tricky).
There's a comparison of Taxonomy modules at: http://drupal.org/node/212834
http://drupal.org/project/content_taxonomy seems to duplicate some of core Taxonomy's functions and even seems to do some synching between
Taxonomy and the CCK fields.
http://drupal.org/project/cck_taxonomy seems, according to the description, to replicate core Taxonomy but using CCK.
Without installing and playing with these modules, I don't know how they store their taxonomy data. If it's stored in CCK fields then some of the other CCK modules you mentioned (Content copy, Field thief, Field copy) should be able to copy them. If they've store term data in an extra database table, or in the core Taxonomy terms table, then perhaps our Action could help.
I mentioned 'auto creating nodes' after reading your comment:
This module would be particularly useful if capable to bear multilingual contents and to provide some help on auto-creating multilingual nodes strongly based upon various cck taxonomy fields (am I asking too much? Possible... I suppose this needs further explanations);
... and yes, I think further explanation is needed, as I don't think I understood what you meant! But yes, making this work with multilingual nodes is important, but not (I think/hope) too difficult.
Anyway, I agree that, if there is an existing module that could do the Taxonomy<->node sync, or be extended to do so simply, then there's no point in duplicating efforts with a new module. However even the code for a custom Action has to be added to Drupal through a module.
So, let me know where you've got to with your thoughts about a template for how this should work...
About Rules & Taxonomy Content modules
Hello Mat,
§ 1-2: No problem at all about the delay before responding.
You're right about the Rules module, as far as I can tell: it is a more powerful way of building actions than the Trigger module. Rules module has been made available as a stable version for a few days only (good news!). I've heard about it in the Using Drupal book by the Lullabot team. Actually, the Rules module was mentionned in this book but the core Trigger module is obviously prefered whenever it appears to be sufficient. At first glance, I guess one should make sure that the Trigger module isn't powerful enough before adopting the Rules module; it could be a way to "keep things as simple as possible". But on the other hand, Rules module's particularities really look promising regarding our needs, and the module is well documented; that may be another way of making our task simpler... ? We will certainly discuss this later.
§ 3-6: Thank you for your explanations about the hook_nodeapi, this sounds very interesting for our need.
I don't use CCK Taxonomy Fields module (it doesn't work with D6), but I use the core Taxonomy module and Content Taxonomy module. The Content Taxonomy module provides various helpful fields to record and display Taxonomy informations in a content type. My basic intentions were:
- to make the typing or checking of data I want to select as easy as possible for me, thanks to various widgets. One can choose a particular vocabulary and also choose which widget is best for you: checkboxes,
list with unique or multiple selectable terms, set then as required or not, etc.;- to display those informations in another way than an confusing list at top or bottom of a post (node).
But honestly :
- I don't recall how a content type edit page looks like before Taxonomy Content (!);
- I wonder now if I will eventually display those CCK taxonomy fields, because the search solution I use already displays them in the margin while the user is making its search. So I have to make some quick trials this week in order to see if I can manage without Content Taxonomy module (and double data storage: CCK + Taxonomy system). I guess I have to select what is the most important to me...
§ 7: terribly sorry about those confusions / lacks of precision, we will talk about this later; you're right, I don't think this would be difficult...
§ 9 About the specifications document: I was waiting for your reply on my proposal before starting working on it ;-) I have begun...
[Edit: After some tests, Content Taxonomy fields don't seem to be so necessary to me anymore (the following points may not be of great interest for you, I simply wrote them to help you understand my previous and current positions):
- the main trouble is probably that on the edit page, Taxonomy fields are now grouped together in the Vocabularies area; I can't select one of them and place it between two CCK fields, in a common fieldgroup for instance;
- I may also loose some seconds while filling some basic Taxonomy fields (radio buttons or checkboxes are truly convenient);
... but I think I can work without them pretty well... Furthermore:
- I don't have to store taxonomy terms as CCK data nor thinking about storing them twice (as CCK data and in the Taxonomy system). I believe that avoiding duplicate contents is always I good thing;
- It seems that storing taxonomy terms in Content Taxonomy fields disallow a correct use of the Taxonomy Image module (I was looking for the origin of this trouble for some time).
These conclusions are precious: I think things are going to be simpler, my nodes are becoming less tricky and heavy. Now I should choose carefully between creating a Taxonomy field or a CCK field. In appearance, our needs become closer than ever... But those tests leads me to really need some CCK fields copying from a parent node to a child node, along with taxonomies' terms!]
Taxonomy Display
Hi Erwan,
Just a quick response to some of the points that are related to Taxonomy display and the edit form.
You can move the taxonomy fields into different field groups - but it requires a bit of alteration to the form object using hook_form_alter in a little custom module. This is usually one of the first things I do on a site - add a little custom module for all the little tweaks, like removing the 'input filter' tips text that confuses users, making sure the 'publishing options' fieldgroup is open, so that users see the options when saving, and also for moving taxonomy fields to more logical places in the form. There can be problems doing this if you're using other modules to provide fancy widgets for the Taxonomy field though.
That's a themeing issue - instead of printing the standard $taxonomy variable in a template, you can send the node's taxonomy data to a theme function and then display how you want. For example, by default, the taxonomy terms are sorted by term, irrespective of the vocabulary, and I often want to change this to group them by vocabulary, or only show certain vocabularies - the taxonomy terms are often used as sorting tools for admin users, which shouldn't be displayed to the users.
Yeah, this always causes a bit of discussion when creating a new content type - should this field be a taxonomy vocab, or just a cck field (e.g. a select list). It comes down to what you think you will need to do with the data - taxonomy is useful for general categorization (site section, type of product, etc) and integrates well with other modules like taxonomy image, taxonomy delegate (if you want users to add extra terms). If the data is only ever going to apply to that content-type though, then a cck field might do the job just as well. But you're right that it's best not to duplicate any fields (cck and taxonomy) if possible.
Hope that helps...
It helps.
I appreciate your sharing of experience, Mat. On the two first points, though, I'm not skilled enough to write a custom module by myself; I have to deal with those lacks and with existing modules for the moment (if I except our project). But I know that Drupal is a fanstastic "place" for those who want to improve and try new things. As far as I'm concerned, I hope I will become more and more technically independant.
Hopefully many modules already exist, you said this before. The Taxonomy hide module includes the option to sort taxonomy terms by vocabularies (or to hide all of them). Above all, you can't ignore it, the Views module is really a great tool to change the way contents are displayed. But I have to make new tests using Views and Taxonomy Image, because I got duplicate contents the last time I tried. I also wonder how easy it is to translate CCK (and no taxonomy) contents... Still so much to explore...
Specifications
A very first document downloadable here (zipped Word document). Not exactly specifications already, but a first step to them... well, I hope so.
Specs
Wow - that's the first draft? I'm speechless! Do you realise I've had to work on large, complex sites where the client was unable to produce a document anywhere near that detailed?! I can see me waving this under a few people's noses, saying "see, see? this is what I meant!".
I've had a quick look through, but I'll have a proper read through in detail now. What's the best way to respond - continue this thread, modify the doc and send it back?
First confuse scenarii ideas "into the wild"
Thanks a lot, Mat.
I am supposed to do that kind of job (express someone's technical needs), and a little better I think (you still have to read it!), though not in English and as a non developper. I was ready to begin the writing of one or two back end scenarii, but I feel we'd better dive deeper into Rules, VBO and maybe Workflow and some other modules before. I confusely feel we need above all some kind of general roadmap, a methodology to help us searching a solution, before (or along with) some detailled specifications and scenarios. This document would say first something like: let's search further like this, this way and this way and see what have been done already; let's take some extra time to read, to test some existing actions made with Rules module, for instance.
Since documentation is often missing, maybe we should also install a little Drupal test site somewhere in order to test some modules or actions or whatever? This could help...
Some first abstract thoughts about back end scenarii, however (without taking feasability worries and risks of being totally ridiculous into account):
- If we work only on taxonomies, we should be able to precise the settings of each single vocabulary like this: we want to use this same taxonomy on different content types, but we also want for two of them (to be selected, through a checkbox for instance) to use and share exactly the same terms: language, quantity (number of terms), quality (tid, description, synomyms?), status (required or not?)...
[- Almost the same idea with CCK field but on one of the content type's "manage fields" form": I've said already that we would need a reliable "Content copy" work (actually this module copy CCK fields' definitions only, from one content type to another), along with a true copy of their contents.]
- Then in order to target our wanted updates more precisely, one could add a simple checkbox before (or after) each field on a parent node edit form, saying: "if this checkbox is ticked, then run a batch update of this field on the same line during the next cron job", or "get prepared to be modified during the next run of an action X through VBO". This could work for both taxonomy terms and CCK fields. Such a "checkbox" solution looks fine only if we suppose that there's one or two nodereferences max (*). I still don't know if the Flag module could help ("Features (...): Optionally show each flag as a checkbox on the node form").
I want to say to that I feel annoyed by the CCK fields need. I understand this is not one of your needs (and not part of my first post above), so I've pulled it down to an "optional need" in the doc. I hope you won't be upset because of my obstination to keep this in the doc, though. I can remove it if you want.
I didn't write anything more about how the module could deliver a multilingual editing help. I will do this here (still without taking feasability worries etc.). Actually I still don't know how the Drupal system behaves with node's translation regarding taxonomy terms and CCK contents. However I hope that after making some terms choices in a parent node, the same terms translated could prepopulate the same fields but in the other parent node which is a translation of the previous parent node. Of course, with the condition that the system holds those translated words somewhere already (am I clear enough?). If not, then this module (or another one) would help to make an automatic prepopulation of the fields of a translated version node. In other words, the parent-to-child copying could also work while staying at the parent-parent level, but for translation purposes. I let you imagine the editing/translating time one could save... one node to rule them all! In the following scheme, only the the first node's edition (bold) could be necessary in theory:
scheme (edit: typed verseion deleted because is wasn't displayed correctly).
I let you read and think about all of this, then we will discuss how we modify the doc (OK for "continue this thread, modify the doc and send it back").
--
(*) I've read a comment by the author of Faceted Search module (David Lesieur), who think that many nodereferences make the Drupal system working much slower. Ultimately, this project could be seen as interesting because it may limits the use of noderefs to a very temporary cron job (heavy update?) or occasionnal action's lauch (light update?); it allows copying/updating the datas from a content type A's parent node to content type B's child node instead of calling tons of noderefs each time a node is displayed.
[Edit (05/28/2009, 19h04): I have updated the doc with few minor things in the final "Useful links" part. Same link above to get this new version.]
Feedback on the first draft
Hi,
OK, a few comments on the first draft. Just to put things in context - having read the document, and considered the points we've talked about above, my current thoughts are that a custom Action is probably the best way to go. That's not written in stone though, but it has influenced my comments below:
§1.2.1.1
Maybe! I think they probably are most of the time, but I could see situations where they might be the same Content type - and as long as both parent and child have taxonomy fields that can be synched, I don't think it matters. It might have an influence on the settings in the next section though...
§1.2.1.2. SECURITY AND SYSTEM PERFORMANCES
If we use a custom module to create a new Action (which can be called by Triggers, VBO, Cron, etc) then it could also provide some admin settings, so that users can specify which Vocabularies to copy and in what circumstances. Whether the settings would be best on the Vocabulary settings page, or as part of the Content type settings, or on an entirely separate page, remains to be seen.
Drupal has its own built-in logging system, so each update can be logged. After testing, we might only want to log any problems, rather than all the successful operations. I suppose, in certain circumstances, we could also send an email to the site admin.
§1.2.1.3 / 1.2.2.2 MULTILINGUAL COMPATIBILITY (I18N)
It sounds like you can see a situation where some children might have more than one parent with different languages - is that right? I was a bit surprised because, on the projects I've worked on so far, nodes have always been monolingual. But I suppose a parent node could be language neutral, while the children have a specific language? Would it matter if the child inherited terms in multiple languages, since Drupal only shows terms in the current language? In any case, it shouldn't be too difficult to check the child node's language
I just did a quick test on a multi-lingual D5 site, and some things are done automatically by Drupal. I created a translation of a parent node which uses a multilingual vocabulary to specify the country. The new translation node already had the translated term selected in the Taxonomy form item. I'll have to check this still works the same way in D6, but it looks like Drupal handles the Taxonomy terms for Translations, so that is one less thing to worry about (not sure what happens if the Taxonomy terms haven't been created when the translation node is created though).
§1.2.2.1 AND SOME CCK FIELDS?
I'm glad to see Content Taxonomy can probably be ignored for our needs. Looking at the issue queue, there seem to be some problems with keeping the fields synched to the core Taxonomy terms, so I think we can make our lives easier by not trying to add another synchronization to that!
For copying the contents of other CCK fields - I think it might be better to look to one of the existing modules. That way we don't risk duplicating code that exists, and we can concentrate on dealing with the Taxonomy terms. I think we're more likely to find a successful solution, if we focus on a simple task. Of course, at this stage, there's no harm in discussing all kinds of ideas.
§1.2.3 back end
As I said above, my current feeling is that an Action would be able to do the manipulation of the terms. It can then be called by a Trigger, used with VBO, Rules, a Cron job, etc, so things can either run automatically in the background, or be called by an Admin when necessary.
The other reason I'm currently in favour of Actions is that I just used them to solve a problem on a site. On a Content type with 2 fields - title and reference code - the client had created several hundred entries with nothing in the reference code field, but instead had added the code in with the title, and was wondering why the search wasn't able to find anything by reference code. So I wrote an Action that looks for a reference code (which are in a predictable format), copies it to the proper field, and then tidies up the title field. Using a Trigger, the Action is called whenever a node is created or updated but, because nobody wants to go back and edit hundreds of existing nodes, a Cron job processes a batch each time it is called. The Cron job can be switched on/off, and the number of nodes to process in each batch can be changed on the admin settings page.
§1.3 Generic principles
That all seems fair enough to me.
Anyway, again, it's great to have all the ideas and possible solutions summarized in one document like that.
Thanks
Thanks for your feedback. I quickly updated the doc with your remarks.
- 1.2.1.1: OK. It could be useful to provide also a "same content type" solution.
- 1.2.1.2: I simply added your remarks below, but we'll have to write this better. OK anyway.
- 1.2.1.3: "It sounds like you can see a situation where some children might have more than one parent with different languages - is that right?"
Yes.
"I suppose a parent node could be language neutral, while the children have a specific language? Would it matter if the child inherited terms in multiple languages, since Drupal only shows terms in the current language?"
I my case, a parent content type is more than just a hidden and generic taxonomy holder thing. It also holds CCK fields (and one image) and those fields can't be language neutral; each parent node exists in two languages. I don't know how I should think about a language neutral node solution and if it would be best or not for me, but at first glance I don't think so...
1.2.2.1 (I deleted the § then re-add it (still as a secondary need) after reading your sentence: "Of course, at this stage, there's no harm in discussing all kinds of ideas.").
"For copying the contents of other CCK fields - I think it might be better to look to one of the existing modules. That way we don't risk duplicating code that exists, and we can concentrate on dealing with the Taxonomy terms. I think we're more likely to find a successful solution, if we focus on a simple task."
I agree with you. My only trouble is that I'm not aware of any true D6 stable solution. I have chosen to delete all my Taxonomy Content fields shared by my parent and child nodes but now I can hardly find how to display my terms and term image in my views as I want, (with my limited dev skills). I have to find how to deal with this.
1.2.3 I agree with you about having a serious try with building one or more Actions. I also feel it is a good way as far as I can tell. It simply seems to be a way to meet success... with less code to write.
Multilingual Terms
Hi,
OK, I think we're on the right track - my main confusion now is about the multilingual terms.
Like you, the parent nodes are fully-fledged nodes (with extra CCK fields and 2 Taxonomy vocabularies) - on one example site: Locations. The child nodes add extra information pages which are node-referenced to the parent. A Location, and its info-pages, can exist in multiple languages, but where translations exist, the translated info-pages point to the translated Location.
So, I had lazily assumed that a child node could copy the terms from its parent because, say, a French child node would be node-referenced to a French parent, and so there wouldn't be any need to filter by language. I think I mentioned before that, in a quick test on a D5 site, when a parent node was translated, Drupal assigned the translated terms to the new node, so a node where the language is set should only ever have terms in one language. So...
"It sounds like you can see a situation where some children might have more than one parent with different languages - is that right?"
Yes.
... and that's where I get confused. Unless the parent nodes are language-neutral, and have terms in multiple languages, I can't see a situation where a French child node would be node-referenced to a French parent and an English parent - but maybe that's just because of the sites I'm working on.
In any case, it would probably be a good idea - and not terribly difficult (compared to the rest!) - to add an option to filter by language, so that children only inherit terms in their own language. That should cover both cases (so maybe I should stop over-thinking things!).
So now it's a case of working out how to filter which nodes need updating for which content types and vocabularies...
Sorry...
I think I have read your question too quickly or get confused myself because of my actual hesitations on my own project. If some children "might have more than one parent with different langages", it would be only because of some kind of "weak" nodereference between a parent in a determined language and its children in the same language, while at least one other version of the parent node is available in another language.
I started here a long explanation about what I mean with my "weak nodereference" (it is about using a numeric content as nodereference, which can become a big problem with contents in various languages). But this case must not exist; I have to find a better solution and our common solution have nothing to deal with that.
In any case, it would probably be a good idea - and not terribly difficult (compared to the rest!) - to add an option to filter by language, so that children only inherit terms in their own language. That should cover both cases (so maybe I should stop over-thinking things!).
I guess this kind of selective inheritance is useless, since we know now that none of us uses any langage-neutral content type and that the child node has a determined language previously set, so that only terms in that language can appear (if previously stored somewhere)?
So now it's a case of working out how to filter which nodes need updating for which content types and vocabularies...
IMHO we have to dive into Rules/Trigger modules capabilities. At the time of writing I am mainly thinking with some drupal backend pages and supposed limitations in mind, while Rules module is presented as a module which "opens new opportunities for site builders to extend the site in ways not possible before"!
At a glance I would say that:
- one could filter a content type, a language, and/or a parent or child node quite easily by building/modifying a dedicated View (that could be seen by admin only, of course);
- then apply (or plan to apply programmatically) some predefined Rule to them, thanks to the VBO module.
This thought doesn't solve the need for selecting one or more precise vocalulary-ies to be inherited/updated. But this is perhaps where the Rules module could become helpful.
How to work together towards this? A possible way is to tell something like: "Erwan should trie this, while Mat should try that, then report one to the other". But [for now] maybe we should [simply] have a look on Trigger/Rules documentation, available tutorials, use cases... in order to get inspired?
[some text] = lately edited parts.
Language and Vocabulary Filtering
Hi,
No no, that's OK. Like I said, I hadn't initially thought about language filtering - assuming Drupal would deal with that - but it makes sense to add that possibility in case, as you say, there is some kind of weak reference to a parent which doesn't have a language assigned.
As to how we filter content-types and vocabularies, I was thinking more about how an admin page could be created to allow this, rather than a UI (Views or Rules) solution. For example, on the site I mentioned before, I have pages (Content-type: pages-info) which can have a node-reference to a parent Location (Content-type: location) from which they only need to inherit terms in the 'geography' Vocabulary. So, maybe on the 'edit' page for the Content-type 'pages-info', we could add a menu for which Vocabularies should be inherited. Or would it make more sense to add a menu to the 'edit' page for a Vocabulary - "Inherit/propagate terms in this vocab to these Content-types..." ?
Good question!
Content type admin page solution:
- allows a global overview on what you intend to copy from one content type to another (+),
- allows one single edit operation (+).
... While with the Vocabulary admin page solution:
- one will loose such an overview (-),
- and one will have to go on each Vocabulary admin page of each Vocabulary one intend to copy (-)...
Furthermore, if you want to add a language filtering option, I am not sure that the best place for that is the Vocabulary admin page, but I may be wrong...
I have tryed and adopted the Taxonomy defaults module; did you see how the module admin page is made? This could give you further ideas...
Taxonomy Defaults
Hi Erwan,
Sorry, been busy on other stuff. I also use the Taxonomy Defaults module on one of my sites, so yes, the interface could be a good guide. I almost wonder whether there might be a way to add the option to 'inherit from parent' by default, but since our code to determine the parent and necessary taxonomy terms is quite complex, it might be too much to include in another module. I wonder whether Taxonomy Defaults could be set to run an Action though...
Just another path
Hello Mat,
This is only another hypothesis, I'm glad you found some interest in this. May I suggest we include this and some other ideas, written in this thread before, in our common document, then decide how we should investigate first? If you agree, I'll try to do this this week.
Specs updated
Hi Mat,
I worked a little on the specs today, as promised. See 1.4 part and first useful links (1.6) (modifications can be displayed).
Updated docs
Hi Erwan,
Thanks for that updated doc. This doesn't relate directly to the Taxonomy problem, but have you seen the Node Clone module?
http://drupal.org/project/node_clone
Maybe that might help with your other aims of copying nodes?
Yes, but unfortunately...
New page...
- Initial thread title ("How to make CCK Taxonomy fields of children nodes automatically inherit terms defined in a parent node ?") changed to "Taxonomy terms inheritance (or updating) from one content type to another (1)"
- A "Page 2" thread, created for better legibility, is titled "Taxonomy terms inheritance (or updating) from one content type to another (2)": http://drupal.org/node/504440
subscribe
subscribe
four months....
since this discussion ended. Has there been any progress? Inquiring minds want to know...
Michael
Civicsolar
http://www.civicsolar.com
Slow progress...
Hi,
Unfortunately, with both of the main protagonists busy on other projects, this has taken a back seat for a while, but I'm going to need to work on this soon for a client site... meanwhile, the discussion continues in another thread: http://drupal.org/node/504440