0

I have a bunch of custom fields on a custom content type. I'm trying to make my module create these fields and remove them on install and uninstall respectively.

There was a previous question and answer on this: https://drupal.stackexchange.com/a/629/2384 However, it is not adequate. The code was not completely presented. The author used node_type_delete() without deleting the content first, and that allegedly leads to trouble later down the line. So I checked the node_example.module as per recommendations on Drupal.org, node_example.install etc. These files provide insight into the structure of the module, but do not discuss all the varieties of fields (like file, taxonomy, etc.,) and how they are to be structured in the .install array.

I have tried to export my content type using Features, and it does produce an array. But the syntax is radically different from what was presented in the example, and I was lost in the arrays and sub-sub arrays.

Is there a simple guide somewhere, that can help me convert my content type into an array specification I can smoothly fit into my hook_install declarations?

  • 1
    What was the problem with using Features to completely handle the import of the content type and fields? If it's just that they both remain after uninstalling the feature, then perhaps you can use a feature to handle the import, and then add a custom .install file that removes the fields (as in node_example.install). Or have I missed something? – Andy Apr 13 '12 at 8:26
  • Well, I would like to save the client the hassle of having to first install a feature, then install my module... AFAIK, I can't package my module also into feature, correct? The client is even expecting this - no dependencies, just 'drop in' the module and work - and uninstall to erase all history of it every being there... – Aditya M P Apr 13 '12 at 8:40
  • 1
    You can package your module into a feature. Just don't touch any of the feature generated files except the .module file. Regarding clean uninstall, the idea in my first comment should work AFAICT, but I've never tried it. – Andy Apr 13 '12 at 8:43
  • Oh? I didn't know that - so when the feature is installed, will it see and act upon the .install file inside my module, which itself is inside the feature? – Aditya M P Apr 13 '12 at 8:57
  • Have you tried Features module ? drupal.org/project/features – niksmac Apr 13 '12 at 9:23
1

There are some useful resources on how to do this. And you dont have to use Features.

Features is great if you understand what it's doing (calling Field API in an automated fashion and exporting definitions). You can use the Field API to define, create instances, attach fields to entities -- and then remove them all module uninistall as you need.

The easiest way for me to do this is look at the functions in the link above and use var_dump() on $field or its $settings after you make it using the Field UI. Then just use the appropriate Field API call like field_create_instance() to wire these var_dump'd arrays into your modules hook_install(). So i'm saying dont create the arrays by hand, create them in Drupal and just copy an export to your code ...

  • 1
    My response is about Fields as that is what asked about here. You linked a page about custom content types. You can also make content types in custom modules. I recommend looking at the standard installation profile in drupal /profiles/standard/standard.info and standard.profile to see how they define content types and attach the body field to them. – tenken Apr 13 '12 at 15:50
  • Are you aware of any advantages to this approach over using Features? – Andy Apr 13 '12 at 16:11
  • 1
    Sorry, i'm saying "find out for yourself". Features can be a pain if you dont understand Overrides and that your features could be reverted without your knowledge. There is nothing wrong with hand-coding a module to create your own entities and fields ... its just your level of comfort in coding/using Drupal and what your workflow needs. I cant tell you what works for you :/ – tenken Apr 13 '12 at 17:58
  • 1
    @adityamenon I'm sorry you feel that way, my intention was to see if we could uncover any specific situations where one might choose Features over non-Features or vice versa. I personally believe that would add value. (I really don't want to evangelise Features - it's a tool and nothing more. I do want to uncover its strengths and weaknesses.) – Andy Apr 19 '12 at 8:12
  • 1
    @adityamenon Thanks for your kind words, very much appreciated. – Andy Apr 20 '12 at 8:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.