Drupal

Drupal content management system, drush, management

Moving Drupal 6 CCK fields from node down into content_multigroup

Follow me as I journey down a shaky path. 

Goal: I am moving some cck fields off of a Quote Node down into the experimental/abandoned/phantom project content_multigroup* whilst keeping the values from the database.  It is to be done with a combo of Feature revert and hook_update_n.

Plan: Leveraging the fact that reverting to Feature code with fields missing (removed) from Drupal/database does not in fact drop the db columns from the content_type_<type> table structure, I should be able to:

CCK Multigroup in Drupal 7? No, but try the old D6 node reference recipe instead.

Miss the old Drupal 6 recipe of:

cck node type + nodereference + nodereference_url + views_attach of Drupal 6 and days gone by?  Fear not-- you can still do it in Drupal 7 in much the same way, just with different names:

Using hook_perm to provide more exportable access control for Views exported with Features

So here I am, pushing against deadlines, pushing to staging, preparing to push this ginormous update to a production, and I notice that my roles are no longer being honored at staging in this View!  *yikes*  I'm going to propose using hook_perm to define some appropriate role permissions instead of "multiple roles" under Views Access.  Here's to innovation, let me know what you think.

Back story:

Features, Diff, Revert, Update

Feature won't revert?  Or not all the way?  .. Here are some scattered thoughts in the wind about what I just solidified in my mind:

  • drush fd featurename
    doesn't actually go and refresh Features' understanding of db and file contents: it seems to work off of what it remembered from when you last ran drush features in order to get a features diff.
  • drush features
    does refresh and reconcile differences of db and file

 

Webform 3.x embeds in a node nicely, if you just let it!

I have been a webform user well before webform-3.x, and it was always part of my understanding webform was its own content type, end of story.  On a current project, I had made some modifications to the Page content type that I needed to show on my webforms, so in webform setup, I enabled only the "webform" content type from my initial update from 2.x to 3.x, and I used a node_load, node_embed to show the webform: