Les fichiers attachés aux nœuds ne sont jamais supprimés du serveur même après leur suppression du nœud (et cette modification est enregistrée), Drupal 7

10

J'ai remarqué quelque chose d'étrange sur mon site: après avoir attaché un fichier à un nœud (via le champ de fichier normal), ce fichier n'est jamais supprimé du serveur . Je le supprime du nœud, enregistre cette modification, mais je peux voir que le fichier est toujours sur le serveur.

Cela rend le remplacement des fichiers très difficile, car lorsqu'un utilisateur essaie de joindre un remplacement, le nom du fichier a le suffixe "_0" ou "_1" (puisque le fichier d'origine est toujours sur le serveur et que le nom est dupliqué) . Cela signifie que nous aurions besoin de trouver tous les liens vers le fichier et de les modifier pour qu'ils correspondent au nouveau nom de fichier / URL. C'est un gâchis total.

Je recherche en ligne et personne ne semble avoir ce problème - les fichiers doivent être supprimés du serveur une fois qu'ils ont été supprimés du nœud.

Des idées pourquoi cela peut se produire dans mon cas? Je ne sais pas par où commencer. Il est certain que la page de configuration «Système de fichiers» n'a rien de cette nature comme option qui aurait pu être vérifiée. Et les options de champ elles-mêmes semblent n'avoir rien de cette nature que j'ai pu régler par inadvertance. D'autres idées?

Boriana Ditcheva
la source
Si je comprends bien, il n'est pas supprimé immédiatement mais il est marqué pour suppression. Une fois marqué, il est nettoyé lors de l'exécution cron. Il en va de même pour le nettoyage des tables.
junedkazi
Bien pensé. J'ai testé cela et les fichiers ne sont jamais supprimés, même après plusieurs exécutions de cron.
Boriana Ditcheva

Réponses:

17

J? ai compris! C'est une question de révisions. Je suppose que cela a du sens. Si vous avez activé les révisions pour ce type de contenu, il conserve tous vos anciens fichiers sur le serveur (associés aux anciennes révisions), il est donc plus difficile de remplacer un fichier. Si vous essayez de le supprimer et de l'ajouter à nouveau au nœud, le nom / lien est mis à jour, comme je l'ai mentionné dans ma question. Puisqu'un fichier portant ce nom est conservé sur le serveur et qu'il existe une duplication de nom, il ajoute ces suffixes "_0", "_1", etc. aux futures versions téléchargées du nom de ce fichier.

Je comprends pourquoi cela se produit cependant, car tout le point de la révision est de pouvoir revenir à n'importe quelle version antérieure de la page.

La solution de contournement est que vous pouvez réellement supprimer l'ancienne révision de l'onglet «Révision» ou «Modéré» (si vous utilisez la Modération Workbench) qui contenait le fichier que vous essayez de remplacer. Ensuite, téléchargez-le à nouveau et le nom devrait alors correspondre sans que vous ayez à revenir en arrière et à modifier les liens pointant vers ce fichier.

J'espère que cela a du sens et que cela aide aussi quelqu'un d'autre!

Boriana Ditcheva
la source
4

J'ai eu le même cas d'utilisation (vouloir remplacer des fichiers tout en conservant le nom de fichier), et le code suivant dans un module personnalisé a atteint cet objectif. Ce code repose sur le module API d'entité , il doit donc être ajouté en tant que dépendance dans le fichier .info de votre module. Commentaires bienvenus.

Cela permet de supprimer immédiatement les fichiers après avoir cliqué sur «Supprimer» puis enregistré le nœud. Avertissement: cela signifie également que lorsque vous supprimez un fichier et enregistrez le nœud, vous ne pouvez pas récupérer ce fichier en revenant à une révision antérieure.

/**
 * Implements hook_node_update().
 *
 * Delete files from old node revisions.
 */
