Массовое поражение интернет-магазинов на базе osCommerce и блогов WordPress
sacha_f

В догонку к предыдущей записи две новости уже на русском языке

В сети зафиксировано массовое поражение интернет-магазинов, построенных на базе свободной платформы osCommerce. События развиваются достаточно интенсивно, если 24 июля используя Google было выявлено около 90 тысяч страниц, содержащих вредоносные вставки, то 31 июля пораженных страниц было уже 3.8 миллиона, а 3 августа - 6.3 миллионов.

В процессе атаки эксплуатируется сразу несколько уязвимостей в различных выпусках osCommerce, позволяющих злоумышленнику внедрить свой JavaScript-код на страницы. В настоящий момент огромное число интернет магазинов продолжает оставаться на старых версиях платформы, но проблема касается не только их, например, среди используемых проблем безопасности упомянуты найденные 14 мая и 10 июля уязвимости, проявляющиеся в последней стабильной версии 2.3.1. Кроме того, в процессе атаки эксплуатируются еще как минимум три уязвимости в старой версии osCommerce 2.2, по прежнему активно используемой в сети.

Судя по анализу логов одного из взломанных интернет-магазинов атака производилась с нескольких украинских IP-адресов, код эксплоитов загружался с нескольких доменов в зоне "RU". После эксплуатации уязвимостей на страницы интернет-магазина внедряется несколько iframe-вставок и JavaScript-блоков с кодом для эксплуатации уязвимостей в клиентском ПО. Например, осуществляются попытки запуска вредоносного кода на машине клиента путем использования уязвимостей в Java, Adobe Reader, Windows Help Centre и Internet Explorer. На некоторые сайты, помимо изменения страниц, был внедрен бэкдор (web-shell), позволяющий организовать удаленный доступ к локальной файловой системе сервера и выполнение команд.

Другая угроза касается публикации информации об уязвимости в популярном дополнении Timthumb.php, используемом для изменения размера фотографий во многих визуальных темах к WordPress. Все темы WordPress, в состав которых входит Timthumb.php, подвержены опасной уязвимости, позволяющей злоумышленнику запустить свой PHP-код на сервере.

Проблема связана с тем, что при проверке домена с которого допускается загрузка фотографий используется оценка наличия маски в URL, т.е. злоумышленник может указать в качестве изображения адрес "http://blogger.com.somebadhackersite.com/badscript.php" и Timthumb.php загрузит его в кэш, который является поддиректорией в корневом каталоге WordPress, в которой в 99% случаях оставлены полномочия запуска PHP-скриптов. В дальнейшем, PHP-код может быть выполнен после прямого обращения к загруженному в кэш файлу.

Уязвимость устранена в SVN-репозитории проекта, но исправления реализовано в лоб, через регулярное выражение для проверки корректности URL. Проблема с загрузкой файлов в кэш, в котором возможно выполнение PHP-файлов, не рассмотрена. В качестве временного решения рекомендуется убрать из массива allowedSites, присутствующего в файле timthumb.php, упоминание возможности прямой загрузки файлов с внешних сервисов, таких как flickr.com, picasa.com, img.youtube.com, wordpress.com, blogger.com и upload.wikimedia.org. Если функции изменения размера изображений не используются, то рекомендуется удалить файл timthumb.php с сервера.

В сети уже зафиксированы факты успешной эксплуатации уязвимости и загрузки на сервер web-консоли "Alucar Shell". По предварительной оценке, основанной на выборке потенциально проблемных страниц через Google, уязвимости подвержено около 39 миллионов сайтов, использующих скрипт timthumb.php. Для взлома скрипт не обязательно должен быть задействован на сайте, достаточно наличия возможности прямого обращения к нему через web.

Источник: http://www.opennet.ru/opennews/art.shtml?num=31377

Уязвимости в osCommerce позволили взломать 5 млн страниц

Атака, мишенью которой стало популярное коммерческое онлайн приложение, инфицировала почти 5 миллионов страниц скриптами, совершавшими попытку установить вредоносную программу на компьютеры посетителей.

