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:

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:

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:

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

Trying to do:

I can't believe it's taken this long to add node_export to my Drupal development workflow-- so simple, check it out!

At local dev:

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:

In previous employment, I inherited a custom/manual JIRA installation on a physical (later VMWare but still stand-alone) box and was used to administering only it.  Fastforward to JIRA 4.2 which gobbles ram for breakfast, my desire to have my own JIRA instance, and an existing VPS (Virtual Private Server) account suitable only for apache + mysql apps.

Looking for other Drupalers in the area, I searched drupal bryan college station and came up with nothing-- not even my own website! Instead, I only received partial, anonymous (and non-SEO) mention on this Austin Drupal blog post and thought I'd better do something about it.