Игорь Воротнёв

1. Не использовать query_posts
2. Откуда берется контент для правой и левой колонок, где он хранится и в каком виде? Схематически покажите архитектуру.
3. Если я правильно понимаю, вам нужно вывести объект "Портфолио", у которого сллева будет логотип/скрин, под ним какое-то описание, а справа - стандартные поля the_title и the_content/the_excerpt, так?

Ответите на эти вопросы - помогу с кодом.

Оксана почитал ваш комментарий к вопросу "что именно не подошло в WordPress" и все стало понятно. Должен вас разочаровать - проблема не в WordPress а в вас и ваших ожиданиях, и смена CMS, соответственно, проблему не решит, а только усугубит. Если перейдете сейчас на Джумлу или что-то еще, через некоторое время вангую повторение вопроса на Тостере или вопрос "Как вернуться снова на WordPress".

Причин тому нескольлко:

- Далеко не все плагины работают со всеми темами прямо из коробки, это нормально, так и должно быть. Часто нужно закатать рукава и дописать что-то в код шаблонов.
- Конфликты плагинов случаются крайне редко, если вы сталкиваетесь с этой проблемой часто - вы что-то делаете не так.
- Обе проблемы были, есть и будут на любой платформе, но и на любой другой платформе этого будет в разы больше.
- Экосистема WP самая большая, кроме того, WP больше других платформ озабочен обратной совместимостью. Этого всего нет у Джумлы и других CMS.
- Другие CMS вам вряд ли подойдут, так как вам требуется не инструмент для разработчика, а конструктор. Посему, у вас вариантов нет, только WordPress или онлайн-конструкторы типа Wix, Squarespace. Но там свободы в разы меньше.

Я бы вам предложил просто начать более углубленное изучение WordPress. Задавать здесь конкретные вопросы по конкретным ситуациям "несовместимости" и "отсутствия поддержки". Мы поможем.

WordPress - лучшая из доступных CMS. Говорю это со знанием дела, как человек, который на базе WordPress разрабатывает целые SaaS-платформы и сложные инструменты. Мощнее только фреймворки - Laravel, Symfony и тд, но это точно не ваш путь, по крайней мере пока.

У вас проверка nonce не проходит, потому что путаница с названиями переменных - и my_ajax, и php_array и тд. Почитайте документацию или вот тут.

А зачем в этом случае пагинация, зачем изобретать какой-то велосипед? Вам нужен Infinite Scroll. Например, он есть в Jetpack. Есть еще с десяток плагинов минимум.

Их много, минимум полторы дюжины. Кто-то использует, кто-то делает руками. Вопрос, как и с любым другим инструментом, должен стоять так - "а есть ли смысл использовать Х в этом конкретном проекте". И ответ на этот вопрос зависит от конкретного проекта.

RAM - от 2Gb
CPU - от 2х ядер
SSD - обязательно
Канал - чем толще, тем лучше :)

На таком железе WordPress Multisite будет прекрасно шуршать с десятками сайтов, если на них не гонять трафик рекой. Если же нагрузка вырастет - придется масштабировать сервер, что вполне нормально.

Ну а если вместо Apache + PHP использовать Nginx + PHP-FPM (версии 5.5.9+ чтобы родной OPcache был ), да еще добавить Memcached/Redis, а MySQL заменить на MariaDB10 - шуршать будет заметно веселей, выдерживать значительно большие нагрузки. А еще можно за Nginx'ом PHP-FPM оставить исключительно как fallback, а перед ним поставить HHVM. Это еще ускорит в разы. Ну а чем быстрее сервер работает и большие нагрузки выдерживает - тем больше сайтов на него можно повесить или больше трафика гнать. То есть, заметно отодвинуть момент апгрейда железа и сэкономить себе немного денег на пиво, детям на конфеты и жене на цветы. Если грамотно подтюнить все упомянутые компоненты, то еще и на презервативы хватит.

Прикол в том, что использовать query_posts() категорически не рекоммендуется, я уже устал это повторять, если честно. Почитайте документацию, поймете, что это вполне ожидаемый результат при использовании этой функции и забудьте про нее, считайте, что ее не существует. Есть WP_Query, get_posts(), get_post().