function MYMODULE_node_update($node) {
  // Array of content types to act on.
  if (in_array($node->type, array('page', 'article'))) {
    $wrapper = entity_metadata_wrapper('node', $node);
    $original_wrapper = entity_metadata_wrapper('node', $node->original);

    // Array of file fields to act on.
    foreach (array('field_public_files', 'field_private_files') as $field) {
      if (!isset($original_wrapper->{$field})) {
        continue;
      }
      $current_files = array();
      $original_files = array();
      // Get files that were attached to the original node (before update).
      foreach ($original_wrapper->{$field}->value() as $file) {
        $original_files[] = $file['fid'];
      }
      // Stop if there were no files previously attached.
      if (empty($original_files)) {
        continue;
      }
      // Get files currently attached to the node (after update).
      foreach ($wrapper->{$field}->value() as $file) {
        $current_files[] = $file['fid'];
      }
      // Delete files that were in the original node but were removed during
      // this update.
      $deleted_files = array_diff($original_files, $current_files);
      foreach ($deleted_files as $fid) {
        if ($file = file_load($fid)) {
          // Delete all usages of the file. Each node revision adds to the usage
          // count.
          file_usage_delete($file, 'file', 'node', $node->nid, 0);
          file_delete($file);
        }
      }
    }
  }
}
Cottser
la source
où nous devrions mettre le code.
BandOfBrothers
Ce n'était pas la réponse que la demande initiale recherchait, mais je l'ai trouvée juste au bon endroit. Merci d'avoir partagé ici!
texas-bronius
0

Il peut s'agir d'un problème d'autorisations sur le serveur. Essayez la même chose sur une installation propre - si vous rencontrez le même problème, c'est au serveur et non à Drupal.

Y a-t-il quelque chose dans les journaux?

Aram Boyajyan
la source
Je viens de le tester pour des problèmes de permission. J'ai une copie locale du site sur ma machine personnelle et le problème existe également là-bas. Cependant, lors d'une nouvelle installation, les fichiers sont effectivement supprimés. Sur mon site problématique, les fichiers ne sont pas supprimés même après avoir supprimé le nœud entier auquel ils sont attachés. Toute autre idée de ce qui pourrait être à l'origine de cela dans ma configuration Drupal. Je suppose que ce doit être un module ...
Boriana Ditcheva
Au moins, vous l'avez limité à l'installation. Quels modules utilisez-vous? Des modules personnalisés / fork / dev?
Aram Boyajyan
0

Je n'ai pas eu la chance de supprimer les anciennes révisions ou d'enregistrer les nœuds sans leurs fichiers joints et de revenir. Ce sont les seules choses qui fonctionnent toujours:

  1. Suppression du nœud
  2. Suppression du fichier en modifiant le nœud et en supprimant manuellement le fichier du serveur.

Je déteste absolument la deuxième option, c'est pourquoi je suis ici à la recherche d'une autre solution.

(Je pourrais aussi sortir des limites, car j'ai un tas de clients exécutant D6.)

Wray Bowling
la source
J'ai commencé un ticket à ce sujet il y a longtemps: drupal.org/node/1816584 . Faites sonner si vous le souhaitez, et il peut y avoir une discussion plus sérieuse à ce sujet s'il y a des voix supplémentaires.
Boriana Ditcheva
0

J'ai également rencontré ce problème avec la modération du plan de travail et l'insertion de champ de fichier montrant en fait les anciennes versions des fichiers téléchargés lorsque les fichiers du même nom sont téléchargés à nouveau dans différentes révisions d'un document.

Pour que tout fonctionne bien, ajoutez la vidéo du nœud en tant que dossier au chemin de téléchargement du fichier. Normalement, je fais quelque chose comme.

Chemin du dossier = actifs / [nœud: nid] - [nœud: titre] / [nœud: vid]

Oui, ce sont de longs dossiers laids avec une folie de sous-dossier, mais vous pouvez trouver des fichiers très facilement via l'ID de nœud ou le titre, puis le sous-dossier empêche les collisions de noms afin que vous puissiez conserver de nombreuses versions du même fichier avec le même nom. Ensuite, vous pouvez supprimer les anciennes révisions si vous souhaitez nettoyer l'espace.

Aidan Foster
la source