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

Если совсем по полочкам раскладывать, то:

- Ваша строчка 9 проверяет не равны ли captcha в $_POST и rand_code в $_SESSION.
- Ваша строчка никак не проверяет, чтобы эти переменные существовали / были определены, поэтому когда их нет - PHP информирует вас об этом (Notice) - прямым текстом говорит, что в упомянутых массивах нет таких индексов (элементов).
- Чтобы устранить PHP Notice, необходимо всегда проверять, заданы ли необходимые переменные:

1. В самом простом случае:

if ( 
    ( isset( $_POST['captcha'] ) && isset( $_SESSION['rand_code'] ) ) // переменные / индексы определены
    && $_POST['captcha'] != $_SESSION['rand_code'] // собственно, сравнение значений
) {
    // остальной код
}

2. В реальных условиях чаще всего это происходит в контексте функций / методов и когда идет ряд проверок, принято использовать подход "fail early" (вариации - quit early, bail out early) – проверки идут не вложенными, а одна за одной, наиболее ожидаемые - первыми. Пример аналогичного фрагмента кода с учетом этой практики:

function some_method_name() {

    // Если индексы не существуют или они приводятся к false - выходим из логики
    if ( empty( $_POST['captcha'] ) || empty( $_SESSION['rand_code'] ) ) {
        return; // может быть return false и тд - зависит от конкретной реализации
    }

    // Этот код выполнится только если предыдущая проверка прошла успешно и оба индекса имеют значения с которыми можно работать дальше
    if ( $_POST['captcha'] != $_SESSION['rand_code'] ) {
        // остальной код
    }
}

На GitHub есть организации.
На BitBucket есть команды (teams) - аналог организаций, плюс есть проекты, которые могут содержать кучу репозиториев.
GitLab не использую давно, не знаю.

Дык Laravel Homestead же

Плюсы:

- файлы проектов на вашей не-виртуальной macos, в виртуалку они мапятся
- все остальное изолировано на виртуальной машине
- там убунта, nginx, разные версии пэхапэ и все такое прочее
- а еще вагон плюшек типа blackfire, xdebug, mailhog, возможность расшарить свою dev-среду и так далее
- при желании все это еще и дополнительно скриптится под свои персональные фантазии

Apply_filters не в хуках, это и есть хук :)

Если не вдаваться в разъяснения в виде кода (это уже хорошо сделал WP_Panda), то человеческими словами это работает так:

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

2. Чтобы дать возможность другим изменить ваше значение, вы оборачиваете его в функцию apply_filters, даете этому фильтру какое-то название (в примере панды - change_vasya_name), и передаете в эту функцию саму переменную, которая содержит ваше значение (Vasya).

3. Другой разработчик пишет свою функцию, которая подключается к этому фильтру по его имени - add_filter( 'change_vasya_name', $text ) - и эта функция на лету примет на входе то значение, которое определили вы (Vasya), может его заменить/изменить (например, на Petya) и вернуть обратно.

4. WordPress когда читает код всех файлов собирает все фильтры в одну стопочку, и их коллбеки (см. п. 3) раскладывает тоже по стопочкам, каждому фильтру свои коллбеки. На одном фильтре может быть много коллбеков (функций). Далее он сортирует их по приоритетам и выполняет по очереди. Таким образом, вместо того, чтобы просто взять ваше значение (Vasya) и использовать дальше его, WP посмотрит, есть ли на этом фильтре функции, если да - выполнит их и вместо Vasya уже будет использовать то значение, которое вернет последний фильтр (в нашем случае он один и возвращает Petya).

1. Не вижу необходимости помещать свойство объекта/класса в дополнительную переменную. Вместо:

