Неплохо знаю WP но зарабатываю мало, что делаю не так?

12k рублей? За два магазина там должно быть 12k $.

Почему nginx выдаёт 404?

Quad_Tree,
попробуйте

location /images {
      root /var/www/stuff/images;
}

или

location ^~ /img/ {
      root /var/www/stuff/images;
}

Ну и nginx перезагрузить

тут подробнее https://www.thegeekstuff.com/2017/05/nginx-locatio...

Плагин polylang создает избыточные страницы языков - как из удалить из видимости?

Посему https://site.com/ru/главная/ в русской версии, а https://site.com/en/home/

Что-то не так. Главная - это корневой урл, без каких-либо слагов. Должно быть:
https://site.com/ - главная, будем считать что язык по умолчанию английский
https://site.com/ru/ - главная на русском (втором языке)
Еще как вариант есть в настройках возможность показывать в урл язык для языка по умолчанию, тогда будет:
https://site.com/en/ - главная, будем считать что язык по умолчанию английский
https://site.com/ru/ - главная на русском (втором языке)
Но это не совсем правильно - язык по умолчанию показывать не нужно.
Для того, чтобы так было, нужно назначить английскую страницу главной, а потом сделать ей переводы. Polylang дальше сделает все сам.
Страница записей тоже должна быть переведена, тогда будет:
https://site.com/press-about-us/ - страница записей на английском, показывает посты на английском
https://site.com/ru/сми-о-нас/ - страница записей на русском, показывает посты на английском

Я подозреваю, что в вашем случае главная страница не назначена корректно в русской версии, поэтому урл site.com/ru, который должен показывать главную страницу, показывает страницу записей.

Какой хороший сайт для приобретения шрифтов вы знаете?

1. Их там мало, по типографским меркам весьма ограниченное число и разнообразность сильно скромная.
2. Это web font, для графического дизайна этого частенько бывает мало (если сравнить с тысячами / десятками тысяч characters в OTF и включением лигатур, символов и тд).

Плагин polylang создает избыточные страницы языков - как из удалить из видимости?

Ну если у вас главная = страница записей, то "дублирует" страницу записей. Только оно ее не дублирует, по хорошему на / и /ru/ должны выдаваться разные записи. На / - на языке по умолчанию, на /ru/ - на русском.

Как правильно настроить специфичные ЧПУ url для собственных типов записей в WP?

Q133,

придется видимо с отладчиком сидеть ..

Разумеется. Без него никак.

Как правильно настроить специфичные ЧПУ url для собственных типов записей в WP?

Боюсь, вопрос слишком объемен для Тостера и ответить вменяемо не представляется возможным. Здесь затрагивается сразу несколько Core APIs, включая те, которые работают с помощью "lots of regexes and some black magic" (это реальная цитата из inline doc WP_Rewrite).

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

Как создать фильтр ACF для таксономии?

azerphoenix, посмотрите как формируется стандартный WP_Query для поиска в WP. Это позволит понять, что нужно установить в хуке pre_get_posts для вашего частного случая

Как разместить произвольное поле (AFC) в боковой панели на странице редактирования записи?

alex-1917, во-первых, я не вижу в вопросе автора ничего, связанного с английским языком. Во-вторых, базовые познания английского в нашей профессии - обязательны. В третьих, там слова совсем простые, догадаться можно, даже без знания английского (суть описана в тексте над картинкой). В четвертых, язык не имеет отношения к версии плагина - 4 или 5, платная или бесплатная.

Ну и разница в отображении несущественна.

Как разместить произвольное поле (AFC) в боковой панели на странице редактирования записи?

Прилагаю скрин с ACF 4, а то товарищ наверху приложил с платной пятой версии, навряд ли у вас такая)))

А какая разница? :)
Настройка положения группы у них одинаковая.

Wordpress txt файлы как запретить загрузку?

А при чем здесь вообще Pods? Задача-то тривиальнее некуда (смотрите мой ответ)

Подсветка ошибок в редакторах JetBrains?

Dartess, можете уменьшить задержку tooltip, при 200мс например они "мгновенны"

