Смена хостинга
Дисклеймер: Данный материал не претендует на методологическое или обучающее пособие.😎Я не веб разработчик, просто делюсь своим опытом, возможно это кому-то пригодится. Хотя я имею опыт переноса сайтов и сам когда-то написал сайт на коленке на HTML, знаю CSS со словарем и на базовом уровне PHP и JS, я прекрасно осознаю что мой уровень по современным меркам недостаточен чтоб тягаться даже с нынешними студентами айтишниками, которым возможно будет очень смешно читать о моих приключениях.
В общем назрела у меня необходимость переноса сайта на другой хостинг. Базово все понятно, опыт у меня в этой части имеется, переносим файлы, делаем экспорт базы данных, правим конфиг и NS записи домена, и вуаля все работает. Конец.
Но оказалось, что это было только начало долгого пути...
При открытии сайта был просто белый экран и очень лаконичная, заряжающая оптимизмом, надпись - Error. При входе в админку все тоже самое. Куда копать совершенно непонятно. Несколько раз удалял и создавал заново базу, просматривал с лупой config ничего не помогало. После долгих танцев с бубном написал в техподдержку.
Они покопались маленько, сказали что все настроено верно, DNS адресуется правильно, SSL работает нормально, больше они ничем помочь не могут потому как у меня не Wordpress, а они работают только с этой платформой (что кстати является фактически стандартом в США).
Тогда попросил их об услуге переноса сайта с прежнего хостинга, у всех хостеров, как правило это прописано и делается бесплатно. Дал им адрес, логины, пароли, они там опять поковырялись, офигели и сказали что ни черта не понятно, а где же cPanel🤪 Короче ничем помочь не могут ибо у прежнего хостера собственное нестандартное ПО в котором они не разбираются, так что рекомендовали обратится к специалисту разработчику сайта.
Классно, я конечно обратился к себе еще раз, но ничего вразумительного в голову так и не пришло. Ковыряясь в опциях cPanel наткнулся на журнал ошибок и решил почитать. А там сплошняком идет ошибка 403 доступа к файлу .htaccess, - недостаточно прав! О как.
Написал опять в саппорт, мне ответили, что они это уже видели, права на файле стоят нормальные, мол проверяйте конфигурацию своей CMS ну и традиционно обратитесь к разработчику, тут разработчик во мне тихо заплакал😢
Путем долгих, скорее всего нелогичных действий, которые я тут пропущу, выяснилось, что дело было в правах пользователя MySQL который почему-то по дефолту при создании был очень ограничен. Назначил максимальные права и сайт тут же открылся. Ура! Или еще нет?
Нефига подобного. Сайт открылся, но вид его был ужасен, шаблон отсутствует, меню нет, картинок нет, короче тихий ужас. Обнаружил что на файлах шаблона стоят права 600, исправил на 644 и по крайней мере что-то произошло, появился фон и шапка сайта. Ну тут хоть понятно куда рыть. Но все права проверять с ума сойдешь, в CMS тысячи файлов и каталогов. Пошел в SSH терминал и тупо выставил на все папки права 755 , а на все файлы 644.
find /dir_name -type d -exec chmod 755 {} \;
find /dir_name -type f -exec chmod 644 {} \;
*dir_name путь к корневой папке сайта.
Ура! Сайт наконец-то приобрел свой нормальный вид. Я уже хотел открывать шампанское, но решил зайти в админку.. Что тут сказать. В админке работает только главное меню, все остальные подразделы пустые, ни форм, ни кнопок, только текст на белом фоне. Недоступны никакие компоненты, плагины, материалы, меню. Невозможно сделать вообще ничего, только просмотреть свойства, обновиться и проверка базы данных.
Ну сделал проверку и получил 119 сообщених об отсутствующих таблицах, несоответствии версии базы данных и прочее, прочее. Как это вообще возможно?!🤯
Удалил базу полностью, создал новую, импортировл дамп заново. Результат тот же. Как может быть что я делаю экспорт проверенной рабочей базы, а после импорта она вся покорежена? В PhpMyAdmin даже особо настроек-то нету, кнопка "экспорт", кнопка "импорт", даже версия у обоих хостеров почти одинаковая, до второго знака после второй точки! Ну ладно, в админке есть опция исправить ошибки в базе. Нажал.
После этого и сайт, и админка слетели напрочь без возможности восстановления. Сайт говорил -
unknown column 'x.reference' in 'field list'
а админка -
Call to undefined method Joomla \CMS\Application\
AdministratorApplication::getInput()
и на этом все. После включения режима отладки получил еще много не менее устрашающих сентенций. Никакие мои манипуляции с базой успеха не имели. Снес все нафиг, откатился к исходному варианту..
Нет ну сайт-то работает, был бы он просто статичный можно было бы и забить, но мне-то надо создавать новые материалы, а как это сделать без админки? Можно прямыми запросами в MySQL конечно, но это как удалять гланды через одно место, короче не вариант.
Попробовал обновить джумлу, чтоб пофиксить базу. Результат тот же самый - белый экран и
Call to undefined method Joomla \CMS\Application\
AdministratorApplication::getInput()
Опять снес все, установил чистую, - работает. Накатил свои файлы - повреждена база данных! Тут у меня вообще закипел разум возмущенный, причем тут база, если я только файлы заменил, а базу не трогал, она только что была рабочая!
Два дня гуглил интернет, ничего внятного не нашел, кроме того, что почему-то может влиять способ переноса файлов. Как может отличаться результат если там копируешь, а тут вставляешь мне не очень понятно, но терять уже было нечего. Нашел два варианта - старый медленный динозавр FTP и специальный компонент Akeeba core.
Акиба по отзывам вообще вещь, весь следующий день читал по нему документацию и совсем приуныл, очень уж это не для новичков. Поэтому решил оставить на крайний случай, а пока попытать удачу со знакомым с детства FTP.
Боже как это медленно! Я уже отвык от такого. Скачивал я сайт на локальный компьютер часа три, а выгружал его на хостинг всю ночь, как минимум 7-8 часов. Слава богу без отключений. Утром зашел уже привычно внес изменения в конфиг и пошел смотреть результат..
Шаблон сайта разъехался, но зато админка работает и говорит, что база в отличном состоянии! Не понимаю какая связь, но копирование файлов сайта через древний FTP реально помогло! Хорошо у меня хоть сайт маленький, а если это крупный портал, его же сутки только скачивать будешь, жуть.
Ну да ладно, осталось решить вопрос с шаблоном. Права вроде нормально выставлены, что теперь-то случилось? Оказалось, что новый хостер автоматом прописывает выбранную версию php в htaccess сайта, а по дефолту использует максимальную, а поскольку я скачал файл с прежнего хостинга там такой записи нет. Так что зашел в cPanel и еще разок прописал нужный php и… ура! Работает! Не прошло и недели.
Мораль сей басни такова, - решающее значение при переносе сайта имеет инструмент копирования файлов сайта! Как именно это влияет мне не конца понятно, но факт, что одни и те же файлы будучи скачаны с панели управления хостингом через браузер и через FTP оказались в итоге различны для CMS. Так что в итоге я сделал-то все изначально правильно, никаких особых сложностей при переносе сайта нет. Просто нужно было файлы копировать иначе вот и вся хитрость.🤷♂️Век живи - век учись, как говорится.
Просмотров: 565
