Pull to refresh

Comments 30

Спасибо очень интересует информация про этот продукт…
>Первым делом отключаем cache в Magento,
или чистим var/cache

сколько о Magento не пиши, а все равно вопросов много ;)
Я бы сказал даже так:
«Первым делом отключаем cache в Magento И чистим var/cache»
Не соглашусь с отключение кеша — в этом случае достаточно сильно замедляется генерация страниц, а при разработке обычно приходится по многу раз перегружать страницы, что приводит к потери времени. Очистка кеша в освновном нужна, если были изменены xml-файлы, а при изменении php, phtml, css и т.д. кеш очищать не обязательно. Для быстрой очистки кеша так же можно написать скрипт (unix: rm -rf var/caсhe/*, windows: del /S /Q var\cache\*) и вызывать его по комбинации клавиш.
Статья хорошая, но вот после дискуссии о необходимости очистки кеша лично у меня «нарисовался» некий скептицизм.

При адекватном проектировании, продукт должен работать быстро и без кеша. А кеширование включают при повышенных нагрузках на сервер, либо при тяжёлой БД.
Да, вы совершенно правы — производительность в Magento это одно из самых узких мест ). Для этого, в боле-менее больших проектах её поднимают на кластерах (в облаках). Или специально-оптимизированные хостинги на производительных серверах для «небольших» проектов используют (memcache, eAccelerator и т.д.). На обычном VPS можно и не пытаться ).

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

Сам подход к проектированию CMS должен подразумевать, что необходимость кеша встает только при наличии «отягчающих обстоятельств». Будь то набег ботов, посещаемость 50000 в сутки либо магазин на 100000 товаров.

Брать за основу разработки ZF также не самое оптимальное решение. Да это ускорит разработку, но и налагает рад зависимостей от стороннего продукта. Что в конкретном случае, добавляет камень в огород ресурсоёмкости.

ZF отлично подходит для штучного продукта, который нужно сдать в срок и забыть про него, либо для очень узко направленной не изощрённой CMS.

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

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

Я не по наслышке знаю что значит разработка CMS и как может аукнуться в будущем любая мелочёвка.
1) Magento рассчитан в основном на крупные магазины. Например, poster.com, в базе которого находится более 200 тысяч продуктов или homedics.com

2) На самом деле Magento не вплотную завязан на Zend Framework. Начало разработки Magento начиналось в то время, когда ZF был на стадии первой версии. Поэтому часть логики была написана разработчиками Magento (это касалось контроллеров, роутинга и др.)
насколько я заметил, отключение кэша действует только для frontend. Админка всё равно кэшируется. В любом случае лучше чистить var/cache в ручную.
однако хорошо постарались в wiki, давно не проверял доки на официальном сайте. Раньше материалов по разработке там почти не было.
Это очень перспективный движок! Судя по описанию, разработчики под него будут стоить очень дорого.
Этот волнистый XML-конфиг так прикольно смотрится издалека :)
Если его повернуть на 90 градусов, то он будет совпадать с силуэтом рельефа за окном разработчика!
скажите, а насколько быстро работает эта cms? какая нагрузка на сервер в сравнении, например, с drupal?
Разработка идет стабильно, регулярно появляются новые версии. Нагрузка на сервер приличная.
а вы установите локально и сами всё ощутите ;) Нагрузка очень большая.
Название модуля не должно содержать символов подчеркивания.
Мой модуль будет называться Snowcore_Blog
Название модуля в данном случае «Blog», «Snowcore» выступает в роли неймспейса.
parent::_construct(); вызывать не нужно, так как в нем нет смысла :)

Как по мне, то статья получилась на 4ку, немного неудачное разбитие подачи информации, хотя видно, что автор старался и более-менее разобрался с мадженто :)

Из комментариев к этой части, удивило, что при частичном выкладывании автор попытался покрыть конфиг в большей степени c учетом напр frontend, но про частично описанную систему перевода в том же config забыл упомянуть

В Magento действительно получаются дорогостоящие операции по сборка xml (config, layout), и кеш по большому счету нужно чистить только при изменении xml файлов

Установка модуля (создание необходимых таблиц) происходит автоматически — при обращении к любой странице.

Если включен кеш и в нем лежит конфиг — этого не произойдет ;)
К сожалению не удалось дописать комментарий полностью :)
Также чувствуется копипаст, особенно в некоторых местах с
www.magentocommerce.com/wiki/custom_module_with_custom_database_table

P.S. А вообще приятно читать про детище, которому ты посвятил больше 2х лет :)
С удовольствием почитаю продолжение
Улыбнуло™ читать комментарии от человека, который проработал месяц и которого уволили :)
Не мне его судить, так как мы лично не знакомы. Я пришел через пол года открытия компании в Киеве и Magento была в очень сыром виде, даже не было публичного бэта релиза. Могу заверить, что в компании никогда не было текучки кадров, а тем более большого числа приходящих и уходящих разработчиков. Возможно под этим он подразумевал себя и своего друга, которого уволили вместе с ним.

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

А в целом, я доволен результатом :)

Если есть какие-то более конкретные вопросы — готов на них ответить
UFO just landed and posted this here
Да, есть такое. Но для начала нужно научиться создавать структуру самому, ручками :)
Sign up to leave a comment.

Articles