Никогда не связывайся с reg.ru!

Настойчиво рекомендую обходить этот хостинг стороной! Я уже однажды писал про то, что они берут деньги за каждый чих и микрофункцию. При этом были комментарии о том, что на других хостингах все эти услуги уже включены в стоимость. Но при этом тарифы основного хостинга reg.ru не дешевле, а чаще даже дороже других, где всё это «включено» в базовую стоимость…

Но стоимость, это даже не главная причина. А вот что вывело меня из себя – это абсолютно скотское отношение к клиенту как точки зрения сервиса, так и предоставления своей базовой услуги.

Какая цель покупки хостинга? Доступность моего сайта в сети в любое время. Хостинг должен обеспечивать его бесперебойную работу, за это я и плачу деньги. Вчера ко мне обратился заказчик со срочной просьбой проверить, почему вдруг перестал работать сайт – это крупный интернет-магазин с сотнями заказов ежедневно на солидные чеки. То есть любой простой сайта даже на несколько часов – ощутимый удар по бизнесу.

Начну с того, как заказчик узнал про то, что сайт недоступен. Хостинг прислал уведомление? Может из поддержки сообщили, что у вас что-то с сайтом? Сработало оповещение мониторинга сайта? Не-а, заказчик зашёл на сайт проверить заказы. То есть хостингу фиолетово, выполняет ли их система свою базовую функцию – работоспособность сайтов.

Окей, допустим, что за такой мониторинг и оповещения надо доплатить отдельно. При этом у заказчика куплена услуга «Расширенная тех. поддержка хостинга», что бы это не означало, но уж точно не оповещение о том, что сайт не работает.

Обратились в срочном порядке в эту расширенную техподдержку и получили ответ: «Сайт не работает, из-за блокировки, которая была установлена из-за того, что размер базы данных превышает 4 ГБ.» 😱 То есть они сами заблокировали сайт в связи со своими же ограничениями, никак об этом не оповестили и более того, не предупредили о том, что база приближается к критическому порогу…

Ох, как же у меня горит жопа с этого… Чувствую, это будет огромный эпос, посвящённый любимому хостингу.

😭 Самый неудобный хостинг reg.ru

Надо отдать должное, когда новый сервер с панелью управления был куплен, ребята выполнили перенос сайта с базой данных на него ровно за 50 минут. Я всё проверил: работает корректно и переключил DNS-записи (что это такое, можно почитать в моём прошлом посте) на новый сервер. Сайт заработал, всё отлично.

Но теперь у заказчика появилось целых четыре админки, в которых ему придётся разбираться:
1. админка самого рег.ру, где ты покупаешь все их бесчисленные услуги
2. админка хостинга сайта, на которой оставалась доменная почта
3. админка рег.ру облака – да, для этих облачных серверов, которые нужно было купить, так как серверы из первой панели ограничены, есть отдельная адмика (не спрашивай. Зачем, я хрен знает)
4. админка облачного сервера, где уже скрыты все настройки самого сервака, включая DNS, сертификаты домена, настройки сайта и всё остальное важное.
…

Для понимания: это четыре разных логина, 4 разных пароля, 4 отдельных и разных интерфейса. Уважаемые рег.ру, можете, пожалуйста, уволить человека, который у вас за UX отвечает? Кажется, он немного иные функции выполняет.

Сайт перенесли, теперь я хочу вернуть деньги за те лишние серверы, которые были оплачены по наводке самой техподдержки, но оказались негодными для наших целей.
Пишу запрос в поддержку: «Прошу отключить, удалить и вернуть деньги за оплату следующих серверов…» и перечисляю их. Ответом ребята, видимо, хотели сделать контрольный выстрел и выдали: «Сделать это вам нужно самостоятельно».

Как же сложно, когда привыкаешь к хорошему сервису и оно становится нормой, адекватно воспринимать такое вот отношение к себе. Когда ты просто пишешь проблему и тебе её решают. Сразу, без вопросов, без тыканья носом в инструкции или бессмысленных подъёбок вроде «у нас всё работает».

