Web Lizard: Да, все верно. Только можно еще чуть сократить:
$tag = get_queried_object();
$product_list = get_posts("tag=$tag->slug");
Хотя использование строчных параметров немного олдскульно, предпочтительней массивом:
$tag = get_queried_object();
$product_list = get_posts( array( 'tag' => $tag->slug ) );
asunaro_ru: да, я понимаю. Сам через это проходил энное количество лет назад. После нескольких таких копипаст, которые повлекли за собой часы отладки и поиска глюков, научился изучать как надо делать правильно.
valikhan: смотрите логи ошибок. Возможно размер файла больше лимита, возможно таймаут срабатывает, смотрите в браузере на этой странице нет ли javascript ошибок в консоли, гуглите на форуме поддержки Cherry Framework. Причин может быть много, в вашем вопросе недостаточно данных для диагностики.
asunaro_ru: Так и хочется написать "идите учите матчасть (основы)" :) На эту тему уже писано-переписано тонны постов и инструкций. Если кратко - query_posts грубо заменяет основной (глобальный) $query попутно ломая кучу всего, на чем завязан WP по мере выполнения остального кода. Есть 3 способа работы с $query:
- new WP_Query() для вторичных запросов если нужны пагинация и плюшки
- get_posts() для вторичных запросов если не нужны плюшки, просто массив Х постов (например, похожие посты к текущему, 5 популярных постов и тд)
- а для модификации основного запроса используется хук pre_get_posts
777 выставлять нельзя, это огромная дыра в безопасности. При 777 в эту папку кто угодно может залить что угодно, и выполнить залитый файл. Если нужны "широкие полномочия" 775 должно быть достаточно (а в идеале 755). Если при 775 у вас проблемы с загрузкой - обращайтесь в поддержку хостинга. Хотя, скорее всего, проблема не в этом.
Silm: Проблема не в CMS как таковой, а в том, что вы с ней делаете. С той же Joomla можно сотворить прекрасный и шустрый сайт. То же касается WordPress, Drupal и любой другой CMS/CMF. Дело в руках. Если на голый WordPress на shared-хостинге без адекватного тюнинга под скорость и кеширования навесить несколько медленных плагинов - например: Broken Link Checker, Redirections, WordPress Social Login, WPML, GeoIP по базам MaxMind из CSV файлов, делать минификацию и конкатенацию скриптов и стилей на лету и тому подобное, то производительность упадет на порядки. На несколько порядков. Если все то же самое сделать руками правильно - заметного спада производительности по сравнению с шустрым голым WP не будет. Например, вместо Broken Link Checker используем анализ логов на сервере + Google Webmaster Tools. Для Redirections - тот же GWT + те редиректы, которых не избежать, ставим руками в конфиг Nginx / Apache .htaccess. Вместо тяжелого WSL для социалок ручками делаем кастомное решение только для того, что надо (WSL грузит огромную либу под десятки соцсетей с полными АПИшками для работы с ними, а нам в реальности надо 2-3 сети и только авторизацию, то есть, пару % от всего кода), тут работы на 2 часа всего. Вместо тяжелого WPML берем Polylang или даже qTranslate X, или мультисайт (зависит от специфики сайта), все строки переводим с помощью родных средств (PO/MO файлы), плагин только для перевода контента. Для GeoIP используем бинарную базу MaxMind и компилим родной модуль для Nginx, это должно работать на уровне сервера, а не PHP который при каждом запросе читает из файловой системы CSV файл на 20Мб и ищет по нему одну строчку. Минификацию и конкатенацию делаем Gulp'ом и используем уже готовые скрипты и стили. Это я привел конкретные примеры из жизни, то что приходилось клиентам рефакторить в течение последнего года. Поэтому, дело не в CMS как таковой. А в руках, которыми делается сайт на этой CMS.
> Прекрасно прошел CMS несколько лет делания сайтов без знания PHP.
Это не разработка, а имплементация. Да, есть масса заказов на такую работу, не спорю. Но и стоимость такой работы ниже. Можно ли жить на этом? Можно. Хорошо ли? Судя по тому, что вы сами перешли на следующий уровень - вряд ли :)
> Потом сразу перескачил на гораздо более серьезные технологии.
Похвально.
> Тратить время на PHP не считаю нужным.
Субъективно. PHP - язык номер 1 для веб. Нравится / не нравится - это другой вопрос. Но то, что большая часть инета работает на PHP, это факт. Включая фейсбук, вордпресс и массу других крупных проектов.
> Правда у меня общепрограммисткий бэкграуд хороший.
Вот с этого и надо было начинать :)
Алексей POS_troi: да, у них многосерверная архитектура (точнее, целые датацентры). Сути это не меняет. Весь WordPress.com - это одна установка WordPress Multisite. И она прекрасно держит такой load, который вы себе не можете представить. Любое железо, независимо от платформы, имеет лимиты. Если у вас миллионы уников в сутки - тут одним серваком не обойтись, придется раскошелиться на горизонтальную масштабируемую схему. Впрочем, при таком трафике это не проблема, деньги на это должны быть однозначно, включая на зарплату хорошего Devops инженера. При использовании WordPress с небольшим трафиком (десятки / сотни тысяч просмотров в сутки) он прекрасно работает и на одном небольшом правильно настроенном серваке, вопрос исключительно в количестве говнокода, который на него навешать. Но это уже вопрос не к WordPress.
helloallhere:
> тк его id уникален, буду использовать конструкцию CREATE UNIQUE INDEX id ON users(id) -индекс по колонке id в таблице users
При всем уважении к ребятам на ruhighload, это весьма странная конструкция. Дело в том, что колонка ID является PRIMARY_KEY, и индекс по ней MySQL создает автоматически. Собственно, они сами об этом написали в пункте "8. Первичные ключи". Видимо вы не читали об индексах в родных таблицах WP - посмотрите тут https://codex.wordpress.org/Database_Description#T...
> Теперь как я понимаю лучше сделать так- для отправки тех автоматических сообщений использовать sendgrid, и при этом будет другой домен, например- no-reply@post.мой_домен.com А получение организовать на обычный домен вроде admin@мой_домен.com с помощью например яндекс почты для домена.
Да, все верно.
> я могу указывать NS сервера, их там шесть, сейчас я использую два, потому что пока эксперементировал с cloudflare (это то, что касалось моего прошлого вопроса про dns сервера, то есть в будущем буду использовать digitalocean, но принцип здесь вроде такой же)
При использовании Digital Ocean у вас будет 3 неймсервера - NS1.DIGITALOCEAN.COM, NS2. и NS3. Все записи (А, TXT, CNAME, MX) вы будете создавать уже в панели Digital Ocean.
> но какой MX мне указывать, чтобы всё работало как я написал выше?(sendmail+яндекс)
После перехода на неймсервера Digital Ocean уже в их панели надо настраивать. Для Sendgrid ничего не надо, его SMTP просто указать в настройках Postfix. Для яндекса настройки тут: https://yandex.ru/support/pdd/set-mail/mx.xml Особое внимание надо уделить записи SPF - в нее кроме яндекса надо добавить IP адрес вашего сервера, возможно Sendgrid (уже не помню, надо в доках смотреть), чтобы письма отправленные Postfix'ом через Sendgrid корректно распознавались.
> чтобы получить ssl, а как с ним там дальше будет
По SSL это уже отдельный вопрос. Задавайте отдельно и приглашайте меня ответить.
> и с кэшированием nginx, там же тоже нужно будет с портами работать, что-то менять
У вас сайт динамический большей частью (авторизованные юзеры), fastcgi_cache Nginx'совский - не самое лучшее решение.
> файрвол включил) но никак не настраивал, я просто думал что при использовании сторонних днс у них там своя защита какая-то предусмотрена
Это разные вещи :) На DNS запросы никто не отфильтрует. Что за файрвол у вас там? По сути логика простая - запретить весь входящий трафик, кроме ssh, http и https. Исходящий разрешить весь.
> почему лучше настроить postfix на работу через них, а не использовать php решение, под заголовком Integrate in Minutes у них на главной странице?
Да, можно через exim. В любом случае, на уровне системы. Грубо говоря, если через PHP - там таймауты, ожидание выполнения стороннего запроса, получение и обработка результата. Лишние ресурсы. В случае с системным пакетом - PHP просто отправляет через родной функционал письмо в очередь пакета, дальше на уровне системы весь процесс идет.
> как я понимаю- после этой настройки, используя комманду php- mail(), мои письма уже автоматически будут отсылаться через этот сервис
Да, все верно. Кроме того, любое письмо отправленное самим сервером (например, logwatch) тоже будет нормально доходить.
> Что лучше выбрать- рассылка через php библиотеку, или используя exim, или postfix? При каком варианте будет наименьшая нагрузка на сервер?
При использовании системного пакета (exim, postfix)
Timitu: Тогда вам необходимо совершенно другое железо. Живая динамическая платформа и "сайт" - это разные вещи. Для соцсети (1кк уников в день это уже ощутимый трафик) понадобится многосерверная архитектура. Базы отдельно, и не одна, тут уже в сторону кластеров надо смотреть. Читать отдельно (желательно из жесткого кеша в памяти, например Redis), писать отдельно. Load balancer, отдельно статику и тд. В общем, проект уже должен изначально строиться в горизонтально расширяемом виде и с учетом его специфики. Да и вообще для проектов такого типа метрика "Х уников в день" не совсем корректна. Уников может быть и 10 тыщ всего, а вот половина из них могут торчать в сети часами и стабильно генерить тыщи запросов. Кроме того, надо уже смотреть и ТЗ. Будут ли там медиафайлы? Видео-аудио, в первую очередь. Стримить медиа - отдельная специфичная задача. И тд.
Впрочем, если у вас есть соцсеть с таким трафиком (1кк уников в сутки), то, во-первых, вам нужно просто нанять очень хорошего devops инженера. Он будет знать что делать. Во-вторых, вопрос стоимости уже не столь важен. Потому как 1млн уников в сутки - это уже трафик, который можно (и нужно) эффективно монетизировать. Но и нужно понимать, что это вполне уже порядок "тысячи долларов в месяц".
Потянет ли это WordPress? С ровными руками, безусловно, да. WordPress.com - самая крупная в мире блогоферма (и отчасти соцсеть) + куча АПИ-сервисов прекрасно работает же. Есть ли смысл пилить это на WordPress? Не думаю.
$tag = get_queried_object();
$product_list = get_posts("tag=$tag->slug");
Хотя использование строчных параметров немного олдскульно, предпочтительней массивом:
$tag = get_queried_object();
$product_list = get_posts( array( 'tag' => $tag->slug ) );