Стоимость создания CMS

Здравствуйте, уважаемые фрилансеры!
Своя веб-студия мечтает о собственном движке, наподобие joomla, bitrix, etc.

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

В общем, это должна быть универсальная cms, которая превращается и в сайт-визитку, и интернет-портал и даже интернет-магазин

Функционал следующий:
1) Под сайт-визитку
Все тексты страниц в базе данных.
1.1) Админская часть, откуда можно добавлять пункты меню навигации, страницы, редактировать содержимое текстов.
1.2) Добавление: (визуальный редактор) возможность загрузить картинку, добавить текст и наглядно увидеть, как это будет выглядеть.
1.3) Обратная связь.
1.4) Карта сайта.

2) Под интернет-портал
2.1) Админская часть (добавление всех материалов на сайт, страниц, редактирование пользователей (удаление, редактирование данных, бан по ip), обратная связь, регистрация/авторизация, поиск по сайту, умное ЧПУ (автоматический перевод заголовка в транслит и формирование ссылки вида: id-заголовок)
2.2) скрипт опроса посетителей
2.3) архив новостей/статей
2.4) фотогаллерея
2.5) карта сайта.

3) Под интернет-магазин
Всё тоже самое, что в интернет-портале, естественно, с корзиной товаров.
Прикрученная система онлайн оплаты (WebMoney, безналичный расчет, всевозможные системы).
Автоматическое уведомление по мобильному телефону, система тикетной службы поддержки, карта сайта.

Все CMS должны работать с MySQL, PHP, JavaScript, JQuery.
Все meta-теги должны настраиваться в админской части.
Возможность устанавливать meta для каждой страницы (ручная установка – для сайта-визитки), автоматическая, если не указана пользователем (интернет-портал и магазин соответственно).

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

Более подробное ТЗ будет согласованно с выбранным исполнителем.

Если хотите что-то хорошее и качественное то разработка обойдется в 5-тизначную сумму в $
Если попроще что-то, то в 4-хзначную...
Ну а если совсем бюджетно хотите, наймите новичков, Вам напишут за 300$

Зависит от того, что система должна выполнять. То, что Вы написали очень мало для универсальной системы.

+ документация, API и т.п. Универсальную вещь в 10 раз сложнее сделать.

Я думаю, что цена от 10 000 и выше.

20 000 $ , только программинг.
А вообще возьмите MODx и допилите до магазина - получите всё описанное

Цитата ("BakST-STUDIO"):

Своя веб-студия мечтает о собственном движке

Наша студия делать сайты и соответственно под них движки не умеет, но зато мы студия!!!!
И умеем драть с заказчиков деньги :P :P

Цитата ("sspy"):

Наша студия делать сайты и соответственно под них движки не умеет, но зато мы студия!!!!
И умеем драть с заказчиков деньги :P :P

А студия не может создавать сайты на готовых решениях?

Я считаю такие крупные самописные не нужны. Некоторые заказчики только бегут от джумлы и подобных ей потому что они очень нагроможденные и под их визитку это сложно.
Я бы создал 2-3 отдельных решения.
Отдельно для визитки, для магазина и т.д.
А то смысл тогда тупо клонировать джумлу или что то в этом роде?

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

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

мне кажется, что Вам, в данном случае собственная cms нужна лишь для маркетинговых целей

все вышесказанное разумеется ИМХО

Как по мне, то лучше использовать фреймворк с набором готовых модулей. Для рядового пользователя это сложно, для среднего программиста пустяк...
Берём фреймворк, пару готовых модулей под него, допиливаем их... Почему фреймворк? Высокая переносимость кода...Меня после Yii ужастно добивает логика тогоже WP, DLE, Joomla и тд.

Цитата:

с технической точки зрения писать собственную cms для сайта визитки

На Yii основной функционал визитки пишется меньше чем за 0.5-1 час... + повторное использование.

BakST-STUDIO, дело это не простое и просто так с наскоку не делается. Если хочется получить в самом деле толковое решение, которое поможет вам в работе, то надо смириться с тем, что времени это займет много и четко очертить бюджет не выйдет. Цифры обозначенные Hungry_Hunter, kalinofski и alexander_vip похожи на правду, но все зависит от того как построить работу ну и конечно надо понимать, что деньги эти прийдется выложить не сразу, а частями на протяжении продолжительного времени.

ИМХО начинать надо с проектирования этого дела, смотреть в сторону модульности, прорабатывать архитектуру. Когда все будет спроектировано и понятно, можно не спеша (нужно не спеша!) постепенно все это дело реализовывать. Тогда получится качественный удобный и в самом деле эффективный продукт. Было бы очень хорошо подключить к разработке своих штатных программистов - им потом эту систему модифицировать и на ее основе строить.