Ну что ж, окей, пойду сам себе верну деньги. 😔

👩‍🦰 Переношу сайт заказчика с reg.ru на другой хостинг

В итоге, как я писал в прошлом посте, сайт заработал, всё ок. Но заказчик заметил, что перестали приходить письма на корпоративную почту. Ещё один сюрприз от любимого хостинга: вместе с сайтом они перенесли и почтовый сервер на новый хостинг, при этом даже не предупредив об этом.

Да, почта работала и надо было просто поменять настройки почтового сервера на новые, но заказчик уже пропустил несколько срочных писем. Когда такая штука становится финальной вишенкой на торте неработающего сайта, есть его уже совсем не хочется. К такому выводу мы в итоге и пришли – перенести домен, почту и сайт на другой хостинг. Именно этой процедурой я сейчас и занят. И я уверен, что это станет огромным облегчением для заказчика, когда узнает, а как ещё может быть.

Перечислю некоторые факторы моего хостинга в противовес рег.ру. Я не собираюсь давать бесплатную рекламу, хотя ранее уже упоминал свой хостинг в своих постах, неленивый сможет найти.

1. Брать деньги за любую мизерную услугу, например переадресацию сайта – опубликовать статью, где написано, как настроить переадресацию быстро и бесплатно

2. Отключать сайт без предупреждения за ограничение, которое закопано глубоко в условиях использования тарифа – предупреждать за два месяца о том, что надо будет продлить домен, даже если на счёте есть деньги для автоматического продления. Кстати, после переноса сайта на новый сервер, объём базы составлял 3,5 ГБ, то есть до предельного порога в 4 ГБ база не распухла. Но сайт всё равно отключили.

3. Брать деньги за «расширенную техподдержку» – любой запрос является приоритетным и за это не нужно доплачивать.

4. Давать клиенту общие указания без конкретики и тыкать носом в стиле «у нас всё работает» – действительно решать задачу сразу, после первого сообщения со стороны клиента.

5. В случае приобретения виртуального сервера выдать клиенту 4 админки – всё решается и настраивается через одну единственную панель управления.

Остальное можешь прочитать в предыдущих постах.

🛍 Что выбрать для интернет-магазина, Shopify или inSales

Так как рег.ру прервал мой поток мыслей насчёт онлайн-ритейла и направил его в свою сторону, пришла пора вернуться в незаконченную тему и ответить на вопрос выбора платформы.

Надеюсь, тебе удалось прочитать предыдущие посты в этой серии, так что думаю, ответ на этот вопрос будет очевидным. Если рынок, на который ориентируется интернет-магазин, находится в пределах РФ, то это однозначно inSales. Альтернативной платформы, которая бы покрывала такой скоуп функциональности, была интегрирована со всеми необходимыми внешними инструментами и из коробки предлагала готовое решение, которое можно запустить буквально в течение дня, я просто не видел.

Если же заложен потенциал выхода на зарубежные рынки, то лучше сразу вложиться в платформу, которая позволит масштабироваться в нужном направлении. И тут нет равных Shopify – пока мировой лидер в этой нише (конструкторов интернет-магазинов). Плюс они постоянно внедряют огромное количество фич на пике трендов в маркетинге и онлайн-ритейле, так что можно будет постоянно улучшать свой магазин вместе с их продуктом.

Промежуточным вариантом остаётся другой лидер мирового масштаба – WordPress, который подойдёт в случае, если нужен полный контроль над разработкой, так как в этом случае весь код полностью доступен для редактирования. И на базе WP можно реализовать практически любую требуемую функциональность, если она выходит за пределы стандартного понимания интернет-магазинов. К тому же WP не зависит от географии, так как это OpenSource лицензия и он просто устанавливается на нужный тебе сервер.

И как всегда, призываю в принятии решений исходить из целей и задач, которые стоят перед платформой. Потому что если взять любой среднестатистический олнайн-магазин, абсолютно аналогичный по функциональности и дизайну можно будет создать с помощью любого из перечисленных инструментов. Так что выбирай мудро.

