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

    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?

    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?

    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?

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

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

    Анатолий, вот как раз для красоты кода не надо. Если есть семантический смысл для него - используйте. Для всех остальных случаев - нет.
  • Сколько раз можно использовать тег aside и есть ли в этом практическая составляющая?

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

    Nikolino,
    Но сколько времени в среднем нужно разработчикам с твоим уровнем знаний, чтобы въехать в такой проект? Неделя, две? Или это можно месяцами изучать, как новый фреймворк?:)

    Джунам разбираться в этом всем не надо - им дают изолированные задачи, которые им по зубам. Для любых вопросов есть лид / наставник. Миддлам разбираться во всей-всей-всей кухне тоже не всегда нужно, достаточно их области ответственности. Остальное - по мере необходимости. Ну и опять же, есть лид и синьоры, есть вся команда под рукой. Да и сам код для миддла пусть и сложный на первый взгляд, но он "по правилам", а значит курится. Синьорам разбираться надо во всем, но для них это как раз уже не проблема, им это по зубам.

    Скорость обучения будет сильно зависеть не только от конкретного человека и его скиллов, но и от команды в целом, от поддержки и помощи коллег, лидов, синьоров. От документации.

    Плюс, редко бывает что человека сначала сажают учить ВСЕ, а потом только пускают к работе. Интеграция в проект происходит постепенно, но сразу. Сначала более простые задачи, чтобы начать вкуривать, потом глубже в лес.
  • Какой уровень MySQL/MariaDB нужно знать среднему php-программисту?

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


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

    На такие вопросы главное отвечать честно. Умение признать что ты чего-то не знаешь - это большой плюс. Умение включить мозг и хотя бы порассуждать в общих чертах и попробовать деконструировать технологию / фичу - огромный плюс. Это говорит о том, что человек способен строить архитектуру в голове, по дороге на работу или на перекуре. А не только методом "написал строчку кода, выполнил, если упало - написал что-то другое" по инструкции с Тостера или StackOverflow. И это важный скилл на самом деле. Я это называю brain environment или "компилятор в голове"
  • Wordpress comment_post_redirect как создать перенаправление?

    Используйте Ajax для добавления комментариев.
  • Как вывести страницу и ее дочерние страницы wordpress?

    1) используйте виз. редактор visual composer, например

    не стоит
  • Как реализовать прием post запроса в wordpress?

    Александр Соболев, не обязательно аякс. рядом с wp-admin/admin-ajax.php лежит wp-admin/admin-post.php, в котором точно такая же логика, как и у аякса, в том числе зеркальные хуки. Используется для работы с пост-запросами. Но есть один нюанс - там после обработки редирект надо делать. В документации все есть.
  • Почему мелькает рябь на экране при открытии крышки?

    HeadOnFire
    @HeadOnFire Автор вопроса
    Уже многие подтвердили, что проблема исчезла после обновления / установки macOS Mojave. И у меня пропало, и у многих участников данной темы, и на западных ресурсах тоже подтверждено. Обновляйтесь.
  • Как выводить для созданной таксономии различные типы записей в зависимости от запроса?

    ligisayan,
    Не надо плодить таксономии.
    1. У вас есть разные custom post types – ford, bmw и так далее
    2. У вас есть одна общая таксономия years, которая назначена всем этим custom post types
    3. Шаблоны у вас должны быть всего 2:
    - один для всех ваших custom post types (разные логотипы и тд подставляются динамически)
    - один для термина таксономии years (контент тоже подставляется динамически)
    4. Для того чтобы создать необходимые URLы создаете произвольные rewrite rules, которые будут содержать необходимые данные и маппить их на необходимые параметры глобального WP_Query:
    - /years/2011/cars/ford/ будет замаплен на ?taxonomy=years&taxonomy_term=2011&post_type=ford
    - данные урл будет обработан самим WP, параметры переданы в глобальный WP_Query который сформирует и выполнит корректный запрос и выдаст вам необходимый результат, с поддержкой всех плюшек типа пагинации.
    - регулярка будет выглядеть что-то типа ^/years/[0-9]{4}/cars/[a-z]+/, а маппинг соответственно
    index.php?taxonomy=years&taxonomy_term=$matches[1]&post_type=$matches[2]

    - разумеется, надо будет прописать rewrite rules для пагинации и прочего, какие именно нужны - смотрите на примере root rewrite rules которые генерит сам WP по умолчанию
    - также, регулярка очень грубая и является исключительно примером "куда копать", там нужно учесть названия авто через дефис и тд.

    В общем, если кратко – ваша задача реализуема через Rewrite API. Но чтобы ее решить вам придется серьезно поднапрячь мозги и освоить этого монстра (а данное API таки монструозное). За вас этого никто не сделает на Тостере, ибо задача объемная, требует дотошного тестирования в ваших конкретных условиях и бесплатно выполнена быть не может.

    Кроме того, ваш изначальный подход создавать custom post type для каждой марки автомобилей не совсем разумен. Лучше сделать так:
    - custom post type всего один, он называется car. Все записи этого типа – это машины. Не знаю что там у вас, конкретные экземпляры или просто модели разных марок, это не принципиально.
    - таксономий несколько: years (года выпуска), makes (производители - форд, бмв и тд), models (fiesta, focus, mondeo и тд, в случае если у вас конкретные экземпляры в custom post type 'car', если нет то эта таксономия не нужна), body (седан, хетчбек, купе и тд) и прочее. В целом, таксономиями принято делать то, что используется для группировки, сортировки и фильтрации записей.
    - все остальное (что редко используется для фильтрации и группировки) идет в виде post meta – цвет, габариты и тому подобное.
    - еще, если характеристик много и по ним в будущем будет поиск и фильтрация (по многим одновременно), то используется Elastic Search или аналоги.

    В общем, у вас на руках достаточно интересная, но и непростая (для начинающих) задача. Если осилите изучение новых для вас концептов, то научитесь очень многому и хорошо так прокачаете свои скилы. Если не осилите - либо завалите проект к чертям собачим, либо запустите (не в срок, с головняками и багами) такое говно, которое будет падать через раз, тупить, и которое невозможно будет поддерживать (даже вам самим).

    Мой вам совет - остановитесь, выдохните. Почитайте про архитектуру крупных проектов. Нарисуйте себе все на бумажках в виде схем. Пометьте зеленым те места, которые знаете как сделать правильно. Пометьте красным те, которые не знаете. И начните изучать их один за другим.
  • Как выводить для созданной таксономии различные типы записей в зависимости от запроса?

    ligisayan, нет, все не так.
    1. В query_vars добавлять новую переменную надо только тогда, когда она новая (WP ее не знает). А post_type - это родная переменная, она движку известна изначально. Добавлять ее повторно не нужно.
    2. Регулярка не в кассу.
    3. Вы вообще смысл не поняли. При переходе предыдущий урл совершенно никак не будет передаваться (кроме стандартного referer). Нужные данные должны присутствовать в _текущем_ урл. То есть, у вас должно быть:
    site.com/years/2011/ – все машины (ford, bmw, audi и тд) 2011 года
    site.com/years/2011/ford/ – только форды 2011 года. Или так:
    site.com/years/2011/cars/ford/ – то же самое, только с base 'cars' – так будет проще обойтись одним дополнительным rewrite rule. В предыдущем варианте надо будет не забыть о других правилах - пагинация, rss, эндпоинты и тд, иначе будут конфликты.
  • Как выводить для созданной таксономии различные типы записей в зависимости от запроса?

    ligisayan,
    Вот так?
    'post_type' => array('bmw' ('bmw', 'mazda', 'ford')

    Вот так:
    'post_type' => array( 'bmw', 'mazda', 'ford' );
    Дает возможность получить по одному термину таксономии (которая общая для этих post types) записи из нескольких post types.

    Но, как я могу определить страницу с какой был переход, чтобы подставить вместо bmw сюда
    'post_type' => 'bmw', нужную переменную, будь то bmw, mazda,ford, чтобы вывелись модели правильной марки?

    Rewrite API. Создаете кастомные rewrite rules, которые содержат в себе марку (custom post type). Благодаря этому марка из урл транслируется в переменную, которая будет доступна через query_vars. Почитайте про Rewrite API.