@iDx полистал StackOverflow, там много вопросов по этой ошибке. Лечат обнулением значения AUTO_INCREMENT. У тебя проблема с таблицей wp_options, попробуй в MySQL выполнить ALTER TABLE `wp_options` AUTO_INCREMENT = 1
Еще говорят, что помогает удаление таблиц и создание заново. По сути это то же самое - AUTO_INCREMENT в новосозданной таблице будет равен 1.
@iDx если установил пакет и что-то с ним не так - надо смотреть логи, править конфиги. Проблема почти всегда этим решается. Удалять надо тоже подчистую (см. гайды выше), включая конфиги и все остальное. И только потом ставить заново. Но это уже крайний случай.
@iDx тогда ручками чистить везде где следы остались, тут я даже не знаю чем помочь. А почему не запустился с первого раза? Вообще, на будущее совет - не надо чуть что сразу все удалять и ставить заново. Сначала надо посмотреть что не так. Это не винда, где обычное удаление и установка заново часто решает проблему.
@iDx так а что пошло не так? я достаточно часто устанавливаю всю эту серверную кухню под WordPress на Ubuntu 14.04 LTS, это все за пару минут делается несколькими командами и поднимается на ура на дефолтных конфигах. Ни разу не возникали какие-либо проблемы. Я обычно использую на убунте Nginx mainline последний, PHP-FPM 5.5.9 и MariaDB 10.1 - все кроме PHP ставятся из своих родных репо после их добавления в sources apt-get. Ну а PHP уже в этой версии идет у меня из родных репо Digital Ocean.
@iDx а от чего именно ссыкотно? MariaDB - это форк MySQL, полностью совместимый, только улучшеный и отвязанный от Oracle, который реально тупит, как и любая корпорация. Его разработкой руководит собственно основатель MySQL, так что переживать нечего :)
@iDx если старый mysql сносить, то конечно они удалятся. mysqldump в помощь. Или PHPMyAdmin. Задампить все базы, установить MariaDB, импортнуть все туда, переключить конфиги на новый сервер и убедиться, что все работает. И только после этого сносить старый MySQL.
@zelenin справедливости ради привожу второй вариант :)
$query = new WP_Query( 'posts_per_page=-1' );
или
$query = new WP_Query( 'nopaging=true' );
дает один и тот же результат.
И, кстати, не обязательно использовать кастомный query, я бы лучше сделал:
add_action( 'pre_get_posts', 'my_change_args' );
function my_change_args( $query ) {
// для тонкого контроля где это нам надо
if ( $query->is_home() && $query->is_main_query() ) {
$query->set( 'nopaging', true );
}
}
Меньше кода переписывать в шаблоне. Я вообще стандартные лупы в шабонах стараюсь не трогать, одна такая функция my_change_args, в которой куча проверок на то, где мы готовим запрос и меняет его соответствующим образом, решает всю головную боль.
Это совершенно другой плагин, который используется для ОЧЕНЬ больших и высоконагруженных баз данных. Данные там хранятся точно в тех же таблицах, что и в обычной установке WP, просто этот плагин позволяет использовать многосерверную архитектуру и репликацию (одна и та же база в многих местах) и еще вагон других фич.
@ykppon что писать - читаем в документации на Nginx.org, гуглим convert htaccess to nginx. Не видя ваш .htaccess больше ничего сказать не могу. По поводу ошибок. 502я - это проблема коммуникации между Nginx и PHP-FPM. Сокет указан верно? FPM pool настроен правильно? PHP не валится из-за таймаута или нехватки памяти? Что в логах Nginx? Что в логах PHP? Вполне вероятно, ему (php) не нравится запрос. Проверьте fastcgi params в конфиге Nginx (nginx.conf + конфиг конкретного сайта). Причин может быть много. Судя по тому, что рядом похожий сайт работает, есть подозрение на конфиг сайта. Проверьте блок location, отвечающий за проксирование на php-fpm.
@Fesor да уж, странные люди никогда не переведутся... Случай с конкретным модулем - это, как мне кажется, чаще для специфических и немаленьких проектов, его опустим. Там, как правило, железо потянет эту прокладку без проблем. Но вот эту лень переписывать htaccess я никогда не пойму. С Nginx же все намного проще.
@AnnaTopowna код WordPress, как и почти всего стороннего кода под WordPress, как и все родные темы (в том числе twentyfourteen) - это GPL. Так что грани никакой нет - копируйте на здоровье, это легально. И даже поощряется. Что касается кода TutsPlus - черным по белому написано тут tutsplus.com/terms-of-use - пользуйтесь на здоровье, даже в коммерческих целях. Что касается шаблона для продажи... Если вы не знаете, что такое дочерние темы и как делать, как работать с базовыми API платформы... Не обижайтесь, ничего личного, но что же такое вы им продаете? Имел я неоднократно опыт "правки премиум-шаблона". Плевался, ругался, чарджил клиента в разы больше чем стоил сам шаблон, за эти же деньги мог бы ему с нуля нормально сделать. Это одна из причин почему я категорически отговариваю всех знакомых покупать шаблоны. Качество весьма сомнительное. Ничего личного)
@IgorBalyas а, то есть падение сервера уже было по факту, а теперь надо что-то выяснять? Если установлены на сервере sysstat или dstat - можно у них спросить (см. мануалы). Если не установлены были ранее (до падения) - тогда не уверен.
@Aingis в целом соглашусь. Есть нюансы, но холиварить давайте не будем) Что однозначно - если страница и так тянет тучу файлов (например увесистый новостной портал, главная страница), то минусы Google Fonts будут нивелированы. Кроме того, можно использовать их яваскриптовый font loader, который эти же минусы тоже устраняет чуть более чем полностью. По поводу кеша - это конечно не та штука, на которую следует рассчитывать, это просто приятный бонус.