Цитата ("Gia-WEB"):

Я бы создал 2-3 отдельных решения.
Отдельно для визитки, для магазина и т.д.

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

Цитата ("trueW3C"):

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

Не всяк годится это раз. Фреймворк рассчитан на универсальные задачи, CMS на специализированные, она состоит из одних и тех же компонент, это два. Чем проще фреймворк тем даже лучше — меньше оверхеда.

По-моему, CMF лучше поддерживать и дополнять, чем просто CMS.

BakST-STUDIO

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

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

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

этой тропой сегодня идут многие популярные студии разработчиков.

lx83, распространенные CMS плохи свой распространенностью - это лакомый кусок для взлома, они часто подвергаются массированным атакам. Если дописан свой модуль, то в нем могут быть точно так же уязвимости, как и в свой cms.
Также распространенные системы всегда универсальны. Универсальность с одной стороны накладывает ограничения на функционал, с другой стороны он бывает избыточен и в 9 из 10 случаев универсальное решение будет создавать большую нагрузку как на сервер так и на разработчиков. Поддерживать и развивать свое всегда проще и приятнее, чем рыть чужой код.

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

Цитата ("frig"):

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

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

кстати, об актаках. наиболее атакуемая ОС сегодня - это Windows, но это не говорит о том, что она опасна как таковая. если создавать пароль со своим именем и днем рождения, любое приложение будет взломано из детского садика.

Цитата ("frig"):

Универсальность с одной стороны накладывает ограничения на функционал,

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

Цитата ("frig"):

9 из 10 случаев универсальное решение будет создавать большую нагрузку как на сервер так и на разработчиков.

нагрузки - вопрос чисто философский: нет сайта - нет нагрузки. любите кататься - любите и саночки возить.

Цитата ("frig"):

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

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

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

Цитата ("lx83"):

Администрация Президента США не стала бы ставить свой сайт на Друпал

что-то мне кажется, что Администрация Президента США может и не догадываться, что их сайт на Друпале А может даже и не знают, что такое CMS

Цитата ("lx83"):

с точки зрения, к примеру, Джумла и Друпал, вопрос безопасности сайтов на них, это вопрос в центре которого не Джумла или Друпал, а лично администратор сайта на них

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

Цитата ("lx83"):

наиболее атакуемая ОС сегодня - это Windows, но это не говорит о том, что она опасна как таковая.

С точки зрения распростренанности - еще и как опасна. Одно дело написать вирус под какую нибудь next или еще что и даже в случае удачи заразить им несколько сот (тысяч?) компьютеров. Другое дело винда - совсем другой порядок = другой выхлоп. Кстати с точки зрения открытости кода, тут тоже можно провести аналогии - кто угодно может сидеть и анализировать исходники линухов или джумлы и найти там уязвимости, но проделать тоже самое с самописной закрытой CMS или виндой - не выйдет. А это уже совсем не одно и тоже с точки зрения поиска уязвимостей.

Цитата ("lx83"):

Администрация Президента США не стала бы ставить свой сайт на Друпал

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

Цитата ("lx83"):

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

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

Цитата ("lx83"):

нагрузки - вопрос чисто философский: нет сайта - нет нагрузки. любите кататься - любите и саночки возить.

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

Цитата ("lx83"):

я искренне желаю вашей студии процветания

нету у меня студии, но спасибо

ИМХО готовые системы созданы для тех, кого устраивает их универсальность и широкий функционал, кто не собирается на них ничего особенного строить и не владеет языками. Поставить, установить модули, потом обновлять и менять версии. Идеальный вариант. Как только шаг в сторону и надо вносить изменения, а они могут при кажущейся внешней простоте быть обширными внутри - собираем все шишки и получает чужие и свои ошибки, интерес для взлома и так далее.

А я написал свою ЦМС и допиливаю ее до чего угодно. Ставил на ней блоги, магазины, порталы, визитки... Кстати по требованиям всё в ней есть

C безопасностью в PHP все намного проще чем вы думаете. Адекватный специалист, кто читал какие бывают уязвимости и через какие дырки ломают сайт напишет защищенную систему, если будет задумываться об этом.

SQL injection отсеивается на одном уровне, в классах работы с базой данных, XSS на другом(глобальный фильтр на входящие данные) и при выводе брать за привычку применять htmlspecialchars или HTMLPurifier или strip_tags.
Загрузка файлов — общий класс для загрузки, с параметрами, какие типы файлов загружать.
Остальное упирается в хороший стиль программирования: не применять register_globals и не эмулировать его, не полагаться на magic quotes, не использовать в include переменные, не eval'ить что приходит от пользователя(вообще eval можно выкинуть в 99% все решается другими средствами).

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