Postponed
Project:
Drush Entity
Version:
7.x-5.x-dev
Component:
Code
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
3 Nov 2011 at 13:32 UTC
Updated:
21 Jul 2014 at 22:49 UTC
Jump to comment: Most recent
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 commenteddrush entity-delete file 1should 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 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 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 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 commentedDo you suggest that each field has its own way adding or setting data to it?
For image it will be
--field_imagefor integer it will be--field_number_integerfor entity reference it will be--field_taxonomy_term_reference, right?I suggest to be more user-friendly and use
--valueregardless 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 --helpordrush --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.