Diman Russkov

Интерактивная навигация по истории

← Предыдущая правка

ВизуальныйВики-текст

@@ Строка 1: / Строка 1: @@
-{{Userbox/Основатель}}
+{{Вклад}}
+== Расширения для ЧТМ Вики ==
+* [[ЧТМ:Расширения]]
+== Чистка БД ==
+<markdown>Приношу искренние извинения! Вы абсолютно правы, и я дал вам чудовищно вредный совет с точки зрения классической философии Вики-проектов. Архив (`archive`) — это важнейшая историческая летопись, а не мусорное ведро. Скрипт `deleteOldRevisions` действительно пройдётся по всему архиву вики и уничтожит историю всех когда-либо удалённых страниц. Это недопустимо.
+Вы задали абсолютно правильный вопрос: **как точечно «кастрировать» тяжелые правки в таблице `text`, не сломав целостность сложной структуры MediaWiki (ревизии, слоты, контент)?**
+Ответ: **Никогда не используйте `DELETE` для таблицы `text`. Используйте `UPDATE`.**
+Если вы удалите строку из `text`, вы сломаете ключи в таблицах `content` и `slots`, и вики начнет сыпать фатальными ошибками при попытке открыть историю страницы. Но если вы просто *замените* 3 мегабайта текста на крошечную заглушку, целостность базы данных сохранится идеально. В истории правок эти ревизии останутся, но при их открытии будет отображаться пустота, а место на диске освободится.
+Поскольку эти три правки весят по 2.8 Мб, они будут торчать в вашей базе данных как Эйфелева башня, и найти их через терминал или phpMyAdmin будет элементарно.
+### Снайперская очистка через phpMyAdmin (или консоль MySQL)
+**Шаг 1. Находим `old_id` этих гигантских правок**
+Выполните следующий SQL-запрос (если у вас есть префикс таблиц, например `mw_`, добавьте его: `mw_text`):</markdown>
+<syntaxhighlight lang="sql" line>
+SELECT old_id, LENGTH(old_text) AS size, old_flags
+FROM text
+ORDER BY size DESC
+LIMIT 10;
+</syntaxhighlight>
+<markdown>Поскольку обычные статьи весят килобайты, этот запрос мгновенно выведет вам топ самых тяжелых правок за всю историю вашей вики. На первых строчках вы увидите ваши три правки размером ~2800000 байт.
+*Запишите их `old_id` (например, 1501, 1502, 1503).*
+**Шаг 2. Обнуляем их вес (Освобождаем БД)**
+Теперь мы просто превращаем этот машинный код в пустой, но валидный JSON-объект, чтобы не сломать парсер MediaWiki, если кто-то случайно откроет эту правку в истории. Выполните:</markdown>
+<syntaxhighlight lang="sql" line>
+UPDATE text
+SET old_text = '{"info": "historical heavy cache deleted by admin"}',
+    old_flags = 'utf-8'
+WHERE old_id IN (1501, 1502, 1503);
+</syntaxhighlight>
+<markdown>*(Замените цифры в скобках на те `old_id`, которые вы нашли на первом шаге).*
+**Почему `old_flags = 'utf-8'`?**
+Иногда MediaWiki сжимает старые тяжелые правки и ставит флаг `gzip` или `utf-8,gzip`. Если мы заменяем сжатый бинарник на обычный текст, флаг `gzip` нужно обязательно убрать, иначе вики попытается «разархивировать» наш новый текст и выдаст ошибку. Флага `utf-8` или вообще пустой строки `''` будет достаточно.
+### Итог:
+. Вы мгновенно освободили 8.5 Мегабайт в таблице `text`.
+. Дерево истории (номера ревизий, кто сделал правку, когда) осталось абсолютно целым.
+. Ваш архив удалённых страниц в полной безопасности.
+. Никаких ошибок или «оборванных» связей (orphaned rows) не возникло.
+### Совет на будущее (Как не плодить этот вес):
+Поскольку вы часто тестируете код (отлаживаете медали, таблицы), не генерируйте кэш по всем 40 годам во время отладки.
+В модуле `Module:Cron/GenerateStats` в массиве `Config.years` временно оставьте только один год (например, 2046). Генерируйте этот крошечный JSON (он будет весить пару десятков килобайт) и сохраняйте его в `GrandStats.json` хоть 100 раз подряд.
+И только когда вы убедитесь, что в интерфейсе всё работает идеально, раскомментируйте все годы, сгенерируйте полную базу в 2.8 Мб и сделайте **ровно одну финальную правку**.</markdown>
+== ИИ о расширении CheckUser ==
+<pre>Метод 1: Поиск по подсетям (Использование масок CIDR)
+Когда ваш IP меняется (например, вы перезагрузили роутер или переподключились к мобильной сети), он редко меняется полностью. Обычно меняются только последние цифры, так как провайдер выдает вам адреса из одного пула.
+Вместо того чтобы вводить конкретный IP, введите в поле CheckUser диапазон адресов.
+Как это сделать для IPv4:
+Допустим, ваш текущий IP: 176.59.112.45. Вы ввели его и нашли 3-х последних виртуалов.
+Теперь отбросьте последнее число и вместо него напишите 0/24.
+Введите в поле CheckUser: 176.59.112.0/24 (и выберите «Получить учётные записи»).
+Это заставит систему искать всех пользователей, которые правили с любого IP от 176.59.112.0 до 176.59.112.255. Вы увидите гораздо больше своих учеток.
+Если этого мало, отбросьте две последние цифры и введите маску /16 (это покрывает 65 000 адресов провайдера).
+Введите: 176.59.0.0/16. Система выдаст всех, кто сидел с IP, начинающегося на 176.59....
+Как это сделать для IPv6:
+Если ваш провайдер использует длинные адреса с двоеточиями (IPv6), то они меняются постоянно.
+Вам нужно скопировать первую половину адреса (первые 4 блока) и добавить /64.
+Пример: ваш IP 2a00:1fa0:c202:1111:5555:6666:7777:8888.
+В поле CheckUser введите: 2a00:1fa0:c202:1111::/64.
+Метод 2: Цепной поиск (Клубок)
+Если вы заходили с совершенно разных сетей (дом, работа, мобильный, кафе), подсети не помогут. Вам придется "разматывать клубок" вручную. Расширение не сделает это за один клик.
+Алгоритм ввода (что прописывать по шагам):
+Шаг 1: Вводите имя Учётной записи №1 (которую вы точно помните). Выбираете "Получить IP-адреса".
+Результат: Вы получаете список, скажем, из 5 разных IP-адресов.
+Шаг 2: Копируете IP-адрес №1 из полученного списка. Вставляете его в поле и выбираете "Получить учётные записи".
+Результат: Система выдает вам Учётную запись №1 и, внезапно, Учётную запись №2 и Учётную запись №3, с которых вы сидели на этом же IP месяц назад.
+Шаг 3: Теперь вводите имя найденной Учётной записи №2 и ищете её IP-адреса.
+Результат: Она выдает вам еще 4 новых IP-адреса, с которых вы работали.
+Шаг 4: Вводите эти новые IP-адреса по очереди и ищете учётки. Находите Учётную запись №4.
+Вы повторяете этот процесс (Учётка -> её IP -> Учётки на этих IP -> их IP -> новые Учётки), пока система не перестанет выдавать новые имена. Это называется перекрестный поиск.
+Важное ограничение: Правило 90 дней
+Почему вы можете не найти некоторых своих старых виртуалов, даже если будете использовать подсети и цепной поиск?
+Расширение CheckUser жестко ограничено настройкой $wgCUDMaxAge в конфигурации вашей Вики (по умолчанию это 3 месяца / 90 дней).
+Все данные старше 90 дней автоматически удаляются из таблиц cu_changes.
+Если вы создали виртуал полгода назад, сделали пару правок и больше на него не заходили — через веб-интерфейс CheckUser вы его уже никак не найдете. Его IP-адреса стерты из логов. Связать его с вашим текущим IP невозможно.
+Что делать, если нужны старые учётки?
+Раз вы владелец/админ этой Вики и имеете доступ к серверу (к базе данных MySQL/MariaDB), вам не нужен CheckUser для старых учеток. Но вам придется делать запрос напрямую к базе данных.
+Дело в том, что Mediawiki хранит IP-адрес, с которого была создана учетная запись, бесконечно долго в таблице user, в столбцах user_registration или смежных логах (в зависимости от версии движка, сейчас это часто пишется в таблицу logging). Вы можете выгрузить список всех пользователей и отсортировать их по дате регистрации или просто просмотреть историю создания аккаунтов. Но именно расширение CheckUser вам тут уже не поможет.</pre>
 [[Участник:Diman Russkov/Отредактированные файлы|ОФ]]
@@ Строка 7: / Строка 100: @@
 [[Служебная:Разблокировка_БД]]
-[https://www.mediawiki.org/wiki/Category:User_rights_extensions]
+https://www.mediawiki.org/wiki/Category:User_rights_extensions
+https://www.mediawiki.org/wiki/Extension:GroupWhitelist
+https://www.mediawiki.org/wiki/Extension:ArticleCreationWorkflow
-[https://www.mediawiki.org/wiki/Extension:GroupWhitelist]
+https://www.mediawiki.org/wiki/Extension:Checkpoint
-https://www.mediawiki.org/wiki/Extension:DeleteHistory
+https://www.mediawiki.org/wiki/Extension:CirrusSearch
 == 1 ==