🔥💩👍

Соберу здесь дайджест постов про платформы онлайн-ритейла, на которых можно строить интернет-магазины.

На чём делать онлайн-магазин? Shopify – мировой лидер в этой нише, на котором запускают многомиллионные бизнесы.

Возможность интеграции платёжной системы в интернет-магазин – ключевой фактор его функционирования. У Shopify есть интеграция с российскими платёжками, но для запуска магазина на нём потребуется юрисдикция в другой стране.

inSales – полнофункциональный российский аналог Shopify. Эта платформа позволяет как создавать свой собственный магазин в режиме конструктора, так и управлять своими магазинами на популярных маркетплейсах и в соцсетях.

Внушительная экосистема inSales включает в себя постоянно пополняемую библиотеку дизайн-шаблонов и расширяющих функциональность приложений, которые можно дорабатывать вплоть до изменения кода при необходимости. Разработка шаблонов и приложений для inSales – это отдельный вид бизнеса, на котором можно заработать.

inSales имеет всё, что надо для построения онлнайн-магазина, включая интеграции со складскими системами, службами доставки, платёжками, расчёт налогов.

Также есть полноценная CRM для ведения клиентской базы и инструменты для продвижения и маркетинга. Разработка (и доработка) магазинов на inSales – отдельная узкая ниша, куда можно направить силы для организации заработка.

Выбирать Shopify следует при потенциале масштабирования за рубеж. Для магазинов внутри РФ однозначно подходит inSales. Если необходим полный кастом и контроль кода – WordPress.

Если остались вопросы, пиши в комментах и хороших выходных!
🔥💩👍

➡️ Как перенести рабочий сайт на другой хостинг, не уронив его

Это серия статей, посвящённая процессу перехода на новый хостинг. Необходимость переноса может возникнуть по разным причинам. Например, хостинг может просто закрыться, можно подобрать более подходящий вариант, когда требуется другой уровень мощностей при масштабировании бизнеса или, как в случае с моим заказчиком, который я здесь подробно описывал, когда хостинг буквально уговаривает тебя всеми возможными способами перейти к конкурентам.

Что будем переносить. Я выделяю четыре базовых составляющих, которые будут затронуты этой процедурой.

1. Доменное имя сайта. Совсем необязательно, чтобы домен был зарегистрирован там же, где будет хоститься сайт. Однако это просто очень удобно: у тебя один контрагент, одно место платежа, одна точка входа и панель управления для всех вопросов с сайтом.

2. Доменная почта. Где домен, там и корпоративная почта, которая обычно как раз находится там же, где и сайт, просто потому что она занимает место на серверах, а хостинг как раз его предоставляет. Тем более, что ушла эпоха бесплатной Яндекс.Почты и теперь нужно самостоятельно заботиться об этом, покупая хостинг.

3. Непосредственно сам сайт, который состоит из двух частей.

3.1. Грубо говоря, это файлы сайта с кодом и медиафайлы, которые составляют контент. Файлы при этом находятся в определённой структуре, менять которую нельзя, так как в коде есть зависимости от местоположения файлов, к которым он обращается.

3.2. База данных. Есть сайты и без БД, как в том случае, где я рассказывал про создание сайта-визитки на чистом Bootstrap: там она просто не нужна. Но если мы говорим про любую CMS или сайт даже на уровне простого блога – это всегда база данных.

Всё это добро нужно перенести на новый хостинг и при этом сделать так, чтобы сайт продолжал работать непрерывно и был доступен на протяжении всего периода миграции.

Разберёмся!
🔥💩👍

🔩 Порядок переноса сайта на другой хостинг

Первый приоритет в этом процессе я отдаю тому, чтобы всё работало без перебоев. То есть ни одно письмо на доменную почту не было пропущено, сайт не лежал бы ни минуты и домен доступен на протяжении всей процедуры.

Для того, чтобы это сделать, я использую следующий алгоритм.

