От куда угодно, если будет открыта такая возможность. Например, Вам понравился плагин-слайдер, а в нем дырка. Например, во время работы с базой данных Вы отдали ей содержимое, предварительно его не проверив. Например, любительски работаете с содержимом $_POST или $_GET. Да тонна вариантов. Например, используя особенности работы SQL можно легко сделать двойника учетной записи администратора. Чтобы этого не случилось, надо следить за длиной передаваемой информации. Если честно, то даже неймется рассказать как сделать двойника, но не буду (здесь же не пакостники собрались).
Так же не стоит забывать об уязвимостях хоста. Например, есть, старый как мир, прием, использующий всем Вам известный .htacces. Или использовать уязвимость связки PHP+nginx с кривым конфигом. Т.е. если попросить у сервера отдать site.ru/img.gif/crack.php, то URI примет вид img.gif/crack.php, что подойдёт под location .php$, а SCRIPT_FILENAME станет равным /scripts/img.gif/crack.php. Скажу прямо, эти дырки в нормальных хостингах закрыты, поэтому их и привел в пример.

Таким образом - сюрприз можно ожидать от куда угодно, была бы фантазия и желание.

Содержимое вредоносного кода под название Troj/JSRedir-MN у Вас на хосте не должно быть.

Если у Вас на хосте чудно настроены права пользователя от имени которого работает web-server (например, apache), то может (есть и другие варианты).

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

Надо определить время изменения инфицированных файлов, которые Вы нашли. Далее смотреть логи сервера, ориентируясь на время вредоносного изменения. Цель - понять где дырка. Залатав дырку, можно тратить время на чистку последствий инфицирования.
Если все это тяжело для Вас, то, как вариант:
Берете резервные копии сайтов, в которых нет вредоносного кода и размещаете их под разными учетными записями на нормальном известном коммерческом хостинге. При размещении сайтов проверяете в базе данных, нет ли посторонних записей (нет ли лишней учетной записи с правами админа). Потом ждете появление вредоносного кода. Если такой код у всех сайтов появился, значит ищете в своих сайтах одинаковые вещи и анализируете их. Если код появился только в одном сайте или в нескольких, но не во все, то ищете разницу и анализируете ее. Ну а если заражений не появиться, то можете временно успокоиться.

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

Успехов.

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

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

Мои желания реализовали: cms.diafan становится лучше с каждым обновлением.

Александр, на мой взгляд в Ваших исходных данных нет конкретики. Вы php или js код имеете ввиду и в каком контексте?
Если php, то Если js, то
Успехов.

Смотря где и в каком контексте. Например в дефолтном cms, в shop.view.id.php

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

Полагаю, что у Вас доработанная механика сайта, которая стала работать некорректно при появлении новых характеристик. Поэтому в слепую вряд ли кто-либо ответит Вам. Да и на вскидку тоже не получится. Надо будет вникать в алгоритм. Скорее всего нужно править java-скрипты (скорее всего в shop.buy_form.js). Полагаю, что лучшем решением было бы, если Вы обратились бы к разработчику данной доработки сайта или к другому специалисту, который Вас больше устраивает.

В документации все уже рассказали:
1. Как добавить шаблонный тег.
2. Как получить свободные данные из БД и вывести их
3. Структура модуля Фотогалерея в Базе данных
Как-то так. Успехов.

Наверно правильнее Ваш вопрос звучал бы так:
а какая информация экспортируется, если воспользоваться в административной части сайта, в разделе "Модули и БД", в закладке "Экспорт/импорт Базы данных" пунктом "Экспорт базы данных", так как при таком экспорте мы увидим, что экспортировались не все имеющиеся таблицы базы данных?
Я правильно скорректировал Ваш вопрос? :)

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

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

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

Как-то так.

Согласен, что мне нужно вникнуть в это дело. Постараюсь на днях сделать это.
Как предложение - может быть было бы не плохо, если в административной части сайта в разделе Импорт/Экспорт базы данных появилась бы чуть более подробная фраза о том, что выгрузка идет за исключением того-то. Так как такую выгрузку можно понимать неоднозначно. Ну - нет, так - нет.

Смотрите java-script, ошибка там. Кроме телефона сейчас ничего нет, поэтому ничего более сказать сейчас не могу.

Денис, безусловно шаблон. Но во время загрузки появляется html, в том числе сгенерированный в php. А далее работает java-script (так же ajax, socket и т.п.). Но в данном случае возможно (не могу проверить сейчас) некорректно работает js-отработка события hover или аналогичного события. Опять же, возможно, у товара несколько цен, а скрипт должен оставлять из всех только нужную цену. Вот в нем и ошибка.
Как-то так.

Так это при загрузки страницы? Тогда выставите тегам style="display: none;" или style="opacity: 0;", а после загрузки страницы js-скирптом снимите эти метки в нужных местах. Вот и все. :)

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

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

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

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

А по уму все же надо предметно тратить время и смотреть, где "накосячено", т.к. такого поведения не должно быть.

Я всегда согласен с Вами, Виталий (DIAFAN.CMS), но добавлю, что еще потребуется отменить у скриптов асинхронность.

Елена, обратитесь к специалистам и все решиться. Иначе нужно кучу времени тратить, чтобы объяснить так, чтобы Вы поняли.
Да, не воспринимайте то, что Вам необходимо долго объяснять, как оскорбление, просто в этом деле одно зависит от другого. Поэтому объяснять действительно долго, а свободного времени катострофично не хватает.
Успехов.

Обратитесь к администратору хостинга. Предоставьте ему сертификат, он все сделает.

Для этого необходимо воспользоваться уже готовыми функциями модуля search. Эти функции все сделают, т.е. нужно просто их инициализировать.

Вопрос: исходя из логики cms или персонально Вашей фантазии? Если опираться на фантазию, то слишком много вариантов. А если исходить из логики diafan.cms, то второй вопрос: где, в административной части или в пользовательской части? В cms хоть и похожие методы, но все же разные.

Ну да, согласен на все 100%, поддерживаю коллега. Только далее Вас не понял. Поясню в чем не понял Вас, ГОРОПАШНЫЙ СТЕПАН (STEPANYCH). Уточняющий Ваш вопрос уже не имел смысла, после ответа коллеги - ПАВЕЛ (PLAHA).

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

ПАВЕЛ (PLAHA), если честно, то долго объяснять как было бы правильно (я имею ввиду правильно - это значит в духе diafan.cms). Если кратко, то при сохранении поля идет проверка на валидность, функция валидности (которую мы заранее подготовили) вернет ошибку. Эту ошибку пихаем в $this->diafan->set_error(ключ, текст). Далее скрипт автоматом сделает то, что нужно: в нужном месте появиться соответствующее сообщение, которое пояснит пользователю, почему не сохранена страница.

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

Если кратко, то все.

Успехов, коллега.

Вы куда-то не туда копируете архив.

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

Скорее всего ввели не корректные параметры. Посмотрите внимательнее на вводимые параметры.

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

Виталий (DIAFAN.CMS) TLS используется в процессе шифрования (я сказал бы, что это продолжение развития SSL), а Сбербанк, скорее всего воспринимает только его. Кстати, это распространенная фишка и используется во многих вещах. Добавить разрешение для TLS на сервере - это минутное дело. При этом необходима для Сбербанка не любая версия TLS, а именно TLS1.2. Это важно.