D6 Programmatic creation of a custom content type with fields
I find what seems to be two different approaches for creating fields for a custom content type via a module. One is from drewish, where the field is first added via cck manually, then dumped with var_export(content_fields()) and then added to the content type in the install via content_field_instance_create(). The other is in rfay's Example module, where Randy creates a table for the module in the install and inserts fields into it that are what cck would insert. I'm wondering if the latter removes the need for me to do all the node processing from my module. Also, my content type has one field (other than title and body) which is an image filefield with unlimited instances, and I'm thinking that that same method would have the field being handled by filefield and that the method in Example would require that I manage the _fid, _list and _data db content, etc., so if there's a reason why this would be a better way to do it, or why the first method wouldn't be, I'm missing it. Jeff -- Ayen Designs 388 Bullsboro Drive #105 · Newnan, Georgia 30263 404-271-9734 Web:ayendesigns.com <http://ayendesigns.com> Blog: theAccidentalCoder.com <http://theaccidentalcoder.com> Drupal: j. ayen green <http://drupal.org/user/367108> IRQ: j_ayen_green IM (Yahoo) baalwww (MSN) baalwww@yahoo.com Skype: ayendesigns Ayen Designs is a tradename of the computer services division of
The D6 node_example in Examples is the non-CCK technique, and it adds *data* but not fields, to a node. Presentation and data management are done in custom code. If you just need something that CCK can do, use features and CCK (which is essentially the easier way to do #1). Both ways work, but if you *can* do it with CCK + features I would think that would be the best technique. -Randy On Mon, Jan 17, 2011 at 4:49 AM, <jeff@ayendesigns.com> wrote:
I find what seems to be two different approaches for creating fields for a custom content type via a module. One is from drewish, where the field is first added via cck manually, then dumped with var_export(content_fields()) and then added to the content type in the install via content_field_instance_create(). The other is in rfay's Example module, where Randy creates a table for the module in the install and inserts fields into it that are what cck would insert.
I'm wondering if the latter removes the need for me to do all the node processing from my module. Also, my content type has one field (other than title and body) which is an image filefield with unlimited instances, and I'm thinking that that same method would have the field being handled by filefield and that the method in Example would require that I manage the _fid, _list and _data db content, etc., so if there's a reason why this would be a better way to do it, or why the first method wouldn't be, I'm missing it.
Jeff --
Ayen Designs 388 Bullsboro Drive #105 · Newnan, Georgia 30263 404-271-9734 Web:ayendesigns.com Blog: theAccidentalCoder.com <http://theaccidentalcoder.com> Drupal: j. ayen green <http://drupal.org/user/367108> IRQ: j_ayen_green IM (Yahoo) baalwww (MSN) baalwww@yahoo.com Skype: ayendesigns
Ayen Designs is a tradename of the computer services division of
-- Randy Fay Drupal Module and Site Development randy@randyfay.com +1 970.462.7450
Ah, makes sense. Ok, so that leaves me with one higher-level question. Is there a question I should be asking myself to decide whether to have cck manage the content type, its field and the processing of both or to do it separately, other than which is easier? On 01/17/2011 04:36 AM, Randy Fay wrote:
The D6 node_example in Examples is the non-CCK technique, and it adds *data* but not fields, to a node. Presentation and data management are done in custom code.
If you just need something that CCK can do, use features and CCK (which is essentially the easier way to do #1).
Both ways work, but if you *can* do it with CCK + features I would think that would be the best technique.
-Randy
On Mon, Jan 17, 2011 at 4:49 AM, <jeff@ayendesigns.com <mailto:jeff@ayendesigns.com>> wrote:
I find what seems to be two different approaches for creating fields for a custom content type via a module. One is from drewish, where the field is first added via cck manually, then dumped with var_export(content_fields()) and then added to the content type in the install via content_field_instance_create(). The other is in rfay's Example module, where Randy creates a table for the module in the install and inserts fields into it that are what cck would insert.
I'm wondering if the latter removes the need for me to do all the node processing from my module. Also, my content type has one field (other than title and body) which is an image filefield with unlimited instances, and I'm thinking that that same method would have the field being handled by filefield and that the method in Example would require that I manage the _fid, _list and _data db content, etc., so if there's a reason why this would be a better way to do it, or why the first method wouldn't be, I'm missing it.
Jeff --
Ayen Designs 388 Bullsboro Drive #105 · Newnan, Georgia 30263 404-271-9734 Web:ayendesigns.com <http://ayendesigns.com> Blog: theAccidentalCoder.com <http://theaccidentalcoder.com> Drupal: j. ayen green <http://drupal.org/user/367108> IRQ: j_ayen_green IM (Yahoo) baalwww (MSN) baalwww@yahoo.com <mailto:baalwww@yahoo.com> Skype: ayendesigns
Ayen Designs is a tradename of the computer services division of
-- Randy Fay Drupal Module and Site Development randy@randyfay.com <mailto:randy@randyfay.com> +1 970.462.7450
IMO, wherever possible, it's best to let CCK manage additional data on a node. And if a custom data type is to be presented, wherever possible, use features to manage it. -Randy On Mon, Jan 17, 2011 at 2:30 PM, <jeff@ayendesigns.com> wrote:
Ah, makes sense. Ok, so that leaves me with one higher-level question. Is there a question I should be asking myself to decide whether to have cck manage the content type, its field and the processing of both or to do it separately, other than which is easier?
On 01/17/2011 04:36 AM, Randy Fay wrote:
The D6 node_example in Examples is the non-CCK technique, and it adds *data* but not fields, to a node. Presentation and data management are done in custom code.
If you just need something that CCK can do, use features and CCK (which is essentially the easier way to do #1).
Both ways work, but if you *can* do it with CCK + features I would think that would be the best technique.
-Randy
On Mon, Jan 17, 2011 at 4:49 AM, <jeff@ayendesigns.com> wrote:
I find what seems to be two different approaches for creating fields for a custom content type via a module. One is from drewish, where the field is first added via cck manually, then dumped with var_export(content_fields()) and then added to the content type in the install via content_field_instance_create(). The other is in rfay's Example module, where Randy creates a table for the module in the install and inserts fields into it that are what cck would insert.
I'm wondering if the latter removes the need for me to do all the node processing from my module. Also, my content type has one field (other than title and body) which is an image filefield with unlimited instances, and I'm thinking that that same method would have the field being handled by filefield and that the method in Example would require that I manage the _fid, _list and _data db content, etc., so if there's a reason why this would be a better way to do it, or why the first method wouldn't be, I'm missing it.
Jeff --
Ayen Designs 388 Bullsboro Drive #105 · Newnan, Georgia 30263 404-271-9734 Web:ayendesigns.com Blog: theAccidentalCoder.com <http://theaccidentalcoder.com> Drupal: j. ayen green <http://drupal.org/user/367108> IRQ: j_ayen_green IM (Yahoo) baalwww (MSN) baalwww@yahoo.com Skype: ayendesigns
Ayen Designs is a tradename of the computer services division of
-- Randy Fay Drupal Module and Site Development randy@randyfay.com +1 970.462.7450
-- Randy Fay Drupal Module and Site Development randy@randyfay.com +1 970.462.7450
A very good way is that followed by the views_gallery module in its install script, where it creates the gallery and image content types, including imagefield, etc. See http://drupal.org/project/views_gallery <http://drupal.org/project/views_gallery>I feel I have improved upon that in my (work in progress) Project Flow & Tracker installation profile, where I use a function from the installation profile API to create a content type and its fields from a file (holding what is exported via content copy). You can download that here (branch 6.x-1.0-alpha1): https://github.com/victorkane/ProjectFlowAndTracker/tree/6.x-1.0-alpha1 Victor Kane http://awebfactory.com.ar http://projectflowandtracker.com On Mon, Jan 17, 2011 at 10:37 AM, Randy Fay <randy@randyfay.com> wrote:
IMO, wherever possible, it's best to let CCK manage additional data on a node. And if a custom data type is to be presented, wherever possible, use features to manage it.
-Randy
On Mon, Jan 17, 2011 at 2:30 PM, <jeff@ayendesigns.com> wrote:
Ah, makes sense. Ok, so that leaves me with one higher-level question. Is there a question I should be asking myself to decide whether to have cck manage the content type, its field and the processing of both or to do it separately, other than which is easier?
On 01/17/2011 04:36 AM, Randy Fay wrote:
The D6 node_example in Examples is the non-CCK technique, and it adds *data* but not fields, to a node. Presentation and data management are done in custom code.
If you just need something that CCK can do, use features and CCK (which is essentially the easier way to do #1).
Both ways work, but if you *can* do it with CCK + features I would think that would be the best technique.
-Randy
On Mon, Jan 17, 2011 at 4:49 AM, <jeff@ayendesigns.com> wrote:
I find what seems to be two different approaches for creating fields for a custom content type via a module. One is from drewish, where the field is first added via cck manually, then dumped with var_export(content_fields()) and then added to the content type in the install via content_field_instance_create(). The other is in rfay's Example module, where Randy creates a table for the module in the install and inserts fields into it that are what cck would insert.
I'm wondering if the latter removes the need for me to do all the node processing from my module. Also, my content type has one field (other than title and body) which is an image filefield with unlimited instances, and I'm thinking that that same method would have the field being handled by filefield and that the method in Example would require that I manage the _fid, _list and _data db content, etc., so if there's a reason why this would be a better way to do it, or why the first method wouldn't be, I'm missing it.
Jeff --
Ayen Designs 388 Bullsboro Drive #105 · Newnan, Georgia 30263 404-271-9734 Web:ayendesigns.com Blog: theAccidentalCoder.com <http://theaccidentalcoder.com> Drupal: j. ayen green <http://drupal.org/user/367108> IRQ: j_ayen_green IM (Yahoo) baalwww (MSN) baalwww@yahoo.com Skype: ayendesigns
Ayen Designs is a tradename of the computer services division of
-- Randy Fay Drupal Module and Site Development randy@randyfay.com +1 970.462.7450
-- Randy Fay Drupal Module and Site Development randy@randyfay.com +1 970.462.7450
Hi Victor, Wow. Nice work (i-p)! I've been frolicking through it, and reached pft.profile. That creates two content types, but I don't see any including of a file that would contain exported type or field info. A treasure map would be most appreciated :) On 01/17/2011 10:20 AM, Victor Kane wrote:
I feel I have improved upon that in my (work in progress) Project Flow & Tracker installation profile, where I use a function from the installation profile API to create a content type and its fields from a file (holding what is exported via content copy).
You can download that here (branch 6.x-1.0-alpha1):
https://github.com/victorkane/ProjectFlowAndTracker/tree/6.x-1.0-alpha1
Sorry, the work is done in the module pft_basic in ./sites/all/modules/pft/pft_basic/pft_basic.install It reads the files from the includes subdir. I got taxonomy and content Victor On Mon, Jan 17, 2011 at 1:26 PM, <jeff@ayendesigns.com> wrote:
Hi Victor,
Wow. Nice work (i-p)! I've been frolicking through it, and reached pft.profile. That creates two content types, but I don't see any including of a file that would contain exported type or field info. A treasure map would be most appreciated :)
On 01/17/2011 10:20 AM, Victor Kane wrote:
I feel I have improved upon that in my (work in progress) Project Flow & Tracker installation profile, where I use a function from the installation profile API to create a content type and its fields from a file (holding what is exported via content copy).
You can download that here (branch 6.x-1.0-alpha1):
https://github.com/victorkane/ProjectFlowAndTracker/tree/6.x-1.0-alpha1
participants (3)
-
jeff＠ayendesigns.com -
Randy Fay -
Victor Kane