Задать вопрос
HeadOnFire

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

PHP, Laravel & WordPress Evangelist
Комментарии

  • Вывод контент из поля записи на другую страницу записи?

    HeadOnFire
    @HeadOnFire
    Эд, ХЗ. По вашим вопросам и ответам на уточнения ничего понять невозможно. Что у вас что, где и в каком виде - одному богу известно.
    Написано

  • Как сделать вывод записей через фильтр?

    HeadOnFire
    @HeadOnFire
    Data-атрибуты просто самый сложный пример

    Фильтрация при запросе из БД или из массива JS еще проще

    Ровно наоборот.
    Написано

  • Как сделать вывод записей через фильтр?

    HeadOnFire
    @HeadOnFire
    Простой способ, который сработает если объектов немного и они все на одной странице. И не будет работать как надо, если этих объектов сотни/тысячи, выводится Х штук на страницу. С помощью дата-атрибутов вы сможете фильтровать только те, которые загружены на конкретной страничке.
    Написано

  • Как вывести все посты на главной странице блога с пагинацией?

    HeadOnFire
    @HeadOnFire
    deniskins23, само по себе ок, неправильно только использование функции query_posts. Вместо нее есть get_posts (у которой кстати suppress_filters по умолчанию уже включено) и WP_Query.
    Написано

  • Как вывести все посты на главной странице блога с пагинацией?

    HeadOnFire
    @HeadOnFire
    deniskins23,
    query_posts( $args );


    https://developer.wordpress.org/reference/function...
    https://10up.github.io/Engineering-Best-Practices/php/

    avoid_query_posts.png

    если кратко - никогда не используйте query_posts
    Написано

  • Как правильно завершить выполнение скрипта?

    HeadOnFire
    @HeadOnFire
    shell_exec("sudo

    Вот это конечно атомный звиздец))
    Написано

  • Стоит ли уходить с разработки WordPress?

    HeadOnFire
    @HeadOnFire
    среди тех кто глубоко знает WP, конкуренция уже маленькая, и спроса тут больше.

    И платят не меньше чем в Laravel / Symfony / whatever
    Написано

  • Стоит ли уходить с разработки WordPress?

    HeadOnFire
    @HeadOnFire
    Stalinko, лучше признайте что вы не в теме и выходите из обсуждения. Сморозили редкую чушь и теперь пытаетесь выкрутиться.

    Лично я основные деньги зарабатываю на WP и люблю его, знаю от А до Я, в прямом смысле этого слова. Лидерство в разделе WP здесь на Тостере как бы подтверждает это. Монструозными конструкторами и билдерами не пользуюсь, пишу все в чистом виде, использую Composer, компоненты тех же Symfony или Laravel, пишу микросервисы на Golang если проекту это нужно, использую другие ЯП и технологии в стеке, если в этом есть необходимость и польза. И все это прекрасно дружит с WP. При этом я пишу и на Laravel, Symfony, Phalcon - так что знаю ситуацию по обе стороны баррикад. При этом на WP у меня ряд Enterprise клиентов с крупными и сложными решениями, беру за работу на WP нормальные деньги и не сталкиваюсь с какими-то вашими шаблонными сайтами.

    Проблема в том, что внутри ВП архитектуру приложения не перепишешь и лучше начинать с нуля например на ларе,

    А не нужно переписывать ничего. Воспринимайте WP как dependency, как модуль. Подключите его в Composer, а дальше пишите как считаете правильным.

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

    Давайте расставим точки над И раз и навсегда. Стоковый WP выполняется ровно с такой же скоростью, как стоковый Laravel. При этом в случае с Laravel это голый Фреймворк, в случае с WP - это уже CMS, мощная админка с кучей типовых фич, БД и тд. Скорость выполнения у них одинаковая, при совершенно разных наборах функциональности. И если от этой начальной точки вы будете дальше свой кастом пилить с умом в обеих случаях, то никаких проблем с производительностью НЕ БУДЕТ. Они будут, если вы начнете навешивать на WP говноплагины. Но если бы у Лары была такая же возможность и аналогичные плагины - производительность страдала бы точно так же. Дело не в платформе, а в кривых руках, которыми вы ее пилите. И в отсутствии необходимых знаний.
    Написано

  • Стоит ли уходить с разработки WordPress?

    HeadOnFire
    @HeadOnFire
    Вот дельный ответ. Для того, чтобы изучить Лару/Симфони/Golang/whatever бросать WP полностью совершенно не нужно. И да, адекватный разраб умеет программировать на ЯП, а не на WP/Laravel/etc. Зная хорошо сам PHP, освоить любой фреймворк не составит труда. Зная один ЯП хорошо, можно достаточно легко освоить другой ЯП, а зная несколько ЯП следующие изучаются еще быстрее...
    Написано

  • Сохранять комментарий названия темы в style.css в WordPpress?

    HeadOnFire
    @HeadOnFire
    Playtoster,
    всё работает даже когда комментарии с названием темы пропали

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

  • Сохранять комментарий названия темы в style.css в WordPpress?

    HeadOnFire
    @HeadOnFire
    Playtoster, вы можете спокойно билдить финальный css в /тема/style.css а не /тема/assets/style.css, и вы можете спокойно вырезать все комментарии из css при билде, исключив только этот в заголовке если он будет начинаться с /**! (обратите внимание на восклицательный знак).
    Написано

  • Почему AJAX запросы работают, только когда авторизован?

    HeadOnFire
    @HeadOnFire
    Tendor, именно поэтому там 2 хука:
    add_action( 'wp_ajax_misha', 'test_function' ); 
add_action( 'wp_ajax_nopriv_misha', 'test_function' );

    Первый для авторизованных, второй для неавторизованных (_nopriv_). По такому принципу работают wp-admin/admin-ajax.php и wp-admin/admin-post.php, так и должно быть. Не сбивайте человека.
    Написано

  • Как правильно сделать 301 redirect на https?

    HeadOnFire
    @HeadOnFire
    Gennick's Macleo, все через -t чекают, это естественно. Дело в другом - вы изначально упустили одно из главных условий задачи - редиректы с non-www на www. Ну да ладно, я же тоже что-то забываю сразу написать и добавляю позже. Это не было упреком, просто обратил внимание что код изменился.

    Что касается конфига выше – так а в чем все-таки его преимущество? То, что все в одном блоке server, который тяжелее воспринимается теперь? А если, например, надо сделать чтобы запросы на 80й (www и non-www) писались в один лог, на non-www 443й в другой, а уже конечные обрабатываемые без редиректов запросы на 443й www - в третий конфиг? А если есть старые урлы (привет, SEO) на, например, non-www https, которых на новом сайте www https нету, и нужны конкретные точечные редиректы?

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

    У любой оптимизации должен быть смысл и реальная польза. Если нет и того, ни другого, то это антипаттерн. В данной ситуации мне это напоминает использование "шибко умных" конструкций типа IF без фигурных скобок и в одну строчку, или более экстремальных вариантов типа легендарного:
    array_key_exists($word, $wordsFound) ? $wordsFound[$word] += count($matches) : $wordsFound[$word] = count($matches);


    Кому-то данный код может показаться хорошим и оптимизированным - меньше строк же. А точнее всего одна. И в момент написания данного кода она даже вроде и понятна. Но вот поддерживать это будучи в здравом уме никто не захочет.

    ЗЫ: И все равно из вашего последнего конфига я не вижу, каким образом non-www https домен (https://example.com) обрабатывается. Либо конфиг неполный, либо Nginx с относительно недавних пор стал умнее и сам догадывает (что вряд ли). На 443м порту слушается конкретно server_name www.example.com, non-www на 443м вообще нигде не слушается. Поэтому я не понимаю как он может работать. По идее он вообще не должен никак отвечать и curl -i https://example.com должен ответить Could not resolve host.
    Написано

  • Как правильно сделать 301 redirect на https?

    HeadOnFire
    @HeadOnFire
    Gennick's Macleo,
    ну я вижу, что вы коммент подредактировали (в первом блоке example.com отстутствовал у вас пару минут назад), но все же, мы по кругу возвращаемся к моему предыдущему комментарию:


    первый блок работает с протоколом http на 80м порту, второй - https на 443м. Каким образом первый блок переадресует httpS://example.com, который через 80й порт не проходит, от слова совсем?


    Я специально для вас выделял жирным - не увидели. Сделаю отдельный акцент - нужно переадресовывать также non-www HTTPS домен на www HTTPS домен. Первый ваш блок обрабатывает только HTTP (www и non-www). Второй ваш блок обрабатывает только www HTTPS домен. В вашем конфиге запросы на non-www HTTPS куда-то в пустоту проваливаются, их никто не слушает. Именно этот кейс закрывает дополнительный блок, который есть в моем конфиге. Именно тот блок, который вам почему-то не понравился.
    Написано

  • Как правильно сделать 301 redirect на https?

    HeadOnFire
    @HeadOnFire
    Gennick's Macleo, а где редиректы non-www на www?
    Написано

  • Как правильно сделать 301 redirect на https?

    HeadOnFire
    @HeadOnFire
    Gennick's Macleo, первый блок работает с протоколом http на 80м порту, второй - https на 443м. Каким образом первый блок переадресует https://example.com, который через 80й порт не проходит, от слова совсем?
    Написано

  • Как задать сортировку списка по алфавиту?

    HeadOnFire
    @HeadOnFire
    vayo, https://stackoverflow.com/questions/1066453/mysql-...
    Либо JOIN, либо подзапрос. Почитайте по ссылке все комментарии к ответам, а также переходите по ссылкам на документацию оттуда. Там много полезной инфо которая объясняет как работает GROUP BY и ORDER BY, особенно в паре.
    Написано

  • Сколько раз можно использовать тег aside и есть ли в этом практическая составляющая?

  • Сколько раз можно использовать тег aside и есть ли в этом практическая составляющая?

    HeadOnFire
    @HeadOnFire
    Анатолий, вот как раз для красоты кода не надо. Если есть семантический смысл для него - используйте. Для всех остальных случаев - нет.
    Написано

  • Сколько раз можно использовать тег aside и есть ли в этом практическая составляющая?

    HeadOnFire
    @HeadOnFire
    Анатолий, ответ на вопрос "нужно ли" придет сам как только вы поймете нюансы, о которых я написал в ответе. Aside имеет конкретную семантическую нагрузку. Используйте там, где это имеет семантический смысл. Не используйте просто так для всего "не-основного-контента". И тем более не используйте для того, что просто визуально должно быть "сбоку от основного контента". Можете не использовать вообще, поисковики ваш контент все равно проиндексируют, так или иначе. Насколько адекватно - это уже другой вопрос.
    Написано