Larisa Moroz

<?php
    $arr = ['Слово 1', 'Слово 2', 'Слово 3', 'Слово 4'];
    $arr2 = array_chunk($arr, 2);
    print_r($arr2);

Редирект это 3xx, а ошибка это 5xx.
Вы не можете отдать два статуса одновременно.

Но вы можете отдав 500 отдать и содержимое страницы.

header('HTTP/1.1 500 Internal Server Error', true, 500);
readfile("my500page.html");

Это очень хороший вопрос, по многим причинам.

Во-первых, очень хорошо что он сам по себе поставлен. Обычно пользователи РНР не задумываются о таких "мелочах". Но на самом деле об этом должен думать каждый программист, делающий сайты
Во-вторых, здесь мы можем видеть довольно характерный баг Апача, который действительно, почему-то не выполняет директиву ErrorDocument для 500 ошибок, полученных от РНР. Ну и вообще, завязываться на Апач во времена доминирования Нжинкса как-то не очень дальновидно.
В-третьих, как правильно заметил Stalker_RED, сделать редирект при 500 статусе (или 500 статус при редиректе) невозможно - статус может быть только один. Да это и нет смысла делать - проще сразу на месте нужную страницу и прочитать.
В-четвертых, текущий подход, прямо скажем, не очень оптимальный:
- о роботах мы позаботились, о пользователе позаботились, но надо ещё не забыть и программиста. Которому как раз сообщение об ошибке-то нужно видеть во всех подробностях!
- просто отдать нужный НТТР код недостаточно - надо бы ещё и завершить работу скрипта.
- ловить все ошибки вручную через try-catch так себе удовольствие. И код раздувает,и поведение потом быстро не поменяешь. А если в какой-то момент захочется для отладки прикрутить whoops - это придётся по всем блокам бегать?

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

В самом простом варианте это будет что-то вроде такого:

set_exception_handler(function ($e)
{
    error_log($e);
    http_response_code(500);
    if (ini_get('display_errors')) {
        echo $e;
    } else {
        include 'pages/error_500.php';
    }
});

В теории, конечно, можно заменить error handler на глобальный try-catch который оборачивает точку входа, но это менее удобно. Тем более, что для обработки фатальных ошибок нужен свой отдельный обработчик, и в итоге код обработки ошибок начинает занимать довольно значительный объем и лучше конечно его инициализацию вынести отдельно.

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

Мне в свое время помогла проработка всех шаблонов проектирования из трех источников: "Head First Design Patterns"+refactoring.guru+designpatternsphp.readthedocs.io. Каждый шаблон разбирала и пыталась понять, почему здесь нужен паттерн, а не процедурный код, обернутый в один класс. Еще помогла книга по чистой архитектуре, но она зашла уже после паттернов. Просто важно полностью для себя понять, почему эти подходы до сих пор существуют и находить для себя два-три примера, потому что один-единственный пример для изучения может быть однобоким и даже неправильным.
Также эти книги и темы помогают вылечиться от трудностей решения задач на фреймворках, потому что наконец-то начинаешь видеть всю структуру и взаимодействия модулей и классов, а не просто примеры из документации натягиваешь на бизнес-требования)

Учись задавать вопросы. То что ты сейчас понаписал - это называется проблема XY, бич всех новичков. (ну и конечно бич всех помогаек на тостере, которым некогда думать, им надо на вопрос отвечать).

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

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

class foo {
    protected $bar;
    public function bar(string $data ) {
        $this->bar = $data; 
    }

    private function baz() {
        if (isset($this->bar)) {
            // сделать что-то
        }
    }
}

В ответе сервера по данной ссылке есть заголовок X-Frame-Options: SAMEORIGIN. Значит сайт запрещает использование данной страницы в iframe других сайтов.

В целом то, что вам нужно скорее ближе к новой функциональности в PHP 8: throw expression. В этом случае ваш код мог бы выглядеть, к примеру, вот так:

Auth::check() ?? throw new AuthenticationRequiredException("Вам необходимо сначала авторизоваться");

Однако, если вы реально хотите именно такой конструкции как ваша - то здесь, конечно, тоже есть варианты, ведь начиная с PHP 7 нам доступен uniform function call syntax и, следовательно, возможны конструкции вида:

Auth::check() ?? (function(){echo "Вам необходимо сначала авторизоваться";})();

Конечно, я ни в коем случае не призываю делать именно так, это плохое решение, но технически возможное.

Существенно лучшим вариантом в этом случае на самом деле будет просто создание отдельной функции, которая будет брать на себя реакцию на такие ситуации:

function failure(string $error): void 
{
  // Просто для того чтобы быть ближе к вашему примеру, 
  // в реальности здесь должна быть нормальная логика обработки, 
  // к примеру тот же throw new RuntimeExcepton($error);
  echo $error;  
}

в этом случае ваш пример сводится к:

Auth::check() ?? failure("Вам необходимо сначала авторизоваться");

Помимо этого обратите внимание на то, что использование null coalescing operator ?? подразумевает, что тип возвращаемого значения функции Auth::check() - это mixed|null что выглядит странно, поскольку от результата проверки ожидается тип boolean.

В реальности здесь лучше подходит сокращённая версия тернарного оператора, т.н. elvis operator. В этом случае ваш код может выглядеть вот так:

class Auth {
    public static function check(): bool 
    {
        return false;
    }
}

function failure(string $error): void 
{
    // В реальности, как указано выше, лучше использовать 
    // throw new RuntimeException($error);   
    // echo используется для примера
    echo $error;
}

Auth::check() ?: failure('Вам необходимо сначала авторизоваться');

Проверить можно здесь.

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

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

В целом правильно, неплохая проработка материала.
У меня есть только пара замечаний, не относящихся напрямую к централизованному обработчику.

• error_reporting(E_ALL & ~E_NOTICE); делать не стоит. Если только не приходится работать с адовым легаси, которое сыпет нотисами, лучше отлавливать все ошибки. Учитывая же что в 8-ке обращение к несуществующей переменной станет не нотисом а предупреждением, такая конструкция со временем станет бессмысленной. что означает - ошибки надо исправлять, а не замалчивать.
  
• ini_set("error_log", __DIR__ . "/php-errors.log"); будет не очень хорошей идеей, если файл error-handler.php выше корня веб-сервера. Ошибки надо прятать подальше.
  
• ini_set('display_startup_errors', 1); - это какая-то дичь, которая кочует из руководства в руководство. Никто никогда этих стартап еррорс не видел, но многие старательно пишут это заклинание у себя в коде. Это по-любому связано с настройкой сервера, и в отладке ошибок поможет примерно ничем.
  
• само по себе задание настроек через ini-set ненадежно. Ошибка может случиться до того, как РНР прочитает эту команду. Задавать надо в конфигурации веб-сервера.
  
• в теории можно добавить флаг или автоматическую проверку на джейсон запрос. и соответственно кодировать ответ в джейсон. Но это только для криовруких фронтендеров, которые не умеют читать НТТР статусы, а ждут что им все разжуют в джейсоне, и без error: true они не поймут, что была ошибка
  
• стек вызовов может быть довольно длинным, и раздувать логи. Можно подумать о более укороченном варианте.
  

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

Я только не понял, почему вопрос про error_handler. Что именно смущает?

scrollmagic
sal

Советую greensock. Не так просто, но оно того стоит, поверьте)

AOS

есть вот ui-kit https://wiredjs.com/

ещё нарыл такую штуку https://bootswatch.com/sketchy/