29 апреля 2008 в 9:40
Хочу сделать большой проект вроде сайта объявлений с рассчетной посещаемстью 5000 в сутки.
С Drupal разобрался сделал уже что-то похожее.
Теперь обратил внимание на Bitrix 6.5 и возник вопрос : Может сделать на Битрикс?
1. Битрикс вроде позволяет сделать все тоже, что и друпал с модулями:
- создавать свои типы данных,
- веб-формы
- разграничивать права доступа
- теги таксономии
- мультиязычность
- форум нормальный
- подписка
2. Вроде как в битриксе это все уже отлажено, русифицированно и собрано вместе
3. Русская поддержка и справочные материаллы.
4. Больше специаллистов по Битрикс
5. Минус - Битрикс и модули платные
6. Меньше модулей ?
7. Производительность - неизвестна
Кто имел дело с Битриксом - оставьте свои отзывы пожалуйста.
Комментарии
Противоречий не находишь вот в этих своих высказываниях?
По моему тебе просто занятся нечем.
Совет: Забей!
Сейчас начнутся холивары
У Битрикса нет дополнительных модулей, есть определенные редакции (в одной 5 модулей, в другой 11) и ВСЕ. Дополнительных модулей докупить нельзя. Нужные другие модули - переходи на другую редакцию, естественно за денюжку.
Форум в Битриксе, да и в Дрюпале оставляет желать лучшего. Если нужен форум, лучше использовать сторонние разработки (Инвижен например).
Поддержка и материалы конечно есть, но разбираться в них порой черт ногу сломит, хотя если поработать подольше на Битриксе, то сможешь хорошо ориентироваться в их документации.
Я бы так не сказал. Специалисты конечно есть, и есть даже очень хорошие, но порой даже сама Техподдержка не в состоянии решить некоторые твои задачи и просит почитать документацию. А, что конкретно в ней читать тебе могут сказать очень смутно.
И еще по поводу модулей. Модули по функциональности (особенно Информационные блоки) очень многофункциональные, но под свои задачи тебе придется покарпеть и попеределывать их. На Битриксе можно сделать фактически все, что угодно (посомтри хотя бы примеры работ на Битриксе), но на Дрюпале я видел сайты ничуть не хуже и ни капли не уступающие по функционалу.
Тут у тебя могут возникнуть проблемы как на Битриксе, так и на Дрюпале, а может и не возникнуть :). Тут все будет зависеть от твоего хостера и от тонкой настройки как одной, так и другой системы.
P.S.: своим клиентам я ставлю Битрикс.Старт (мне и этой редакции по функциональности вполне хватает). Для своих некоммерческих проектов я выбираю Дрюпал. И меня устраивают обе системы, хотя конечно к обеим сторонам есть нарекания
P.P.S.: думаю, что тебе одинаково подойдут и Битрикс и Дрюпал. Но в любом случае тебе много придется переделывать и настраивать. Тут скорее будет решать только денежный вопрос.
То есть вообще нету? Зря они в Битриксе этот момент упустили - могли бы еще денег срубить. И людям проще было бы.
А как вБитриксе происходит переделка модуля? Как хак или как хук в Друпале?
То есть проблемно потом обновляться или нет?
4. Больше специаллистов по Битрикс
5. Минус - Битрикс и модули платные
Вот два ключевых момента. Определись с тем кто будет поддерживать сайт, сколько ты готов выложить за поддержку и попробуй найти спеца по одной и второй CMS, а там уже видно будет, что лучше.
Хотя я, разумеется, сделал бы проект на Друпале
По Drupal я уже сам почти спец, но замучился делать все сам, а спеца по Drupal в нашем городе на постоянку не найдешь.
По стоимости: если посчитать сколько работы нужно для того, чтобы из Drupal сделать Bitriх (установить модули, полностью русифицировать, настроить чтоб все вместе работало), то я думаю стоимость Bitrix и выйдет (по крайней мере стоимость по партнерской программе).
Имеем основной сайт на БУС и рядок дополнительных сервисов, сделанных по сути для себя, на Друпале. Вот таки что имею сказать: если речь идет о реально большом проекте, то Drupal таки не очень подходит. Точнее сказать, теоретически все в нем есть, но объем допиливаний, доделок и докруток зашкалит за все разумные рамки. Скажем, нормальной подсистемы рекламы в Drupal нет (в БУС она тоже не идеальная, но для продакшн более подходит). Нормальной статистике для Drupal по-моему вообще не существует. Идея хранить кэш в БД выглядит зело странной. Рисовать разноформатные странички в Друпале муторно, а уж объединять на одной странице разные виды контента... Не, все решаемо, все можно сделать, но -- приходится заниматься вещами, в общем, далекими от прикладных задач. В полной обвязке (с CCK, Views и прочим добром) Drupal не сильно легче Битрикса, с большими базами (нод так тысяч на сто живет сложно). Ну и так далее, вроде все мелочи -- но наступаешь постоянно.
В Битриксе многое уже решено, да и вообще система более вылизана и интегрирована между собой. Там другой гемморой: представления юзера о том, как должен работать тот или иной компонент часто радикально расходятся с представлениями разработчиков. Самый вопиющий пример: модуль "Фотогалерея 2.0", весь такий вебдванольненький, но... не умеющий класть галереи по правам юзеров, в итоге один юзер может грохнуть/отредактировать _все_ галереи. Плюс чисто программерская привычка делать "универсально", в свое время мы долго просили: сделайте фичу "показать в день не более N тыс. показов заданного баннера". В итоге они "сделали удобнее и универсальнее", сваяв режим "равномерная открутка", когда система сама типа рассчитывает количество баннеров и сама распределяет количество по дням. Оно хорошо, только вот делает она это плохо, неточно и глючно. А простейшее ограничение проблему решило бы в корне.
С точки зрения разработки, "Битрикс" все же поприятнее. Есть API, вполне разумный, стабильный, автообновление (почти гарантированно не мешающее жить, в отличие от Drupal'ского), развитая подсистема "событий", AJAXы и все такое. Система шаблонизации существенно мощнее. Но въезжать тут надо довольно долго тоже, зато потом 99% фукнциональности можно загнать в комплексные компоненты и жить спокойно.
А можно пожалуйста поподробнее про комплексные компоненты или указанее где почитать.
И насколько сложно разрабатывать свои модули?
И сложно ли обновляться после внесения изменений?
Вот документация http://www.1c-bitrix.ru/help/
насколько сложно зависит от уровня владения пхп
*жрет попкорн*
Раньше мне нравился Битрикс хорошей тех поддержкой, я всем говорил, что половино стоимости Битрикса - это тех поддержка. Сейчас там при любом удобном случае отправляют решать вопросы с партнерами, а партнеры в свою очередь денег не хило.
Еще минусы Битрикса:
- Тормознутость (использую пакет бизнес, хостинг мастерхост тариф "Битрикс")
- запутанность и порой не логичность в интерфейсе.
- не гибкость в переносе материалов. например: создаем материал в одном инфоблоке, а в соседний инфоблок хрен перекинешь, только копи пастом либо импорт.экспорт экселем.
- модули не гибкие, в друпале с этим лучше.
- сообщество битрикса. помогают с неохотой либо за деньги, в этом плане Друпал выигрывает (пользуясь случаем хочу поблагодарить участников друпал.ру)
- с битриксом лучше не связываться тем, кто не особый специалист в PHP потому как если захочется немного не стандартных задач, нужно лезьт в код
- о минусах можно говорить еще бесконечно, но думаю и так всем понятно...
Плюсы Битрикса:
- Шаблонизатор действительно удобный.
других плюсов не нашел...
Я с битриксом пока еще не связался, и пока не все понятно, может почитать о плюсах и минусах где-то можно?
>Я с битриксом пока еще не связался, и пока не все понятно, может почитать о плюсах и минусах где-то можно?
Для исходной задачи топикстартера Битрикса многовато.
Ну не совсем "сайт объявлений" - чуть покруче
>- Тормознутость (использую пакет бизнес, хостинг мастерхост тариф "Битрикс")
А, это да. Битрикс - -по определоению == дедик. (А про Матсерхостский тариф для него я промолчу, в здешнем фильтре мата столько слов небось нет)
>- запутанность и порой не логичность в интерфейсе.
Ага, но "они работают". Правда, выражается это в том, что они рванулись вместо исправления реальных проблем рисовать кнопки "Старт" в админке и AJAX туда совать. Тут согласен.
>- не гибкость в переносе материалов. например: создаем материал в одном инфоблоке, а в соседний инфоблок хрен перекинешь, только копи пастом либо
>импорт.экспорт экселем.
Тут есть причина: структура может быть разная. Вот более серьезное: невозможность reuse свойств, это если в CCK поле задал, то потом его хоть в стаю типах материала юзай. В "Битриксе" не так, там все строго загнано в рамки инфоблока.
>- модули не гибкие, в друпале с этим лучше.
Ммм... Один хрен.
>- сообщество битрикса. помогают с неохотой либо за деньги, в этом плане Друпал выигрывает (пользуясь случаем хочу поблагодарить участников друпал.ру)
Да, есть такое.
>- с битриксом лучше не связываться тем, кто не особый специалист в PHP потому как если захочется немного не стандартных задач, нужно лезьт в код
Факт. "Битрикс" следует приобретать в комплекте с разработчиком (не считая дедика
>- о минусах можно говорить еще бесконечно, но думаю и так всем понятно...
Скажем, чтобы сделать хитрую систему фильтров материалов по параметрам в Друпале придется нехило напрячься с Views или ваять руками кастомный модуль. В БУС это делается влет стандартными API, или вообще без оного.
Плюсы тоже есть
Нашел по теме:
http://ru-mambo.ru/smf/index.php?action=printpage;topic=10582.0
http://www.habrahabr.ru/blog/bitrix/24777.html
http://life.screenshots.ru/the-code-inside/vnutri-koda/bitrix-vvedenie/
С обновлениями там проблем нет. Обновления проходят намного приятнее, чем в Дрюпале.
Для переделки модуля ты его копируешь, обзываешь по своему и переделываешь как твоей душе угодно. Т.е. у тебя фактически может оказаться 2 модуля - один стандартный и один твой.
ТС, почитай www.1c-bitrix.ru. Там достаточно инфы, для понимания, что такое Битрикс и с чем его едят.
У меня наоборот, техподдержка раньше вызывало не очень приятное впечатление. После того, как я им за ответы начал ставить оценки "недостаточно полно" и "ответ не устраивает", она стала очень даже отзывчивой и направлять за решением поставленной задачи именно туда, куда нужно (хотя это может и случайность, но сейчас она мне больше помогает, чем раньше).
Кэширование и модуль Компресия часто помогают. Про тариф на мастерхосте тоже слышал много нехорошего, наверно поэтому они его сейчас прикрыли на модернизацию.
Не соглашусь. Порой сложно в них разобраться, но один модуль Инфоблоки может с лихвой заменить несколько Дрюпаловских.
Я не особый специалист и приходиться решать много нестандартных задач. Долблю техподдержку, курю документацию, пробую попрой тыкать пальцем в
коднебо, но задачи свои решаю.Я сразу знал, что начнутся холивары
Если эту тему поднять на форуме Битрикса, думаю там мнение будет однозначное - БИТРИКС. Тут, мне кажется, люди полояльнее.
Хотя это как проблема отцов и детей - она вечна. Нет ни одной идеальной цмс. Кому-то нравиться одна, кому-то больше подходит другая, третьи вообще пользуются самописными.
ТС, я думаю инфы и мнений тебе достаточно, так что прикидывай, что для твоих задач и возможностей подойдет больше.
Спасибо за подробные объяснения.
*откупорил пиво и покосился на плакатик с каплей в центре... "мы своих не бросаем."*
Лирическое замечание.
Рациональность использования в Drupal всякого рода "утяжелителей" (Views, CCK, Devel и т.д.) вызывает определенные сомнения. В большинстве случаев проще, надежнее и просто правильнее разработать модуль решающий частную проблему в соответствии с текущей необходимостью, чем полагаться на "чужой" громозкий код, который заведомо имеет ошибки. Более того, Drupal вообщем и следует рассматривать в качестве платформы для серьезной разработки (подразумеваются виду опытные специалисты), а "сделаем это по-быстрому" позволяют Joumla и ее платные аналоги (визитки, магазины и прочие "шаблонные" проекты).
Для моих скромных задач "Рациональность использования в Drupal всякого рода "утяжелителей" (Views, CCK и т.д.)" сомнений не вызывает.
>Рациональность использования в Drupal всякого рода "утяжелителей" (Views, CCK, Devel и т.д.) вызывает определенные сомнения.
Избавляет от велосипедописания. На самом деле, разумно использовать тот же Views на прототипном серваке, если вдруг выяснилось, что он стал мегапопулярным и народ попер, проще вообще кастомную систему сваять уже
Позвольте не согласится.
"Чужой, громоздкий код" отрабатывается месяцами, тестируются баги, предлагаются решения и эти решения опять тестируются. Так что багов там заведомо меньше чем в вашем коде. А вот если вы пишете свой модуль и еще в добавок НЕ ВЫКЛАДЫВАЕТЕ его в репозиторий, то вы являетесь создателем вашего личного програмного обеспечения, и никто и ни что не сможет вам помочь при возникновении проблем.
А вот если вы выложите ваш модуль и его хорошенько потестируют, вот тогда и будет вам щастье в вашем проекте.
В этом то и сила сообщества.
>> Для моих скромных задач "Рациональность использования в Drupal всякого рода "утяжелителей" (Views, CCK и т.д.)" сомнений не вызывает.
Бог в помощь. Только это было отстраненное замечание.
Развитие Drupal осуществляется в рамках одновременно двух парадигм: юзабилити и конечный функционал; api (технологическая платформа), постепенно "сваливаясь" в сторону юзабилити.
Первое направление, вообщем, следует признать, тупиковым (любая коммерческая cms изначально создается с акцентом на юзабилити и проработку набора наиболее часто употребимых web компонентов). Однако, отказаться от развития в нельзя по понятной причине: "популярно то, что красиво и понятно".
Вторая парадигма представляется более конкурентноспособной по той причине, что в ее основание положен труд многих энтузиастов. Ценность вклада которых совсем не в том, что они разрабатывают "удобненькие" модули, а в постоянной модернизации платформы и пополнении базы знаний. Каждый модуль - знание (или решение), которое может быть использовано любым другим разработчиком в качестве базиса для получения новых знаний.
Безусловно, в ситуации выбора - "платформа или решение" - определяющим фактором является характер решаемой задачи. Однако, не стоит забывать, что под "решение" всегда нужно подстраиваться, тогда как платформа - "глина" или высокодетализированный конструктор. Конечно, определенным объемом знаний нужно обладать в любом случае. Но если последний случай неизбежно приводит к порождению новых знаний, то первый только к рецептированию способов использования, превращая разработчика среды по сути в оператора некого программного комплекса.
ps. Вычитку не проводил. Всего доброго.
Написано сложно, но правильно
Если эту тему поднять на форуме Битрикса, думаю там мнение будет однозначное - БИТРИКС.
вовсе не обязательно - там многие про друпал не знают, как узнают - на него и перейдут.
Попробуй s.builder.
(http://www.sbuilder.ru/)
Можешь выслать ТЗ. Ответят мона сделать или нет.
Не читал все. Но битрикс не люблю
Кстати разработчики очень приятные
>> Позвольте не согласится.
"Чужой, громоздкий код" отрабатывается месяцами, тестируются баги, предлагаются решения и эти решения опять тестируются. Так что багов там заведомо меньше чем в вашем коде. А вот если вы пишете свой модуль и еще в добавок НЕ ВЫКЛАДЫВАЕТЕ его в репозиторий, то вы являетесь создателем вашего личного програмного обеспечения, и никто и ни что не сможет вам помочь при возникновении проблем.
А вот если вы выложите ваш модуль и его хорошенько потестируют, вот тогда и будет вам щастье в вашем проекте.
В этом то и сила сообщества.
Конечно Вы в праве не соглашаться.
Мною был предложен взгляд разработчика, а не оператора/администратора компонентов. Да и речь шла вовсе не о тех модулях, которые "гиперуниверсальны" и являют по сути законченный продукт - приложение. А о частных решениях в рамках совершенно определенного проекта (решениях прикладного характера). Крайне сомнительно, что оторванные от проекта в виде самостоятельных модулей они могут представлять какую-либо особенную ценность.
Небольшой модуль, который создает блок в соответствии с определенными запросами проекта (sql-запрос и формат вывода данных) разработать гораздо быстрее, чем разбираться во Views и ССК (хотя из любопытства это наверное следует сделать). Но стоит ли дельться с сообществом разработкой, являющей решение, которое достижимо Views. Конечно заявление "разработать гораздо быстрее" предполагает наличия такой малости как умение и желание "писать" (программировать) и знания api Drupal. Для тех же кто "неофит", "не умею", "давай сделаем это по быстрому" или просто жаждет мнения сообщества о "своих ошибках в своем коде" прямая дорога в репозитарий за универсальными решениями.
Тирады про "баги", "проблемы", "тестирование", "щастье" опустим - дилетантизм.
да блоки без виевса делаются элементарно - sql язык это нативный язык запросов - тот же виевс но не птичками а буковками, но гораздо приятнее нечто законченное в комплексе делать это через виевс ) плюс в нем и кеширование некоторое есть - так что не факт что быстрее.
Ребята, вы знаете, я обожаю view. С ним работаешь как с пластилином, захотел вылепил птичку, захотел - кошечку. Мммм..... Лепота.
Это учитывая, что с помощью "аргумент хендлин код" можно один и тот же вид перелепить вообще по разному, хош списком, хош таблицей, ну там фильтры и все прочее тоже. См. тут: http://drupal.ru/node/9250
А вот с языком SQL я не очень дружу, фактически даже трех джоинтов связать не могу. Вот это для меня ИСТИННОЕ мучение.
Нет, уж лучше views, тем более там кеширование есть.
Ребята, вы знаете, я обожаю view. С ним работаешь как с пластилином, захотел вылепил птичку, захотел - кошечку. Мммм..... Лепота.
+1000 )))
еще бы с аргументами разобраться )))
Аргументы это те же фильтры, только передаются они через адресную строку.
>>"Рациональность использования в Drupal всякого рода "утяжелителей" (Views, CCK и т.д.)"
Не соглашусь с этим высказыванием! Почему вы считаете их "утяжелителями"? views весьма грамотно строит запросы к базе (не всегда конечно), но обычно это намного "легковеснее" нежели стандартная система загрузки каждой ноды!
>>"Рациональность использования в Drupal всякого рода "утяжелителей" (Views, CCK и т.д.)"
Не соглашусь с этим высказыванием! Почему вы считаете их "утяжелителями"? views весьма грамотно строит запросы к базе (не всегда конечно), но обычно это намного "легковеснее" нежели стандартная система загрузки каждой ноды!
Уважаемые коллеги! Складывается впечатление, что кроме цитируемых вами слов в моих сообщениях более ни чего и не было. А ведь ключевые слова - "вызывает сомнения". Что по своей сути своей является не императивом (утверждением категорического характера), а критической мыслью (размышлением). Которая (мысль) была поводом для решения вопроса "кто я есть программист или оператор?". В качестве основного постулата выступало заявление, что оторванность от знания платформы в последствиях будет иметь ограничение уровня свободы оперирования ее реальными возможностями. Точнее уровень свободы мышления будет определяется уже не возможностями платформы, а функциональными возможностями компонентов сторонних разработчиков. Если совсем утрировать, то "лепим из пластелина" или "складываем кубики"?
ps. Тяжело конечно. Всего доброго.
То есть Вы утверждаете, что чем хуже человек знает возможности ядра, тем чаще он будет пользоваться сторонними модулями?
Пользуясь Вашими словами я могу сказать, что это утверждение "вызывает сомнение".
Приведу пример.
Следуя Вашей логике получается, что если человек хорошо знает PHP то он сам себе напишет систему управления сайтом. А вот если он плохо знает PHP, то будет пользоваться сторонними разработками вроде Друпала.
Это утверждение конечно логично. Только есть еще один момент. Писать свою CMS это по меньше мере неблагоразумно, во первых это долго, во вторых в Вашей CMS будет заведомо больше багов, ведь как известно количество багов обратно пропорционально количеству разработчиков и тестеров. Ну а если Вы не учитываете такую вещь как "баги" в ваших проектах, тогда я вообще молчу.
Ну а "уровень свободы мышления" определяется как знанием самой системы, так и знанием дополнительных возможностей этой системы.
Конечно, если я владею системой, я могу написать все, что мне нужно. А вот если я знаю еще и "дополнительные возможности" , то я опять же выполню свою задачу, но только потрачу на это в икс раз меньше времени.
Чувствуете разницу?
Вы не обижайтесь, ни чего личного, но в Вашем проекте я бы участвовать не стал.
Во первых, Вы не заботитесь о качестве продукта и не учитываете баги.
Во вторых, Вы не заботитесь о рациональном распределении времени на разработку.
Какие уж там обиды. Вы оппонируете, значит, имеете мнение. Я с ним не соглашаюсь, а значит это моя проблема. Почему бы умным людям не пообщаться, даже если они немного друг друга не понимают.
Ваша логика несколько настораживает. Скорее всего, виной тому то, что мною была предложена несколько идеализированная модель, отчасти оторванная от повседневной жизни. Иначе, сложно понять, почему при словах о программировании, вам видится php, хотя речь в целом об алгоритмистике. При словах «поиск решения» вы видите «баги» и «одинокого фрилансера в ночи». Разработкой, как вы правильно заметили, может заниматься команда, в которой помимо программистов и аналитиков, могут присутствовать тестеры (контролеры кода). Да и вообще не имеет смысла говорить о качестве кода, когда потенциально любой код может содержать ошибки. Просто к разным проектам предъявляются разные требования (например, интранет проекты предполагают тщательную проработку кода в части безопасности, интерфейсная часть менее приоритетна).
Рациональность также определяют задачи конкретного проекта. В вопросе про «дополнительные возможности» я склонен с вами согласиться. В одном случае достаточно использовать стандартные компоненты, а в другом помимо drupal может потребоваться привлечение других технологий. Об этом я оговорился сразу. Набор базовых решений (библиотеки, код предыдущих решений, репозитарий) конечно присутствует, что избавляет от "изобретения велосипедов". Можно использовать готовое решение (в том числе из репозитария сообщества), особенное, если оно отвечает запросам. Если же готового компонента нет или возможности имеющихся образцов скудны (в недостаточной степени соответствуют потребностям проекта), то не следует к нему приспосабливаться. Альтернативное решение не должно отражаться на конечных целях. Его разработка должна исключить трату времени на поиск готового рецепта (удовлетворяющего на 100%). Иными словами, знание "дополнительных возможностей" платформы должно быть подкреплено знанием самой платформы.
Утрируя, "кубики" должны скрепляться "глиной". Вопрос в том, чего должно быть больше «глины» или «кубиков». А может без «глины» вовсе можно обойтись.
Понимаю.
Просто я против "идеализированной модели"