Последние сообщения

Попробуйте установить настройки ini в .htaccess файл.

Настройки не сохранятся, если вы поместите их в файл PHP, который не с компилируется из-за синтаксической ошибки.

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

Вам придется использовать другой способ установки этих директив, хотя это может быть сложно. Похоже, ваш PHP работает как CGI, а не как модуль Apache, поэтому единственный способ установить директивы ini — это отредактировать сам php.ini.

Чтобы убедиться, пожалуйста, запустите phpinfo(); и посмотрите, что там говорится о API сервера.

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

Вы должны иметь возможность использовать log_errors чтобы записать все ваши ошибки в файл. Вы даже можете использовать error_log записать ошибки в конкретный файл, если это облегчит вам жизнь.

Как специалист по поисковой оптимизации, я рекомендую сохранять карточку товара с пометкой «Товар закончился» в статусе «Скрыто».

Для поисковых систем важны возраст страницы и накопленные показатели DR и ПФ. Даже если товар стал дефицитным, он ещё долго будет привлекать трафик, поскольку люди могут надеяться на его возвращение. Вопрос в том, как использовать этот трафик.

В идеале на первом экране нужно чётко указать, что товара нет и больше не будет, но есть аналоги. Это не всегда возможно, но к этому нужно стремиться.

Не рекомендую сразу закрывать карточку или перенаправлять на другие страницы. Коды 404 или 301 могут вызвать возврат на поиск, что крайне нежелательно.

Поскольку скрытый товар не отображается в меню, категориях и других разделах, при переходе по прямой ссылке (например, из результатов поиска или если покупатель сохранил ссылку или добавил товар в избранное) страница с товаром откроется. Таким образом, вы не потеряете трафик на эту страницу.

Технопарк Нобель, Подскажите почему вы считаете, что Скрытый лучше? Интересно ваше мнение.

Лучше поставить наличие ноль и статус — скрытый

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

Убирать не хочется, ведь эта страница проиндексирована поисковыми системами и привлекает дополнительный трафик на сайт по различным запросам.

Используйте phpinfo, чтобы найти загруженный php.ini и отредактировать его, чтобы скрыть ошибки. Он переопределяет то, что вы вставили в свой скрипт.

Чтобы предотвратить появление ошибок, вы можете:
— Напишите в .htaccess: php_flag display_errors 0
— Разделите свой код на отдельные модули, где основной (родительский) файл PHP устанавливает только error_logging, а затем включить() другие файлы.

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

Если ваша базовая система настроена на сообщение об ошибках E_STRICT, они могут быть выведены еще до того, как ваш код будет рассмотрен. Не забывайте, что error_reporting/ini_set — это оценки во время выполнения, и все, что выполняется на этапе «до запуска», не увидит своего эффекта.

Судя по вашему комментарию, ваша ошибка…

Ошибка синтаксического анализа: синтаксическая ошибка, неожиданная T_VARIABLE, ожидание ',' или ';' в /usr/home/REDACTED/public_html/dev.php в строке 11

Тогда применяется та же общая концепция. Ваш код никогда не запускается, так как он синтаксически недействителен (вы забыли ';'). Таким образом, ваше изменение отчета об ошибках никогда не встречается.

Чтобы исправить это, необходимо изменить отчеты об ошибках на уровне системы. Например, на Apache вы можете разместить…

php_value error_reporting 0

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

Прагматично: не пишите файлы с синтаксическими ошибками :)

Внутри вашего php.ini:

display_errors = on

Затем перезапустите веб-сервер.

Вы не можете обнаружить ошибки синтаксического анализа в том же файле, где во время выполнения включен вывод ошибок, поскольку он анализирует файл перед фактическим выполнением чего-либо (и, поскольку во время этого возникает ошибка, он ничего не выполняет). Вам потребуется изменить фактическую конфигурацию сервера, чтобы включить display_errors и использовать соответствующий уровень error_reporting. Если у вас нет доступа к php.ini, вы можете использовать .htaccess или аналогичный, в зависимости от сервера.

Среда разработки
Это всегда работает для меня:

ini_set('display_errors', '1');
ini_set('display_startup_errors', '1');
error_reporting(E_ALL);

Однако это не позволяет PHP отображать ошибки синтаксического анализа, произошедшие в одном и том же файле. Кроме того, эти настройки могут быть переопределены PHP. В этих случаях единственный способ отобразить эти ошибки — изменить ваш php.ini (или php-fpm.conf) с помощью этой строки:

display_errors = on

(если у вас нет доступа к php.ini, затем вставив эту строку .htaccess тоже может сработать):

php_flag display_errors 1

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

display_errors = off
log_errors = on

И тогда вы сможете увидеть все ошибки в журнале ошибок. См. раздел «Где найти журнал ошибок PHP».

AJAX-вызовы
В случае вызова AJAX на сервере DEV откройте DevTools (F12), затем вкладку «Сеть». Затем инициируйте запрос, результат которого вы хотите увидеть, и он появится на вкладке «Сеть». Нажмите на него, а затем на вкладку «Ответ». Там вы увидите точный результат.

Находясь на живом сервере, все равно проверяйте журнал ошибок.

Для нового проекта действительно лучше использовать кодировку utf8mb4 вместо utf8. Вот основные различия между utf8_general_ci, utf8mb4_general_ci и utf8mb4_unicode_ci:

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

utf8mb4_general_ci:
— Поддерживает все символы Unicode, включая эмодзи и редкие иероглифы.
— Немного быстрее при сортировке по сравнению с utf8mb4_unicode_ci, но может иметь проблемы с точностью для некоторых языков.

— Также поддерживает все символы Unicode.
-Более точен при сортировке и сравнении символов для различных языков, так как использует алгоритм Unicode Collation Algorithm (UCA).
-Рекомендуется для проектов, где важна точность сортировки и сравнения символов.

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