1. Синхронизировать доменную почту с нового сервера. Это значит, что все письма будут приходить (пока речь только про входящие) на новый почтовик, расположенный на другом хостинге. Если это будет сделано, то ни одно письмо не будет пропущено, так как новый хостинг уже слушает входящие со старого почтового сервера, а старые письма также считаны с него. После переключения почтовика новые письма начнут падать сюда же.

2. Перенести домен на обслуживание на новый хостинг. При этом все его настройки сохранятся, и они будут смотреть на старый сервер. Доменная почта продолжит работать со старым почтовиком, а сайт будет загружаться со старого хоста. Но доменное имя при этом перейдёт под управление новым регистратором.

3. Перенести сам сайт и базу данных на новый хостинг. Эти две составляющие я не разделяю, так как они работают в неразрывной связке (разумеется, речь идёт про сайты с БД). Необходимо убедиться, что всё работает как надо на новом хосте, после чего переходить к финальному шагу.

4. Переключение доменных адресов на новый хост. Когда на новом сервере всё лежит в готовности, осталось нацелить на него домен. Здесь же переключается и почта на новый сервер, поэтому эти настройки выполняются одновременно.

5. Когда всё заработает с нового хостинга, останется погасить всё на старом: удалить базу, файлы сайта, почистить все кэши и дампы, отписаться от услуг и вернуть деньги за неиспользованный период обслуживания.

🔥💩👍

📧 Переносим сайт на новый хостинг. 1 этап: синхронизация почты

Следуем описанному в предыдущем посте алгоритму. Сначала надо синхронизировать доменную почту на новом хостинге со старым. Процедура здесь точно такая же, как и при первичной настройке почтовика. Я её описывал на примере перехода с Яндекс.Почты на свою собственную, поэтому само подробное руководство можно почитать там.

Если кратко, то на новом хостинге нужно завести доменную почту, как если бы она создавалась в первый раз. Но при этом в надо подсунуть ей настройки с уже работающего хостинга. В эти настройки входят следующие штуки.

1. IMAP – сервер входящей почты

Когда мы укажем старый почтовый сервер, новый хостинг будет обращаться к нему, слушая входящие. И любое письмо, которое пришло на ящики нашего домена, будет попадать в новый ящик, созданный уже на новом хостинге. Соответственно, все новые письма будут прилетать в два места.

2. Адреса ящиков

Они нужны для загрузки всех прошлых писем, которые сейчас лежат на старом хосте. Кроме самих писем забирается и структура папок, если ты сортируешь письма, этот же порядок будет соблюден на новом хосте.

3. Пароли ящиков

Очевидно, что для скачивания прошлый писем нужен доступ к ящикам, который открывается паролем. Здесь указывается именно текущий пароль, который сейчас используется для входа в почту, чтобы новый хостинг сам мог зайти в ящик и вытянуть оттуда все письма.

Таким образом получится ещё одно место, где можно читать письма, но пока только читать: сервер исходящей почты будет подключен позже. А пока важно убедиться, что все старые письма подтянулись, а новые приходят корректно.

🔥💩👍

Переносим сайт на новый хостинг. 2 этап: трансфер домена

Пока синхронизируется почта можно сразу заняться переносом домена, так как это самый долгий этап из всего нашего алгоритма. Процедура включает как технические, так и юридические аспекты со стороны обоих регистраторов, но в эти подробности мы не будем вдаваться, так как они всё делают самостоятельно.

Целевой регистратор (и хостинг в одном лице), разумеется, заинтересован в переносе домена к нему, поэтому большую часть работы выполняет самостоятельно. Однако с нашей стороны требуется инициировать процесс переноса домена.

Сначала нужно найти в текущем хостинге (регистраторе) место, откуда можно запросить авторизационный код (auth-code), который является ключом для старта процедуры. Где и как это происходит, можно найти в документации к хостингу. Если уж совсем лень, можно спросить у техподдержки.

