私のサイトで何か奇妙なことに気づきました:(通常のファイルフィールドを介して)ノードにファイルをアタッチした後、そのファイルがサーバーから削除されることはありませんです。ノードから削除し、その変更を保存しますが、ファイルがまだサーバー上にあることがわかります。
これにより、ユーザーが置換ファイルを添付しようとすると、ファイル名に「_0」または「_1」のサフィックスが付けられるため、ファイルの置換が非常に難しくなります(元のファイルがまだサーバー上にあり、名前が重複するため)。 。つまり、ファイルへのすべてのリンクを見つけ、それぞれを編集して新しいファイル名/ URLに一致させる必要があります。それは完全に混乱しています。
私はオンラインで探していますが、誰もこの問題を抱えているようには見えません-ノードから削除されたファイルはサーバーから削除されるべきです。
なぜこれが私の場合に起こっているのでしょうか?どこから始めればよいかわかりません。確かに、「ファイルシステム」設定ページには、チェックされたオプションとしてそのような性質はありません。そして、フィールドオプション自体には、私が誤って設定したような性質は何もないようです。他のアイデアは?
わかった!それは改訂です。それは理にかなっていると思います。そのコンテンツタイプにリビジョンが有効がある場合、allサーバー上の古いファイルを保持します(古いリビジョンに関連付けられています)なので、ファイルの置き換えは間違いなく困難です。削除してノードに再度追加しようとすると、質問で述べたように、名前/リンクが更新されます。その名前のファイルはサーバー上に保持され、名前の重複があるため、それらの「_0」、「_ 1」などのサフィックスが、そのファイル名の将来のアップロードされたバージョンに追加されます。
しかし、なぜこれが起こっているのか理解しています。改訂の全体のポイントは、ページの過去のバージョンに戻すことができるからです。
回避策は、置き換えようとしているファイルが含まれていた「リビジョン」または「モデレート」タブ(ワークベンチモデレーションを使用している場合)から古いリビジョンを実際に削除できることです。次に、もう一度アップロードすると、名前が一致するはずです。前に戻って、そのファイルを指すリンクを編集する必要はありません。
それが理にかなっていて、他の人にも役立つことを願っています!
私は同じ使用例を持ち(ファイル名を維持しながらファイルを置き換えたい)、カスタムモジュールの次のコードはこの目標を満たしました。このコードは Entity API モジュールに依存しているため、モジュールの.infoファイルに依存関係として追加する必要があります。フィードバックを歓迎します。
これにより、[削除]をクリックしてノードを保存した後、すぐにファイルを削除できます。警告:これは、ファイルを削除してノードを保存するときに、以前のリビジョンにロールバックしてそのファイルを元に戻すことができないことも意味します。
/**
* 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);
}
}
}
}
}
このスレッドで言及されているように、孤立したファイルを削除するモジュールを作成しました:
https://www.drupal.org/project/fancy_file_delete
また、手動でファイルを強制的に削除したり、管理されていないファイルを強制的に削除したりすることもできます。
これは、サーバーの権限の問題である可能性があります。クリーンインストールでも同じことを試してください。同じ問題が発生する場合は、Drupalではなくサーバーに依存します。
ログに何かありますか?
私はワークベンチのモデレートでもこの問題に遭遇しました。同じ名前のファイルがドキュメントの異なるリビジョンで再アップロードされると、ファイルフィールド挿入はアップロードされたファイルの古いバージョンを実際に示します。
スムーズに動作させるには、ノードのvidをフォルダーとしてファイルアップロードパスに追加します。通常私は何かのようなことをしています。
フォルダーパス= assets/[node:nid]-[node:title]/[node:vid]
はい、それらはサブフォルダーの狂気を持つ醜い長いフォルダーですが、ノードIDまたはタイトルを介して本当に簡単にファイルを見つけることができ、サブフォルダーは名前の衝突を防止するため、同じ名前の同じファイルの多くのバージョンを保持できます。その後、スペースをクリーンアップする場合は、古いリビジョンを削除できます。
古いリビジョンを削除したり、ファイルを添付せずにノードを保存して戻ったりすることはできませんでした。これらは常に機能する唯一のものです:
私は2番目のオプションが絶対に嫌いです。そのため、ここで別のソリューションを探しています。
(私はD6を実行しているクライアントの束を持っているので、私も範囲外に出る可能性があります。)