[development] D6 Programmatic creation of a custom content type with fields

[Victor Kane]

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 at 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 at 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 at 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 at yahoo.com
>>> Skype: ayendesigns
>>>
>>> Ayen Designs is a tradename of the computer services division of
>>>
>>
>>
>>
>> --
>> Randy Fay
>> Drupal Module and Site Development
>> randy at randyfay.com
>> +1  970.462.7450
>>
>>
>
>
> --
> Randy Fay
> Drupal Module and Site Development
> randy at randyfay.com
> +1  970.462.7450
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20110117/dd7930e8/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 1462 bytes
Desc: not available
Url : http://lists.drupal.org/pipermail/development/attachments/20110117/dd7930e8/attachment.jpe 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 8316 bytes
Desc: not available
Url : http://lists.drupal.org/pipermail/development/attachments/20110117/dd7930e8/attachment-0001.jpe