Если воспринимать посты не в штыки, а как бесплатные рекомендации по улучшению, то тема очень даже полезная. :)
В официальном отчёте (ссылка из первого поста) источника данных не нашёл (плохо искал?)... Погрешности-ошибки-допущения (неучтённые) в исходных данных часто являются причиной искажения результатов. ИМХО, для такого вывода инфы мало:
Как уже было озвучено, есть неточности... изначально, в формулировке... хостинг компании не всегда "владеют" IP адресом, и наоборот.. если IP-адресом "владеет" компания - это не значит, что она является хостером
первый http://myip.ms/browse/sites/1/ipID/173.194.34.10/ipIDii/173.194.34.10
третий http://myip.ms/browse/sites/1/ipID/66.155.9.238/ipIDii/66.155.9.238
А где обещанная в названии темы аналитика?
Хотя бы результаты-погрешности оценить? С поддоменами разобраться, с LIR-ами..
Возможно, имеет смысл поработать над учётом NS-серверов..
Проще всего сделать оговорку "в исходных данных так".. Но в этом случае не стоит заявлять об объективности статистики.
Бесспорно, работа проделана.. Однако, есть куда расти, над чем работать..
Удачи в развитии
А формально - это как?.. Человек обещает "мегаскрипт", защиту от всего.. и, ясное дело, защиты этот скрипт не даёт..
Кроме того, некоторые сайты, которые тоже используют проверку
if(!get_magic_quotes_gpc()) { $in = addslashes($in); }
будут повторно добавлять \" бэкслэши перед кавычками \" где надо и не надо.. А потом - и перед \\\"кавычками и самими экранирующими бэкслэшами \\\"...
А чуть позже - появятся вопросы от пользователей что за \\\\
Вполне уместно loh.txt (в том самом изначальном смысле)
"Магическим" кавычкам больше 10 лет.. и, честно говоря, мне они только мешали (если в CMS не было предусмотрено встроенной обработки - использовал аналогичный подход, но "наоборот" - т.е. "разэкранирование" в случае включенных слэшей) Не всегда данные от пользователя нуждаются в экранировании.. Да и думать об этом нужно на выходе - при помещении в хранилище (не обязательно mysql-базу), а не "на входе"..
Поддерживаю отказ от этой фичи всеми конечностями..
Вам бы для начала про реляционные базы данных почитать, про проектирование. Про нормализацию...
Можно курс от Интуита пройти.
p.s. "нормальная" (нормализованная) таблица в mysql будет отличаться от приведённой на скриншоте
Имхо, на сегодняшний день не обязательно иметь адрес, телефон и кучу строительных компаний, банков или других "претендующих на солидность" организаций в списке клиентов, чтобы качественно оказывать услуги хостинга (читать, чтобы свой сайт работал "как положено" - доступен, не тормозит, не отдаёт роботам всякий бред, не глючит при загрузке файлов и всё такое)
Сотрудники технической поддержки, отвечающие на звонки, как правило, не обладают очень уж высокой компетенцией (это нормально, первая линия и всё такое)... И если что-то случается, то, как правило, следует ответ в духе "Да, мы в курсе, наши специалисты уже работают". А если "всё работает", то, как правило и оперативная поддержка не особо нужна. (иногда, правда язык не поворачивается назвать "оперативным" звонок с 10-15 минутным ожиданием, который "очень важен для нас"..)
О том, что сложности возникают как у ведущих и мировых, и Российских хостинг-компаний, так и у "не очень" - наверняка, можно найти в интернетах. Конечно, если при учёте статистики ко вторым относить т.н. "школохостинги", то, ясное дело, негатива в их сторону будет гораздо больше.
Однако, есть достаточное количество компаний (в том числе, имеющих официальных представителей на этом Форуме), которые, не являясь самыми крупными, обеспечивают (на мой взгляд) вполне достойное качество услуг (сайт открывается.. ну и дальше по тексту)
А, в общем-то, шашечки или ехать - каждый решает сам.
p.s. По поводу перехода на VPS - если есть желание освоить VPS (набраться опыта, "прокачать" навыки администрирования) - конечно, переезжать.. Если нет уверенности - можно панельку заказать.. тестовый сервер.. А если желания разбираться нет, нужно просто "чтоб работало" - вполне подойдёт вариант "с администрированием" или т.н. VIP-хостинг (тот же хостинг, только с бОльшими лимитами)
Запустите скрипт mysql-primer.sh (гуглить из открытых источников, при желании - посмотреть) - всё, что подсветит красным - заслуживает Вашего внимания.
Зачем? В смысле, с какой целью?
PDO ещё есть.. там кодировка прямо в строке подключения указывается :)
Если нужно, чтобы страница отображалась пользователю, но не индексировалась - можно запретить в robots.txt (например, clean param или Disallow: *?cnm в секции для Yandex) и/или прописать в meta rel=canonical основную страницу
Если и пользователю не нужна - 301 редирект.
загадочные желания...
Если телепатия не подводит - вставить после RewriteEngine ON (yourpage заменить на свою страницу)
RewriteRule yourpage.html - [L]
Так получайте.. Помощь можно и бесплатно..
кракозябры в сайдбаре, настройка Robots и тд.