$st = $item->timestamp;
if(time() < $st){

достаточно:
if( time() < $item->timestamp ) {

2. В PHP exit - это конструкт, и если в него не передается параметр, скобки необязательны (принято не указывать их): вместо exit(); достаточно exit;

3. Для выхода из цикла необходимо использовать break. Разница в том, что exit прекращает выполнение скрипта вообще, break - только выходит из цикла, прекращая дальнейшие итерации:

if( time() < $item->timestamp ) {
    break;
}

4. Возможно, вам вообще нужно просто прекратить логику в текущей итерации и перейти к следующей итерации (скипнуть текущий элемент в итерации) - для этого есть continue:

if( time() < $item->timestamp ) {
    continue;
}
// тут остальная логика в итерации цикла, 
// при выполнении условия и вызове continue; эта логика для текущей итерации не будет выполнена, 
// произойдет переход к следующей итерации цикла
...

5. Уточните, вам таки из цикла выйти надо (перестать проверять данные в следующих итерациях), или же прекратить выполнение всего скрипта?

6. Что касается "почему такая конструкция не работает":

– ваш дамп, это значения $item->timestamp?
– вы уверены что условие проверки верное, в вашем коде текущий unix timestamp должен быть меньше $item->timestamp, то есть последний должен содержать timestamp в будущем. Рискну предположить, что на самом деле вам необходимо:

if( $item->timestamp < time() ) {
    continue;
}

На сайте используется тема с названием wrk. Вангую, что это полностью кастомная тема. Определить просто - открываете инспектор или исходный код, и смотрите пути к статическим файлам. В данном случае путь определяется по favicon:

Если WP запускается под ajax-запрос, то в процессе устанавливается константа DOING_AJAX. Также есть функция wp_doing_ajax(), c помощью которой можно проверить - это обычный запрос или ajax. Возвращает булевое true/false.

Проверяйте, и если ajax - не меняйте значение в сессии.

Внимательно посмотрите на регулярку слева, и на маппинг справа:

(.?.+?)(?:/([0-9]+))?/?$ -> index.php?pagename=$matches[1]&page=$matches[2]

Это - основное правило (rewrite rule) для страниц WordPress. Как оно работает:

- /page-name/ - страница первого уровня
- /page-name/sub-page-name/ - страница второго уровня (дочерняя, вложенная)
- /page-name/sub-page-name/sub-sub-page-name/ - страница третьего уровня (и это не предел)

В этих случае маппинг выдаст, соответственно:

pagename=page-name
page=

pagename=page-name/sub-page-name
page=

pagename=page-name/sub-page-name/sub-sub-page-name
page=

и WP_Query будет запрашивать такие страницы. В вашем случае страница uslugi/asdfdsf, как дочерняя страницы uslugi – не существует. Отсюда и 404, все логично. Вот пример:



Если же ввести число, сработает другая часть регулярки:

- /page-name/123/

будет замаплен в:

pagename=page-name
page=123

Чувствуете разницу? Вторая переменная, $page теперь заполнилась. Это нужно для разбивки контента страницы. WordPress позволяет вам разместить на странице какой-то длинный текст/контент, и разбить его на странички. Именно эта часть регулярки отвечает за постраничный вывод.

Но поскольку в сам WP_Query отправляется запрос на получение контента страницы целиком, а постраничная разбивка происходит уже на лету, то и ответ 200 вполне логичен. Как и вывод одного и того же контента, независимо от номера страницы.

Вот пример такого запроса. Обратите внимание на установленные переменные:



Так работают стандартные rewrite rules WordPress. Что делать? Можно хукнуться в один из ранних хуков, например template_redirect, проверить контент на предмет постранички, и сделать редирект на 404. Но, зачем?

2й, необязательный параметр функции the_field() - ID объекта (записи). Если его не передавать, то функция будет использовать ID записи, которая в момент вызова находится в глобальной переменной $post. А вот там как раз в этот момент может находиться совершенно не то, что вы думаете. Отсюда и пустое значение - функция пытается взять значение этого поля у записи, у которой этого поля вообще нет. Не у той записи, которая вам нужна.

У вас вызов the_field() идет в цикле (который WordPress Loop) или нет?

Apex Up?

Проблема с пользователями. Посмотрите тут: dustinbolton.com/wordpress-xampp-on-mac-update-per...

Nginx не поддерживает .htaccess, это конфигурационный файл Apache.