Вам же гугл сказал все - 550мс ответ сервера. Это и есть узкое место. Сервер принимает запрос, делает что-то свое, форвардит на PHP, тот поднимает весь WordPress, тот неоднократно лезет в базу данных, потом данные обрабатывает, генерирует html и возвращает их серверу, который отправляет в браузер. Оптимизуйте так:

- SSD
- Удаляем Apache и забываем как страшный сон
- Nginx, отключить все ненужное логирование, оптимизировать настройки (буферы, keep-alive и тд), gzip, кеширование статики на стороне клиента и адекватное время жизни кеша
- PHP5-FPM версии 5.5.9 и выше с встроенным OPcache, оптимизировать настройки
- кеширующий бекенд (Memcached / Redis)
- MariaDB вместо MySQL (пошустрее будет) - погоняйте неделю-две в дефолтном конфиге, потом тюнить по результату (кеши в основном)

Далее на уровне самого WordPress:

- плагин для объектного кеширования (Memcached / Redis)
- Fast Full Page Cache или аналог (не используйте тяжелые WP Super Cache / W3 Total Cache) для кеширования страниц целиком
- минификация и конкатенация скриптов и стилей

Есть еще и хардкор для настоящих мужчин:

- HHVM с фоллбеком на PHP
- Nginx fastcgi_cache
- Кастомная сборка Nginx с модулем nginx_memcached, чтобы PHP вообще не поднимать без острой надобности
- Nginx SPDY
- и так далее...

Ну и, конечно же, сам сайт надо рефакторить - и верстку, и функционал. Удалить ненужные плагины, где можно обойтись одним фрагментом кода вместо целого плагина - обходиться.

Удачи :)

Ни в коем случае не ставить никаких ISP Manager / Vesta / CPanel, иначе никогда не научитесь тому, чему хотите научиться. Кроме того, они жрут ресурсы. Даже Vesta, которая самая легкая, их жрет прилично, а я сильно сомневаюсь, что у вас VPS c 8+ Gb памяти.

Изучать надо по урокам и статьям, читая мануалы и best practices по каждому package. Порядок, плюс-минус, таков:

- развернули ось
- сделали сразу апдейты
- создали и настроили swap
- поменяли пароль рута на что-нибудь супер-мега-сложное (его мы использовать все равно не будем)
- создали себе обычного юзера с паролем нормальной сложности (он будет использоваться для sudo)
- дали юзеру права sudo
- закрутили гайки по SSH - сменили порт, запретили вход руту и вход по паролю (только по ssh-ключам), разрешили вход только одному своему новому логину
- настроили UFW - простой, но эффективный firewall на основе iptables - default deny, allow http, https, свой кастомный ssh-порт. Если логиниться будете только из нескольких мест (офис, дом) - можно вообще ssh разрешить только на эти IP.
- sudo dpkg-reconfigure tzdata чтобы установить свою временную зону, так логи потом легче читать и понимать
- настроили logrotate
- настроили logwatch
- настроили Postfix, чтобы сервер вам письма мог слать (мы его настраиваем на внешний мейлер, например Mandrill, чтобы все письма точно в спам не падали)
- настроили fail2ban (потом, после установки и настройки веб-сервера и сайтов, в fail2ban можно дополнения писать, например мы на WordPress-сайтах мониторим попытки авторизации в админку и блочим тем же fail2ban)
- дальше ставим все что нужно - Git, Nginx, HHVM, PHP5-FPM, MariaDB, Memcached/Redis и так далее.

Регулярно заходите на сервер, делайте apt-get update && apt-get dist-upgrade.

p.s.: это по ubuntu/debian, для других систем все то же самое, но packages и команды могут немного отличаться

Если плагин простенький - обычный функциональный паттерн. Если чуть сложнее - одним файлом с одним классом. Если что-то сложнее - уже упомянутый WordPress Plugin Boilerplate (оф. сайт)

в настройках шаблона всё жёстко закреплено и можно выводить только то, что есть в нём по дефолту

Добро пожаловать в мир "универсальных тем на все случаи жизни с 1001й настройкой", которые в реальности ни разу не гибкие. В вашем случае - это премиум-шаблон. Стучитесь в поддержку к разработчикам, вы за это деньги заплатили.

Easy Digital Downloads
WooCommerce