DigitalEmotions: вместо вашего get_posts() я вам дал правильный способ получения постов (объектов). Почитайте документацию по WP_Query. Перед тем, как выводить контент в цикле foreach вам его сначала надо получить из базы данных, для этого и существует WP_Query или get_posts (как легковесная обертка вокруг того же WP_Query). Ну а если получить объекты с помощью WP_Query, то и использовать их надо вместо цикла foreach в цикле while, в формате WordPress Loop.
Приведенный вами массив - это какая-то каша, вырванная из контекста. Опишите четче задачу, покажите скрин страницы и весь код шаблона. Без подробностей невозможно увидеть картинку целиком.
Марк Розенталь: Nginx, Apache, Node и тд - это сути не меняет. Важно под каким юзером запускается процесс веб-сервера. По умолчанию в Дебиане - www-data, группа www-data.
Марк Розенталь: Дебиан (как и Убунта) по умолчанию просто не создает эту папку. Есть такое general rule of thumb, что все приватные юзерские файлы должны быть в папке юзера /home/username/, а юзерские файлы, доступные извне через вебсервер - в папке /var/www/sitename/, так же как и все логи в папке /var/log/, временные файлы - в папке /var/tmp/. Грубо говоря, именно папка /var/ является тем местом, куда надо запихивать все кастомные и изменяемые файлы.
kamwork: насчет плагинов волшебного рецепта нет. Все зависит от задач. У нас много самописного, какой-то код уже давно оформился в собственные плагины. Из сторонних решений используем проверенные. Из тех, которые могу советовать с чистой совестью, которые часто (некоторые - постоянно, в некоторые сами контрибьютим) используем сами - Advanced Custom Fields 5 Pro, WooCommerce, Easy Digital Downloads, Query Monitor, WordPress Social Login, Revisr, Polylang, все что написано такими авторами как Marc Jacquith, John James Jacoby, Pippin Williamson, Justin Tadlock, Boone Gorges, Сергей Бирюков, Tom McFarlin, компании 10UP, Humanmade и многие другие. Будете вариться регулярно в экосистеме WordPress - сами будете видеть что к чему.
Если интересует какой-то конкретный функционал - спрашивайте. Помогу чем смогу.
Данила: Ооо)) Тогда у вас сейчас откроется новый дивный мир) WP с помощью этого АПИ существенно шагнул вперед (пока, правда, неофициально, как видите. Хотя адепты WP давно в курсе и активно используют, это АПи пилится уже достаточно давно).
Крил: ну задача все еще не ясна. Что с вашим куском кода происходит в средах WP и WC - непонятно. Установите для отладки хотя бы Query Monitor. На данный момент, похоже, вы не совсем разобрались как работает WP_Query, и тем более не учли, что WooCommerce использует свой класс WC_Query, который как раз и переопределяет все, что ему нужно, в родном WP_Query. У него есть свое подключение в хук parse_request для анализа запроса (ваши переменные), а также в pre_get_posts для модификации запроса непосредственно перед его выполнением. Посмотрите исходный код класса, чтобы понять их workflow. По тем данным, которые вы предоставляете, я не могу у себя воссоздать аналогичные условия, поэтому могу строить только предположения. Первые из них - либо у вас переменные не парсятся корректно, либо они не передаются корректно (возможно после всех ваших танцев с бубном они перезаписываются WooCommerce'ом на свои, в порядке приоритета).
Данила: интересное решение, с удовольствием почитал бы статью. А то все обычно сводится к сборкам на базе готовых плагинов) Люблю кастомные решения! Не забудьте запостить ссылку когда будет готова статья :)
ЗЫ: Так, навскидку, а вы в курсе v2.wp-api.org/? Сильно упрощает подобную интеграцию, особенно по части js-шаблонизаторов да и вообще js на фронте. В декабре основа REST API войдет в WP 4.4, в апреле - целиком уже в WP 4.5
kamwork: у нас потолок на полную загрузку 800мс для небольших сайтов, 1200мс для больших и сложных. Это, так сказать, внутренний корпоративный стандарт. Если где-то приближаемся к этому лимиту - пора думать о рефакторинге и искать узкие места. Справедливости ради - это цифры на своих серверах, заточенных полностью под WP, на базе Nginx, HHVM c фоллбеком на PHP-FPM, Redis, MariaDB, с использованием объектного кеша, OPcache в PHP (в HHVM он объективно родной и лучше), оптимизацией скриптов, стилей, картинок и тд. Но это не full page cache, а динамика, а сервера - далеко не самые мощные, мы используем Digital Ocean, местами AWS, все VPS в основном 1Гб RAM / 1 Core или 2Гб RAM / 2 Cores. Для крупных проектов используем многосерверную архитектуру, а не более мощные сервера.
Еще бы описали что там под капотом - кастомная таксономия, свои функции для вывода etc. Хотя бы в двух словах, алгоритм. Для будущих поколений будет очень полезно (собственно, в этом одна из главных фич подобных сайтов QA).
Крил: ну так поставьте массив вручную для отладки, это как раз правильный подход. А костыли с дырками - неправильный и опасный. Вероятность того, что у вас не заложен нормальный бюджет и сроки на рефакторинг слишком высока, и шансы того, что кусочек подобного кода попадет в продакшн - тоже весьма высоки.
Мой ответ - уточняющий. Разбираться в текущем коде - не есть хорошо. Вернитесь в отправную точку, сформулируйте четко задачу, тогда можно будет воссоздать аналогичные условия у себя и помочь вам с отладкой. Сейчас же ваш "временный" код может больше ошибок вносить, чем вы пытаетесь отловить.
kamwork: Ларочка - это не движок, это низкоуровневый фреймворк. Согласен по поводу нового вопроса, Pavel Designer: запостите его отдельно и пригласите ответить. Распишу подробнее.
Данила: Нельзя. "New formats cannot be introduced by themes or even plugins", см. тут, прям первый абзац. Можно обойти (решить ту же задачу) создав свою кастомную таксономию, можно хакать файлы ядра и тд, но это все - альтернативные решения или хаки. Используя родные Post Formats создать свой кастомный формат НЕЛЬЗЯ.
kamwork: тогда WP смело берите. ACF 5 Pro за вполне разумные деньги решит все вопросы с метаданными, дополнительными полями, галереями, повторяющимися полями, зависимыми полями и тд. Реально сэкономит массу сил и времени.
MetaDone: ну вот, вы сами понимаете, что там говнокод, который сильно, СИЛЬНО усложняет контент. К тому же, он лочит на использование этого плагина, что недопустимо на больших проектах. Мы на одном сайте с 6к статей как-то чистили контент от шорткодов и подобных прелестей. Это головняк еще тот, а 6к - это еще небольшой сайт. Я не против визуальных редакторов как таковых, но Visual Composer и им подобные - это уродливые решения, от которых вреда в разы больше, чем пользы. На средних и крупных проектах. Для небольших сайтов - вполне пойдет.