Как правило, есть форма с одним полем, куда нужно ввести домен, который требуется перенести. После чего хостинг запросит подтверждения легитимности этого действия. Здесь у всех по-разному, кто-то присылает ссылку подтверждения на почту администратора домена или SMS с кодом, кто-то запрашивает копию паспорта или свидетельство о регистрации в случае, если домен зареган на юрлицо.

В любом случае тебе понадобится доступ к контактам, которые были указаны при регистрации домена. Если забылось, их можно найти в информации про доменное имя. Там обычно можно скачать сертификат на домен, где указаны контакты владельца. Кстати, именно поэтому нельзя в качестве почты владельца указывать доменную, так как её легко потерять.

Когда подтверждения пройдены и код Auth-получен, можно заходить на новый хостинг. Там ищем в разделе с доменами функцию переноса, где надо указать передаваемый домен. Новый хостинг сразу запросит Auth-код, который мы заботливо подготовили. Вводим его и далее остаётся только терпеливо ждать (обычно несколько дней), пока хостинги договорятся и всё сделают.

В результате на новом хостинге появится домен, а на старом исчезнет. Вот такая магия.

🔥💩👍

Переносим сайт на новый хостинг. 3 этап: миграция сайта и базы данных

Пожалуй, самый сложный технически этап из всего алгоритма. Но при этом может оказаться самым быстрым и лёгким в зависимости от хостинга.

Идеальный вариант – хостинг сам занимается переносом без твоего участия. Всё, что нужно сделать, это предоставить ему данные для доступа к текущему сайту и базе данных. Далее специалисты выполняют всю работу по выкачиванию файлов, заливке их на нужный сервер, копированию базы данных к себе, настройке всего этого добра и подключению к какому-нибудь тестовому техническому домену.

Если этот вариант не про твой хостинг, то я бы в первую очередь задумался, а нужен ли тебе такой хостинг… Потому что в их интересах в первую очередь, чтобы они держали у себя твой сайт и домен, это их бизнес. И выполнение операции по переносу сайта – вполне рутинная задача и показатель уровня сервиса. Разумеется, это должно быть бесплатно, так как тебе всё равно придётся платить за аренду серверных мощностей, на чём и зарабатывает хостинг.

Перенос сайта должен быть в виде отдельной функции в панели управления хостингом. Обычно там форма, куда нужно ввести домен сайта, после чего хостинг запросит у тебя доступы к текущему сайту.

Итак, доступы. Обычно требуется следующее: доступ к файлам осуществляется через FTP-протокол, поэтому нужно будет новому хосту дать аккаунт к нему. Настраивается этот доступ в текущем хостинге. Нужно найти раздел FTP и там создать нового пользователя, указав для него логин и пароль. Также в этом разделе должны быть настройки сервера, по которым можно будет достучаться до него из внешнего FTP-клиента. Скопируй их и передай вместе с логином и паролем новому хосту.

Те же действия надо сделать и для базы данных: найти этот раздел в админке текущего хоста, создать юзера, найти настройки базы и передать всё в новый хостинг.

Если не получается что-то, не забывай, что есть техподдержка, у которой можно спросить, где всё это находится.

🔥💩👍

Переносим сайт на новый хостинг. 4 этап: переключение на новый сервер

Технически к этому моменту сайт перенесён на новый хостинг, доменное имя находится под его управлением, и почта приходит сюда же. Но если ты посмотришь на серверы, на которые нацелен домен, то обнаружишь, что это всё ещё старый хостинг. Поэтому он и открывается до сих пор без перебоев, так как обращается всё к тем же файлам на том же сервере, что и раньше.

Что будем менять: NS, то есть Name-space серверы и А-запись у домена. Как всё это делается, я рассказывал в прошлых постах, можешь почитать детали там. Вкратце упомяну, что при изменении DNS должно пройти какое-то время, прежде чем все изменения вступят в силу, обычно до 2 суток всё это может происходить.

