| Project: | File (Field) Paths |
| Version: | 7.x-1.x-dev |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (fixed) |
| Issue tags: | FileField Paths 2.x |
Issue Summary
Steps to reproduce:
1) Download fresh install of Drupal 7, FFP 7.x-1.x-dev, and Devel.
2) Add field to Page content type called "field_files", and configure field with some FFP settings.
3) Visit devel/php, and execute the following code:
<?php
$instance = field_info_instance('node', 'field_files', 'page');
dvm($instance);
?>You should see the Filefield Paths settings in "ffp_field_files".
4) Now execute the following code:
<?php
$instance = field_info_instance('node', 'field_files', 'page');
$instance['bundle'] = 'article';
field_create_instance($instance);
?>This adds an instance of "field_files" to the Article content type.
5) Edit that field and you will see that none of the FFP field settings are preserved.
I think this is because the field settings are handled by filefield_paths_form_alter() and filefield_paths_form_submit(), which never get fired by field_create_instance().
This small patch implements hook_field_create_instance() and calls filefield_paths_form_submit() with the instance information, and if FFP settings are present, they will get saved.
Thus, the following code snippet can be used to test it:
<?php
$instance = field_info_instance('node', 'field_files', 'page');
$instance['bundle'] = 'article';
field_delete_instance($instance); // delete the instance we created earlier
field_create_instance($instance);
?>| Attachment | Size |
|---|---|
| ffp-field-create-instance.patch | 466 bytes |
Comments
#1
Can you make sure this patch applies against 7.x-1.x in git, and get someone else to test and mark as RTBC?
#2
Re-rolled against DEV.
If anyone wants to test it, here's a way to do it. Create a field programmatically, one which includes FFP settings. Then, enable Devel and do something like this at devel/php:
<?php$entity_type = 'node';
$field_name = ''; // the name of your field instance here
$bundle_name = ''; // the name of your content type
$info_instance = field_info_instance($entity_type, $field_name, $bundle_name);
unset($info_instance['id'], $info_instance['field_id']);
include_once DRUPAL_ROOT . '/includes/utility.inc';
$output = "field_create_instance(" . drupal_var_export($info_instance) . ");";
drupal_set_message("<textarea rows=30 style=\"width: 100%;\">". $output .'</textarea>');
?>
Now you have a copy of your field definition. Delete your field, and make sure no lingering FFP settings exist in the filefield_paths table, and no variables prefixed with "ffp_" exist in the variables table. Then visit devel/php again and import the contents with field_create_instance(). Your programmatically-created field should contain the FFP settings.
#3
Here's a revised patch which only affects those field instances which actually have FFP settings in them.
#4
One problem... if the field is created in update.php, then it won't work, since the FFP modules are included on hook_init, and I don't think hook_init gets fired on update.php.
We'd need to include the files. Is there another way to include them besides hook_init?
#5
On second thought, this seems like a secondary issue. We should open up a new ticket to get update.php support working. Can somebody review this and get it committed?
#6
Issue with hook_init() is resolved in dev, I will review this issue tomorrow.
Thanks for the good work joelstein.
#7
While the patch is good, unfortunately the settings don't currently come from the field instance, so it's not much use until that is fixed.
#8
Tagging this for 2.x, which will be a rewrite once the 1.x port is stable.
#9
I have just recently re-worked FileField Paths so it is now only using instance settings so this patch is no longer required.
Checkout the latest dev (coming out in the next 12 hours) and let me know if it works for you.
Cheers,
Deciphered.
#10
Automatically closed -- issue fixed for 2 weeks with no activity.