Ppaa

Немного улучшает ситуацию периодический запуск wp db optimize.
Не пойму, почему все-таки wp_options растет? Можно ли безболезненно отключить autoload в этой таблице?

Удаление полнотекстового индекса
SHOW CREATE TABLE wp_posts;

В структуре таблицы были строки, начинающиеся с
FULLTEXT KEY
У меня это были
crp_related
crp_related_title
crp_related_content

Для mysql 8 возможно понадобятся следующие команды
set global sql_mode=’ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION’ ;
set session sql_mode=’ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION’ ;

Затем
ALTER TABLE wp_posts DROP INDEX crp_related;
ALTER TABLE wp_posts DROP INDEX crp_related_title;
ALTER TABLE wp_posts DROP INDEX crp_related_content;

PS. Однако в итоге это еще не все. Таблица wp_options все равно достигла 12 Гб и место снова закончилось, но был найден плагин https://ru.wordpress.org/plugins/fg-fix-serialized-strings/ от разработчика FG Joomla, который возможно поможет решить и эту проблему. Сейчас снова запустил конвертацию, наблюдаю за процессом.

Нет, я ничего не путаю. Это не общий объем, а именно данные — архив новостей за 15 лет и база данных нормативных документов, причем практически без картинок. Темы оформления также никакой пока нет, ей я собирался заняться позже, когда конвертировал бы данные.
Размер файлов в каталоге с базой joomla.
du -h
6,5G

• Ответ изменён 5 лет, 9 месяцев назад пользователем Ppaa.

У меня есть VM c ubuntu внутри, где я делаю тестовые сайты. Там я написал скрипт, который очень удобно обновляет их все, хоть в cron ставь. Но если перенести его на хостинг без поддержки ssh, то там уже надо через веб-интерфейс. Связываться с дополнительными плагинами не очень хочется, т.к. теряется автоматизация. С другой стороны параметр —http для чего ведь в wp-cli есть, но примеров его работы найти не удалось.