А вот как сработает магия постоянного доступа к сайту. Так как сейчас он фактически находится на двух серверах двух разных хостингов, с внешней стороны неважно, на какой именно сервер смотрит домен: в любом случае результат загрузки будет одинаков, один и тот же сайт. Поэтому, когда произойдёт переключение и сайт будет загружаться с нового хоста, пользователь просто не заметит подмены.

Есть нюанс с обновлением базы данных. Если это, например, интернет-магазин, то может получиться так, что до переключения заказ придёт на старый сервер, а после переключения в базе данных на новом сервере этого заказа не будет, так как нет никакой синхронизации данных. Можно сделать следующее.

Во-первых, запланируй переключение на тот момент в течение дня и недели, когда на сайте самая низкая активность, например в ночь с субботы на воскресенье.

Во-вторых, после переключения можно попросить техподдержку хостинга сравнить две базы данных и в случае наличия расхождений, синхронизировать данные и загрузить со старого хоста недостающие заказы. Таким образом данные выровняются и можно спокойно начинать работать на новом хостинге.

🔥💩👍

Переносим сайт на новый хостинг. 5 этап: переключаем почту и гасим старый хостинг

Финальный штрих эпопеи с переносом сайта – это настройка почтового сервера. Почта для домена у нас уже настроена, мы добавляли ящики на самом первом этапе в новый хостинг. Это значит, что входящие мы уже видим здесь и пришла пора настроить исходящие письма.

За это отвечают те же DNS записи MX типа (Mail eXchange). Во многих хостингах есть кнопочка автоматической настройки MX-записей, которая сделает всю нужную работу. В противном случае надо найти в инструкции по настройке доменной почты, какой именно хост нужно прописать для того, чтобы почта начала работать отсюда.

После того, как это сделано, останется подождать несколько минут, пока произойдёт переключение. Опять же, с запасом время на переключение обычно берут 48 часов, но на практике достаточно минут 10 и можно уже тестировать новую почту.

Если работаешь с письмами из браузера, то у хостинга должен быть web-интерфейс для управления письмами. Самый популярный у них – RoundCube, вполне себе годный почтовик, где нет ничего лишнего и который работает как часы. Если надо настроить какое-нибудь навороченное приложение для обработки почты, типа Outlook, то в разделе с почтой для домена должны быть настройки для почтовых клиентов, где будут указаны необходимые параметры. Хотя сейчас почти всегда достаточно логина и пароля от почты.

Как только всё начало работать с нового хостинга, пришла пора прощаться со старым. Наверняка остались месяцы, если не годы неиспользованных подписок на всякие услуги. В этот я рекомендую запросить возврат денег за них: идеально, если их можно просто вывести. Если нет, то можно придержать на будущее и потом при необходимости, например, купить на них новые домены (и передать их в новый хостинг, ага).

На этом заканчивается процедура переноса сайта. Искренне желаю, чтобы у тебя не возникало такой необходимости в проектах, но теперь у тебя пошаговая инструкция, как это делать.

🔥💩👍

🚗 Дайджест переноса сайта на новый хостинг

Иногда требуется перенести сайт на новый хостинг: старый хостинг закрывается, поднимает цены, не хватает возможностей или по другим причинам.

Что нужно переносить: доменное имя (обычно его регистрируют там же, где находится сам сайт), доменную почту, файлы сайта, базу данных.

Рекомендуемый порядок переноса, который обеспечивает плавный переезд без периодов недоступности: синхронизировать доменную почту, перенести домен на обслуживание на новый хостинг, скопировать файлы сайта и базу данных, переключить доменные адреса на новый хост. В конце погасить старый хостинг.

Для синхронизации почты надо создать доменные ящики на новом хостинге и нацелить их на старый сервер, чтобы они скопировали структуру папок и принимали входящие, включая всё, что там уже лежит.

Для переноса домена необходимо получить специальный ключ авторизации процедуры на старом регистраторе. Обычно требует дополнительных подтверждений личности.

Миграция сайта производится, как правило, самим хостингом. Всё, что нужно сделать – дать им доступы к FTP старого хоста и в некоторых случаях – доступ к админке. Остальное они сделают сами.