Массовая атака, в ходе которой взламывались сайты, использующие непропатченные версии osCommerce - приложения для управления онлайн-магазином – распространялась в течение прошлой недели. Когда исследователи из фирмы безопасности Armorize впервые обнаружили ее 24 июля, результаты поиска Google выдали, что инфицировано 91 000 веб-страниц. Во вторник те же результаты поиска показали, что эксплойт распространился почти на 5 миллионов страниц.

Согласно Armorize, атака эксплуатирует, по меньшей мере, три уязвимости в osCommerce, причем одна из них была обнаружена три недели назад. Уязвимости позволили злоумышленникам использовать украинские IP-адреса для внедрения iframes в уязвиммые веб-сайты. Iframes незаметно перенаправляет посетителей к вредоносным файлам, расположенным на willysy.com и exero.eu. Эти доменные имена, в свою очередь, направляют пользователей к сериям промежуточных сайтов, которые в конечном итоге пытаются эксплуатировать несколько уязвимостей Windows.

Посетители, которые не установили патчи, оказываются взломанными, обычно без каких-либо внешних признаков.

Видео, представленное ниже, демонстрирует атаку в действии.


На момент написания статьи, результаты поиска Google показывали, что 4.5 миллионов страниц инфицированы ссылками willysy.com и 415 000 страниц – посредством exero.eu iframe.

Источник: http://www.xakep.ru/post/56383/default.asp

OsCommerce: malware attack spreads to 5 million pages
sacha_f

An attack that targets a popular online commerce application has infected almost 5 million webpages with scripts that attempt to install malware on their visitors' computers.

The mass attack, which compromises websites running unpatched versions of the osCommerce store-management web application, has spread virally over the past week. When researchers from web security firm Armorize first discovered it on July 24, Google search results suggested just 91,000 webpages were infected. As of Tuesday, those same search results showed the exploit had spread to almost 5 million pages, сообщает The Register



"Яндекс" рассекретил покупки в интернет-магазинах Shop-Script
kocetkov
Источник

Вчера пресса сообщила об инциденте с "рассекречиванием" данных о покупателях некоторых интернет-магазинов. Собственно вот часть публикаций и это только начало:

http://hitech.newsru.com/article/25jul2011/shopolea 

http://www.argumenti.ru/incident/2011/07/117280 

http://lenta.ru/news/2011/07/25/eshops/

Всю ночь анализировал поисковую выдачу и собрав большую выбоку могу заявить следующее:

1. Львиная доля появившихся в поисковой выдаче заказов региональные.

2. Почти все представленные сайты сделаны на системе Shop-Script.

3. На всех сайтах стояла Яндекс.Метрика (несколько сайтов из сотни успели убрать, но в кэше выдачи остались).

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

А теперь механика произошедшего:

В Shop-Scripte есть встроенный сервис проверки статуса заказа. Статус можно посмотреть по прямой секретной ссылке, которая высылается покупателю и зайдя по ней можно увидеть статус заказа без авторизации. Такие письма вам могут присылать службы рассылки, другие магазины, какие угодно сервисы, допустим Фейсбук, да даже МойКруг самого Яндекса так делает.

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

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

Выводы:

  • правильность настройки robots.txt в данном случае спорна, т.к. Яндекс.Метрика собирает больше информации, чем публично задокументировано
  • в следующий раз может всплыть что угодно, счетчик Метрики вполне может видеть и передавать (!) любые ваши персональные данные, в т.ч. номера кредиток и прочего, не обязательно сознательно, злоумышленникам достаточно сформировать правильный запрос в поисковике
  • не меньшую угрозу представляет Яндекс.Бар вашего браузера
  • некоторые журналисты в желании опубликовать горяченькое проявили себя идиотами, не сильно от них отстали их "эксперты"

Примеры статусов заказов из Москвы.

Ответ саппорта SS:

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

 

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

<skip>

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

Для разработчика система очень сложная (иногда хочется биться головой об стенку). Там намешана целая куча технологий. Они даже Zend Framework умудрились использовать очень нестандартным путём, а уж с базой данных вообще без поллитра не разобраться.

Для пользователя всё не очень сложно, а для покупателя вообще всё прекрасно. Только разработчикам сложно :)

<skip>

Жрет ресурсы, платежные модули найти халявные сложно. нужно либо докупать, либо пистаь. Русская документация - это не проблема я понимаю, скорей сложность. для меня было хуже всего это ресурсоемкость даже для небольшой посещаемости ( 4000 -5000 уников )...

