- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
В 2023 году Google заблокировал более 170 млн фальшивых отзывов на Картах
Это на 45% больше, чем в 2022 году
Оксана Мамчуева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Так что в итоге ТС'у делать предлагаете?
Ответили несколько раз - или переписывать код для совместимости или находить актуальную замену. Второе предпочтительнее.
серьезно, если обновлений от автора скриптов (шаблонов или что там...) просто нет и не будет, никто же не пойдет ковыряться вникать в чужой код.
Не.. Ну ты скажи - ты что, реально считаешь, что через время не может появится новых ошибок? А как он их увидит, если ты советуешь их скрыть. Да не просто скрыть с экрана, а вообще не писать в логи?
Потому какой выход реальный?
Ты не понимаешь, что старый код - это не просто ошибки, но ещё и возможные дыры?
И добавлю еще что display_errors=off это не только нормально, но и необходимо, если это продакшн сайт, а не что-то без траффика для экспериментов своих.
1. Но ты-то сперва советовал error_reporting, а уж потом как бы между прочим обмолвился о display_errors.
2. Это нормально когда на фронте для юзеров. Но ненормально когда админ этого не видит.
Я лишь хотел донести мысль, что есть (и очень много) сайтов/владельцев/ситуаций когда что-либо исправлять это вообще не про них, это практически не реально.
Не потому что это сложно сделать, а потому что владелец просто не будет тратить на это время, владелец сам не разбирается и не будет изучать ничего нового, владельцу сайт не на столько дорог, чтоб платить кому-то за исправления. И даже заняться найти актуальную замену - тоже может оказаться непосильной задачей для владельца. Уж поверьте опыту, какие только клиенты не встречаются. Даже просто создать в корне файлик для яндекс верификации - просто черная магия, требующая обращения за платной услугой к "программистам". О чем вы тут, о каком исправлении ошибок говорите, какой там "админ" что-то когда-то увидит, я вас умоляю 😉
А потому вариант "чего не видно, того и нет" тут более чем применим.
Как именно - не суть важно, не надо придираться к последовательности.
Дыры? Опять же, если взломают (вполне может быть что давно сделали, просто владелец не в курсе 😑 и прекрасно живет с этим) то невелика потеря.
Даже если исправить все те warning и deprecated, возможные дыры не перестанут там существовать... а обновить/заменить как уже сказано скорей всего не вариант, иначе бы и вопросов таких никто не задавал.
В общем я так и не понял что конструктивного вы предлагаете. Возьмитесь да почините/обновите/замените ему бесплатно. Не?
А потому вариант "чего не видно, того и нет" тут более чем применим.
Как именно - не суть важно,
Жесть.. просто жесть.
Это-то как раз очень важно. Ты свой хостинг по такому же принципу строишь?
то невелика потеря.
Это прекрасно.. Слова не мальчика но хостера. :)
В общем я так и не понял что конструктивноговы предлагаете. Возьмитесь да почините/обновите/замените ему бесплатно. Не?
как я понял, что лучшим решением будет перейти на другой шаблон
а если скрыть ошибки, то как и где это делается
В конфиге вебсерера/хтасесее, в ПУ хостинга (на реальном хостинге) и/или в коде. Но неправильное включение может привести к фатальной ошибке = неработоспособности сайта.
В конфиге вебсерера/хтасесее, в ПУ хостинга (на реальном хостинге) и/или в коде. Но неправильное включение может привести к фатальной ошибке = неработоспособности сайта.
Верней тот кто сможет, то в принципе не пользуется чужими поделками и уж тем более не сидит в конце 2020 на php 5.3.
Ну почему? Нормальное явление даже для тех, кто знает и практикует. У меня самого есть парочка древних сайтов на 5.3-5.6, прекрасно живут, прекрасно себя чувствуют. Зачем их переводить на что-то другое? Замечательный принцип "Не трогай, если работает" - еще ни разу не подводил. Зачем переписывать сайт, тратить на него время и силы, если на выходе не получу ничего нового? А вот шанс что-то упустить и нарушить работу, потеряв трафик - потенциальная возможность всегда остается. Так что чур.
"display_errors=off" - нормальная практика. Ошибки должны быть в системных логах, а не на сайте. На девелопе они могут отображаться, чтобы в лог не бегать, но на продакшене им в браузере делать нечего, совершенно. Тут абсолютно согласен. Достаточно просто периодически поглядывать в логи на наличие ошибок. Более того, это нужно, по сути, либо после запуска, либо после серьезных апдейтов. Если на сайте ничего не меняется и в логах ничего не было ранее проблемного, то и не появится, ошибки из ниоткуда не возникают.
По поводу ТС и что ему делать - вариантов масса: откатиться назад по версии; обновить движок и тему до актуальной; нанять того, кто обновит тему до соответствия версии. Вопрос времени и средств, не более того. В принципе сама постановка вопроса в теме ниочем и имеет очевидные ответы.
Всем спасибо за советы, как я понял, что лучшим решением будет перейти на другой шаблон
Если трафика на сайте не очень много или его потеря не так критична, то можно и шаблон другой поставить. Если же достаточно много и доход существенен, то лучше потратиться и сделать ревизию текущего шаблона, как на предмет устранения ошибок, так и на предмет дополнительной его безопасности от взлома. Как минимум на адаптацию под версию.