Используя запрос MySQL и BASH, как я могу удалить, переименовать или переместить все файлы изображений, используемые узлами Drupal, до определенной даты? - PullRequest
0 голосов
/ 27 марта 2020

СПРАВОЧНАЯ ИНФОРМАЦИЯ, ЕСЛИ ВЫ ЗАИНТЕРЕСОВАНЫ: Мой друг владеет журналом и публикует соответствующий веб-сайт Drupal 7 с 2011 года. На сайте есть тысячи статей и около 50 000 изображений в поддержку этих тем. статьи. К сожалению, из-за адвокатов, занимающихся троллингом авторских прав, он уже столкнулся с парой судебных исков о нарушении авторских прав в отношении изображений, которые, по его мнению, были получены из "Creative Commons". Со времени своего первого судебного процесса в 2016 году он удостоверился, что все изображения принадлежат компании, занимающейся стоковыми изображениями. Но, по-видимому, совсем недавно, еще одно изображение, появившееся до 2016 года, заставило другого тролля по авторскому праву искать 18 000 долларов (кстати, это буквально фотография хот-дога). Тем не менее, его компания по страхованию бизнеса просто хочет платить сборы за урегулирование, а не рисковать чем-либо в суде, но требует, чтобы все потенциально подозрительные изображения были удалены с сайта в будущем. Поскольку 95% историй, опубликованных на его сайте, в любом случае имели менее 1000 просмотров (они стоят менее 50 центов от рекламодателей), он согласился снять все эти изображения, потому что $ .50 определенно не стоит риск кормления новых троллей.

ВОПРОС: Какой лучший способ удалить, переименовать или переместить все изображения, которые связаны с узлом истории, до определенной даты в 2016 году ? Было бы неплохо, если бы мы могли временно изменить имена файлов в файловой системе с "trollfood.jpg" на "trollfood.jpg.bak" (или что-то в этом роде), чтобы, если / когда он мог убедиться, что изображение действительно находится в публикации c домен, он может его оживить. Было бы также неплохо, если бы мы могли на время заменить все потенциально подозрительные ссылки на изображения (в БД) ссылками на изображения-заполнители (чтобы люди все еще могли прочитать статью, не задаваясь вопросом, куда делись изображения ... возможно, изображение будет кратким объяснением ситуации с троллингом). В любом случае, с момента, когда я что-то сделал с Drupal, прошло уже совсем немного времени, поэтому я забыл, как drupal связывает файлы с узлами (и у него есть несколько пользовательских типов контента для его основных статей).

Я был возможность получить все потенциально подозрительные изображения в списке с помощью mysql:

SELECT fid, filename, timestamp, from_unixtime(timestamp, "%Y-%m-%e") 
FROM drupal7_therooster.file_managed 
where timestamp between unix_timestamp('2011-01-01') and unix_timestamp('2017-01-01');

// here's sample output:
# fid   filename                        timestamp   from_unixtime(timestamp, "%Y-%m-%e")
6154    _MG_5147.jpg                    1373763148  2013-07-14
6155    _MG_5179.jpg                    1373763148  2013-07-14
6161    The Lone Bellow (4 of 5).jpg    1373866156  2013-07-15
6162    The Lone Bellow (1 of 5).jpg    1373866156  2013-07-15