<skip>

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

Источник - дискуссия в facebook (ссылку не даю, т.к. она у каждого пользователя facebook она будет своя)






UMI.CMS. Частное мнение веб-разработчиика
cashavcev
Взято отсюда: "Независимый обзор UMI CMS", http://notes.bazarov.me/2011/%D0%BD%D0%B5%D0%B7%D0%B0%D0%B2%D0%B8%D1%81%D0%B8%D0%BC%D1%8B%D0%B9-%D0%BE%D0%B1%D0%B7%D0%BE%D1%80-umi-cms/

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

Начнем от печки:

Документация, демо и установка

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

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

Установка обычно не требует особых усилий, если не вылезают две традиционные ошибки UMI – первая это отказ завершать установку из-за якобы недействительного лицензионного ключа… В службе поддержки мне посоветовали установить систему на домен «без www»?

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

Более того, существует, незнаю есть ли сейчас, официальный список хостингов куда можно поставить UMI CMS. За остальные они не отвечают, 50/50 господа)

Интерфейс

Если же вам все таки повезло поставить движок перед вами открывается интерфейс администратора. Если бы не документация – я бы не разобрался никогда. Система состоит из модулей. Каждый из них добавляет новую функциональность в систему. Вроде все нормально. Иконки модулей, красуются сверху страницы. Первая мысль – с ними разберемся потом – где настройки сайта? Т.е. обычные во всех нормальных системах настройки названия, девизов, метатегов ну проч. что позволяет сделать сайт нашим. Их нет в обычном понимании. Потыкавшись с полчаса по страницам модулей, я обнаружил маленькую кнопочку в левом верхнем углу с названием «модули». Там можно найти все теже модули, и кнопку конфигурация. Вот оно! Нет. Изменить можно только то, что «очень нужно» изменять – а именно включить отключить капчу, ЧПУ, и размеры изображений.

Поясняю – по умолчанию система везде в названии сайта гордо пишет что это UMI CMS, а description – «umi CMS демо DEMO сайт система управление». Убрать эту красоту можно пройдя до вкладки «домены»(!), потом нажать «редактировать»(!!) напротив актуального домена и только там я нашел настройки префикса title, keywords и description.  О роскоши типа фавикона я молчу. Там же можно зачем то изменить язык на китайский и арабский… *facepalm*

Фонтан логики на этом не иссякает. Я продолжил искать кнопку «Добавить страницу» или что-то вроде того. Оказывается за это отвечает модуль «Структура», название которого больше подразумевает под собой что-то вроде таксономии или на худой конец меню. Для справки «Структура» – позиционируется как отдельный модуль, что подразумевает под собой дополнительные возможности, но никак не базовые функции.

Добавление материала

В меню структура я обнаружил наконец-то страницы сайта. Здесь рука художника прошлась кнопкам редактирования. Они неожиданно появляются в центре строки и представляют из себя тренажер на меткость клика. Я с непривычки первые разы несколько раз создавал какие-то копии страниц, выключал и включал их. Повысив меткость мы наконец-то попадаем на страницу добавления подстраницы. Здесь все вроде по человечески – можно назвать страницу и т.п.  Также можно добавить «псевдостатический адрес»-  это ЧПУ и они сурово набираются транслитом автоматически. То есть если не уследить и написать «Станок фрезерный трехмерный автоматический МТМ 45-12″ то ЭТО пойдет в название страницы на транслите (stanok_frezernyj_trehmernyj_avtomaticheskij_mtm_4512). Поле «псевдостатического» можно изменить, но не смейте после этого трогать название страницы иначе все скинется до первоначального состояния. Незнаю как всем но мне не нравятся ссылки размером с товарняк.

Название страницы надо писать самостоятельно. Иначе если вы так и не нашли где менять префикс title страниц система будет гордо напоминать о себе заголовком вида UMI.CMS -название страницы. (Как оказалось впоследствии – даже если изменить)

Далее следует текстовый редактор, который очень, очень похож на связку TinyMCE+TinyBrowser. Лично у меня были даже все глюки этой связки а именно:

  1. Не работала загрузка картинок на сервер
  2. Не работала вставка адреса картинки из браузера в поле вставки.

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

