Вот это уточнение, как по мне - самое важное.
Ибо одно дело, когда ру-трафик, и ищут по наименованию на русском или англ - не суть важно. Или даже ищут перевод, как пример - сайты с переводами текстов песен - там все на одной странице и это правильно.
И другое дело, когда у вас довольно приличная часть ищет на другом языке - логичнее, что им будет выдана страница на их языке, а не мешанина.
Так что да, логичнее было бы сделать разные страницы под разноязычных пользователей.---------- Добавлено 28.07.2019 в 19:28 ----------
Так вроде неплохо, на мой взгляд. Может быть еще стоило бы вынести в отдельный поддомен, типа en.karoqs. Но, хотя бы для англоязычного пользователя уже будет хорошо - текст на его языке, а не мешанина.
VDS тоже является "DS" - выделенным сервером. Написали бы "дедик", было бы понятнее. Не ждите на общем форуме идеальных формулировок, пишите проще и вас будут лучше понимать. На то эти сокращения и нужны.
Разговор велся за качество хостера, потому, о каких бы услугах речь не шла: хостинг, виртуалка, дедик и даже колокейшн - вы все равно завязаны на то, какое качество услуг они предоставляют. Начиная от виртуального окружения и заканчивая обслуживанием физических серверов и коммуникаций. И потому не имеет серьезного значения, дедик это или виртуалка - выделенный сервер так или иначе завязан на работу хостера. Что в виртуалке может быть проблема, что физический дедик подсунут убитый, что в колокейшн поставите свое оборудование, но вам остальные коммуникации подведут через ж - вы всегда зависите от качества хостера. Так что, что бы вы не имели ввиду - это не панацея.
По хостингу - не замечал разницы, если скорость и качество работы сайта в норме. Теоретически, можно попасть на плохой ip, находящийся в спам-базах, но у меня где бы клиенты не хостились - явных проблем замечено не было. И так, чтобы перенесли сайт с хостинга на хостинг и вдруг стало хуже или лучше - тоже не замечал.
Может у кого есть иная практика - тоже было бы интересно послушать.
А вот https однозначно - влияет. После переезда наблюдается прирост с Яндекса. Одна беда - с Гугла проседает )) У всех по-разному, но влияние однозначно есть.
Скажем так, от хостера вы по-любому зависите. Просто это будет не хостинг, а виртуалка, к примеру, если конечно это не дедик. А виртуалка все равно работает в общем окружении и, зачастую, если хостер так себе, то это самое окружение может быть каким угодно. Не раз попадал уже так, что, к примеру, моя виртуалка значительно начинает тупить из-за того, что кто-то еще в этой ноде сильно нагружает контейнер. У нормального хостера такого быстро прижмут даже без жалоб, а у так себе - или надо сообщать, или даже с него по итогу переезжать.
Ну и опять же, если сайтов даже пусть 10, но у них трафика по 100 человек - то 5к на обслуживание этого всего при стоимости хостинга на тот же объем в 500 рублей - нецелесообразно.
Ну и по факту, на практике получается так, что абсолютно у всех хостеров бывают затупы и проблемы. Вопрос лишь только в том, как часто. Никакой тестовый период или отзывы не помогают, только долговременное использование покажет. Лучше, конечно, брать у тех, кто работает давно и меньше жалоб в инете или на профильных сайтах как этот серч, а дальше зависит от проекта и требований. Я для себя выбрал пару за многочисленные периоды и худо-бедно доволен.---------- Добавлено 27.07.2019 в 16:58 ----------
Так это может вопрос в нестабильности плагина, а не проблема с хостингом?
По сути еще раз указали кодировку базы.
Ну да ладно, главное, что нашли решение.
Перед CREATE TABLE IF NOT EXISTS ...
Будет
SET NAMES 'utf8'; CREATE TABLE IF NOT EXISTS ...
А, только там может быть по строке проблема с кавычками, тогда без них, просто
SET NAMES utf8; CREATE TABLE IF NOT EXISTS ...---------- Добавлено 26.07.2019 в 19:37 ----------Посмотрел, там для загрузки распарса другая команда:
$@ --local-infile=1 -e "USE $database; TRUNCATE $table; LOAD DATA LOCAL INFILE
Так что нужно в нее добавить names:
$@ --local-infile=1 -e "USE $database; TRUNCATE $table; SET NAMES utf8; LOAD DATA LOCAL INFILE ..
Попробуйте так изменить скрипт.---------- Добавлено 26.07.2019 в 19:42 ----------Ну и последнее, на самом деле импорт может быть проходит как положено. А вот выводится неверно. Часто на сайте для вывода используется указание этой же SET NAMES utf8; в сессии перед получением данных. Т.е. сначала открывается коннект к базе, затем указание кодировки, затем сам select данных.
Можно попробовать проверить кодировку файла, иногда сохраняется не в той. Ну и перед командой создания/импорта данных добавить команду, принудительно переводящую базу в работу с нужной кодировкой:
SET NAMES 'utf8';
Также можно для секции конфигурации прописать:
[mysqld]character_set_connection=utf8
и рестартануть мускуль.
В Яндексе - еще может и прокатит с использованием переезда. Он худо-бедно делает их нормально и не так болезненно относится к ссылочному, хотя это тоже имеет значение. А вот гугл - под вопросом. Как по мне - это вопрос рациональности. Вам очень-очень надо перенести на отдельный домен? Это важнее рисков потери позиций? Если да - переносите. Если можно оставить как есть - я бы не трогал.
Это чтобы уж наверняка? ) Если уж надумаете переносить - "редизайн" гарантированно надо отложить до тех пор, пока либо позиции не восстановятся, либо будет понятно, что они точно не восстановятся. А то потом будете в догадках, это редизайн все убил или переезд )
Полагаю, что директор не занималась бы фигней с добавлением вручную, если бы у нее был API/XML. Очевидно, что у них это действительно не автоматизировано. А распознаванием картинок никого не удивишь, было бы желание. Но, для малого кинотеатра это уже, возможно, излишества.
Яндекс же, вполне может получать данные из какой-то глобальной системы, куда вносятся сеансы или для отчетности или еще для чего. Но, думается мне, что даже если таковая система есть - ценник "входа" в нее будет слишком высок для того, чтобы из нее получать сеансы одного малого кинотеатра.
Тут вариант один - расспросить еще раз директора и, если она еще куда-то вбивала сеансы - пытать на предмет с кем там можно пообщаться. Если же она или новый директор скажут, что все ручками и локально - остается всего пару вариантов: Яша парсит картинки и распознает текст, либо это делает вручную кто-то из сотрудников. С их доходами это вполне имеет право на жизнь, посадить пользователя, который раз в сутки обходит сайты/паблики нескольких десятков кинотеатров и вручную корректирует сеансы.
Хотя, может кто еще напишет варианты или в курсе "изнутри". Если таковой найдется - у меня тоже пара вопросов есть )
Если у них ничего нет, то может Я.Афиша парсит их в ВК и преобразует в сеансы. Когда-то давно я по API ВК отлично получал посты нужной группы, а уж выбрать оттуда название-время - это дело чисто техническое.
Ну или найдите того, кто готов вам писать сеансы вручную и имеет всегда актуальную инфу, билетерша-кассирша какая-нибудь. Вопрос только в цене, ибо информация публичная сама по себе.
