0

I've taken control of a project recently, and I see a workflow I've not used before.

The original developer would create content types on his dev machine; use Features to export the content type's code, and upload that as a module (with related functionality) to the production server. Enabling it, the content type is created.

Now that the content type is created, I'd like to add / adjust / delete field configurations. What's the correct workflow to work with the content type from that point? Once the content type is created, is it part of the db as if I had created it normally through the UI? Can I safely delete the Feature generated content type code? Can I manage fields through the UI, or would I have to fiddle with the Feature generated code?

Thanks!

5
  1. Once the content type is created, is it part of the db as if I had created it normally through the UI?
    Yes

  2. Can I safely delete the Feature generated content type code?
    No- See this Q/A for a more complete answer.

  3. Can I manage fields through the UI...
    Yes - once you have the content type set the way you want it, you should regenerate the feature module so that you have an up-to-date representation of your content type in code.

  4. ...or would I have to fiddle with the Feature generated code?
    Definitely no

What's the correct workflow to work with the content type from that point?

First, make sure you have a clean starting point by ensuring that all of your features in all of your environments have the "Default" status (this just means that the loaded database configuration of the Feature matches the configuration defined in code in the Features module).

  1. Make changes to the content type through the UI on dev as you normally would.
  2. Once the content type has been modified to your liking, Recreate the Feature by clicking on the "Recreate button". That will generate a tar file. Extract that file in the same directory as the existing Feature module - overwriting the previous version.
  3. Revisit the Features page on dev. The feature that was previously overridden should now be "default".
  4. Assuming you are using git or subversion or similar, commit the changes to the Feature module and pull them to staging. (If you're not using source control, just FTP the changes to the Staging server).
  5. Visit the Features page on staging. The Feature in question should now have a status of overridden. Click on the "Overridden" link, tick the checkboxes on the resulting page and click "Revert". This will update the database settings to match what is defined in the new Features module. The status of the Feature should now be "Default". (Note: sometimes the Features module automatically pulls in the new settings when you visit the Features page, but honestly, I'm not sure what triggers that or when - perhaps someone can add to that).
  6. If all goes well on staging, repeat the same steps on prod.
  • I did not have Dev or Staging before this project, no. But now, I do - dev, stage, production. I can immediately see the benefit, and I'm assuming this is why Features is so attractive? To not have to manually re-add content types and configurations for each phase? So then, in point 3 above, you mean "Yes" in that I use the UI on the dev server, and then reexport the code to be passed on to staging and production? (What I had originally meant was can I / should I add fields directly to staging / production, bypassing features altogether) – blue928 Dec 10 '13 at 19:23
  • Also, per your ".. different discussion" comment, I would definitely like to know more about that workflow including dev, staging, and production, and how Features is best integrated into that. If you have any links, please add them? Thanks! – blue928 Dec 10 '13 at 19:27
  • Ok, so if you DO have dev/staging/prod environments set up, then typically you would adjust your content types on dev. Once you have them the way you like them, recreate the feature on dev and push that code to staging. Once it's on staging, visit the Features admin page. One or more of your features on staging should now be marked as overridden. You should revert this feature (which is a little confusing) which will update your database to reflect the changes reflected in the new feature code. If all goes well, repeat on prod. ...I'll update my answer to reflect this when I have a minute. – Adam Balsam Dec 10 '13 at 19:32
1

When working with features you want to continue with the dev box to prod workflow. With features you're creating modules, so all the config code lives within your exported feature.

Here's a drupal.org link to updating features - https://drupal.org/node/582680

You'll make changes on your dev box, then update your feature and move that to your production site.

You shouldn't delete the content type code in the feature.

You can fiddle with the UI to update fields within the feature just make sure you rebuild on your dev box.

The purpose of features is to allow you to quickly move configurations from site to site, and if you are using something like Git provide version control in case you need to move backwards.

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.