Шаблоны

Дизайн в UMI CMS это отдельная песня. Во первых поддерживается аж два типа: TPL и XSL. C первого взгляда неясно зачем, однако потом, когда по привычке уже собран шаблон TPL выясняется, что многоуровневое меню на TPL сделать нельзя! Переделываем.

Подключать шаблон нужно тоже очень хитро. Во первых он разделен на четыре части.

  1. Собственно шаблон-разметка
  2. CSS
  3. Меню
  4. Изображения

Все эти файлы нужно распихивать по четырем разным папкам находящимся «в разных зданиях на разных этажах». Изображения «images» я не нашел куда девать, поэтому просто положил в корень сайта, бог с ним бывает такое. Разметку надо затолкать в www/tpls/content, меню в www/tpls/content/menu, а css как совсем не трудно догадаться в www/css/cms(!). Будьте внимательны, ибо количество других папок в каждой подпапке over 9000. Также везде нужно прописать абсолютный адрес к картинкам вида «http://www.site.ru/images/image1.jpg», иначе на страницах второго уровня и ниже система потеряет пути к картинкам а в последствии и к шаблону вообще.

Это еще не все! После этого, надо зайти (нет, не в «Шаблоны данных» как может показаться) а цитирую «зайти в настройки модуля «Структура», вкладка «Шаблоны»», после этого приводится адрес (http://yourdomain.ru/admin/content/config/) там это можно найти. Навигация по админпанели в столь далекие края просто не идет.

Итак в открывшемся заповеднике нужно вручную прописать названия файлов ваших разметок. После чего, надо выбрать добавленный шаблон как основной, но(!), все ранее созданные страницы придется редактировать, устанавливая на них другой шаблон. Галочка «по умолчанию» отвечает только за новосозданные страницы. В общем вместо 1 минуты потраченной на заливку шаблона в папку, как в нормальных системах мы получаем настоящий квест.

SEO и статистика

Этот раздел находится здесь в основном из-за того, что в CMS встроена никому не известная программа под названием Site Auditor. Меня это поврегло в шок. Естественно она не работает. Нужно выделить место под кеш проги, но где это разрешать на серваке неясно. К тому же легче просто её скачать.

Статитстика движка порадовала своей красочностью и наглядностью, но на мой взгляд liveinternet проще и информативнее.

Быстродействие

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

Выводы

Возможно, товарищи, я аргхи тупой! Но я не понимаю зачем тратить столько денег на истинно русскую CMS. Все вроде есть, все вроде должно работать, но сделано настолько «правильно» что работает «по нашему». А вкрапления «зарубежного» софта, пришаманенного в админку умиляют.  Версия Lite стоит 3900 р, максимальный пакет Commerce (что как бы намекает нам на бесплатный osCommerce на базе которого сделан магазин (догадка))  стоит почти 30 000 рублей. Есть и бесплатная версия но лично мне этот шедевр даром не нужен, поскольку есть Drupal и, бог с вами, Joomla и ModX.

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

Поразительно.


Joomla
kocetkov
Источник темы: http://forum.searchengines.ru/showthread.php?t=596929&page=3

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

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

Всему причиной отрытый код системы и ее компонент, ошибки («дыры») в дополнительных и основных модулях. В защиту системы сказать нечего, есть огромная практика по разрешению уровня безопасности Joomla, есть форумы, есть патчи (заплатки) и главное все на русском языке. Взломать же сайт, не только теоретически, но и практически не состовляет большого труда. Задумайтесь прежде чем на ней запускать коммерческий проект. Еще одним недостатком, опять же по сведению статистов, стала скорость загрузки. Ваш покорный слуга тоже так сначала считал. Но вышла новая версия, скорость повысилась, но не на столько, чтоб сравнивать ее с другими CMS, так что вопрос отпадает.

Дело все в том, что скорость загрузки сайта зависит напрямую от нескольких факторов: нагрузки на сервер хостера, ширина канала данных (скорость трафика), скорость отборки из базы данных, скорость интерпретирования PHP кода. С конца: интерпретатор PHP один из самых быстрых в мире языков программирования, к нему претензий вряд ли может быть, но косяков в коде хватает, не говоря уж про закомментированный. Отборка из базы данных напрямую зависит от сервера, где находится база, разработчики же любой CMS всегда производят улучшения кода и в состоянии оптимизации запросов к базе данных (у совершенства нет предела). Вывод какой все факторы становятся решающими. Как Вы сами понимаете, на любом сервере одновременно могут обрабатываться сразу несколько потоков данных: кто-то закачивает с сервера файлы (а это могут быть как фильмы, так и мелкие экземпляры изображений), кто-то делает резервный архив сайта (по сути удаленная работа с сервером), а Вы в этот момент хотите просмотреть состояние Вашего заказа. Ширина канала и процессорное время в разное время сильно разнятся, тут уже надо исследовать ситуацию методом «научного тыка». Но многие показатели все же зависят от CMS, и то как она написана.

К примеру, один и тот же сайт размещался на трех разных площадках. После полного запуска каждого из них, в разное время проверялась скорость загрузки (для чистоты эксперимента временные данные, естественно, удалялись). Было сразу заметно какой из хостеров, а один из пробных был наш удаленный сервер, наиболее быстро отрабатывает. То есть Joomla реально тормозила, и чем больше данных она обрабатывала тем меньше пользователей получали отклик. При 1000 IP в сутки нормально но при 10000 виртуальный сервер так тормозил, что надо было реально переходить на выделенный. Причем заметно «на глаз», без использования дополнительных программ и чего бы то ни было. Знаете чем все закончилось? Через пару месяцев этот самый сервер существенно потерял в скорости. Менять месторасположение сайта необходимости не было, в дальнейшем добавили еще пару серверов и скорость вернулась в норму, но все же осадок остался. Меседж этого абзаца простой: хотите чтобы сайт быстро грузился, тогда поменьше обвеса и помощней хостер, а лучше свой сервер в хорошей гермозоне.

Разбираем косточки дальше. Недостаток продолжаются. Сайты на Joomla плохо индексируются и их не видят поисковики. Да, и это остается фактом, достаточно мало настроек под SEO существует в Joomlе, хотя они есть, не поспорить, только вот толку то от них. Оказывается тут и поработать надо, причем головой. Именно за то, чтобы сайт был известным, платятся деньги за его «раскрутку», оптимизацию и, наконец, внешнюю рекламу. Индивидуальные CMS заточенные под конкретный проект лучше может быть и не были когда то но время изменилось и Joomlе с эксклюзивной CMS ну никак не потягаться

Теперь разберем недостатки, которые оспорить нельзя, а то и вовсе невозможно. Joomla не может управлять несколькими сайтами одновременно. Так что новый сайт – новая CMS. Это же относится и к субдоменам. Построение шаблона дизайна в линейном режиме. То есть, если Вам захотелось разные дизайнерские решения разместить на разных типах страниц, то придется написать достаточно сложный код в самом шаблоне, что уж говорить о конкретной одной странице. Например, если тип страницы frontpage, то загрузить только вот этот код к примеру а не какой то другой, если content, то этот и так далее. Шаг в право или в лево расстрел, ничего работать не будет. Конечно, для программистов в большинстве случаев это не составит особого труда, но вот только проблема, найти того кто вам это будет делать. Чуть-чуть не вяжется с заявлениями, что Joomla – это самая простая CMS или, как говорят наши зарубежные друзья, CMS для домохозяек (представил себе такую домохозяйку с книгой по PHP5, половником и ребенком в руках на кухне , забавненько). Да и вообще, работа с дизайном сайта не лучший конек Joomla. Сюда же можно отнести и работу со стилями.

Несмотря на бесконечные возможности с присвоением каждой странице своего стиля и отличные встраиваемые редакторы, для изменения вывода приходится иногда перелопатить множество страниц кода, чтобы чуть-чуть подправить. Главное чтобы не задеть остальные странички (ведь дизайн тут линейный). Особо не радует использование стилей в дополнительных компонентах, иногда приходится переделывать все страницы вывода, затрагивая классы и функции. Отсюда, полная отсутствие обратной поддержки кода – при установки/обновлении системы можно больше навредить чем улучшить. Лучшее – враг хорошего.

http://deaction.com/uslugi/sistema_upravleniya_sajtom_joomla_cms_sozdanie_sajtov_na_joomla_cms/


Недостатки Joomla:

1. Слабая безопасность от взлома;

2. Есть некоторые недочёты в иерархии элементов движка. Например, теги H1, H2, H3 и т.д. располагаются не очень удобно;

3. В Joomla нельзя управлять одновременно несколькими сайтами. Для каждого нового веб-ресурса необходимо устанавливать отдельную CMS. Хотя для некоторых пользователей это может и не являться проблемой;

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

5. Медленная загрузка веб-страниц по сравнению с другими некоторыми CMS и тем более классическими сайтами. Вытекает из 4 пункта;

6. Отвратительная индексация поисковыми системами. Обусловлена сложной иерархией элементов и 4-м пунктом.


Я сливаю джумлу в унитаз, и начинаю знакомится с Друпалом. С джумлой я дружить точно не буду. Спасибо... Просто жалко потраченное время... Я уже думал приступать к созданию сайта... И обломался...

VamShop 1.61: никаких сдвигов в улучшении работы интернет-магазина не наблюдается
kocetkov
Источник: http://pf.sochi-2014.com/vamshop161 (и вообще, рекомендую: http://pf.sochi-2014.com/problems - обзор проблем PrestaShop, VamShop, ShopOS, OSC VAM STS, WebAsyst)

==============

Уже довольно давно наблюдаю за изменениями системы VamShop. Больше года назад отметил  замедленную работу магазина в простых, казалось бы, ситуациях.  Поддержка на основном форуме  по существу в этом вопросе ничем помочь не могла. После некоторых моих выступлений на эту тему  ситуация улучшилась. Это произошло в начале 2010 года с выходом версии 1.56.

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

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

Для экспериментов был использован магазин, в котором имеется 4 категории 1 уровня, в каждой их которых 4 подкатегории, содержащие также по 4 подкатегории. Таким образом, всего имеем 4 категории первого уровня, 16 категорий второго уровня, 64 категории третьго уровня.  В каждую категорию поместил 12 товаров.

Теперь помещаю товары в корзину и слежу за количеством запросов при формировании страницы.


  Корзина пуста В корзине - 1 товар В корзине - 5 товара В корзине - 10 товаров В корзине - 20 товаров
Главная страница 96(83) 112(92) 176(118) 256(155) 416(223)
Страница раздела 208(151) 224(158) 288(186) 368(221) 528(285)
Страница товара 116(91) 132(105) 196(133) 276(161) 436(238)
Корзина 82(69) 144(93) 322(122) 562(171) 1042(270)
Инфо страница 87(75) 103(83) 167(110) 247(146) 407(215)

 

О чем говорят полученные результаты? Четко видна тенденция: при увеличение товара в корзине число запросов растет примерно в арифметической прогрессии. А это есть первый признак неправильного (неграмотного) использования базы данных. Поскольку база данных для того и существует, чтобы скорость операций практически не зависела от объема  данных.

Вот недавно на форуме появилось сообщение пользователя о том, что у него браузер зависает при большом (несколько сотен) количестве товаров  в корзине.  Данные в приведенной таблице говорят о том, что на странице корзины при увеличении числа товаров  в корзине на  10 число запросов увеличивается на 480. То есть один товар в корзине прибавляет 48 запросов. При количестве товаров 800 единиц требуется порядка 40 000 запросов! Понятно, что такого не выдержит никакой даже самый продвинутый хостинг.

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

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

Некоторые пользователи пытаются находить свои пути решения. Вот, скажем, недавнее сообщение с предложением использовать  memcached. Очень даже стоящее предложение. А поддержка отвечает: "memcached по умолчанию ведь не везде есть".  Выходит, не боится отвечающий прослыть дилетантом, не знающим, что такие вопросы в скриптах давно уже решаются элементарно использованием условного оператора if.  И не возникает у него также мысль о том, что если  memcached компенсирует хотя бы частично тормоза его разработки, то пользователи уж как-нибудь позаботятся о том, чтобы его установить. Хотя бы сменой хостинга, как он раньше частенько советовал.  Увы, наблюдается полнейшее пренебрежение к насущным проблемам пользователей.

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

=================

Drupal5, сборка Ubercart для ИМ
cashavcev
Взято отсюда.

У меня был магазин на Друпале, так что могу поделиться опытом (пятая версия движка, сборка Ubercart).
Выбрала потому, что это была единственная (имхо) cms с большим количеством опций нужных опций, удобной админкой и понятной (имхо) логикой.
Плюсы:
Возможностей действительно много: импорт данных из прайсов, генератор отчетов + можно настроить отображение страниц, ссылок, калькулятор тарифов, вывод данных в XML, дополнительные теги + чпу и более-менее чистый код (чего не было в Джумле). На виртуальном хостинге (магазин + другие сайты) только раз было превышение лимитов, и то не из-за ИМ. Файлы перевода частично подгрузила, частично русифицировала сама (кое-что пришлось привести к единому виду).
Минусы:
Еесли нужна быстрая загрузка страниц - Друпал не подходит (кэширование не сработает для новых пользователей, а минификация java-скриптов, от которых я не могла отказаться из-за нужды в больших красивых картинках товара - процесс, хм, непростой). Если не хочется терять трафик из-за долгой загрузки - идите в webo.in, хотя бы ради бесплатного анализа. Это, имхо, жирнейший минус.
Другой минус - корзина. Пришлось сокращать число полей и этапов чекаута, а то каждый третий клиент не завершал заказ (замеры целей по Я.Метрике). Эпопею с калькулятором (с добавлением стоимости доставки и скидок) самостоятельно так и не завершила.
Не нравилась (существовавшая на тот момент) система управления внутренними баннерами.
К встроенному поиску пришлось прикрутить дополнительный скрипт + поработать с навигацией, т.к. собственный поиск Друпала был без морфологии.
Отслеживанием поведения посетителей из разных источников не занималась, тут ничего не скажу. Вообще, встроенная система аналитики жутко тормозила сайт (другой модуль, который пришлось отключить - генератор xml карты сайта). Но для 6 версии Друпала есть много новых модулей + можно найти сторонние решения.
Количество товаров было около 200, но имею контентный сайт на Друпале в несколько тыс. страниц... Все то же самое. Не думаю, что при 1000 позиций у вас появятся какие-то особенные проблемы.
Сейчас у меня двойственное отношение к Друпалу - с одной стороны, ИМ можно вывести по НЧ (и даже СЧ) только внутренней оптимизацией, с другой - ненавижу ждать пока страница загрузится (даже 2-3 секунды для меня много). Каково посетителям из регионов, боюсь даже представить.
Tags:

Битрикс - технологический спонсор. Шо, опять?!...
kocetkov
Когда весной был РИФ, на сайт РИФ'а зайти было невозможно. Он падал и тупил. Как раз раз в то время, когда Рыжиков в своем твиттере радостно сообщал, что все круто и быстро работает. А все остальные стонали - невозможно даже программу и схему проезда прочитать с сайта!

Премия Рунета. Битрикс снова технологический спонсор (звучит то как!). И что мы видим? Сколько не кешировали в хтмл, сколько ни оптимизировали и не закупали тонны железа - один хрен сайт тупил и открывался через раз.

Уважаемые организаторы конференций! Бойтесь Битрикса! Стоит ли сотрудничество с ним недоступности ваших сайтов и подпорченного имиджа? Да лучше взять тормозной друпал и воткнуть его на три мощных сервера, арендованных на месяц конференции. Это будет надежнее и стабильнее, чем сидеть и ждать - когда прокашляется снова и снова упавший сайт.

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

Минусы Shop Script
kocetkov
Из SE: http://forum.searchengines.ru/showthread.php?t=308744&page=54

1. Очень мало готовых шаблонов. Заказ нового в среднем 300-500$.
2. Нет складского учета товара - пожалуй для многих это будет огромнейший минус.
3. Встроенный дизайнер, посредственен.
4. Без каких либо навыков программирования сделать из него хороший магазин представляется мало возможным, готовьтесь к доп тратам.
5. Трудноват для самостоятельного изменения функционала или шаблона, т.к. имеет совсем не стандартную "архитектуру"

Указанный позже как плюс "Имея базовые навыки PHP и HTML и потратив несколько дней на изучение форумов, можно перелопатить стандартную тему до неузнаваемости, и изменить функционал" опротестован в минус:

6. "Лопатить" шопскрипт ~ 80-150$ отдай за доработку.

?

Log in