Как только сайт будет на новом хостинге, следует перенацелить домен на новый сервер таким образом, чтобы он начал загружаться оттуда.

В конце не забыть переключить доменную почту тоже на новый сервер, после чего уже можно будет пользоваться почтой с нового хоста.

И финальный штрих – погасить все услуги на старом хостинге, вернуть неиспользованные деньги и закрыть аккаунт.

🔥💩👍

Как отправлять клиентов в чат сразу после оплаты

Вчера ко мне обратился один из моих заказчиков с просьбой разработать чат-бот, который умел бы принимать оплату и после оплаты отправлять клиентов в закрытый Telegram-чат. Я, как и следует делать любому продакту, к которому приходят с готовым решением, начал спрашивать про задачи, которые стоят перед ним.

Задача следующая: из Инсты клиент по ссылке попадает на страничку Таплинк (конструктор страниц со ссылками), откуда он должен иметь возможность оплатить продукт (как российской, так и зарубежной картой) и при успешной оплате попасть в закрытый Telegram-чат. То есть доступ к этому чату и является продуктом.

Если пойти от обратного и предположить, что в чат клиент попадает из чат-бота, в котором оплачивает продукт, то кажется вполне логичным собрать такую штуку. Но это разработка самого бота, его поддержание или оплата за конструктор, на котором он собран. Кажется, можно проще.

Посмотрим с другой стороны. Путь из Инсты в Таплинк понятен и не требует вмешательств. А вот из Таплинка к оплате продукта можно реализовать на самом деле несколькими способами. И первый, самый простой – использовать сам Таплинк, в котором есть интеграции с платёжными системами.

Загвоздка этого способа в том, что для разных типов карт надо будет делать разные ссылки, которые ведут на разные платёжки (для российских карт одна, для зарубежных – другая), что может путать клиентов. И подключение платёжек доступно только на старшем тарифе. К тому же не факт, что получится на одном аккаунте подключить сразу несколько платёжных систем.

Как оказалось, не самый очевидный на первый взгляд, но явно более простой вариант, нежели разработка своего чат-бота. Есть ещё парочка, про которые расскажу завтра.

🔥💩👍

💳 Как сделать прослойку для оплаты продукта между Инстой и Telegram-чатом

Если по тем или иным причинам не получается организовать оплату средствами самого конструктора Taplink, существуют другие варианты реализации задуманного.

Один из них – сделать прослойку в виде платёжной странице на любой удобной платформе. Если у тебя уже есть сайт, например, можно на базе этого же сайта сделать простейшую платёжную страницу с формой оплаты, куда и будет попадать пользователь при нажатии на нужную ссылку.

К сайту, разумеется, в свою очередь должна быть подключена платёжная система, которая и будет выполнять функции приёма платежей. На сайте также выполняется настройка того, куда будет отправлен пользователь в случае успешной и неуспешной оплаты. Если не получилось оплатить, то можно показать ему какую-то инструкцию с решением возможной проблемы. Если же всё хорошо, то сайт может автоматически направить клиента в чат Telegram, ведь это обычная web-ссылка.

Подобную страницу довольно легко собрать, например, на конструкторе Tilda, которую я часто упоминаю и использую для многих случаев. Там есть встроенные интеграции с большим кол-вом платёжных систем, которые настраиваются очень просто. Легко можно подключить и несколько штук для оплаты разными типами.

А ещё есть вариант без сайта, который мне нравится больше всего. Практически в каждой платёжной системе есть возможность создания платёжной страницы – это, по сути, и есть страница сайта, которая базируется в платёжке. Как правило, там можно задать сумму платежа, указать наименование товара и другие вещи, которые будут предзаполнены у клиента при попадании на страницу. Ему останется выбрать метод оплаты и произвести её.

И ключевая фишка. При настройке платёжной страницы всегда есть параметр Success URL, или ссылка при успешном платеже, в которой и нужно указать адрес, ведущий на закрытый чат в Telegram. Разумеется, на платёжную страницу будет сформирована ссылка, которую и нужно будет вставить в Taplink. И всё будет работать.

