Ну да. Судя по количеству файлов, там много всего, прям куча. Так что самое главное не переживайте, данные есть. Как минимум, загрузите в PMA, дампы-то обычные.
А техподдержка что говорит? Давали доступ?

Дмитрий, это пользователь облаков как раз
Т.е. аренды. Одним кликом "хостинг+установка системы+шаблон".
Так что надо делать скидку в общении, что это не веб-мастер, а пользователь

Елена, в административной части сайта, слева, внизу не появились такие пункты?
https://user.diafan.ru/userfiles/forum/imgs/6544_screenshot_11.png

Тогда зайдите в "Модули и БД" (это в админке, слева, в самом низу, где настройки) и проверьте, стоят ли галки напротив «Темы и дизайн» и «Файловый менеджер».

Кстати, зачем Вам эти модули? "Темы и дизайн" модуль чисто для импорта дизайна. А вместо файлового менеджера удобнее пользоваться FTP-клиентом в виде программы. Доступы на лицензии же есть у Вас.

А почему капсом?

Да, ветку "Облака Аренда" надо будет завести.

ftp-пользователь должен появиться в лицензии, в ЛК, на вопросике и "Информация о сайте".
Это если понадобится что-то доработать на сайте, перепрограммировать, алгоритм оформления заказов поменять в РНР Но не Вам лично! Так, может, какого веб-мастера наймете

это в "Дополнительные параметры" в каждом товаре.
Или через импорт.

Нет, не импорт/экспорт
Идёте в настройки магазина, вкладка "яндекс.маркет"
site.ru/admin/shop/config/
Там отмечаете параметр "Выгружать только помеченные товары".
После этого у товаров появится галка "Выгружать в Яндекс.маркет*.

А массово помечать из списка товаров можно макросом, вроде

Открываете firebug, или "проинспектировать элемент", или правая кнопка мыши в хроме и "Просмотр кода элемента". Затем лупой подводите к картинке и смотрите, где она лежит и какие у неё свойства и в каком файле css. И правите их.

Не надстройку, а платежный модуль, так правильнее.
Да, брать за образец любой модуль отсюда http://addons.diafan.ru/modules/platezhnye-moduli/, брать API RBK и впаивать

Может, недовыкачали? Или повредили как-то? Не правили никак его?
Качните заново. Если что, приложите в поддержку архив, разберемся

Ну мы шаблоны перепроверяем по несколько раз. И последним разом сами выкачиваем с аддонсов как пользователи и пробуем установить. Я сам десяток только на этой неделе установил без проблем.
А ТП что говорит?

Смотрите настройки post_max_size, max_upload_size и memory_limit.
Все три должны быть больше размера шаблона. Мегов по 10 хотя бы, т.к. большинство шаблонов в 4-5 мегов укладываются.

Это известный баг, или "особенность" пхпшной функции resize. Мы как-то сражались на одном сайте, обгуглились, но по-моему так и не победили. Там надо в ядро интерпретатора на хостинге лезть, вроде

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

Чтобы все в лицо этого дезинформатора посмотрели

Не метод, а библиотеку. Ну и не заменили, а добавили.
Была только GD, она медленновата. Ввели imagick

Я не передергивал, просто уточнил, чтобы у других была полная информация. Против Вас вообще ничего не имел в этом сообщении

Тип сидит в role_id.
Но там в таблице пользователей чисто номер типа.
И надо глянуть, что там в модельке, отбирается ли это поле в result

Глянули? Отбирается?

Да. Смотрите в этом файле, где отбираются поля. И для образца как раз ищите fio.
Где fio, password, name, phone отбирается - это как раз из таблицы пользователей.
Если там нет role_id, то надо по образу соседних добавить.

Я ж говорил
Если вышла цифра - это id типа пользователя. 1 - админ, 2 - модератор, 3 - покупатель (или какие там номера, я не помню, мышку подведите в админке к каждому). Чтобы выходило имя типа доступа, надо его в таблице users_role выдергивать.
Например, так:

Блин, нет. В $result["role_id"] сидит цифра!
Уф. Вот как объяснить?
Этот код только название типа доступа запишет в переменную $name_role - я её так, для примера назвал.
Чтобы это применить в моделе и вьюхе, надо назвать переменную так же, как и другие переменные. Я не помню навскидку, но там как везде, массив $result[""], готовящийся к передаче во вьюху.
Сначала добавляете к полям role_id. Потом эту role_id используете в запросе за именем, в query_result.
А вместо переменной $name_role пишете $result["name_role"], чтобы во вьюхе эту $result["name_role"] и вывести.
Хотя смотря как там принимающий массив называется, может $rowt["name_role"] она будет. Я не помню!
Тут работы на минуту, а писать все эти объяснения дольше!

Да это проблема давнишняя, от цмс не особо зависит. Вон, полно обсуждений

Мы в пакете ничего особо такого не меняли. Обычные корректные заголовки, 200 ок, last modify и пр..

У себя посмотрел в вебмастере на сайтах, нет такой проблемы.
Может, в сочетании с хостингом что-то получается?

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

Разбираемся

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

Хотя есть еще одна теория. Gzip вряд ли, ведь тогда весь сайт был бы проблемным, а так только некоторые страницы.
Кто может дать в службу поддержки свой сайт с фтп для анализа? Кто смелый?

Да не, экспериментов не будет. Только посмотреть, без воздействия.
Ведь только некоторые страницы с ошибкой.
А у нас точно нет каких-то особых заголовков для некоторых страниц. Может, сжатие некорректно работает из-за какого-то содержания страниц особого. Например, в карточке товара какой-нибудь особый баннер выводится, который некорректно сжимается. Или может BOM, который очень у многих фигурирует в шаблонах и вьюхах, мы уже рукой махнули каждый раз поправлять всех. Например, шаблон карточки товара отредактировали в обычном блокноте. В результате туда BOM записался. Скрипты не жалуются, так как BOM после заголовков выводится, а вот на content-lenght влияет. А при сжатии он учитывается/не учитывается. Или Яндекс его не видит/не считает за символ и по мнению яндекса там длина меньше. А сервер его видит и дает большую content-lenght. А может наоборот...
Прикол в том, что на всех сайтах, что делали мы, этих ошибок нет. А мы точно всё в UTFwithoutBOM пишем.
Так что надо смотреть.

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

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

Так что ждем

Так он правильный! Тут похоже дело не в том, что CMS неправильный заголовок отдает, а в том, что размер content-lenght ранее был другим, и при повторном обращении робота изменился!
Нам прислали в ТП с десяток сайтов с сотней примеров и страниц и мы все проанализировали. НЕТ разницы между исключенными страницами и неисключенными, НЕТ разницы между размером с сервера и размером отдаваемым заголовком! Всё идентично и корректно.
Исправлять-то нечего, нет локализованной проблемы. Мы не нашли ни одного сайта, где заголовок и реальный content-lenght с сервера отличался бы.
Проблема ведь в чем? В том, что "Яндекс выкинул некоторые страницы в панели вебмастера".Из-за чего? Из-за ошибки в алгоритме самого Яндекса, и Яндекс уже сказали, что они у себя эту ситуацию исправили. Мы на этот процесс никак не могли и не можем повлиять.