Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
We concentrated on node and term but we should definitely test the File entity.
Comments
Comment #1
clemens.tolboomThis is a nice issue ... files belong to something. Say
tells us it belongs to user 1 ... but to what content type?
gives us the nids where the files are used. Which is equivalent with
So we need to render the output of
which is the result of a call to http://api.drupal.org/api/drupal/includes--file.inc/function/file_delete/7
Comment #2
clemens.tolboomComment #3
helmo CreditAttribution: helmo commenteddrush entity-delete file 1
should error when the file is used somewhere. This would help to maintain the referential integrity within the site.A more complex solution would be to offer an alternative interactively.
Adding a usage_count to the output of entity-read is an option to make it visible for a user that the file is used somewhere. But the next question the is to give a reverse lookup of where it is used.
Comment #4
clemens.tolboomRunning test code
shows deleting user pictures works. But that implies devel or user.module does not call file_usage_add.
Checking http://api.drupal.org/api/drupal/includes--file.inc/function/file_usage_... shows user_update_7013(&$sandbox) and user_save so my guess it's devel_generate.
Comment #5
clemens.tolboomI reported this under #1336224: User picture not saved through a file_usage.
Comment #6
clemens.tolboom[ Powered by #1115636: Issue Macros and Templates - _default ]
This is similar to #301621: Ability to add files
Comment #7
clemens.tolboomMoved to Drush Entity.
Comment #8
clemens.tolboomXRef media.module: #1438668: Programmatically creating files and populating their fields with shows a File migration class.
Comment #9
clemens.tolboomXRef: Devel #1336224: User picture not saved through a file_usage.
Comment #10
ragnarkurm CreditAttribution: ragnarkurm commentedMerge with Drush Fields provides full functionality manipulation of file of image field.
Following operations are available: get (list), add, set, del and count.
Working examples:
Comment #11
clemens.tolboomI don't see how to bulk add files?
What is weird about the output is that it shows the content of related file entities.
This should be rewritten into
We could short circuit the latter
into
which would provide queries like show the files and author of node 1
Note drush support output formats which seems broken for 8.x
Hope above is clear enough to make new issues with small patches?
Comment #12
ragnarkurm CreditAttribution: ragnarkurm commentedSorry, I did not provide how it works adding multiple files.
$ drush entity-del node 1 field_file
Save field data? (y/n): y
$ drush entity-get node 1 field_file
The field is empty.
$ ls -l /tmp/abc/
$ drush entity-mod node 1 field_file --add --value=/tmp/abc
Save field data? (y/n): y
$ drush entity-get node 1 field_file
Comment #13
ragnarkurm CreditAttribution: ragnarkurm commentedIt will not be a small patch.
it will be the biggest.
File field is most complex amongst popular fields.
Secondly, I wonder why cannot integrate all fields at once, why one by one?
Comment #14
ragnarkurm CreditAttribution: ragnarkurm commentedDo you suggest that each field has its own way adding or setting data to it?
For image it will be
--field_image
for integer it will be--field_number_integer
for entity reference it will be--field_taxonomy_term_reference
, right?I suggest to be more user-friendly and use
--value
regardless of the field type. It also keeps the code and commandline simpler.Bigger problem is that I run into difficulties having common command (in
entity_drush_command()
) for updating entity and fields. Only common factor is the name of command. But not further. They operate very differently. The usage (seedrush --entity-mod --help
ordrush --fields-mod --help
) is quite massive already, did you check? It is generated dynamically from all supported fields. If you suggest to merge drush entity update with it how will it be? I suggest to use separate commands for entity update and specific field update. It will be even difficult to create a good documentation for such command.There is one more consideration beyond merge (needs separate issue?) - files should actually be added to the system by front-end query. Meaning: drush will invoke piece of code by http://... Then all permissions fall into place in a right way. Otherwise code owner and web server will often be different users and drupal might not be able to handle files properly (for example to delete when needed etc). It means there should be corresponding piece of server-side counterpart code (complimentary module?) for supporting file transfers.
My current code does not have that, I realized that need later. Drush Fields has option to set owner, group and permission by commandline options, but that might not be enough always as these things may require elevated permissions.