А в пароле есть что-нибудь нестандартное? Точки с запятой, слеши и т.п.. Может система при авторизации их вырезает. Я с нескольких учёток пробовал - всё работает.

Вы проверяйте что возвращают Ваши выражения. У Вас:
возвращает 9 (3+6), т.к. считает все пункты во всех списках с классами shopmenu_level_3. И Вы всегда получете выполнение условия >5.

У Вас не 1 элемент, у Вас набор. Нужно его весь обходить.

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

Инструкция по этой теме (тестирования и выявления) имеется.

Есть у Вас ссылка на CSS. Не там смотрите. Смотрите HTML. При этом чтобы видеть ясную картину, включите режим разработчика в админ-панели (раздел "Параметры сайта").

Вот ссылка на кэшированный файл CSS передо закрывающим тегом </head> :

В сжатии. Вынесите свой файл отдельно под основной, который show_css.
<link href="http://jang.su/custom/jang/css/styles.css" rel="stylesheet" type="text/css">

название из параметром тега show_css уберите.

Включите сжатие и проверьте. Если всё нормально. Создайте файл style2.css, добавьтье его в тему и в параметры show_css. И начните туда переносить постепенно код из style.css. Перенесённый код будет сжиматься, оставшийся нет. Когда перенесёт очередной сегмент и всё испортится - определите где загвоздка. Найти ошибку или выявить проблемный для сжатия участок уже не проблема. Он либо исправится в итоге, либо останется в несжимаемом файле, а всё остальное будет кэшироваться.

Обычно так советует делать сервис с сомнительной репутацией - Google Page Speed Insights.

Защищённый режим введен в обновлении 6.0.11.0 - "Защищенный режим работы CMS" (в логах изменений). Введён как раз для того, чтобы обновлённые сайты в случае несовместимости кастомизации с файлами обновления (а такое случается часто) не падали в ошибку полностью, а оставалась рабочей админ-панель. Это позволяет откатить обновление, поправить настройки, отключить проблемные дополнения и т.д..

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

Любое обновление с использованием кастомизации на сайте - это риск несовместимости и ошибок. Гарантия работы обновлений касается только файлов оригинального дистрибутива. В отношении любых пользовательских изменений - никакой гарантии. А этим очень часто пренебрегают как и архивными копиями перед обновлениями. И потом предъявляют претензии.

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

Вот как-то так.

Эту тему уже комментировали разработчики на форуме.

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

Да тут не важно в какой раз. Я по запарке иногда кеш в настройках забываю отключить и сбросить и сижу тестирую чего-нибудь минут 5, пока не вспомню. Лучше сразу писать что было сделано. Если ничего не описано, значит ничего не сделано, следовательно, нужно задать уточняющие вопросы.

А то Степан, например, написал сообщение об ошибке без подробностей. Вроде всё очевидно, а по факту - нет.

При обновлении (если недавно обновлялись) мог включиться безопасный режим.
Зайдите в "Параметры сайта" и проверьте - стоит ли галка внизу на "Включить защищенный режим работы CMS".

Если стоит - попробуйте отключить. Проверьте.

Также посмотрите в разделе "Темы и дизайн" созданные темы, названные по дате обновления custom_дата_время
Попробуйте их активировать.

Не факт что дело в этом, но методом исключения надо проверить все вероятности.

Отпишитесь - помогло или нет.

У гугла больше пунктов по микроразметке, чем у Яндекса, но они необязательны и не критичны. Проверьте в Яндексе. Если там нормально, то можно особо не обращать внимания.

Это субьективно. И это не ошибка.

А мне бы шрифт покрупнее. Мелкое всё. Но если что я сам себе настрою.

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

На странице пожелания в вишлисте (в общем списке отсутствует).

В вишлисте если отвечаешь в ленте на комменатрий, то он автоматически не добавляется, страница не обновляется. Обновляешь страницу - появляется сообщение и вместе с ним ошибка JS в консоли. До перезагрузки скрипты на странице не работают. Если редактировать добавленное ранее сообщение, то ошибка не повторяется. Только при первой отправке.

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

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

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

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

От кастомизации много чего зависит.

Просто - это к Степану за 1000р.

Каждому по тысяче и расходимся.

У человека стоит вопрос развести кого-нибудь на готовое решение в виде кода и скопировать его, а потом говна набросать на вентилятор, потому что оно не работает так, как нужно. Глянь его другие темы на форуме.

Ctrl+P не забудь. и поделиться.

А потом Яндекс выпустит новое поле и всё по-новой. У меня в голове давно зреет идея сделать поля для Яндекса кастомными. Нужно какое-то поле - добавил. Не нужно - удалил. Но руки до этого у меня пока не дошли. Может зимой будет времени побольше свободного - дойдут.

Ну не "Останкино" же )) Теперь ясно какой фразой Сергея вызывать, если что

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

Проблема в том, что часто ставят "Цена договорная", а когда до бюджета в переписке договоришься, выясняется что "Мы стартап, денег пока нет" или "Вы охренели, чего так дорого? За углом в 2 раза дешевле". Почему при этом в бизнес-плане стартапа не учтены расходы на тех.обслуживание или почему не берут за углом, непонятно. Наверное, потому что в первом случае нет бизнес-плана и он не планируется, а во-втором есть понимание, что за углом не только дешевле, но и хуже в 2 раза и хочется качество как тут, а цену как там. 9 из 10 таких диалогов заканчиваются ничем. Большинство заказчиков и исполнителей не заключают договоров.

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

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

Diafan, да, пельменная. И производит хорошие такие пельмени в упаковке, расфасованной по 1 кг. И реализует. А майонез там, приправы, соль, перец и т.д. - это уже не к производителям пельменей. Это всё покупается отдельно и готовится потом самостоятельно при наличии навыков и возможности или с привлечением тех, у кого есть навыки и возможность. Вы же, покупая пельмени, не звоните потом производителю в какой-нибудь Щёлковский мясо-перерабатывающий комплекс и не требуете прислать Вам повара или предоставить кухню для приготовления пельменей. Так и тут. Мы производим продукт. Он рабочий. А как его потом готовить и есть каждый сам решает.

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

Смотрите ограничения хостинга на размер файлов (в параметрах сайта на последних версиях выводится, также в настройках модуля "Каталог" во вкладке "Изображения" в самом низу) и права на папки, в частности /userfls.