Это правда жизни большинства сайтов на дешевых shared хостах.
Я не обобщаю это на всех и ни на что своё уж тем более не проецирую. Всего лишь предложил один из очевидных выходов в данной ситуации, зачем на все так агрессивно реагировать :)
Если ТС в силах сменить шаблон на тот, где не будет ошибок... то зачем вообще было тут что-либо спрашивать спрашивается? Надо было первым делом это и сделать. Я ведь предположил, что это непосильная задача.
И даже не посылал его "В конфиге вебсерера/хтасесее", понимая что это еще менее реальной задачей окажется, а сказал что лучше обратиться к хостеру.
[offtopic]
SeVlad, я уже с большой буквы пишу и все равно какая-то ненависть ко всему человечеству чувствуется. Ну да ладно... Уверен, это все из-за отсутствия велосипеда 😎 - предложение бесплатного велосипеда до конца года в силе если что. Я ж не просто так, не безосновательно считаю свои велосипеды хорошими (за свою цену), знаю что колеса должны быть не квадратными, не треугольными, а именно круглыми. И подозреваю, что максимум что вам доводилось водить это с овальными колесами. От того и раздраженность и нетерпимость к окружающим. Какой-то перманентный ПМС.
Мне это напоминает серию:
https://internetkomfort.io.ua/v85f6b9eaa6d3b5e48b02313e54d71b2a
Советую переступить гордость и посмотреть 👍
[/offtopic]
Я лишь хотел донести мысль, что есть (и очень много) сайтов/владельцев/ситуаций когда что-либо исправлять это вообще не про них, это практически не реально.
Не потому что это сложно сделать, а потому что владелец просто не будет тратить на это время, владелец сам не разбирается и не будет изучать ничего нового, владельцу сайт не на столько дорог, чтоб платить кому-то за исправления. И даже заняться найти актуальную замену - тоже может оказаться непосильной задачей для владельца. Уж поверьте опыту, какие только клиенты не встречаются. Даже просто создать в корне файлик для яндекс верификации - просто черная магия, требующая обращения за платной услугой к "программистам". О чем вы тут, о каком исправлении ошибок говорите, какой там "админ" что-то когда-то увидит, я вас умоляю 😉
А потому вариант "чего не видно, того и нет" тут более чем применим.
Как именно - не суть важно, не надо придираться к последовательности.
Дыры? Опять же, если взломают (вполне может быть что давно сделали, просто владелец не в курсе 😑 и прекрасно живет с этим) то невелика потеря.
Даже если исправить все те warning и deprecated, возможные дыры не перестанут там существовать... а обновить/заменить как уже сказано скорей всего не вариант, иначе бы и вопросов таких никто не задавал.
В общем я так и не понял что конструктивного вы предлагаете. Возьмитесь да почините/обновите/замените ему бесплатно. Не?
Так что в итоге ТС'у делать предлагаете? 😐
Вам же прямо сказано - "как её исправить незнаю", а значит он точно не будет ничего исправлять.
Нет, можно конечно сколько угодно умничать и в целом все правильно - ошибки надо не прятать, а исправлять, но... серьезно, если обновлений от автора скриптов (шаблонов или что там...) просто нет и не будет, никто же не пойдет ковыряться вникать в чужой код. Верней тот кто сможет, то в принципе не пользуется чужими поделками и уж тем более не сидит в конце 2020 на php 5.3.
Потому какой выход реальный? Никто тут конечно не видел что там за сайт, но с 99% можно предположить что никакой особой ценности не представляющий. А потому просто спрятать warning'и и забить на все - нормальное решение в данной ситуации. Либо заплатить кому-то, чтоб поковырялся и исправил... но опять же, мы не знаем никаких подробностей, может это будет стоить в 5 раз дороже, чем весь тот сайт стоит целиком.
И добавлю еще что display_errors=off это не только нормально, но и необходимо, если это продакшн сайт, а не что-то без траффика для экспериментов своих.
Ошибки пусть пишутся в логи, а на сайтах отображать их нельзя. Это не красиво, это не профессионально и может быть даже опасно в случае если в этой ошибке высветится что-то, чего посторонним знать не нужно.
Вы хоть раз видели какие-то ошибки скриптов на чем-то более-менее серьезном? Ошибки у всех случаются, у того же гугла и авито не раз видел, но это были именно правильно оформленные перехваченные ошибки, а не тупо ошибка в таком-то скрипте, такой-то строке.
Это НЕ ошибки. Если кроме этих надписей ничего не сломалось больше, то самое простое - просто скрываем в настройках php их отображение:
error_reporting=E_ALL & ~E_DEPRECATED & ~E_NOTICE & ~E_WARNING
(как сделать - хостеру пишите если не в курсе)
Или вообще все отображение ошибок выключаем:
display_errors=off
Тот openapi-sandbox.kucoin.com выдает вам ответ 401 Unauthorized
И Invalid KC-API-SIGN - что бы это ни значило.
Т.е. со скриптом все ок, но не ок со взаимодействием с тем сторонним хостом. Уж не знаю что и как там должно быть.
Во-первых домен ip-123-456-789.eu свободен, а значит никакого поддомена ns123456.ip-123-456-789.eu быть не может.
Если у вас по нему что-то там открывается, то это уже вопрос в совершенно другой плоскости.
Но если в общих чертах, то всегда надо делать основной "заглушку". Чтоб при обращении по ip (или любому привязанному к этому ip домену) открывался не первый сайт из конфига, а эта заглушка.
Ну про злоупотребления - это скорей редкость, чем постоянно так происходит. И да, ограничить память можно уровнем выше, пусть хоть сколько угодно ставят memory_limit.
В любом случае, всем же не навязываю, у вас своя политика, у меня своя - чем меньше ограничений, тем лучше для конечного клиента. А с теми редкими случаями нагления лучше решать вопрос индивидуально, чем из-за них резать все подряд всем.
Да, auth_socket и по-сути да, авторизация конечно никуда не пропадает, а просто чуть упрощается. И да... возможно насчет какого-то ускорения это я загнул 😀
Просто была мысль попробовать, но застопорилось на проблеме скриптов типа phpmyadmin в открытом доступе.
Основная идея скорей была в упрощении. Т.е. добавляя новую базу, нужно бы было от пользователя только имя базы и все. Момент с логин/паролями вообще упразднить. И чтоб в скриптах своих логин/пароли на базу они могли использовать любые. К примеру перенес с другого хоста и сразу заработало, без правки конфигов.
Суть в том, что если что-то (например php скрипт) уже запущен от имени какого-то пользователя, то смысла еще авторизоваться по паролю к mysql нет никакого. Если это скрипт злоумышленника, то также не составит труда этим скриптом открыть любой файл конфига и там взять этот пароль.
Авторизация нужна если доступ к сокету mysql есть у всех (в случае одной общей mysql например) или, что еще хуже, mysql открыта портом в интернет.
А когда у нас все заперто в рамках одного пользователя (mysql, apache/php, все файлы), то эта доп. авторизация mysql вообще не несет ценности. Самое главное это не запускать опасный код из под себя. А если уж запустил, то все... никакая авторизация не спасет.
Попросил бы не обобщать.
Вы сами умудрились заплатить непойми кому, а теперь все виноваты?
Самое первое что нужно смотреть это кто такие, где находятся, офф регистрацию проверять и т.д.
Вот у вас претензия образовалась к ним и дальше что? Кому предъявлять? Нужно было об этом думать ДО оплаты.
Там где анонимность, там высокий % жулья.