Wordpress: грамотное подключение скриптов и стилей для разных страниц?

zorca, хм.. если речь идет о сайте / проекте целиком, то у меня композер в корне, все зависимости - они на то и зависимости. Это и либы, и плагины/mu-плагины, и сама тема. Все это подключается из корня и управляется одним composer update. В чем разница между каким-то сторонним плагином / либой (типа CarbonFields например) и своим кастомным решением для CPT/CT? Ни в чем, и то и другое - код, без которого сайт не будет работать.

Ну, у меня как раз со скоростью ядра проблем нет) Работает вполне себе хорошо и даже быстро. Что могу сказать наверняка - не медленне, чем Laravel. А вот сторонний код чаще всего оставляет желать лучшего.

С ларой по сути та же проблема. Низкий порог входа и все легко и красиво. Как результат - медленно. Не вытеснит ларка вордпресс :) Не вытеснит.

Wordpress: грамотное подключение скриптов и стилей для разных страниц?

zorca, ну, это уже личные предпочтения. Я вот озабочен performance по самое немогу, поэтому без dump-autoload как бы не работаю по определению. В принципе я и не вижу в этом проблем - на локальной машине дампить автозагрузчик нет необходимости, пусть себе хватает все на лету, динамически. А при деплое на прод в пост-деплое дергайте дампинг и все. Локально - удобно работать. На проде - быстро. И все автоматизировано.

Wordpress: грамотное подключение скриптов и стилей для разных страниц?

thehighhomie, а вот это не ко мне, сорян :) Я с frontend завязал 2 года назад)) и ни разу не пожалел)) моя стихия - backend.

Wordpress: грамотное подключение скриптов и стилей для разных страниц?

zorca, я не совсем понял в чем смысл "без обновления Композера" и по поводу изменений на лету.

Wordpress: грамотное подключение скриптов и стилей для разных страниц?

zorca,

в Sage он вроде уже есть. Я про автолоадинг.

Кстати да. Он же ставится через Composer.

Wordpress: грамотное подключение скриптов и стилей для разных страниц?

zorca,

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

Нет, потому что метаданные и так тянутся, по определению. Праймится post cache. Метаданные будут читаться в любом случае, дополнительных запросов нет. Одно дополнительное поле в результатах запроса, который и так будет выполнен, совершенно никак не скажется на скорости. Выборка идет по индексу post_id.

Чтение тонны метаданных из замечательно спроектированной базы Wp ну никак не сможет обогнать одну проверку пыхи на наличие файла. Можно поспорить, если есть желание.

А что тут спорить? Если бы нужно было делать отдельный запрос в БД - тогда да, можно бы какой-то benchmark запилить и проверить. Но отдельного запроса нет, мы просто подбрасываем еще одну строчку в результат уже существующего запроса. Overhead практически равен 0. При использовании object cache - реально 0.

thehighhomie,

и при удалении/редактировании страницы нужно удалять/редактировать ассеты.

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

а на счет namespaces и autoloading в вордпресс можно подробней? пример с каким нибудь модулем или приложением? пожалуйста

Гуглите wordpress + namespaces + autoloading. Там просто вариантов конфигурации больше чем один. Можно свой автозагрузчик, можно Composer на уровне плагина (или темы), можно Composer глобально на уровне сайта целиком (я предпочитаю такой метод).

Wordpress: грамотное подключение скриптов и стилей для разных страниц?

zorca,

Мы разбиваем functions.php на отдельные файлы с аатозагрузкой из нужной папки, чтобы не путаться.

У меня в functions.php только after_setup_theme, все остальное автолоад. Это как бы само собой разумеется. У тех, кто еще не добрался до namespaces и autoloading, но уже более-менее продвинулся, будут require_once модульных файлов из какой-нибудь папочки inc.

Метабокс избыточно

Чем избыточно?

можно проверять на наличие файла css со слагом страницы

То есть lookup file_exists? Имхо, взять из памяти готовые, уже загруженные метаданные - быстрее.

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

Как преобразовать $_POST в массив php?

А что у вас в $_POST['meters']? Покажите состояние массива $_POST при отправке формы.