Imagefields do not work when trying to create nodes using the following syntax:

nodes[article][field_article_image][0][filepath] = profiles/my_profile/libraries/images/79.jpg

Taken from install_profile_api, these need a little special handling.

Comments

sirkitree’s picture

Status: Active » Needs review

marking needs review

sirkitree’s picture

Version: 6.x-2.0-beta1 » 6.x-2.x-dev

patch succeeds with an offset on -dev and still works, so changing version to latest dev

q0rban’s picture

Title: Handle imagefields in node creation » Handle filefields/imagefields in node creation

Marked #1013430: Allow installation of files in profiler as a duplicate of this issue. Updating title appropriately.

dixon_’s picture

StatusFileSize
new1.38 KB

I'm cross posting the patch by fabsor from #1013430: Allow installation of files in profiler. I'd say that this patch is a much more generic and simpler approach to the same problem as this doesn't specifically tie to filefields and imagefields.

Basically what it does is to add a component callback which lets you insert files into the {files} table. You can then use the corresponding fid when creating nodes.

fabsor’s picture

Subscribing =)

q0rban’s picture

Status: Needs review » Needs work

I'm concerned about specifying fid in this way. All other profiler components don't allow you to set the serial id in this way. We'd need some other way of gluing together the files to node filefields/imagefields without it though.

This should also do some checking to make sure the files exist.

eojthebrave’s picture

Status: Needs work » Needs review
StatusFileSize
new5.19 KB

Okay, here's an approach to this that should work well for both file/image fields and for generic file uploads.

It's sort of a combination of the ideas from both of the previous approaches. Allows easily attaching files to file/imagefields and allows installing files directly via a new compontent though does NOT allow specifying a {files}.fid.

It also provides a mechanism for using files[] to install a file and then retrieve it's fid without having to hard code serial id's into the profile.

Note that the patch in the first approach runs all files through the appropriate validators before attaching them. I didn't think that this was necessary since we're not doing validation on anything else when saving a node. If we do want to do validation it makes this feature much more complicated as we have to handle files[] and file/imagefields differently since things attached with files[] use the system validators and those attached to file/imagefields can have additional validators as part of the field instance.

Also note that this removes the field specific lookup of the destination directory for saving files and replaces it with the ability to specify a destination directory in your profile.

This patch adds the ability to specify something like:

files[key][filepath] = path/to/my-file.jpg

OR

nodes[key][field_file][0][filepath] = path/to/my-file.jpg

This is the minimum that you would need to do in order to add a new file to the {files} table and to add a file as an attachment to any filefield or imagefield.

In addition to specifying the 'filepath' property you can also specify any $file object property, i.e.) 'filemime', 'filename', etc ...

You can also specify a 'name' property which functions like the 'name' property on a node in that it will attempt to locate a user account with the specified name and assign the file to that user.uid.

Finally, and probalby most useful you can use the 'destination' key to specify the destination directory that a file should be saved into relative to root of the default files directory.

For example:

files[key][filepath] = path/to/my-file.jpg
files[key][destination] = my_files/directory

Would save the uploaded file to sites/default/files/my_files/directory/my-file.jpg

This is especially useful for things like file/imagefields that are placing their files into a custom directory structure.

q0rban’s picture

Version: 6.x-2.x-dev » 7.x-2.x-dev
Status: Needs review » Needs work

Thanks for the work on this guys! First of all, I'd like to update the version here to 7. We should work on a patch for 7 first and then backport.

+++ b/profiler_api.inc
@@ -315,6 +316,97 @@ function profiler_install_variables($vars, $config, &$identifiers) {
+  global $profiler_files;

I'd rather not use global here. Can you create a profiler_get_files() and profiler_set_files() that use static storage instead? The Drupal 7 patch should use drupal_static.

+++ b/profiler_api.inc
@@ -315,6 +316,97 @@ function profiler_install_variables($vars, $config, &$identifiers) {
+function _profiler_install_file($file) {

Are there no good Drupal API functions to accommodate this? Is most of this code copy/pasted from existing functions that just couldn't work? If so, can we make note of what functions were used to make this function?

+++ b/profiler_api.inc
@@ -315,6 +316,97 @@ function profiler_install_variables($vars, $config, &$identifiers) {
+    drupal_set_message(t('Filepath must be specified when installing files.'), 'error', FALSE);

Since this stuff happens inside a batch process, I'm not sure a drupal_set_message is going to be of much value. Maybe we should add some watchdog entries in addition?

+++ b/profiler_api.inc
@@ -338,6 +430,19 @@ function profiler_install_nodes($nodes, $config, &$identifiers) {
+    $fields = content_fields(NULL, $properties['type']);

We need to make sure field/content module exists first.

+++ b/profiler_api.inc
@@ -338,6 +430,19 @@ function profiler_install_nodes($nodes, $config, &$identifiers) {
+      if (strpos($field_name, 'field_') !== FALSE && $fields[$field_name]['type'] == 'filefield') {

Seems like this could be simplified thusly:

      if (isset($fields[$field_name]['type']) && $fields[$field_name]['type'] == 'filefield') { 

Powered by Dreditor.