🔥💩👍

Не забудь при переносе сайта на новый хостинг!

Пара нюансов, про которые можно забыть при переносе сайта на другой хостинг и сервер, но которые могут всё поломать. Кстати, на прошлой неделе завершился перенос интернет-магазина заказчика на новый хостинг и вот уже несколько дней он без перебоев работает оттуда.

Первый нюанс – это SSL-сертификат домена. Когда мы переносим доменное имя к новому регистратору, сертификат не переносится вместе с ним, так как является отдельной сущностью, связку с которой обеспечивает хостинг.

Развитие событий зависит от того, какого типа сертификат был установлен на домене. Я писал в прошлых постах, какие они бывают, как приобретаются и устанавливаются на домен. В случае, если это был бесплатный Let’s Encrypt сертификат, то всё довольно просто: надо заказать такой же на новом хостинге. Это можно сделать сразу в тот момент, когда перенос домена завершён.

Второй вариант – это любой платный сертификат. В этом случае надо будет вспомнить тот светлый момент приобретения сертификата и найти его, именно сам сертификат. В его составе должно быть две вещи: непосредственно сертификат и его приватный ключ, который представляют собой набор символов, начинающихся со строк

----- BEGIN CERTIFICATE -----

----- BEGIN RSA PRIVATE KEY -----

Они и понадобятся тебе при установке этого сертификата на новом хосте. Там надо зайти в раздел доменных имён (у некоторых хостингов эта секция запрятана в консоль ISPManager, привет рег.ру) и найти функцию, позволяющую добавить сертификат к домену. Там должно быть два поля, в которые и нужно вставить сертификат и приватный ключ. После сохранения этих данных сертификат будет привязан к домену.

До того момента, пока сертификат не привязан к домену, посетители сайта будут видеть предупреждение о том, что соединение небезопасно и лучше отсюда убежать подальше. Устанавливай сертификат и всё станет норм.

🔥💩👍

Всегда проверяй версию PHP

Вчера я рассказал про SSL-сертификат, который нужно не забыть перенести вместе с доменом на новый хостинг. Сегодня поведаю про другую штуку, которая может унести немало крови и времени в процессе выяснения причин, почему что-то не работает или криво выглядит.

Сайт перенесли, все файлы до последнего бита на месте и чётко зеркалят исходную структуру. База данных перенесена и полностью идентична прежней. Все связки проставлены корректно, сайт запускается и даже работает… Но что-то в нём может идти не так, например какая-то одна функция. С интернет-магазином, который я недавно переносил, это была функция открытия разделов каталога. То есть в сам каталог попасть можно, если открыть его окольными путями или по прямой ссылке, но вот из основного меню категории не открывались.

Или визуальные глитчи и артефакты, например, странная полоска, которая пересекает половину макета. Или съехавшие блоки, которые выглядят как недоделанная вёрстка. Это могут быть совсем незаметные баги, но иногда такие, что просто невозможно пользоваться сайтом.

Причина таких поломок может крыться в простом несовпадении версии программного языка кода на исходном и целевом серверах. В чём тут соль. Любой программный язык, на котором пишут сайты, развивается и претерпевает изменения от версии к версии. Например, раньше для создать какой-то функции нужно было написать алгоритм со всеми условиями, а в новой версии эта функция встроена и вызывается одной командой. Старый код при этом может перестать работать.

Библиотеки, которые исполняют код на сервере сайта, тоже могут иметь разные версии. Соответственно, необходимо убедиться в том, что версия языка совпадает с той, на которой написан и работает сам сайт. Иначе жди подобных сюрпризов.

Нужно сходить в старый хостинг и найти, какая версия языка установлена на сервере, где был раньше сайт. Разумеется, лучше сделать это ещё до переноса. На новом сервере в настройках сайта нужно установить ту же версию. Обычно это простые настройки в формате переключателей.

🔥💩👍