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

Используйте 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, так как он обеспечивает лучшую поддержку символов и точность при работе с различными языками.

Мы можем использовать CSS для отображения стандартного изображения-заглушки, если аватарка отсутствует. Вот пример, как это можно сделать:
1. Добавьте стандартное изображение-заглушку в ваш проект, например, default-avatar.png.
2. Обновите ваш CSS для отображения заглушки, если аватарка отсутствует:

 
.striped-list .item .icon img {
display: block;
height: 50px;
width: 50px;
transition: all 0.3s ease 0s;
object-fit: cover;
}
 

 
.striped-list .item .icon img[alt=""] {
content: url('/path/to/default-avatar.png');
}
 

1. Обновите HTML для использования атрибута alt как индикатора отсутствия аватарки:

<br>
<a href="/users/4601">
<img src="/upload/046/u4601/ce/18/f484d6b0.jpg" alt="" title="Екатерина">
</a>
 

В этом примере, если атрибут alt пустой, CSS заменит изображение на заглушку. Вы можете настроить путь к заглушке в content: url('/path/to/default-avatar.png'); в соответствии с вашим проектом.

Лучше дождитесь обновления DST Platform до 3 версии, там будет этот функционал заложен по умолчанию в систему, об этом уже была речь т.к. некоторым пользователям сложно воспринимать весь функционал системы, особенно в панели управления