Lindon_cano: Серьезно? В связке nginx + php-fpm ошибки как раз перехватываются Nginx'ом и пишутся в свой error.log. У PHP есть интересная настройка catch_workers_output, которая как раз и передает ошибки от FPM на Nginx. То же самое происходит если настройка display_errors имеет значение stderr. Если в php.ini принудительно не включено логгирование в файл, то больше никуда ошибки не пишутся. FPM-лог будет содержать только ошибки при запуске PHP.
ligisayan: Отдельный вариант - сделать через командную строку. Делаете обычный дамп базы, а потом прогоняете через утилиту sed. Она делает поиск-замену практически мгновенно даже в гигабайтных файлах. Как пользоваться - смотрите доку.
ligisayan: Что за ошибка? 502? Смотрите логи веб-сервера, это в 99% случаев из-за того, что большой объем данных передается, буферы надо увеличивать. У меня WP Sync DB используется на каждом проекте как обязательный инструмент, прекрасно работает с базами любых размеров (самая большая - 12Гб)
Борис Шепелев:
> в пользовательском интерфейсе этот файл можно не использовать
Да, можно. Но не стоит, так как на этот jQuery, вместе с noConflict надеются все остальные плагины экосистемы WordPress. Есть такая штука, называется "стандарт". И в экосистеме определенного программного продукта есть свои соглашения, которые следует соблюдать. Если этого не делать, то "в пользовательском интерфейсе" очень скоро будет грузиться одновременно несколько разных версий одной и той же библиотеки. Что не есть хорошо.
Galyanoff: Это одно и то же) Если таких записей несколько - можно руками в админке проставить галочку. А если их много - тогда этот запрос "проставляет галочки" оптом.
Максим Жаров: Все я прекрасно понял и именно это и подозревал. Нельзя просто заменить index.php который поднимает всю систему на что-то свое и ожидать что все будет работать. Вы таки делаете все неправильно.
Алексей Ярков: Вот эту фразу "Можно теперь в виде плагина это оформить." лучше удалить из вашего ответа, так как она будет вводить в заблуждение будущие поколения начинающих. WordPress-плагин из этого кода не получится.
Ну теперь, когда погрузился весь необходимый контекст, оно заработало - и хорошо. Но, пожалуйста, не надо советовать делать из этого плагин (не получится), и тем более советовать другим идти подобным путем - это костыль. Все то же самое можно было сделать без подключения файлов ядра, если бы чтение файла и рекурсия были написаны в файле functions.php вашей темы или в виде простенького плагина. Данный код - это просто костыль, один файлик в корне сайта с помощью которого можно импортнуть данные. При таком подходе то же самое можно было сделать и без файлов ядра, ведь в конечном итоге категории - это всего лишь данные в БД. Посмотрели структуру таблиц, считали файл и написали достаточно простой SQL-запрос. И все.
Алексей Ярков: Ну с рекурсией вы знакомы, это уже некий показатель :) Под средой в последнем комменте я имел в виду как раз ваш LAMP. Настройки ошибок. Туда смотреть надо. Ну или попробуйте обычный var_dump() на разных местах, чтобы отловить где происходит ошибка. Xdebug думаю у вас вряд ли стоит на LAMP, а ковыряться с ним да еще с ST3 - занятие не из приятных.
Максим Жаров: Вообще я не понимаю зачем вы трогаете index.php, если вам нужно именно главную страницу сайта, создавайте темплейт front-page.php в папке темы и пилите там. Фокус в том, что файлов index.php в WordPress - тьма тьмущая, о каком именно вы говорите? О том который в корне проекта? Который в корне темы?
Максим Жаров: Вы однозначно что-то делаете не так, потому что за 12 лет работы с WP у меня ни разу не возник подобный вопрос, ни у кого из моих знакомых не возник, а вы говорите о весьма базовой вещи. Проблема в том, что входящих данных от вас недостаточно чтобы понять что вы делаете и что идет не так.
Александр: А вы знаете в какой среде топикстартер запускает проект? Может это простенький шаред хостинг где установлены жесткие лимиты на к-во переменных и вложенность, на память и тд. Может там нет объектного кеширования и даже кеша опкода. Может там сама БД через одно место настроена. Может у него стоят плагины которые вмешиваются и модифицируют запросы. Я разработал не один проект с гигабайтными базами и сотнями тысяч, миллионами записей, в том числе и на WP. И все прекрасно работает. Вопрос не в инструменте, а в его использовании. Ну и надо понимать, что серверочек с 256М оперативки не потянет такую базу на любой платформе - CMS или фреймворке (кроме разве что минималистичного низкоуровневого кода созданного специально под эту задачу). Для соответствующих объемов данных нужны соответствующие ресурсы, это абсолютно нормально.
Gavrilla: Во-первых, урл вида /skachat/video/ теоретически получить можно, но очень геморно и не стоит того. Стандартный урл который можно получить выглядит как /skachat/category/video/. Почему? Потому что то, что идет после /skachat/ в первую очередь парится как single запись типа skachat. Поэтому, чтобы WP смог различать индивидуальные записи и категории, нужен префикс (например category). Для этого при регистрации таксономии в rewrite нужно указать:
Алексей Ярков: А кто вам сказал что вот этот код из гиста прям должен работать? По сути вам надо залить в WordPress некоторые данные из файла / json. Это можно сделать из контекста WP (functions.php, простенький плагин) или из вне по REST API. В вашем коде вы подключили taxonomy.php с этой целью, а потом вызываете функцию wp_create_category(). Посмотрите внимательно подключенный файл и код этой функции. В ней вызываются другие функции WP, которые у вас не подключены (отсутствует контекст). Отсюда и проблемы.
