Os arquivos anexados aos nós nunca são excluídos do servidor, mesmo depois de removidos do nó (e essa edição é salva), Drupal 7


10

Percebi algo estranho no meu site: depois de anexar um arquivo a um nó (através do campo de arquivo normal), esse arquivo nunca é excluído do servidor . Eu removo-o do nó, salve essa alteração, mas posso ver que o arquivo ainda está no servidor.

Isso torna a substituição de arquivos muito difícil, porque quando um usuário tenta anexar uma substituição, o nome do arquivo tem o sufixo "_0" ou "_1" (como o arquivo original ainda está no servidor e faz com que o nome seja duplicado) . Isso significa que precisaríamos encontrar todos os links para o arquivo e editar cada um para corresponder ao novo nome / URL do arquivo. É uma bagunça total.

Estou procurando on-line e ninguém parece ter esse problema - os arquivos devem ser excluídos do servidor depois de removidos do nó.

Alguma idéia de por que isso pode estar acontecendo no meu caso? Não sei por onde começar a procurar. Certamente, a página de configuração 'Sistema de arquivos' não possui nada dessa natureza como uma opção que pode ter sido verificada. E as próprias opções de campo parecem não ter nada dessa natureza que eu possa ter definido inadvertidamente. Alguma outra ideia?


Se bem entendi, ele não é excluído imediatamente, mas está marcado para exclusão. Uma vez marcado, é limpo na execução do cron. O mesmo acontece com a limpeza das tabelas.
— junedkazi

Bem pensado. No entanto, eu testei isso e os arquivos nunca são excluídos, nem mesmo após várias execuções do cron.
— Boriana Ditcheva

Respostas:


17

Deixa comigo! É uma coisa de revisões. Eu acho que faz sentido. Se você tiver revisões ativadas para esse tipo de conteúdo, ele mantém todos os seus arquivos antigos no servidor (associados a revisões antigas), portanto, a substituição de um arquivo definitivamente é mais difícil. Se você tentar removê-lo e adicioná-lo novamente ao nó, o nome / link será atualizado, como mencionei na minha pergunta. Como um arquivo com esse nome é mantido no servidor e existe uma duplicação de nomes, ele adiciona os sufixos "_0", "_1" etc. às futuras versões carregadas do nome desse arquivo.

No entanto, entendo por que isso está acontecendo, já que todo o ponto de revisão é ser capaz de reverter para qualquer versão anterior da página.

A solução alternativa é que você pode realmente excluir a revisão antiga da guia 'Revisão' ou 'Moderada' (se estiver usando a Moderação do Workbench) que continha o arquivo que você está tentando substituir. Em seguida, faça o upload novamente e o nome deverá corresponder sem que você precise voltar e editar os links que apontam para esse arquivo.

Espero que isso faça sentido e que ajude outra pessoa também!


4

Eu tive o mesmo caso de uso (desejando substituir arquivos enquanto mantinha o nome do arquivo), e o código a seguir em um módulo personalizado atendeu a esse objetivo. Esse código se baseia no módulo API da entidade , portanto, ele deve ser adicionado como uma dependência no arquivo .info do módulo. Feedback bem-vindo.

Isso permite excluir arquivos imediatamente após clicar em 'Remover' e salvar o nó. Aviso: isso também significa que, quando você remove um arquivo e salva o nó, não é possível recuperar esse arquivo revertendo para uma revisão anterior.

/**
 * 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);
        }
      }
    }
  }
}

onde devemos colocar o código.
— BandOfBrothers

Não é a resposta que a solicitação original estava procurando, mas achei que era exatamente o que estava procurando. Obrigado por compartilhar aqui!
— texas-Bronius


0

Isso pode ser um problema de permissão no servidor. Tente o mesmo em uma instalação limpa - se você estiver enfrentando o mesmo problema, é responsabilidade do servidor e não do Drupal.

Existe algo nos logs?


Eu apenas testei para problemas de permissão. Eu tenho uma cópia local do site na minha máquina pessoal e o problema existe lá também. No entanto, em uma instalação limpa, os arquivos são realmente excluídos. No meu site problemático, os arquivos não são excluídos, mesmo depois de eu excluir o nó inteiro ao qual estão conectados. Quaisquer outras idéias que possam estar causando isso na minha configuração do Drupal. Eu estou supondo que deve ser um módulo ...
— Boriana Ditcheva

Pelo menos você o reduziu à instalação. Quais módulos você está usando? Algum módulo / fork / dev personalizado?
— Aram Boyajyan 17/10/12

0

Não tive sorte em excluir revisões antigas ou salvar nós sem os arquivos anexados e voltar. Estas são as únicas coisas que sempre funcionam:

  1. Excluindo o nó
  2. Removendo o arquivo através da edição do nó e exclusão manual do arquivo do servidor.

Eu odeio absolutamente a segunda opção, e é por isso que estou aqui procurando outra solução.

(Eu também poderia estar saindo dos limites, já que tenho vários clientes executando o D6.)


Comecei um ticket sobre isso há muito tempo: drupal.org/node/1816584 . Entre em contato, se desejar, e talvez haja uma discussão mais séria sobre isso, se houver vozes adicionais.
— Boriana Ditcheva

0

Também deparei com esse problema com moderação do ambiente de trabalho e a inserção do campo de arquivo na verdade mostra as versões antigas dos arquivos carregados quando arquivos com o mesmo nome são recarregados em diferentes revisões de um documento.

Para que as coisas funcionem sem problemas, adicione o vid do nó como uma pasta ao caminho de upload do arquivo. Normalmente estou fazendo algo parecido.

Caminho da pasta = recursos / [nó: nid] - [nó: título] / [nó: vid]

Sim, são pastas longas e feias com uma loucura de subpasta, mas você pode encontrar arquivos com muita facilidade via ID ou título do nó e, em seguida, a subpasta impede colisões de nomes, para que você possa manter muitas versões do mesmo arquivo com o mesmo nome. Depois, você pode excluir as revisões antigas, se desejar limpar o espaço.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.