Running code, as to create dummy content, after a Feature

drupal 7 programmatically create node in installation profile
http://www.group42.ca/creating_and_updating_nodes_programmatically_in_drupal_7

I have spent the day discovering that you cannot populate with content the content type created in a Feature module using the .install file of that Feature module.

Programmatically creating a node in an update hook works just fine in Drupal 7, provided the content type being used exists. If it doesn't exist, there's no explicit warning- the {node} table is populated but none of the fields, not even shared fields like the body field stored in {field_data_body}, are created.

Building an installation profile, uses Features a bit-- trying to programmatically create a little starter content to go with the feature. This only works after the content type has been created, of course. How do i make sure a hook_install runs after a Feature module does its work?

Unfortunately i don't think these have any impact whatsoever on hook_install() implementations.
http://api.drupal.org/hook_update_dependencies
http://api.drupal.org/update_resolve_dependencies

There's an RTBC issue (Howto execute custom code after all features modules and dependencies are installed ?) with a patch to add a post-Feature-installation update hook

So after finally determining that it is not possible... here's the workaround installation script.

cd web
drush -y si sdl
drush cc all
drush -y en sdl_content

Where that last thing is just a module with all the same stuff in its .install file that would have been nice to be able to put in the sdl installation profile's .install file or the feature module's .install file.

Not sure the drush cc all is necessary, it should have an identifier at top, but anyway make this chmod 755 and you're good to go.

There is no way to easily have a drush script recognized by drush in project directories, it seems, which makes there no good way to have a drush script in version control with a site

<?php
    'title' => 'We don\'t have the page you are looking for (404 File Not Found error)',
    'type' => 'person',
    'body' => array(
      'und' => array(
        '0' => array(
          'value' => 'There\'s no page at the path you came here to see, but please look around and even if you don\'t find what you\'re looking for, you\'ll likely find something to interest or inspire.',
          'format' => 'filtered_html',
        ),
      ),
    ),
?>

19:50 mlncn: Building an installation profile, uses Features a bit-- trying to programmatically create a little starter content to go with the feature. This only works after the content type has been created, of course. How do i make sure a hook_install runs after a Feature module does its work?
19:57 wizonesolutions: mlncn: Hmm. Perhaps you could use module weight for that? Or is the created content itself within the feature module?
19:58 wizonesolutions: (I mean the code to create it)
19:59 mlncn: wizonesolutions: i think we have to set module weight in the .install file (with a db call), so, can't see that controlling when hook_install() runs. And i don't think module_implements_alter can help either ?
20:00 mlncn: wizonesolutions: i'm happy to create the content in a different module entirely, will see if a .install file in a module that depends on the Feature module creating the content type will work
20:03 wizonesolutions: mlncn: Yeah, that might be the first thing to try...since the order the hooks run in will probably avoid the order of operations issue.
20:03 wizonesolutions: mlncn: Maybe investigate if Features itself has some hooks it runs after it does its own hook_install stuff as well.
20:03 mlncn: wizonesolutions: good call
20:04 wizonesolutions: mlncn: I can't remember, but does it even generate a .install file? I suppose it would. If you change that, does it overwrite your changes when you regenerate? I know it doesn't do that for the .module file at least.
20:04 wizonesolutions: I was talking about this with someone a bit the other day
20:04 mlncn: wizonesolutions: no, this part is really cool. Features creates a .module file but then never touches it when it regenerates (using drush features-update anyway) and it doesn't create or touch the .install at all
20:05 wizonesolutions: mlncn: Oh - then maybe module weight + your own .install would be another option?
20:05 mlncn: wizonesolutions: so i routinely have 'hybrid' 'Features' (capital f) and feature (lowercase f) modules, with .install and update
20:05 wizonesolutions: but I guess that's what you're currently doing
20:06 mlncn: again, i don't think module weight affects the order of .install, since i'm 99% certain Drupal 7 still can only set module weight with a database query in the .install. But yeah, hoping just putting it in another module works
20:06 wizonesolutions: Cool. Yeah, adding code to a feature module is pretty cool...nice way to put everything related in one place.
20:06 mlncn: yup
20:07 wizonesolutions: Oh, maybe you can set the module to be dependent on feature #1 too?
20:07 wizonesolutions: Perhaps that would control calling order.
20:07 mlncn: wizonesolutions: but on this when-order-of-operations matters stuff, i wish there were some clearly good way to do it. I've seen dependenies installed after the module that dependend on them, Drupal doesn't seem to care. In update hooks there's some crazy function that can set their order but not .install hooks i don't think
20:08 mlncn: yep
20:08 wizonesolutions: ouch
20:09 wizonesolutions: Well, sounds like you've got a plan anyway...so good luck...I'd be interested in how it goes!
20:09 mlncn: http://api.drupal.org/hook_update_dependencies (being that crazy function)
20:10 mlncn: wizonesolutions: can i post our chat as the ultimate keyword mine for "i'm trying to set the order of these crazy _install functions? :-) )
20:11 wizonesolutions: mlncn: Quote away :D
20:11 mlncn: Thanks!

Not possible to edit the old nodes and have the changes stick.

They had revisions with uid 0, but for the one i edited that changed to admin, like in the {node} table-- but it is still broken.

Cannot find anything in the database to distinguish the working nodes from the nonworking nodes. Even looked in field_config and field_config_instance.

Everything looks like it must be the same for the non-working (title-only) installation profile nodes and except that they don't have fields— so if something is created without fields it is done for? But that doesn't make sense, because new fields can be added to content types.

Here's the {node} table— busted auto-created and (below) new through-the-UI-created are the same:

| nid | vid | type | language | title | uid | status | created | changed | comment | promote | sticky | tnid | translate |

| 18 | 18 | person | | Thierry Debaille | 1 | 1 | 1309522355 | 1309522355 | 0 | 1 | 0 | 0 | 0 |
| 19 | 19 | person | en | Rnd new one | 1 | 1 | 1309525471 | 1309525471 | 0 | 1 | 0 | 0 | 0 |

Never did find out exactly what was broken about these nodes, but the why they were broken eventually became clear: They were created when their content type did not yet exist. Hence the fix is to ensure the Feature code has fully run before greeting the oncoming car [why in the world did i type that, how tired am i?]-- i mean, before running any content creation code.

Problems with node_object_prepare()

node_object_prepare() should not assume the present logged-in user.

<?php
  if (!isset($node->nid) || isset($node->is_new)) {
  // ...
    global $user;
    $node->uid = $user->uid;
  }
?>

Looking more into this, it assumes a lot. The function says it is for edit forms but it still seems very useful for programmatic node creation- should it be refactored?