10 июля в 11:32
На проекте более 16 млн лайков по статьям, поставленным через Flag.
Сеошники обнаружили, что ссылки на установку лайка (вида https://****/flag/flag/like_content/114962?destination&token=*****) попали в индекс и редиректят на статью. По их выводам это вызывает определённые санкции со стороны поисковиков. Несмотря на то, что сам вывод ссылок (и, соответственно, установку новых лайков) на текущий момент отключили - они остались в индексе как "живые" (поскольку реагируют на запрос и осуществляют редирект).
В идеале необходимо возвращать по этим ссылкам 404. Это со слов сеошников.
Было принято решение удалить все лайки.
1. Удалить накопленные флаги через управление конкретным флагом не удаётся - при клике на "Удалить" система надолго задумывается (видимо, из-за большого объёма удаления) и в итоге выдаёт 504. После чего беглый анализ показывает, что ничего удалено не было. Сервер на VPS, если что.
2. Модуль Flag (и зависимый от него Flag Count) удалить не позволяет (что давало некоторую надежду, что флаги при этом удалятся автоматом) - требует сначала предварительно удалить все сущности flagging (которых, как я писал выше, более 16 млн).
3. Помимо удаления отдельных флагов - есть штатный общий батч для удаления сущностей flagging для всех типов флагов. Если воспользоваться батчем, то процесс всё же движется, но крайне медленно - удаляется порядка 1000 флагов за 5 мин. Грубый расчёт показывает, что полное удаление 16 млн. займёт около 1300 часов. Что неприемлемо.
Самое занятное, что на проекте в robots.txt обнаружилась запись вида (для любых User-agent):
Disallow: /flag/
Но мне неизвестно, когда добавили эту запись. Возможно, после того, как бот уже нахватался ссылок.
Вопрос: как быстро удалить флаги или принудительно установить 404 для любых путей /flag/* (учитывая, что модуль останется включенным - т.е. роуты по путям останутся закреплены за Flag). Вариант "вычистить какие-то таблицы" является самым плохим по ряду причин. Да и удобных инструментов для работы с MySQL (а-ля phpMyAdmin) на проектена текущий момент нет, как и root-доступа. Для этого нужно тормошить сисадмина и просить его устанавливать PMA.
Комментарии
похоже, что при удалении флага, Flag Count пересчитывает статистику заново, по всем 16М записям.
Так ведь и недолго базу изнасиловать до смерти.
написать свой RouteSubscriber где заменить контроллеры модуля Flag на свои, возвращающие 404, ну или
хакнутьпропатчить контроллеры Flag'a - думаю, больному от этого хуже уже не станеттам ключевое слово - php, со всеми вытекающими таймаутами, нехватками памяти и прочими прелестями интерпретатора
можно поставить локально MySQL Workbench - он умеет пробрасывать ssh-тоннель до хоста
Тоже думал над этим вариантом (сабскрайбер либо прямой хак). Однако мысль отклонилась в сторону .htaccess (как более быстрому выходу) и с удивлением обнаружил, что он не реагирует на добавление новых правил. Совсем. Даже заведомо ошибочные добавляю с целью именно убедиться в его работоспособности - ничего. Ощущение, что запросы как-то там закешированы злым прокси (а он есть снаружи и реально злой). В общем, видимо, по-любому нужно тормошить и ждать админа.
ого, там Апач?
Да вот только что растормошил админа, говорит, что там nginx. Т.е. мои манипуляции в расчёте на апач были бесполезны. ) Что-то вообще не подумал об nginx-альтернативе.
Кстати, вопрос: а почему "ого"? Апач на нагруженных проектах - редкость?
да я бы сказал, что в 2025 году Апач вообще - редкость
Как же я стар и бородат. Когда вся жизнь прошла?
РЕШЕНИЕ:
В общем, в итоге быстрее всего оказалось решить вопрос через сисадмина, поскольку доступа к конфу nginx у меня нет. Растормошил его и дал маску пути
/flag/flag/like_content/*. Он уже добавил нужные правила для 404 в конф.