Building advanced websites with Drupal without any need of custom coding/modules is rapidly improving almost on a daily basis. With a foundation using modules such as Views, Page Manager (CTools) Panels, Rules, Flag, etc we can accomplish many advanced designs by just point and click.
There is, however, one important thing that needs to be looked at and that is how Drupal in some cases automatically delete data or content without asking the user if it should be deleted first. Compare this to other areas where Drupal tries to really make sure the user knows that the data will be lost forever.
I am currently involved in a project that includes migrating content for the clients Drupal 6 based site to a new Drupal 7 site. The new site also implements multilingual support, which turned out to have an unexpected, and unwanted, side effect.
After migrating all the content we started to go over the nodes and change the non English ones to the correct language. The only thing we did was to open the node edit form, switch the language from English to, for example, Swedish and then save. Yes, the node was now saved with Swedish as language, however all images, in image fields, where also gone. Not just from the node, but also from the file system. After some testing we found a workaround for this, by creating a new revision, we where able to preserve the images.
There where no warning when this happened. Drupal simply decided that the images where no longer used and thus automatically deleted them from the system.
This behavior is also happening in several other places. For example when deleting fields.
In other places Drupal is almost overdoing the process, such as when disabling and uninstalling a module where you have to go through several steps and Drupal ask "Are you really sure....".
At least for me this is confusing, but most importantly a bit scary as deletion is happening without warning.
We need to create a standard for how configuration, data and content are deleted from a site. When it comes to content nothing should be deleted without the user, with the right permission, has confirmed it should. Just because I remove an image from a node, doesn't mean I want it removed from the file system too. Especially now when reusing files is very easy.
When it comes to fields its even worse as not only is the field deleted, the database table is renamed with something like deleted in the new table name, thus adding orphaned tables.
Since Drupal keeps track on where stuff is used, it should be possible to manage these things much better. For example be able to get a list of all files, fields, etc that are not used anywhere.
Now when more and more are using the Features module, this could potentially create a lot of problems as well.
Thus, we need to make sure deletion of the last instance something is used is handled properly both when its done manually and automatically using for example Features.
Comments
Another use case where "the Drupal way" fails
Here is an example of another situation when Drupal's habit of automatically deleting stuff will cause major problems when it comes to media files:
Scenario: You have a site using the Media module where files can be uploaded either to fields or embedded using a WYSIWYG editor.
Currently there is no way to prevent this from happening. The "Remove media" button tells me, as a user, that the image will be removed from being used for this page. Nothing tells me Drupal will also permanently delete it from the file system if it, wrongly, decides it is the last place it is used.
This is really serious in my opinion and will without a doubt create a lot of problems!
I do realize this is a tricky problem to solve, but having Drupal decide what files to delete is not the right solution. I rather have orphaned files, which very well can be reused at some stage in the future, left lurking in the file system.
--
/thomas
T: @tsvenson | S: tsvenson.com
These just sound like bugs.
These just sound like bugs. Obviously this is the wrong place to post to get a bug-fixed and you should file an issue in the appropriate queue. I don't think people did this on purpose.
knaddison blog | Morris Animal Foundation
@greggles: I did go over how
@greggles: I did go over how Drupal does things in relation to the use case above and our conclusion is that this is how Drupal works. Its not a bug.
I posted it here because it is a usability problem. It is Drupal that has "veto" on when files, as well as configuration, are being deleted. The user, or even developer in many cases, are in many cases not even getting a warning, Drupal just deletes the file or render a configuration unusable as well as unrecoverable.
My opinion is firm on this. Drupal shall never do decisions like this without a warning giving the user a choice to either go ahead and delete the affected file/content/configuration or not.
--
/thomas
T: @tsvenson | S: tsvenson.com
Even if it is how Drupal
Even if it is how Drupal works right now, your best bet would to report this as a bug in the relevant queue. I haven't seen many things get fixed in a groups.d.o. discussion.
@yoroy: Problem for me is
@yoroy: Problem for me is that I don't really know where to look and decide where to file this as a bug. The other problem I have is that it is in many places throughout Drupal Core.
The reason I posted it here is that it is a usability issue and I was hoping we could start a discussion about a broad approach so that deleting of files, data and content are handled the same everywhere. Including putting the user in charge of making the final decision.
As I point out in the OP, in places such as uninstalling a module, a user has to go through several checkpoints before the unrevocable uninstallation is done. While in other areas, such as in the example in #1 it happens without any kind of warning, and then everything in between.
That is just in Drupal Core where I as a user should be able to expect things to be handled the same everywhere.
--
/thomas
T: @tsvenson | S: tsvenson.com
This is one of Drupal's biggest usability problems
Not this specific issue, but the problem of where to bring up and discuss fundamental design/usability issues in Drupal or various modules.
The issue queues are frequently somewhat dismissive of complaints about usability. The typical response is "works as designed", blame it on some other module or Drupal core, or else just ignore until it closes itself in two weeks. The module developers are essentially doing it for themselves, even if their goal is to provide a tool that helps others (that is, they aren't hired to implement a design or specification created by someone else, let alone one driven by user needs), are not necessarily focused on or good at usability, and have plenty of other things they'd rather work on. They also suffer from the "curse of knowledge" - they know how the code and user interface works, so they don't have any problems using it. They thus tend to see people with usability complaints as just needing a little more experience to understand how to use the tool properly. New users may not be taken seriously until they gain enough knowledge to be a Drupal insider, by which time they, too, suffer from the "curse of knowledge" and may have learned how to work around the issue (job security!). The strategy often seems to be to ignore the complaints of new users until they either go away or stop being new users.
Furthermore, users may not always word their complaints as politely as they might, and the maintainers may take the criticism personally.
Drupal core seems to be taking usability more seriously in the context of usability studies, but there doesn't seem to be an appropriate forum for people to voice such complaints, observations or questions, particularly when it comes to contrib modules (many of which are arguably de-facto core, when 90% of sites rely on them...). (I also think the usability studies I've heard of have been focusing on the wrong audience, but that's for another discussion...)
I think there needs to be a buffer forum between users and issue queues, someplace where people can be heard by impartial listeners (usability team) who won't take criticism personally, and who might answer questions, but fundamentally will be asking (and taking note of, and following up on) "why did someone need to ask this question in the first place?". These questions, particularly where a trend emerges, should be digested and studied (ie, with testable prototypes of possible solutions), and when a good solution is found, appropriate (and politely-worded) issues can be filed in the appropriate queues.
So the question remains: if not here, where SHOULD people go to, essentially, complain about Drupal (core and contrib) usability and documentation problems? Because I'm not sure the issue queues are quite the right place either.
It's a problem yes, we don't
It's a problem yes, we don't have a clear platform for where to start engaging in usability discussions. Issue queue is often too deep in the trenches. Here on groups.drupal.org the audience is smaller and often not tracked by core and contrib developers. But yes this group is the place to start if you want to discuss broader topics etc.
'Complaining' is just not the way to go about it though. Complaining will trigger dismissive responses. There are quite some assumptions in your comment about what others should be doing, but the simple fact is there aren't that many usability folk involved (enough) to make what you're proposing happening. So by all means, join the club!
Start some discussions here or in the issue queues (tag issues with 'usability' so we can find them). If you are on IRC, find us in #drupal-usability. Next monday we'll have another edition of UX open hours in IRC, drop by if you can.
For what it is worth, here is
For what it is worth, here is the issue to track with the Media module. http://drupal.org/node/1239056
Probably a bug
I don't want to derail the constructive discussion going on here, but I think what's reported in the OP is a core bug: http://drupal.org/node/1141912. Posting the link here so for other people will be easier to find it.
yeah it's kind of odd, the
yeah it's kind of odd, the following will cause the image.module (image field) to delete the file, but write the record to the managed files table..
$file = file_save_upload($uri);
$file->status = FILE_STATUS_PERMANENT;
$file->filename = basename($uri);
$file->uri = $uri;
$file->uid = $uid;
$file->filesize = strlen(file_get_contents($uri)); // warning @wohalazy !!
$file->filemime = stristr('jpg', $uri) ? 'image/jpeg' : 'image/gif';
file_save($file);
$node->field_photo[LANGUAGE_NONE'][0]=$file;
node_save($file);
http://dgtlmoon.com