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

1. Есть get_the_content(), которая возвращает контент, а не выводит.
2. Полученный контент (в виде string) можете уже думать как разбивать, но тут сложно придумать надежный способ со стороны бекенда. Думаю можно пробовать на клиенте с помощью javascript. Но, имхо, дизайнера надо отправить на какие-то курсы адекватности. Потому что данное UI-решение это совсем неадекватный UX, если речь идет о контенте, который предназначен для чтения.

Сортировать лучше не на выводе в цикле, а еще при получении всех записей. В вашем случае за это отвечает вот этот код:

$posts = $this->get_favorites( $post_type, $user_id, $limit );

Покажите что там в методе get_favorites(). Судя по тому, что дальше вы работаете с массивом объектов, внутри этого метода вызывается get_posts(). Попросите его отсортировать для вас посты еще на этапе выборки из БД.

Пагинация всегда рассчитывалась и будет рассчитываться от основного цикла. Основной цикл, он же Main Query, это тот, который WordPress запускает сам, после того как спарсит request и определит по rewrite rules а чего вы от него хотите.

Произвольные запросы с помощью new WP_Query( $args ) не являются и не могут являться основным запросом, это всегда будет дополнительный запрос, который выполняется уже после основного. Отсюда, оно совершенно никак не влияет на пагинацию, что вполне логично и разумно - ведь у вас на одной странице дополнительных циклов WP_Query может быть много.

С основным же запросом и изменением его параметров работают через хук pre_get_posts (а в нем изолируют именно is_main_query).

Матчасть, все есть в официальной документации с примерами кода.

Сразу скажу - я не специалист в стриминге, VoD и подобном, но исходя из логики и знания упомянутых инструментов, мне кажется есть смысл рассмотреть вариант haproxy в виде балансировщика и для SSL termination, а за ним пусть стоит Nginx. Первый быстрее по SSL и хорош в виде балансировщика. Второй хорош для оставшихся задач.

Label в данном случае это просто string, который вы отображаете в UI? То есть, каждое созданное поле будет иметь 2 "параметра" - label (то что отображается возле поля) и value (то, что ввели в поле)? Я тут вижу еще одно узкое место - когда вы доберетесь до полей других типов (number, radio, checkbox и тд), то у вас возникнут дополнительные "параметры" - тип поля и другие свойства. И вот тут все станет намного интереснее :)

Есть такой вариант - хранить в postmeta сразу 2 записи на одно поле:

fieldname => field value (значение)
fieldname_label => label value (лейбл)

Называть поля можно по разному. Например:

fieldname => value
_fieldname = label

В этом случае поле, которое начинается с подчеркивания, считается "скрытым" и "системным". Можно суффикс добавлять. Ну а дальше понадобится куча "подсистем", чтобы с этим удобно было работать.

А есть еще один вариант - хранить всю (любую) необходимую информацию в значении поля в виде сериализованного массива. Очевидный минус - по такому полю искать будет сложно (впрочем, внешнее индексирование с помощью того же Elastic Search проблему решит). В остальном - пихайте туда что хотите - значение поля, его лейбл, плейсхолдер, лимит символов и тд. Да хоть весь html целиком.

Так, по CMS в целом уже ответили, я лишь пролью свет на сам процесс. По сути термин "натянуть на CMS" не имеет особого смысла. Объясняю:

- В подавляющем большинстве случаев, если делать по уму, речь идет не о вставке нескольких переменных во вьюху, а о подключении ряда плагинов, их настройке, а также написании кастомного кода. Чем больше плюшек и функционала в дизайне, структуре - тем больше кастома надо пилить. На бекенде. И делать это правильно. "Натянуть" абы-как тут не покатит.

- Чем более кастомный проект, тем больше и больше работы именно на бекенде. Исходя из этого, на практике в крупных проектах фронтенд вообще не прикасается к PHP, "натягиванием" занимаются именно бекендеры. Фронт выдает чистую верстку, а уже задача бекенда - сделать из нее конечный динамичный продукт. Максимум, что светит фронту - уже после натяжки делать какие-то правки, но и тут работа будет сводиться к HTML-CSS-JS. Даже если HTML физически находится внутри файла с расширением .php.

Для больших объемов, когда грозят таймауты, используйте WP-CLI

Имею ввиду письма: уведомление об ответе, письма подтверждения регистрации и т.п.

Во-первых, это называется транзакционные письма.
Во-вторых, под это существует вагон узкоспециализированных сервисов, которые умеют только в это, но умеют очень хорошо, и стоят на хорошем счету у всех почтовиков. Сервисы эти, внезапно, называются сервисами транзакционных писем (Transactional Email Service). Это Amazon SES, Mailgun, Sendgrid и вагон аналогичных. Есть и русскоязычные - гугл в помощь.

Неужели так сложно воспользоваться поиском?

Как обернуть дивом каждые 3 записи?

Есть предположение, что вы не совсем корректно продумали архитектуру, но без нормального описания сути задачи сложно говорить точнее. По сути:

1. 2 одинаковые записи не нужны, достаточно одной, а к ней уже привязывать счетчик(и)
2. Счетчик тоже вполне может быть один, а вот его состояния, чередования и прочие данные - хранить отдельно
3. Смена счетчика / обнуление и обновление данных вешается на cron

Откройте для себя мир продуктов Atlassian и не изобретайте велосипеды.

При использовании "бесконечного скролла" многие почему-то делают только скролл вниз, а про верх забывают. Это архитектурная ошибка. Должно быть как - порцию нового подгрузили, порцию старого выгрузили. В обе стороны. И тогда никаких проблем с затупами не возникнет никогда. От слова совсем.

Можно и нужно. Grid создали не для того, чтобы заменить Flex. Это 2 разных метода построения лейаута, если грубо:

- Grid = 2D (расположение элементов по 2м осям одновременно, по горизонтали и по вертикали)
- Flex = 1D (расположение элементов только по 1й оси, горизонтали или вертикали)

Еще грубее - flex хорош для "инлайна", выравнивая элементов в одной строке или колонке, как правило это конкретно контент-элементы, а grid - хорош для контейнеров и более общих элементов (карточек и тд). То есть, гридом задали общую структуру и лейаут, флексами внутри блоков расставили контент-элементы.

имхо:

- роботам ограничить аппетит в robots.txt адекватным rps/rpm
- выставить тот же адекватный rps/rpm на уровне сервера с помощью rate limiting

результат:

- роботы без проблем индексируют
- обычным пользователям никаких капч и неудобств
- особо активным и левым ботам с аппетитом выше rate limit - автоматический бан или просто сброс запросов свыше лимита (тут на выбор по вашему желанию)

Вставлять код надо в визуальный редактор, но в текстовом режиме (вкладка Text а не Visual, справа вверху). Только что проверил - все работает. Если у вас не работает, значит какие-то плагины или код фильтруют контент (и могут вырезать iframe, например по соображениям безопасности).

А еще проверьте свои плагины в браузере, возможно какой-нибудь AdBlock или аналог вмешивается.

https://woocommerce.com/products/woocommerce-order...

Плагин позволяет создавать свои кастомные статусы (Pending Payment в вашем случае) и менять процесс (то есть порядок переходов между статусами).