Теперь, как я могу использовать это, чтобы найти потенциально оскорбительные истории, использующие эти изображения, и выполнить следующее:

  1. Создайте список всех историй, которые используют эти изображения, чтобы я мог сохранить это на тот случай, если он захочет восстановить эти изображения. Я знаю SQL достаточно хорошо ... Я просто не знаю, какие таблицы хранят какие данные.
  2. Создайте запрос, который заменяет эти ассоциации изображений в этих историях на изображение-заполнитель (поэтому, если в истории используется "trollfood" .jpg ", эта история теперь использует" safetyimageplaceholder.jpg "вместо этого. К некоторым историям прикреплено несколько изображений.
  3. Как только все потенциально оскорбительные статьи ссылаются на изображение заполнителя, мне все равно нужно переместить все оскорбительные файлы, чтобы они не могли быть доступны юристам ... Кстати, у меня есть доступ через s sh. Есть ли хорошие способы использования команд bash только для перемещения / переименования файлов, которые соответствуют списку, который я генерирую из SQL запрос? Я просто хочу быть осторожным, чтобы не удалять / переименовывать / перемещать любые изображения, которые НЕ были частью запроса. Имейте в виду, что дата создания файла в файловой системе - 2017+ на сервере, поскольку сервер был перемещен (или скопированы) в 2017 году, поэтому первоначальные даты создания файловой системы были неточными.

Я знаю, что это долго вопрос ... и это касается сайта Drupal, но я думаю, что мне может понадобиться помощь соответствующих экспертов SQL и bash, поэтому я разместил это здесь вместо Dexal Speci c stackexchange. Я полностью открыт для любых предложений, если для этой проблемы лучше подходит другой, совершенно другой подход. Ура!

1 Ответ

0 голосов
/ 30 марта 2020

Я смог ответить на свой вопрос. Мне пришлось сделать три основных вещи:

STEP ONE: Создать запрос к базе данных Drupal MySQL, который бы дал мне список всех потенциальных файлов, нарушающих авторские права, которые использовались узлами создано между 2012 и 2017 годами:

SELECT fm.fid, fm.filename, 
n.title, n.nid, from_unixtime(n.created, "%Y-%m-%d") as 'node_date'
FROM file_managed fm 
JOIN file_usage fu ON fm.fid = fu.fid 
JOIN node n ON fu.id = n.nid
WHERE created BETWEEN unix_timestamp('2012-01-01') AND unix_timestamp('2017-01-01')
ORDER BY node_date

Это довольно сложный запрос, но в основном он объединяет столбцы из трех таблиц (таблицы file_managed, node и file_usage в Drupal 7). Таблица file_usage представляет собой регистр общего ключа, файлы которого (через fid) используются на каких узлах (через nid).

ШАГ ВТОРОЙ: Организация и фильтрация данные для создания списка файлов.

Я отфильтровал и упорядочил результаты по датам создания узла. На первом шаге я получил около 48 тыс. Записей из запроса на соединение, а затем создал электронную таблицу Google для очистки и сортировки данных. Вот образец таблицы Google . Этот лист также включает данные из таблицы node_counter, которая отслеживает просмотры страниц для каждого узла. Используя простую функцию VLOOKUP для сопоставления общего количества просмотров страниц для каждого nid на основном листе, теперь основной лист можно сортировать по просмотрам страниц. Я сделал это, чтобы определить, какие изображения прикреплены к каждому узлу / статье, и я должен сначала проверить Это запрос sql, который я использовал для получения этих данных из БД следующим образом:

SELECT nid, totalcount, daycount, from_unixtime(timestamp, "%Y-%m-%d") as 'date'
FROM node_counter
ORDER BY totalcount DESC

ШАГ ТРЕТИЙ: Напишите сценарий оболочки, который будет принимать наш отфильтрованный список файлов и переместить их куда-нибудь в безопасное место (и отключить веб-сервер publi c).

По сути, мне нужен простой сценарий BASH, который будет использовать список файлов из второго шага для перемещения их с веб-сервера. , Имейте в виду, что когда каждый файл изображения загружается на сервер, Drupal может (и сделал) создал около десятка различных форматов rat ios и размеров и поместил каждую из этих копий в соответствующие папки. Например, одно имя файла изображения может быть скопировано и изменено в:

  • files / coolimage.jpg
  • files / large / coolimage.jpg
  • files / hero / coolimage.jpg
  • files / thumbnails / coolimage.jpg
  • files / * / coolimage.jpg et c et c.

Итак, я нужно взять список из ~ 50K имен файлов и проверить эти имена в дюжине разных подпапок, и, если они присутствуют в подпапке, переместить каждое из них в архивную папку, сохранив структуру дерева папок / файлов и оставив позади файлы, которые «безопасно» хранить на веб-сервере publi c. Итак ... Я закончил тем, что написал ЭТОТ простой скрипт и открыл его на Github на случай, если кому-то еще это пригодится .

Вот и все! К счастью, я знал некоторые SQL и как использовать таблицы Google ... и некоторые основы c bash .. и хорошо, как использовать Google и решать проблемы. Если пользователи Google смогут найти это полезным в будущем ... ура!

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...