Comments 302
Не хочу открывать холивар, но почему вдруг табличная верстка это так плохо?
с float выскакивает куча подводных камней, в то время как с таблицами нет, по крайней мере если сам макет сайта на табличках.
с float выскакивает куча подводных камней, в то время как с таблицами нет, по крайней мере если сам макет сайта на табличках.
прежде подобное спрашивать, стоит сперва написать хоть один нормальный проект в таблицах
А что вы понимаете под «нормальным» проектом?
не холивара ради, но в hh.ru в некоторых местах таблицы используются для жесткой обвязки (layouts). В большей степени нужно было для поддержки всяких IE6 и тому подобное. Назвать проект маленьким при 15 млн посещениях язык не повернется.
Таблицы надо использовать для таблиц.
Гугл, например, индесирует таблицы как таблицы, а не как страницы, в итоге страдает сео у сайтов с табличной версткой.
Сильно падает скорость рендеринга страницы. А так же любой пшик требует перерисовки _всей_ страницы, чего можно избежать.
эмм да, в тему дивы и таблицы. я не являюсь профессионалом, но может, уже давно есть решения без хаков размещения точно по вертикали дива его содержимого?
Например вот:
habrahabr.ru/blogs/css/71236/
habrahabr.ru/blogs/css/71236/
Добавление изображений (известная проблема CMS)
Ну вот с WP у меня почему-то особых проблем не возникало в этом плане.
Ну вот с WP у меня почему-то особых проблем не возникало в этом плане.
Чтобы установить UMI.CMS себе на хостинг необходимо скачать файлик install.php, который сам скачает все файлы CMS из интернета.
А вот это фуфуфу. Вдруг он накачает там какой-нить header.php, в который будет вшит какой-нибудь рекламный блок или ещё какая гадость? Это каждую php-шку проверять теперь?
*вопросы обусловлены тем, что вообще ни разу не работал с данной cms.
А вот это фуфуфу. Вдруг он накачает там какой-нить header.php, в который будет вшит какой-нибудь рекламный блок или ещё какая гадость? Это каждую php-шку проверять теперь?
*вопросы обусловлены тем, что вообще ни разу не работал с данной cms.
Сам часто использую вп Заливка изображений сделана на 5+.
WP похоже единственная CMS, где это нормально сделано. Самому раньше нравилось.
UMI вполне окупает свои 30к в качестве полной версии со всеми модулями. Есть бесплатная версия, которая вполне подойдет под сайт-визитку.
Если хотите CMS без изъянов и вылизанную до чиста как в коде движка, так и в верстке — естественно, писать лучше свою, с тем функционалом, который требуется вам или вашей студии.
Это ИМХО и ничто более.
Если хотите CMS без изъянов и вылизанную до чиста как в коде движка, так и в верстке — естественно, писать лучше свою, с тем функционалом, который требуется вам или вашей студии.
Это ИМХО и ничто более.
Полная пробная версия UMI.CMS без установленных демо сайтов занимает 180 мб.
Если это правда, то это чуть больше чем должен занимать сайт визитка.
Если это правда, то это чуть больше чем должен занимать сайт визитка.
Хотя возможно бесплатная версия будет поменьше — интересно насколько.
Если заранее приобрести бесплатный ключ и использовать его при установке — то скачаются только те модули, которые есть в бесплатной версии. Получится порядка 40-50 мб.
Всё равно дико много.
А может кто-нибудь «разложить» что там сколько места занимает?
Самое забавное, что после установки остается папка sys-temp, в которой лежит 120 Мб уже установленных апдейтов (т.е. папка не удалилась сама).
Но самое интересное, в папке files лежат 40 Мб обучающего видео…
В итоге остается 24 Мб чистого веса. Думаю, если покопаться еще, можно сократить уже развернутый дистрибутив до 15 Мб, причем с тем же функционалом.
Но самое интересное, в папке files лежат 40 Мб обучающего видео…
В итоге остается 24 Мб чистого веса. Думаю, если покопаться еще, можно сократить уже развернутый дистрибутив до 15 Мб, причем с тем же функционалом.
UFO just landed and posted this here
Однажды видел человека, который получил от хостера счет за перерасход места (план был меньше минимального, просто чтобы index.html кинуть). Хостер полез, посмотрел, и объяснил, что в папке не только index.html и пара картинок, а phpmyadmin и что-то в этом духе.
И вот тут было «я негодуэ» — «это не я, это мой ввеб-мастер, а он мне, негодяй, не сказал».
Ну ладно в описанном случае, но «забыть» видео — это некисло ))
И вот тут было «я негодуэ» — «это не я, это мой ввеб-мастер, а он мне, негодяй, не сказал».
Ну ладно в описанном случае, но «забыть» видео — это некисло ))
>приобрести
>бесплатный ключ
я один думаю, что здесь что-то не так?
>бесплатный ключ
я один думаю, что здесь что-то не так?
А вот Drupal — полная рабочая версия занимает всего 11 мбайт и 1154 файла, а по функционалу — отнють не визитка, в разы функциональнее чем UMI. Имхо слишком много мусора накопилось в UMI за время разработки, который подчищать и оптимизировать никто не хочет… В результате каждая новая версия всё больше прожорлива на ресурсы и тормознее… В битриксе та же проблема.
Зато UMI и Битрикс делают успешный бизнес! Во всём нужна золотая середина между качеством (кода) и количеством (прибыли). Зачастую, она находится не совсем там, где её представляет программист.
Насчёт бизнеса я не спорю, но тут речь идёт именно о качестве продукта с точки зрения программиста, а не о прибыли. Автоваз например тоже имеет неплохие продажи, но качество в сравнении с конкурентами — ниже плинтуса.
UMI и Битрикс на первую план ставят прибыль, поэтому всё внимание уделяют маркетингу и продажам, а не отслеживанию качества, оптимизированности кода и развитию системы, поэтому со временем она становится всё сложнее, глючнее и неповоротливее.
Но зато маркетологи в описании добавляют всё больше плюсиков и галочек аля «на нашей cms можно сделать всё что угодно» и «в нашей cms больше строчек кода чем у всех конкурентов вместе взятых», а выбор cms при покупке обычно делают маркетологи, которые мало чего понимают в разработке, поэтому продажи растут и все довольны.
Насчёт UMI я точно не скажу — не разбирался, а вот у Битрикса требования к хостингу просто огромные, даже для сайта из трёх страничек. Причём многие хостинги вынуждены даже были разработать отдельный дорогостоящий тариф для битрикс-сайтов, т.к. на обычном тарифе уже ресурсов нехватает. Хотя на Drupal, Wordpress, Joomla множество довольно объёмных сайтов работают без проблем на самых дешёвых тарифах. А платные CMS стоят немало, поэтому плюс 1000 рублей в месяц за хостинг это уже копейки, неважно что CMS для вывода 1 абзаца статического текста целые горы сворачивает, главное что продажа состоялась.
Поэтому если систему будет выбирать программист, а не маркетолог/менеджер/секретарша, то выбор падёт на более качественные с точки зрения кода и функционала CMS, а не на те, которые висят в топах по количеству продаж и цене. Но, к сожалению, обычно выбор делает не программист, ему сайт уже достаётся на этапе «вот мы тут купили классную CMS, давай разбирайся и делай, чтобы к понедельнику всё заработало».
Хотя и многих программистов завлекает галочка в описании «техническая поддержка и помощь в установке» в надеждах что саппорт CMS за них всё настроит и сделает, а в итоге это выливается в то, что саппорт даёт только стандартные отписки и разбираться в деталях не собирается, а нормальной документации по API и коду не даёт, т.к. CMS закрытая, поэтому программист сам тоже ничего сделать уже не может — замкнутый круг — либо обходись стандартным функционалом который дали либо плати разработчикам ещё денег за доработку модулей.
UMI и Битрикс на первую план ставят прибыль, поэтому всё внимание уделяют маркетингу и продажам, а не отслеживанию качества, оптимизированности кода и развитию системы, поэтому со временем она становится всё сложнее, глючнее и неповоротливее.
Но зато маркетологи в описании добавляют всё больше плюсиков и галочек аля «на нашей cms можно сделать всё что угодно» и «в нашей cms больше строчек кода чем у всех конкурентов вместе взятых», а выбор cms при покупке обычно делают маркетологи, которые мало чего понимают в разработке, поэтому продажи растут и все довольны.
Насчёт UMI я точно не скажу — не разбирался, а вот у Битрикса требования к хостингу просто огромные, даже для сайта из трёх страничек. Причём многие хостинги вынуждены даже были разработать отдельный дорогостоящий тариф для битрикс-сайтов, т.к. на обычном тарифе уже ресурсов нехватает. Хотя на Drupal, Wordpress, Joomla множество довольно объёмных сайтов работают без проблем на самых дешёвых тарифах. А платные CMS стоят немало, поэтому плюс 1000 рублей в месяц за хостинг это уже копейки, неважно что CMS для вывода 1 абзаца статического текста целые горы сворачивает, главное что продажа состоялась.
Поэтому если систему будет выбирать программист, а не маркетолог/менеджер/секретарша, то выбор падёт на более качественные с точки зрения кода и функционала CMS, а не на те, которые висят в топах по количеству продаж и цене. Но, к сожалению, обычно выбор делает не программист, ему сайт уже достаётся на этапе «вот мы тут купили классную CMS, давай разбирайся и делай, чтобы к понедельнику всё заработало».
Хотя и многих программистов завлекает галочка в описании «техническая поддержка и помощь в установке» в надеждах что саппорт CMS за них всё настроит и сделает, а в итоге это выливается в то, что саппорт даёт только стандартные отписки и разбираться в деталях не собирается, а нормальной документации по API и коду не даёт, т.к. CMS закрытая, поэтому программист сам тоже ничего сделать уже не может — замкнутый круг — либо обходись стандартным функционалом который дали либо плати разработчикам ещё денег за доработку модулей.
UFO just landed and posted this here
Бизнес 37signals менее успешен?
В бизнесе описанных компаний размер не главное — продажи и техническое совершенство отнюдь не всегда в жизни рядом, к сожалению.
Имхо проблема не то что на сервере лежит, а то что на клиента грузится. А с этим у UMI (у других не лучше) — традиционно задница. У них крайне громоздкий бэкофис, грузящий кучу файлов очень большого объема.
2-3 года назад чтобы отедактировать страничку требовалось загрузить несколько сотен файлов на 1-2 Мб. сейчас вроде чуть-чуть сократили. Но не радикально.
2-3 года назад чтобы отедактировать страничку требовалось загрузить несколько сотен файлов на 1-2 Мб. сейчас вроде чуть-чуть сократили. Но не радикально.
Похоже на заказную статью. Или у вас какая-то личная неприязнь к этой CMS. Хотите сделать продукт лучше? Сообщайте в UMI о багах и ошибках, пишите предложения, вступайте в community. За что платить и сколько денег каждый разберется своей головой. А критиковать каждый горазд.
я вот статью не напишу, но всем посоветую десять раз подумать прежде чем смотреть эту UMI.CMS,
а потом выбрать всё что угодно, но только не её. это моё оценочное суждение не подкреплённое примерами,
но говоря о ней я и матов не использовал ;-)
а потом выбрать всё что угодно, но только не её. это моё оценочное суждение не подкреплённое примерами,
но говоря о ней я и матов не использовал ;-)
Оглянитесь вокруг — это комьюнити!
Стоит кому-либо написать критическую статью, как его обвиняют в заказухе. В свое время писал аналогичный разбор полетов о скрипте магазина PHPShop. Реакция была один в один. Что за мода?
Иногда создается впечатление, что о некоторых продуктах/услугах либо хорошо, либо никак, равным счетом, как об усопших.
Иногда создается впечатление, что о некоторых продуктах/услугах либо хорошо, либо никак, равным счетом, как об усопших.
ну… если писать хвалебную статью, ощущение о «заказухе» будет сильнее. Но это лишь мое представление о мире.
UFO just landed and posted this here
По мне так логичным такой вывод будет в случае: «единственная вменяемая альтернатива — XYZ». А тут просто крик души, отчасти рассчитанный на то, что популярность хоть немного но снизится и придётся реже с ней сталкиваться.
UFO just landed and posted this here
Не понимаю, была бы альтернатива — логично было бы предположить, что заказ от альтернативы. А тут даже не понятно от кого заказ. От Drupal? Смешно.
Помню на хабре писали про CMS для интернет-магазинов «Simpla» — автор позиционировал как очень современное (с точки зрения технологий) и лёгкое решение. Альтернативы с самым скромным функционалом CMS есть!
В России? Ну что за дискриминация-то! Интернет он интернациональный. Отличной платформы для интернет-магазина нет и в мире. Я про те, что можно сказать/поставить/купить, а не платформы которые находятся в руках одного производителя и их даже за деньги получить заполучить, да и смысла в этом нет ибо они обычно заточены реалии одной конторы.
Альтернативы не предложено, потому что целью статьи не было выбрать лучшую CMS. Цель была показать UMI.CMS изнутри.
Баги, недоработки — это одно. О них пишут. Но в статье просматривается описание системной болезни всего проекта в целом. Сам в свое время сделал несколько проектов на этой системе. Глубоко не копал, так как сайты были не слишком сложные. Но уже тогда многие вещи дико раздражали. Так что такие статьи нужны. Ибо такое простить можно опен сорсу, но никак не коммерческому продукту, где деньги платят в первую очередь за качество.
> что приводит к не валидной верстки.
Боже
Боже
мне, кажется, мало более менее понимающих разработчиков пойдут на UMI, а вот начинающих может привлечь drag-and-drop)
я тоже когда-то с ucoz'а начинал =)
хотя) на вкус и цвет фломастеры разные))
я тоже когда-то с ucoz'а начинал =)
хотя) на вкус и цвет фломастеры разные))
Да остальные массовые продукты не сильно лучше.
Битрикс, например, стоит сильно дороже, а толку.
Почти каждая из описанных проблем к нему применима.
Особенно про разработку.
Доки расходятся с реальным положением вещей, иногда обнаруживаются куски вида while(false){...}.
Причем доки расходятся так, что даже если залезть, внутрь, не очевидно по названию, что именно делает функция. И да, слов private protected и public в основном API битркса как CMF просто нет[возможно, из нет вообще нигде]. Т.е даже так показать разработчикам, что для них предназначено, а что нет, в планы авторов не входило.
Но. Справедливости ради: по функционалу из коробки битрикс реально уделывает большинство CMS.*
*) если у кого-то есть чем оспорить это утверждение, буду только рад. Пишите в комментариях.
Битрикс, например, стоит сильно дороже, а толку.
Почти каждая из описанных проблем к нему применима.
Особенно про разработку.
Доки расходятся с реальным положением вещей, иногда обнаруживаются куски вида while(false){...}.
Причем доки расходятся так, что даже если залезть, внутрь, не очевидно по названию, что именно делает функция. И да, слов private protected и public в основном API битркса как CMF просто нет[возможно, из нет вообще нигде]. Т.е даже так показать разработчикам, что для них предназначено, а что нет, в планы авторов не входило.
Но. Справедливости ради: по функционалу из коробки битрикс реально уделывает большинство CMS.*
*) если у кого-то есть чем оспорить это утверждение, буду только рад. Пишите в комментариях.
Ещё больше раздражает отсутствие static. Без него в IDE не работает автокомплит так как по умолчанию, все функции считаются не статическими. Ну и ещё кругом в файлах портянки кода по несколько тысяч строк без единой функции, т.е. в глобальном пространстве имён значительно тормозят работу IDE. А ещё, достаточно открыть основные классы ядра системы в нормальной IDE, что бы методом статического анализа увидеть кучу ошибок. Как у них вообще Битрикс работает, когда в ядре явные ошибки? Ещё больше не понятно, почему те кто берёт столько денег за свой продукт, не могут просмотреть свой код в IDE хотя бы разок и исправить баги? Неужели, это так сложно?
Использование static, имхо, должно быть аргументировано чем-то большим, чем «в IDE не работает автокомплит». Тем более, что автокомплит в нормальной IDE вполне работает для конструкций типа
даже без объявлений phpDoc типа
$user = new User();
$user->login($login, $password);
даже без объявлений phpDoc типа
/* var User */Естественно, оно работает. Но в битриксе полно статических методов, таких как CIBlockElement::getById(); или CIBlockElement::GetList();
Так вот, когда я в phpStorm набираю «CIBloc...», то IDE вообще не автокомплитит класс т.к. в нём нет ни одного статического метода. Название метода она тоже не автокомплитит. PhpStorm голимая IDE?
Так вот, когда я в phpStorm набираю «CIBloc...», то IDE вообще не автокомплитит класс т.к. в нём нет ни одного статического метода. Название метода она тоже не автокомплитит. PhpStorm голимая IDE?
Кстати, в какой еще CMS/CMF есть аналоги иблоков? Ну друпал не берем, он из аналогичных и много более юзабельных иблоков чуть менее, чем полностью.
СFile кстати как пример. Очепь ппц.
CCaptсha.
От таких инструментов я местами сру костылями.
Есть еще один момент в битриксе, который меня очень пугает. Стопроцентно рабочего способа компоненту решить какой именно шаблон подключать нет. Тот что документирован не работает. Можно поставить костыль и вызвать нужный темплейт текушего шаблона, или же по резалту работы дать темлейту вызвать инклудом то, что нужно. но это ппц и ломает mvc, ломает полностью.
СFile кстати как пример. Очепь ппц.
CCaptсha.
От таких инструментов я местами сру костылями.
Есть еще один момент в битриксе, который меня очень пугает. Стопроцентно рабочего способа компоненту решить какой именно шаблон подключать нет. Тот что документирован не работает. Можно поставить костыль и вызвать нужный темплейт текушего шаблона, или же по резалту работы дать темлейту вызвать инклудом то, что нужно. но это ппц и ломает mvc, ломает полностью.
>Кстати, в какой еще CMS/CMF есть аналоги иблоков?
Да полно. В любом фреймфорке сгенерировать модель со своими полями, добавить шаблон, админку — вот и инфоблоки.
В моём фреймфорке, например, произвольные данные с админкой (допустим, список докладчиков или галерея или новости или товары) генерируется за 10 секунд.
Это касается любой админки, основанной на нормальном фреймфорке (не только PHP, ActiveAdmin + Ruby on Rails тоже подходит).
Да полно. В любом фреймфорке сгенерировать модель со своими полями, добавить шаблон, админку — вот и инфоблоки.
В моём фреймфорке, например, произвольные данные с админкой (допустим, список докладчиков или галерея или новости или товары) генерируется за 10 секунд.
Это касается любой админки, основанной на нормальном фреймфорке (не только PHP, ActiveAdmin + Ruby on Rails тоже подходит).
Соль именно в CMS с примесью CMF, типа битрикса и сабжеавой UMI.
Фреймворки понятно, что большинство. Генерация CRUD достаточно стандартно.
Фреймворки понятно, что большинство. Генерация CRUD достаточно стандартно.
ActiveAdmin + Ruby on Rails имхо вполне себе CMF, судя по виду.
MaxSite CMS, yupe, codear — вот неполный список именно CMS, причём мои слова относятся и к ним, т.к. основаны на CI и Yii. Причём MaxSite очень даже популярна.
Я к тому, что решения есть, именно CMS и именно с аналогами инфоблоков. Просто о них мало кто знает из заказчиков.
MaxSite CMS, yupe, codear — вот неполный список именно CMS, причём мои слова относятся и к ним, т.к. основаны на CI и Yii. Причём MaxSite очень даже популярна.
Я к тому, что решения есть, именно CMS и именно с аналогами инфоблоков. Просто о них мало кто знает из заказчиков.
О, друпал 8. Основан будет на symphony. Чем не CMS?
То ли я не понял кейс, то ли вы хотите чего-то странного. В PHP название класса употребляется в пяти (навскидку) случаях (за исключением всяких фабрик и колбэков, где имя класса передаётся строкой):
— после new
— type hinting для параметров функций/методов
— вызов статического метода
— при наследовании класса
— в instanceof
Во всех этих случаях PhpStorm справляется отлично. Что я не учёл?
— после new
— type hinting для параметров функций/методов
— вызов статического метода
— при наследовании класса
— в instanceof
Во всех этих случаях PhpStorm справляется отлично. Что я не учёл?
class CIBlockElement {
function getById() {… }
}
Так как метод не объявлен статическим, PhpStorm не будет его автокомплитить.
function getById() {… }
}
Так как метод не объявлен статическим, PhpStorm не будет его автокомплитить.
Что я делаю не так?
А вы знаете, что такое «статический метод»? Если знаете, то зачем вы создаёте объект?
2012-01-22_233631.png
2012-01-22_233631.pngВы обосновывали необходимость наличия статических методов тем, что без них не работает автокомплит. Я сказал, что это очень сомнительный аргумент для введения статических методов, тем более что и без них автокомплит работает (при создании объекта, естественно).
А в вашем примере естественно автокомплита не будет, не допускает PHP использование имени класса в данном контексте и PhpStorm об этом прекрасно знает. Что вы там хотели написать?
А в вашем примере естественно автокомплита не будет, не допускает PHP использование имени класса в данном контексте и PhpStorm об этом прекрасно знает. Что вы там хотели написать?
CIBlockElement::getById()? Так это будет ошибкой, поскольку getById не статический метод. PHP Strict standards: Non-static method CIBlockElement::getById() should not be called staticallyПеречитайте мой коммент. Притензия не к IDE и не к php, а к битриксу за то что статические методы они не помечают ключевым словом «static» и из-за этого не работает IDE.
Перечитал — не вижу там фразы «статические методы они не помечают ключевым словом «static»». Написали бы сразу — не было бы этого препирательства со скринами, а то я понял как «Bitrix не засоряет код использует статические методы, а мне они очень нравятся», а не «Bitrix использует методы объекта как методы класса, не объявляя их static».
А эти методы и не являются статическими. Конечно, если добавить ключевое слово static оно станет таковым, но мы имеем то что имеем. Так же у меня предположение есть что это все дело пошло со времен PHP4 и после уже не перерабатывалось.
Проверил — без E_STRICT даже нотайсы не выдаются при вызове таких методов как статических (A::b(), где b без static), если $this в них не использовать. Честно говоря, удивлён O_o
Ты только сейчас открыл для себя, что в PHP можно статически вызвать метод, не объявленный как static и не содержащий $this в своём коде?
Вроде опытный чел, ну или казался таким ))
Вроде опытный чел, ну или казался таким ))
Как-то не приходилось так извращаться. Если решал использовать метод как статический, то объявлял его статическим. Если не решал, то не объявлял. И вообще статические методы не люблю. Лучше синглтон инстанцирую :)
1) Чем это лучше?
2) Как вообще синглтон может заменить статический метод (аналогом которого является просто функция, function())?
3) За что можно не любить статические методы?
2) Как вообще синглтон может заменить статический метод (аналогом которого является просто функция, function())?
3) За что можно не любить статические методы?
1) Тем, что существует однозначность контекста использования метода без необходимости изучать его код.
2) Что статические методы, что функции, что методы синглтона существуют в одном экземпляре и потому легко взаимозаменяемы.
3) За то, что они являются глобальной сущностью и в подавляющем большинстве случаев привязка в других частях кода к ним идёт жёсткая, получается сильная связанность кода. Плюс, как правило, получается что класс имеет несколько областей ответственности.
P.S. Единственное разумное в подавляющем большинстве случаев использование статических методов — эмуляция нэймспэйсов или модулей.
2) Что статические методы, что функции, что методы синглтона существуют в одном экземпляре и потому легко взаимозаменяемы.
3) За то, что они являются глобальной сущностью и в подавляющем большинстве случаев привязка в других частях кода к ним идёт жёсткая, получается сильная связанность кода. Плюс, как правило, получается что класс имеет несколько областей ответственности.
P.S. Единственное разумное в подавляющем большинстве случаев использование статических методов — эмуляция нэймспэйсов или модулей.
Кстати с вызовом статического метода для класса с несколькими декларациями он стал справляться только с 3 версии, за что я ему премного благодарен.
А мы вот использовали много разных CMS, много лет занимаемся разработкой веб-проектов различной сложности, в результате перепробовали более 10 платных и бесплатных продуктов, остановились на HostCMS, всем кто еще не смотрел её — настоятельно рекомендую, мы рады и клиенты наши тоже. Для больших проектов используем фреимворки, в частности на Zend пишем, ибо коробочная CMS под порталы и социальные сети — это мягко говоря непрофессионально.
Единственный плюс HostCMS — относительно вменяемая документация. Если потребуется немного больше «типового интернет-магазина» — то делать его на HostCMS рискнет только мазохист.
avtotovary.com.ua/ — около года назад сделали на HostCMS, функционал довольно широкий, много нестандартного.
шок! видео! скачать! [x]
ничего «нестандартного» не увидел.
Не все видно снаружи, чего только стоило интегрировать базу товаров в несколько миллионов позиций, завязать это все с 1С, складами и т.д. Такое по Вашему лучше на юми делать? Или какой продукт использовать в данном случае?
Я не агитирую за какой-то конкретный продукт и не отговариваю, это спор на тему что лучше. Поэтому не надо втихую минусовать, нужно аргументы приводить!
Я не агитирую за какой-то конкретный продукт и не отговариваю, это спор на тему что лучше. Поэтому не надо втихую минусовать, нужно аргументы приводить!
Честно спрошу, а чего стоило?
Выгрузка XML и приложенных документов и картинок вменяемым 1С-ником делается за два дня. Дальше в архив, ftp передача, а там из крона разбор чем угодно. И пофиг, какая CMS.
Выгрузка XML и приложенных документов и картинок вменяемым 1С-ником делается за два дня. Дальше в архив, ftp передача, а там из крона разбор чем угодно. И пофиг, какая CMS.
Может для веб-разработчика не так просто разобраться как выгружать из 1С?
Если бы все было так просто, автомагазинов было бы куча, а так их единицы почему-то…
А мне казалось что организовать продажу авто просто сложнее, неже ли торговать плеерами и т.д.
Ну, я по крайней мере знаю пятерку магазинов автозапчастей, которые с 1С работают, один даже который напрямую из 1С работает с мускульной базой на сайте(кстати на семерке еще). А насчет интеграции — так ведь не покопавшись во внутренностях проекта как определить, использует он 1С или нет? Скажу только, что сам сделал порядка 4х систем с такой интеграцией и работал еще с двумя, на разных работах, с совершенно разной структурой сайтов и 1С. Так что я повторюсь, это не трудно, главное чтобы одинэсник был правильный. А так и импорт картинок возможен, и выгрузка прикрепленных документов и многое другое.
Тогда мне интересно, как вы будете выгружать 2 млн. товаров с картинками из 1С, при этом чтобы остаток всегда был актуальным? Да, в распоряжении у вас будет только один сервер сердненький на сайт, 1С и все остальное, сайт при этом безусловно сайт не должен тормозить?..
о_0, рад за ваших менеджеров, которые 2 мл товаров могут обновить за раз. Как реализуется -можно глянуть хотя бы механизмы битрикса. Актуальные остатки при торговле с сайта — это миф, т.к. если у вас нет привязки sms на телефон, то процент ложных заказов непомерно высок.А если есть — то имеется задержка подтверждения, от 1 минуты. Еще сложности с ситуациями высокой посещаемости и множества магазинов…
С 1С этот магазин тоже работает, но только с бухгалтерией…
UFO just landed and posted this here
У всех есть много проблем, нужно выбирать лучшее решение.
Вопрос на засыпку в таким случае: что лучше всего подходит магазинов?
Вопрос на засыпку в таким случае: что лучше всего подходит магазинов?
UFO just landed and posted this here
Мы сертифицированные партнеры битрикса, для разработчика очень неблагодарная система и производительность мягко говоря оставляет желать лучшего. Хотя поддержка, безусловно, на хорошем уровне и функционал широкий. Про другие 2 цмс ничего сказать не могу.
Мы вот еще хотим попробовать мадженто, говорят очень хорошая система, сами не пробовали…
Мы вот еще хотим попробовать мадженто, говорят очень хорошая система, сами не пробовали…
У магенто высокий уровень входа. Для работы с ней понадобятся программисты с уровнем знаний выше среднего. Тяжелая система, но компенсирует функционалом.
Очень высокий уровень абстракции с разными xml-ми и файлами конфигурации. Не думаю, что затраты на работу с ней смогут переплюнуть более простые вышеприведенные cms.
Но опробуйте, почему нет. Потом расскажите, будет любопытный опыт. Но нужно сразу готовиться к необходимости хорошего вкуривания в систему.
Но опробуйте, почему нет. Потом расскажите, будет любопытный опыт. Но нужно сразу готовиться к необходимости хорошего вкуривания в систему.
«Товар не может быть больше чем в 1 категории
Стоимость доставки почтой не считается. И ems туда же
Доставка и оплата не зависит от региона (это вообще жесть курьер во Владивосток из Москвы привет!)
Вес товаров не влияет на стоимость доставки (или 20-30 правил на 1тип доставки)»
1) Товар может быть в любой категории — есть функция ярлык, можно создать одним кликом в списке элементов для любого элемента любое кол-во ярлыков и помесить в любую группу.
2) Прикручивается, ничего сложного. Было бы стандартно — согласен, меньше гемороя. Есть кстати модуль, правда платный но ничего не мешает сделать свой.
3) Вранье. Доставка зависит от региона. Все стандартно настраивается в админке.
Оплата идет после выбора адреса доставки. Но при желании можно поменять шаги местами. Да, надо понимать типовую корзины, почитать api. Легко. Вообще зависимость в шаблоне xsl обработки шагов в корзине можно менять, ничего сложного. В коробке — типичный пример но никто не мешает написать свою логику, там для этого больших усилий не надо.
4) Поясните пример, не совсем понятно какая у вас стояла задача на сайте.
5) Маркетинг. Допиливается, не все за вас будут делать разработчики. Хорошо бы канечно из коробки но трудностей не вижу. Делали, задницы никакой нет.
6) Непонятно в чем трудность, лень?
Итог — задница у вас 8(
Стоимость доставки почтой не считается. И ems туда же
Доставка и оплата не зависит от региона (это вообще жесть курьер во Владивосток из Москвы привет!)
Вес товаров не влияет на стоимость доставки (или 20-30 правил на 1тип доставки)»
1) Товар может быть в любой категории — есть функция ярлык, можно создать одним кликом в списке элементов для любого элемента любое кол-во ярлыков и помесить в любую группу.
2) Прикручивается, ничего сложного. Было бы стандартно — согласен, меньше гемороя. Есть кстати модуль, правда платный но ничего не мешает сделать свой.
3) Вранье. Доставка зависит от региона. Все стандартно настраивается в админке.
Оплата идет после выбора адреса доставки. Но при желании можно поменять шаги местами. Да, надо понимать типовую корзины, почитать api. Легко. Вообще зависимость в шаблоне xsl обработки шагов в корзине можно менять, ничего сложного. В коробке — типичный пример но никто не мешает написать свою логику, там для этого больших усилий не надо.
4) Поясните пример, не совсем понятно какая у вас стояла задача на сайте.
5) Маркетинг. Допиливается, не все за вас будут делать разработчики. Хорошо бы канечно из коробки но трудностей не вижу. Делали, задницы никакой нет.
6) Непонятно в чем трудность, лень?
Итог — задница у вас 8(
UFO just landed and posted this here
4) Да, в системе при создании способа доставки (условий) есть возможность указать диапазон веса заказа от и до. Вы об этом написали сами, «или 20-30 правил на 1тип доставки» — скажите а что за ситуация такая? Хорошо, вес заказа составил 28кг, мы знаем что курьер не может увести более 25кг, в таком случае в условии доставки курьером будет указан вес «до 25кг». Способ доставки курьером не будет доступен для выбора. В чем проблема? Можете прояснить о чем речь насчет 20-30 правил? Простите, возможно я не совсем понял вашу ситуцию.
5) Тут спорить не буду, вы правы. Но меня это не расстраивает, а вот коробочников которые любят все получить только из коробки — да. Такой спорный вопрос.
6) Так вы значит «коробочник»?
5) Тут спорить не буду, вы правы. Но меня это не расстраивает, а вот коробочников которые любят все получить только из коробки — да. Такой спорный вопрос.
6) Так вы значит «коробочник»?
При использовании xslt шаблона яваскрипты работают только если их вставить в текстовый редактор
Я всего месяц работаю с этой цмс, тестовый сайт делал как раз на xslt. <сарказм>а такой особенности и не заметил</сарказм>
Многое правда, хотя и видно, что у человека накипело. Впрочем вечный совет всем критикам: «сделай лучше!»
Вечный ответ на «сделай лучше»: чтобы понять, что вещь — говно, не нужно разбираться в его сортах.
но нужно как минимум предложить вменяемую альтернативу. иначе все говно, а автор один такой красивый стоит.
Альтернативы? Зависит от задачи, но практически всё, для чего юзается UMI, можно сделать на Друпале, а чуть поднапрягшись — даже на Wordpress. Это я уже не говорю, что визитку можно сшить на том же Wordpress или Textpattern.
Возможно моя точка зрения прозвучит несколько резко, но WP зло! Мне не раз приходилось делать на WP различные сайты визитки, как минимум мне пративно то, что большая часть нестандартной логики сайта находиться в шаблонах. По поводу плагинов — в наличии имеется широченный набор плагинов, лишь 2-3% которых хоть как-то являются вменяемыми. Сам WP страдает огромной прожорливостью, загружает все что есть в момент загрузки даже очень простой странички, а все эти хваленые плагины очень любят прописывать фильтры с приоритетом, выраженным в отрицательных целых числах, что собственно заставляет перекрывать фильтры других плагинов… словом… это бывает просто ужасно. Но опять же, у меня просто накипело и я не переношу эту CMS. Хотя признаю, в плане работы с контентом на чистом WP, в качестве платформы для ведения блогов, альтернатив у нее очень мало, если они вообще есть.
Drupal просто не люблю. отход от стандартов при верстке дизайна, и уже надо копаться в коде… искать что и как… Админка просто ужасна… заказчик каждый раз при использовании будет откладывать по кирпичику и в конце месяца строить крепость из оных. Опять же это лишь мое мнение сформированное под влияением «очень специфичных проектов, которые почему-то надо реализовывать именно на этой CMS».
Мараль сей басни такова — выбирайте то, что вам нравится, но хорошего очень мало, и обычно платное не означает «качество» — максимум наличие поддержки.
Drupal просто не люблю. отход от стандартов при верстке дизайна, и уже надо копаться в коде… искать что и как… Админка просто ужасна… заказчик каждый раз при использовании будет откладывать по кирпичику и в конце месяца строить крепость из оных. Опять же это лишь мое мнение сформированное под влияением «очень специфичных проектов, которые почему-то надо реализовывать именно на этой CMS».
Мараль сей басни такова — выбирайте то, что вам нравится, но хорошего очень мало, и обычно платное не означает «качество» — максимум наличие поддержки.
На этот вопрос есть более удачный вариант ответа:
«Я в своей жизни не снес ни одного яйца, но о качестве яичницы могу судить лучше любой курицы»
«Я в своей жизни не снес ни одного яйца, но о качестве яичницы могу судить лучше любой курицы»
только тут мы не яйки да омлеты обсуждаем. и уж «снести» таковое потенциально в состоянии каждый.
а общем, кто хочет — ищет возможности, кто не хочет — причины.
а общем, кто хочет — ищет возможности, кто не хочет — причины.
Я не вижу смысла писать трицикл, когда в природе существует достаточное количество готовых решений разной степени гибкости, пригодных для кастомизации в нужную сторону.
Уходить в дебри фреймворков есть смысл только в двух, на мой взгляд, случаях: либо ты пишешь какую-то мелкую поебень, ради которой брать полновесный двигатель смысла нет ну просто никакого, либо тебе нужно нечто настолько невероятно кастомное, что проще написать самому, чем строгать чужое.
Уходить в дебри фреймворков есть смысл только в двух, на мой взгляд, случаях: либо ты пишешь какую-то мелкую поебень, ради которой брать полновесный двигатель смысла нет ну просто никакого, либо тебе нужно нечто настолько невероятно кастомное, что проще написать самому, чем строгать чужое.
смысла их писать и нету, кроме упомянутых и justforfun.
суть критики «критики...» в том, что 1) ТС придирается на половину к малоиспользуемой/никомунинужной стороне вопроса 2) подходит к этому достаточно однобоко — не предлагает способа решения и не предлагает альтернатив. Все это создает ощущение надуманности и, гм, заказухи.
У любой коммерческой системы (т.е. которую нельзя спустя полтора месяца, после того как авторы поняли, какую же фигню они нагородили, взять и сделать вообще несовместимой) есть много особенностей. Где-то больше, где-то меньше. Знать их нужно. А кривить губу, мол «фуфло, а отступы тут некошерно сделаны» — может любой неудачник.
суть критики «критики...» в том, что 1) ТС придирается на половину к малоиспользуемой/никомунинужной стороне вопроса 2) подходит к этому достаточно однобоко — не предлагает способа решения и не предлагает альтернатив. Все это создает ощущение надуманности и, гм, заказухи.
У любой коммерческой системы (т.е. которую нельзя спустя полтора месяца, после того как авторы поняли, какую же фигню они нагородили, взять и сделать вообще несовместимой) есть много особенностей. Где-то больше, где-то меньше. Знать их нужно. А кривить губу, мол «фуфло, а отступы тут некошерно сделаны» — может любой неудачник.
Хуясе малоиспользуемой и никому не нужной…
XSS-инжекты повсюду — это, действительно, никому не интересный косяк, ах-ха; вёрстка, от которой валидатор жрёт воображаемый валидол — это тоже никому не интересно; отсутствие вменяемого саппорта и документации даже для платных юзеров — это ведь ерунда, правда?
Мне думается, Вы путаете первое и второе, суп с котлетами, так сказать. Целью ТС было не сколько сказать, что сабжевая CMS, мягко говоря, не торт, а именно объяснить, почему она не торт.
А вот когда единственным доводом защиты является то, что код-де наследуется аж с мелового периода, и юзер должен всё это учесть — это лишь еще один довод к тому, что так кодят только не очень порядочные люди, которым похуй на качество конечного продукта.
XSS-инжекты повсюду — это, действительно, никому не интересный косяк, ах-ха; вёрстка, от которой валидатор жрёт воображаемый валидол — это тоже никому не интересно; отсутствие вменяемого саппорта и документации даже для платных юзеров — это ведь ерунда, правда?
Мне думается, Вы путаете первое и второе, суп с котлетами, так сказать. Целью ТС было не сколько сказать, что сабжевая CMS, мягко говоря, не торт, а именно объяснить, почему она не торт.
А вот когда единственным доводом защиты является то, что код-де наследуется аж с мелового периода, и юзер должен всё это учесть — это лишь еще один довод к тому, что так кодят только не очень порядочные люди, которым похуй на качество конечного продукта.
юзер в любом случае что-то учитывает, впрочем это не аргумент, да.
xss как раз в той половине, которая боле-мене полезна.
касательно верстки админки и сайта (которые занимают «бесполезную» имхо половину) тут уже встречались доводы более компетентных людей, насколько это [не]актуально. аргументы, которые в обсуждении уже есть: 1) свои пространства имен предусмотрены стандартом; 2) наезды на «устаревшие» тэги — мягко скажем «пока преждевременны»; 3) топы (гугл и многие, что с ним в одной весовой) — тоже не валидны.
Мух и котлет стоит разделять. Объяснив, «почему не торт», ТС докинул половинку негатива, которая 1) на работу не влияет (ну плевать валидаторам на половину косяков без xhtml+xml, который к тому же не воспринимается ie8-); 2) никому не видна (простихоспаде, на код страницы админки мне глубоко и с высокой). Они бесполезны — так чего их обсуждать?
Если со всем вышеупомянутым тот же друпал, кой ТС, судя по обилию удачных постов, любит и использует — что-ж, круто. Давайте найдем, почему юми занимает большую долю рынка в россии, заделаем контору, которая эти недостатки устранит — сделаем хорошее дело, приучим пользователей и студии к правильной подаче цмс и будем зашибать деньгу.
xss как раз в той половине, которая боле-мене полезна.
касательно верстки админки и сайта (которые занимают «бесполезную» имхо половину) тут уже встречались доводы более компетентных людей, насколько это [не]актуально. аргументы, которые в обсуждении уже есть: 1) свои пространства имен предусмотрены стандартом; 2) наезды на «устаревшие» тэги — мягко скажем «пока преждевременны»; 3) топы (гугл и многие, что с ним в одной весовой) — тоже не валидны.
Мух и котлет стоит разделять. Объяснив, «почему не торт», ТС докинул половинку негатива, которая 1) на работу не влияет (ну плевать валидаторам на половину косяков без xhtml+xml, который к тому же не воспринимается ie8-); 2) никому не видна (простихоспаде, на код страницы админки мне глубоко и с высокой). Они бесполезны — так чего их обсуждать?
Если со всем вышеупомянутым тот же друпал, кой ТС, судя по обилию удачных постов, любит и использует — что-ж, круто. Давайте найдем, почему юми занимает большую долю рынка в россии, заделаем контору, которая эти недостатки устранит — сделаем хорошее дело, приучим пользователей и студии к правильной подаче цмс и будем зашибать деньгу.
Сэр, Вы явно не понимаете, для чего автор топика вообще начал все это.
Позвольте, я разъясню — его посыл заключается в том, что стыдно продавать такой хуёвый продукт. Если до Вас это не дошло даже после трех моих комментариев — увы, медицина здесь бессильна.
Позвольте, я разъясню — его посыл заключается в том, что стыдно продавать такой хуёвый продукт. Если до Вас это не дошло даже после трех моих комментариев — увы, медицина здесь бессильна.
>Давайте найдем, почему юми занимает большую долю рынка в россии,
Реклама? Маркетинг? Партнерские программы? В случае FOSS как-то не очень понятно зачем вкладывать деньги в рекламу без монополии на исходники. Грубо говоря, наша студия будет рекламировать Drupal и наши услуги по созданию сайтов на нём, а результатами этой рекламы будут пользоваться все её использующие, пользуясь, что «Drupal» будет на слуху у клиентов. Если вообще захотят отказаться от процентов с UMI, Bitrix,… Не доплачивать же им за использование Drupal в проектах своих клиентов? Такое даже «космонавт» себе не позволяет.
Реклама? Маркетинг? Партнерские программы? В случае FOSS как-то не очень понятно зачем вкладывать деньги в рекламу без монополии на исходники. Грубо говоря, наша студия будет рекламировать Drupal и наши услуги по созданию сайтов на нём, а результатами этой рекламы будут пользоваться все её использующие, пользуясь, что «Drupal» будет на слуху у клиентов. Если вообще захотят отказаться от процентов с UMI, Bitrix,… Не доплачивать же им за использование Drupal в проектах своих клиентов? Такое даже «космонавт» себе не позволяет.
Верстка админки была упомянута для одной цели — если совершаются такие простые ошибки, то что творится внутри самой CMS?
>Впрочем вечный совет всем критикам: «сделай лучше!»
Не любят люди велосипеды. К сожалению.
Не любят люди велосипеды. К сожалению.
Может, к счастью? Поиск выхода из ситуации, который бы не потребовал построения очередного quick'n'dirty-костыля — это воистину пища для мозгов, особенно, если у тебя есть немного времени на это дело.
Использование популярных универсальных CMS чаще всего и является quick'n'dirty-костылём. Уж больно много в них унаследованного кода, который нельзя трогать минимум из-за BC, не говоря о, мягко выражаясь, неочевидной архитектуре и об опасении «всё сломать», потому как тестов нет.
Не соглашусь. Друпель представляет из себя идеальный пример не-костыля: по сути, из архива он только на журнальчик восьмиклассника и годится. Модульность спасёт мир.
А вот реально quick'n'dirty — это хаки к phpBB, которые меня когда-то дико заёбывали взаимной несовместимостью.
А вот реально quick'n'dirty — это хаки к phpBB, которые меня когда-то дико заёбывали взаимной несовместимостью.
тогда резонный вопрос: коль он так близок к идеалу, где-ж его популярность? Вопрос на полном серьезе — вебдевер я начинающий, в болоте этом пока разбираюсь ни разу.
Кого-то отпугивает отсутствие вменяемо локализованной документации, кого-то — некоторые ньюансы модульной системы. Вместе с тем, документация есть на английском языке, если кому-то нужно, а ньюансы вполне известны, и с ними можно ознакомиться, не выжигая Гугл дотла.
запустить контору по саппорту, нанять тех-переводчиков и сделать пяток «сборок» — и рынок у нас в руках? :D
Запустите, наймите, сделайте. Вы же такой крутой, говорите про то, что тыкать в недостатки, пусть даже обоснованно, могут только неудачники, а настоящие мужики молча всё починят и отдадут.
Ну так делайте, чего ж Вы стоите?
Ну так делайте, чего ж Вы стоите?
ну и зачем из контекста выдирать? не «тыкать в недостатки» в «тыкать в бесполезные и никомуненужные недостатки», коих из перечисленных ТС половина. и не «неудачник», а «заказуха/холивор».
дабы не плодить ветки: коммерческий продукт стыдно выпускать, если он прибыль не приносит.
дабы не плодить ветки: коммерческий продукт стыдно выпускать, если он прибыль не приносит.
То есть, если продукт свуйня, но более-менее продаётся, в силу того, что не все в курсе, что у него внутри — это нормально, по-Вашему?
«это бизнес»
нет это не нормально. но и закрывать глаза, на то что у остальных это либо так же, либо своих запарок хватает — тоже не вариант. именно поэтому если неонку внутри (некошерные отступы и устаревшие тэги) не видно — ее нет.
нет это не нормально. но и закрывать глаза, на то что у остальных это либо так же, либо своих запарок хватает — тоже не вариант. именно поэтому если неонку внутри (некошерные отступы и устаревшие тэги) не видно — ее нет.
Тут хорошо подойдёт «вам шашечки или ехать?». Увы, но рынок не способствует созданию продуктов с качественным кодом, заказчики просто не могут его оценить и выбирают «ехать», ещё не ведая, что у «такси» нет запаса прочности. К тому же он может и не понадобиться, если условия не выходят за рамки стандартных.
А потом кто-нибудь ушлый будет внедрять ваши сборки, не отстегивая вам ни копейки и пользуясь вашей рекламой, FOSS же, свобода!
редхат живее всех живых, чем не пример.
RHEL рассчитана на энтерпрайзный рынок с достаточно грамотными специалистами у заказчика, которым поддержка и консультации у «посредников» не нужны, они сами знают систему не хуже «посредников» (после обучения и сертификации в RH :) ). По крайней мере о примерах внедрения RHEL на принципах аутсорса я не слышал.
Рынок же CMS, по-моему, рассчитан на заказчиков, у которых специалистов нет и поддержка нужна на уровне «какую кнопку нажать, чтобы новость добавить?» или модуль написать, редко баг в самой CMS исправить. Это может сделать любой разработчик, владеющий предметом, в крайнем случае он может обратиться на drupal.ru/org, а «наша» фирма ему не нужна, как не нужны «посредники» в случае с RHEL.
А Mandriva вон банкротится.
Рынок же CMS, по-моему, рассчитан на заказчиков, у которых специалистов нет и поддержка нужна на уровне «какую кнопку нажать, чтобы новость добавить?» или модуль написать, редко баг в самой CMS исправить. Это может сделать любой разработчик, владеющий предметом, в крайнем случае он может обратиться на drupal.ru/org, а «наша» фирма ему не нужна, как не нужны «посредники» в случае с RHEL.
А Mandriva вон банкротится.
Не знаю как сейчас, но в 5 модульность не всё решала, чуть ли не в официальном FAQ приводились рецепты кастомизации с патчами ядра, из-за которых обновление превращалось в попоболь.
UFO just landed and posted this here
>> хотя рекомендованный знак это знак дефиса
Можно поподробнее об этом. У нас всегда разделяют подчёркиванием (_) и вроде всё окей. Что мы не учитываем?
Можно поподробнее об этом. У нас всегда разделяют подчёркиванием (_) и вроде всё окей. Что мы не учитываем?
Сам толком UMI никогда не пользовался, сайты делаем на своем велосипеде. Но после этого поста у меня сложилось впечатление, что CMS толковая (раз уж автор, которого эта CMS явно достала, привел такие пустяковые высосанные из пальца аргументы а-ля невалидной верстки и xss в режиме администрирования, не по феньшую расставленных дефисов и вообще не по-джедайски добавленных атрибутов style в коде сайта самой CMS).
Это не высосанные аргументы, а нечто вроде элементарной гигиены, не соблюдая правила которой, значительно увеличиваются шансы однажды эпически обосраться.
ИМХО, валидность верстки волнует в основном всяких версткодрочеров (ни один из топ сайтов её не проходит, проверил google, youtube, facebook, twitter, yandex и т.п.). А корить за использование b вместо strong, это вообще версткодрочерство высшего уровня.
Более того, если бы автор все-таки прочитал стандарт HTML, то увидел что тег b никем не отменен, и не заменен «более семантически правильным» strong. Это 2 разных тега для разных случаев. Названия компаний, к примеру, рекомендуется выделять именно b. Как может UMI CMS догадаться какой из двух использовать не ясно, соответственно претензия высосана из пальца.
Растолкуйте мне, молодому-зеленому, как верстка на офсайте UMI.CMS увеличила Ваши шансы эпически обосраться. Или как это сделали теги <b> вместо <strong>. Или атрибуты umi:element-id=«44», которые, насколько я понимаю, видны только в режиме администрирования.
Это ли должно быть предметом критики, если CMS действительно настолько херовая?
Напоминает «If you can't win an argument, correct their grammar instead»
Это ли должно быть предметом критики, если CMS действительно настолько херовая?
Напоминает «If you can't win an argument, correct their grammar instead»
Увы umi:element-id=«44» по всему сайту. Ну если это заложено в шаблон.
Во-первых, успокойтесь и не пытайтесь меня оскорбить — я ничего не говорил о _моих_ шансах обосраться =)
Во-вторых, критика не сводится только к семантически неправильным тегам. В посте достаточно аргументированно рассмотрены шесть аспектов, по которым у автора возникли вопросы. Если для вас XSS уязвимости в админке не аргумент, тогда — удачи, разговаривать с вами больше не о чем.
И в-третьих. Код веб-страницы обрабатывается машиной в соответстивии с определенными стандартами. Если стандарты были похерены, то нет гарантии, что страница будет обработана правильно. Странно, что это нужно объяснять.
Во-вторых, критика не сводится только к семантически неправильным тегам. В посте достаточно аргументированно рассмотрены шесть аспектов, по которым у автора возникли вопросы. Если для вас XSS уязвимости в админке не аргумент, тогда — удачи, разговаривать с вами больше не о чем.
И в-третьих. Код веб-страницы обрабатывается машиной в соответстивии с определенными стандартами. Если стандарты были похерены, то нет гарантии, что страница будет обработана правильно. Странно, что это нужно объяснять.
Я совершенно спокоен, не имел в виду ничего личного и не хотел оскорбить, по поводу шансов — просто процитировал Ваш комментарий.
Стандарты нужно соблюдать, но бывают и исключения. Честно говоря, не думал, что они выпускают наружу эти свои umi:something. Логика подсказывала, что они их вырезают при показы обычным смертным посетителям. Уже написал выше, она меня подвела.
Стандарты нужно соблюдать, но бывают и исключения. Честно говоря, не думал, что они выпускают наружу эти свои umi:something. Логика подсказывала, что они их вырезают при показы обычным смертным посетителям. Уже написал выше, она меня подвела.
Странно, что они упоминают свяной. У нас есть какой-то вспомогательный сайт на юми… рсновной сайт работает на том, что осталось от битрикс8 — нашего кода там больше + ядро тоде правили, чтобы баги не потерли наши данные.
Помимо этого явакод также никак не обрабатываетсяКакой код?
Интернет магазин Азбуки вкуса делал я, и да, он на UMI.CMS.
Хороший сайт. Только скорая помощь в шапке смущает.
Вы даете ссылку на shop.av.ru/, а автор на www.azbukavkusa.ru/
Поскольку на официальном сайте UMI не указаны ссылки, я выбрал первый сайт, который нашел Google по запросу «азбука вкуса».
Ссылку из материала убрал.
Ссылку из материала убрал.
Плохо смотрели, ссылка есть.
Извините, если не по адресу, хочу сообщить о баге. Строке с банками от прокрутки на тачпаде башню сносит в любом браузере. OS X Lion.
>Обратная сторона этой возможности — применение нестандартных атрибутов у html тегов (например: umi:element-id=«44» umi:region=«row» umi:field-name=«name» umi:empty=«Название раздела» umi:delete=«delete»), в результате чего получается не валидная верстка.
Что значит «нестандартных атрибутов»? Вообще-то возможность определения своих неймспейсов в html никто не отменял. То что w3c-валидатор не понимает определенный пользователем неймспейс, так это проблема валидатора — пишите им багрепорт. А по делу: не надоело делать сайты не для людей, а для роботов-валидаторов?
Очень много спорных пунктов, например то что из админки системы можно реализовать XSS уязвимость. Зачем давать доступ в админку тем, кто будет реализовывать уязвимости? Очевидно, что имея доступ в админку можно что-то поломать.
И последнее: «явакод» — это что такое?
Что значит «нестандартных атрибутов»? Вообще-то возможность определения своих неймспейсов в html никто не отменял. То что w3c-валидатор не понимает определенный пользователем неймспейс, так это проблема валидатора — пишите им багрепорт. А по делу: не надоело делать сайты не для людей, а для роботов-валидаторов?
Очень много спорных пунктов, например то что из админки системы можно реализовать XSS уязвимость. Зачем давать доступ в админку тем, кто будет реализовывать уязвимости? Очевидно, что имея доступ в админку можно что-то поломать.
И последнее: «явакод» — это что такое?
А вы не рассматриваете ситуацию, когда у одного из редакторов (ну там блондинка-секретарша добавляющая новости) сопрут/угадют пароль, и тогда злоумышленник вполне может использовать XSS, для получения больших прав, чем положено редактору.
Рассматриваю, точно так же рассматриваю ситуацию, что у главного редактора (не блондинка с правами чуть большими чем у блондинки) сопрут пароль и используют его для прямого доступа к файловой системе.
Вы предлагаете для пользователей сделать отдельную галку: запретить XSS в админке? Коробочная CMS — общее решение. Кто-то хочет в админке писать javascript-код прямо в html-редактор, кто-то это называет необходимой фичей, кто-то уязвимостью, решать разработчикам системы, что разрешать, а что запрещать. Это просто особенность системы и надо ее учитывать.
Вообще, для таких «не надежных» редакторов делается отдельный кабинет со стороны сайта, и доступы в админку не даются.
Вы предлагаете для пользователей сделать отдельную галку: запретить XSS в админке? Коробочная CMS — общее решение. Кто-то хочет в админке писать javascript-код прямо в html-редактор, кто-то это называет необходимой фичей, кто-то уязвимостью, решать разработчикам системы, что разрешать, а что запрещать. Это просто особенность системы и надо ее учитывать.
Вообще, для таких «не надежных» редакторов делается отдельный кабинет со стороны сайта, и доступы в админку не даются.
Хм, а что такого сложного в галке удалять/экранировать javascript в настройках юзера. Большинство юзеров добавляющих контент, его всё равно не знают. А не надежных редакторов полно.
P.S. я тоже когда-то думал, что не стоит ограничивать юзеров в админке ;)
P.S. я тоже когда-то думал, что не стоит ограничивать юзеров в админке ;)
Да ничего сложного, как и в реализации огромного количества галок и настроек, которые еще надо задокументировать, а пользователю не забыть включить.
В итоге получим коллайдер, которым управлять будет не реально =)
В любой системе есть свои преимущества и недостатки, у любого продукта есть своя концепция, что разработчики будут делать, а что никогда не будут. Это не из-за того что сложно, а из-за того что концепция такая выбрана.
В итоге получим коллайдер, которым управлять будет не реально =)
В любой системе есть свои преимущества и недостатки, у любого продукта есть своя концепция, что разработчики будут делать, а что никогда не будут. Это не из-за того что сложно, а из-за того что концепция такая выбрана.
> То что w3c-валидатор не понимает определенный пользователем неймспейс, так это проблема валидатора
Нет. Это проблема не w3c, а вполне конкретного верстальщика, который обязан проверять все баги верстки на фоне ложного срабатывания валидатора.
Нет. Это проблема не w3c, а вполне конкретного верстальщика, который обязан проверять все баги верстки на фоне ложного срабатывания валидатора.
Да это не проблема для нормального верстальщика, который знает стандарты и знает, что валидатор тоже может ошибаться.
Это проблема касается скорее «версткодрочеров» (как их кто-то тут назвал), которые не могут спокойно дышать, когда валидатор вываливает им что верстка не валидна и не выдает им заветную кнопочку что все валидно.
Это проблема касается скорее «версткодрочеров» (как их кто-то тут назвал), которые не могут спокойно дышать, когда валидатор вываливает им что верстка не валидна и не выдает им заветную кнопочку что все валидно.
Если вы сами сопровождаетет/модифицируете свой код — то нет вопросов, но если ваш код отдается на сторону — как-то уж очень неприлично.
И почему «версткодрочеров»? Сдавать любой код (не только HTML) с предупреждениями, ошибками, и соплями — моветон. Хоть в Java, хоть в PHP, хоть где.
И если в коде 100 ложных срабатываний, пропустить 101 реальное — вполне обычное дело.
И почему «версткодрочеров»? Сдавать любой код (не только HTML) с предупреждениями, ошибками, и соплями — моветон. Хоть в Java, хоть в PHP, хоть где.
И если в коде 100 ложных срабатываний, пропустить 101 реальное — вполне обычное дело.
Я не говорю, что отдавать НЕ валидную верстку/код — это нормальная практика. Я говорю, что есть бага именно в w3c-валидаторе, который забивает на то, что разрешено стандартом и считает не валидным то, что на самом деле валидно.
Вот вполне валидное определение неймспейса.
Почему я должен отказываться от того, что разрешено стандартом из-за какого-то глюка в валидаторе? как будто бы я делаю сайт для него.
Вот вполне валидное определение неймспейса.
<html xmlns="http://www.w3.org/1999/xhtml" xmlns:myns="http://myns.ru/">
....
<a href="/" myns:myAttr="boo" />
....
Почему я должен отказываться от того, что разрешено стандартом из-за какого-то глюка в валидаторе? как будто бы я делаю сайт для него.
> Почему я должен отказываться
Вы никому ничего не должны.
Просто выгода от использования своего пространства имен кажется мне совершенно не очевидной, а наличие нескольких сотен ложных предупреждений об ошибке вполне очевидны. На их фоне сложно искать реальные баги, и сопровождение большого проекта (сотни шаблонов), который много лет пилят разные верстальщики и программисты превращается в ад.
Вы никому ничего не должны.
Просто выгода от использования своего пространства имен кажется мне совершенно не очевидной, а наличие нескольких сотен ложных предупреждений об ошибке вполне очевидны. На их фоне сложно искать реальные баги, и сопровождение большого проекта (сотни шаблонов), который много лет пилят разные верстальщики и программисты превращается в ад.
Выгода очевидна — edit in place в юми, jQuery тоже использует собственные атрибуты и ничего страшного. Это удобно и по стандарту.
> Выгода очевидна — edit in place в юми,
Извините, я не понял зачем ломать валидатор ради edit in place. Можно сделать ровно то же не ломая ничего.
> jQuery тоже использует собственные атрибуты и ничего страшного.
> Это удобно и по стандарту.
jQuery использует свои атрибуты вопреки стандарту. Но делает это в динамике. После загрузки страницы. При этом Кац в своей Библии предостерегает разработчиков от использования «собственных атрибутов».
Извините, я не понял зачем ломать валидатор ради edit in place. Можно сделать ровно то же не ломая ничего.
> jQuery тоже использует собственные атрибуты и ничего страшного.
> Это удобно и по стандарту.
jQuery использует свои атрибуты вопреки стандарту. Но делает это в динамике. После загрузки страницы. При этом Кац в своей Библии предостерегает разработчиков от использования «собственных атрибутов».
>Извините, я не понял зачем ломать валидатор ради edit in place
А никто его не ломает, он сам ломается) при чем тут edit in place? Конечно же можно вырезать эти атрибуты в режиме обычного посетителя, но это сразу минус производительности. Я бы рекомендовал юми сделать настройку, чтобы они вырезались простейшей регуляркой для тех кому это важно.
>jQuery использует свои атрибуты вопреки стандарту. Но делает это в динамике.
Нет, не вопреки, а именно ПО стандарту. И да, валидатор забивает на динамику и это опять же не правильно с его стороны. Т.е. если страница, которая проходит валидацию после отработки динамики не валидна, то грош цена такой «валидной» верстке.
А никто его не ломает, он сам ломается) при чем тут edit in place? Конечно же можно вырезать эти атрибуты в режиме обычного посетителя, но это сразу минус производительности. Я бы рекомендовал юми сделать настройку, чтобы они вырезались простейшей регуляркой для тех кому это важно.
>jQuery использует свои атрибуты вопреки стандарту. Но делает это в динамике.
Нет, не вопреки, а именно ПО стандарту. И да, валидатор забивает на динамику и это опять же не правильно с его стороны. Т.е. если страница, которая проходит валидацию после отработки динамики не валидна, то грош цена такой «валидной» верстке.
> А никто его не ломает, он сам ломается) при чем тут edit in place?
При том, что результатом его работы является поломка валидатора. Можно было сделать без этого, но разработчики UMI сделали именно так. Плохой валидатор или хороший — другой разговор.
Об остальном тоже не буду. Речь идет не о jQuery, и не о том что лишний xsl:if при включенном кэше — проблема высосанная из пальца.
==
мы ушли далеко в офтопик. Но суть остается — CMS не должна осложнять работу разработчика. И это недоработка разработчиков UMI. Не критичная, не самая неприятная (и без того хватает недоработок), но недоработка.
При том, что результатом его работы является поломка валидатора. Можно было сделать без этого, но разработчики UMI сделали именно так. Плохой валидатор или хороший — другой разговор.
Об остальном тоже не буду. Речь идет не о jQuery, и не о том что лишний xsl:if при включенном кэше — проблема высосанная из пальца.
==
мы ушли далеко в офтопик. Но суть остается — CMS не должна осложнять работу разработчика. И это недоработка разработчиков UMI. Не критичная, не самая неприятная (и без того хватает недоработок), но недоработка.
Можно пробовать использовать другой валидатор, или валидировать шаблоны на уровне шаблонов, а не на уровне уже сгенерированной страницы. Все равно ведь зачастую страница хранится не в одном шаблоне, а может храниться в десятке или даже сотне файлов — блоков, и после обнаружения ошибки валидатором надо еще потом найти где именно лежит ответственный за эту ошибку блок кода.
В любом случае, бороться с ложными срабатываниями мне тоже кажется несколько странным.
В любом случае, бороться с ложными срабатываниями мне тоже кажется несколько странным.
> Можно пробовать использовать другой валидатор,
Скиньте плиз адрес на плагин без дополнительных примочек в виде Java или выхода на сторонний ресурс. Я пока не нашел.
> В любом случае, бороться с ложными срабатываниями
> мне тоже кажется несколько странным.
Вы кажется не поняли о чем я пишу. Я пишу о том что при отладке кода в идеале не должно быть никаких ошибок. Все равно каких. Потому что если ошибки есть, с ними все равно нужно разбираться и тратить на это время. А его и так мало.
Скиньте плиз адрес на плагин без дополнительных примочек в виде Java или выхода на сторонний ресурс. Я пока не нашел.
> В любом случае, бороться с ложными срабатываниями
> мне тоже кажется несколько странным.
Вы кажется не поняли о чем я пишу. Я пишу о том что при отладке кода в идеале не должно быть никаких ошибок. Все равно каких. Потому что если ошибки есть, с ними все равно нужно разбираться и тратить на это время. А его и так мало.
Чтобы получилась хорошая годная цмс вам нужно:
1. партнерская программа с большими откатами, хорошо мотивирующая студии продавать именно вашу цмс
2. реклама во всяких «бизнесовых, деловых» местах, чтобы заказчик просил у студии именно вашу цмс (в рекламе используйте слова «эффективность вашего бизнеса», «умные инвестиции» etc, заказчик разводится как кролик)
3. говнокод, тонны багов и мутный интерфейс, чтобы студия могла зарабатывать на поддержке и чтобы клиент не мог уйти
например автогенерация метатегов — это очевидное зло, отбирающее хлеб у студийных сеошников, такой функции не место в коммерческой цмс
1. партнерская программа с большими откатами, хорошо мотивирующая студии продавать именно вашу цмс
2. реклама во всяких «бизнесовых, деловых» местах, чтобы заказчик просил у студии именно вашу цмс (в рекламе используйте слова «эффективность вашего бизнеса», «умные инвестиции» etc, заказчик разводится как кролик)
3. говнокод, тонны багов и мутный интерфейс, чтобы студия могла зарабатывать на поддержке и чтобы клиент не мог уйти
например автогенерация метатегов — это очевидное зло, отбирающее хлеб у студийных сеошников, такой функции не место в коммерческой цмс
О да. к пункту 2 надо добавить слова «продукт», «решение», «обеспечивает», «продукт» (ещё раз).
После этого слова объединяются в одну солянку и получается: Программный продукт обеспечивает надёжные решения для бизнеса, и эффективность бизнеса напрямую зависит от выбранного проверенного продукта. (ну или что то подобное, что часто можно услышать из уст г-на Рыжикова.
После этого слова объединяются в одну солянку и получается: Программный продукт обеспечивает надёжные решения для бизнеса, и эффективность бизнеса напрямую зависит от выбранного проверенного продукта. (ну или что то подобное, что часто можно услышать из уст г-на Рыжикова.
с Битрикса тоже не уходят :)
Хороший пример, не относящийся к вебдеву, но тем не менее подходящий под вышеперечисленные пункты — 1С
Пользовался один год UMI.CMS для сайта со статьями, заплатил 8900 руб за первый год, потом продлил один раз ради того чтобы получить тех. обслуживание и обновление системы.
В итоге тех. поддержка не помогла, сайт не заработал (после простого обновления).
Впечатление за что берут деньги непонятно. А просто размещать статьи на сайте и платить за каждый год не вижу смысла. С каждым обновлением происходили какие-то ошибки и требовалась помощь тех поддержки.
(на сайте не было никаких доп. наворотов и сторонних модулей, только голая система)
В итоге тех. поддержка не помогла, сайт не заработал (после простого обновления).
Впечатление за что берут деньги непонятно. А просто размещать статьи на сайте и платить за каждый год не вижу смысла. С каждым обновлением происходили какие-то ошибки и требовалась помощь тех поддержки.
(на сайте не было никаких доп. наворотов и сторонних модулей, только голая система)
честно говоря мне UMI.CMS изначально не понравилась, когда приглядывался к ней. документация очень слабая, а это о многом говорит
Усугубляет тот факт, что документация более чем нужна. Для вставки банального скрипта (допустим, форма отправки сообщения), необходимо создать минимум 7 файлов. У каждого — своя структура. И если у какой-либо иной системы скудная документация, но всё делается в две строчки, тот тут качество документации становится критическим моментом.
В битриксе (хотя я его и недолюбливаю) можно открыть страницу контактов, воткнуть PHP — код, и он заработает.
Про Yii, Codeigniter и основанные на них системы я вообще молчу — там в этом плане сказка.
В битриксе (хотя я его и недолюбливаю) можно открыть страницу контактов, воткнуть PHP — код, и он заработает.
Про Yii, Codeigniter и основанные на них системы я вообще молчу — там в этом плане сказка.
В UMI реализованы аналогичные возможности uf.umi-cms.ru/
Подозревал, что данная CMS говно, но не знал, что всё настолько плохо и ужасно устарело.
Если рассматривать информационные сайты и сайты-визитки, то как отметили выше, wp и txp заметно лучше umi (хотя и там своих проблем хватает).
А вот с интернет-магазинами всё грустнее. Буржуйские CMS-ки требуют серьезного допиливания там, где в наших всё работает из коробки. Ну не знают они про киви и почту России. А со (всеми известными мне) русскими коробочными интернет-магазинами ситуация примерно такая же, как описано в этой статье. Или тормозит, или не работает, или сделано через одно место, а скорее всего всё сразу. Плюс документация отсутствует в принципе.
В целом же, на мой скромный вкус из «большой тройки» (битрикс, уми, неткат) уми наименее пахучее.
А вот с интернет-магазинами всё грустнее. Буржуйские CMS-ки требуют серьезного допиливания там, где в наших всё работает из коробки. Ну не знают они про киви и почту России. А со (всеми известными мне) русскими коробочными интернет-магазинами ситуация примерно такая же, как описано в этой статье. Или тормозит, или не работает, или сделано через одно место, а скорее всего всё сразу. Плюс документация отсутствует в принципе.
В целом же, на мой скромный вкус из «большой тройки» (битрикс, уми, неткат) уми наименее пахучее.
UFO just landed and posted this here
Не нравится, не пользуйте. Пипл хавает и ладно. Но за критику спасибо. Мне всегда было интересно, почему я не использую юми. Теперь есть на то причины. Кроме цены, конечно же.
Если захотите сделать на этой CMS не стандартный (для нее) функционал, придется очень много поломать голову. Т.к. у той же Джумлы модули пишутся гораздо проще. В документации по Юми очень тяжело разобраться. По крайнем мере после чтения переведенных документаций по ZF или Yii, где все толком объяснено, чувствуешь большую разницу. Возникает ощущение, что документация и вики пишется на «отстань», чего не скажешь об opensource проектах.
Изучая исходные коды системы понимаешь, что самый любимый (и похоже единственный) шаблон проектирования, который изучила команда разработчиков, это Singleton. Он используется везде, во всех макросах. Местами в сорцах можно видеть турдукен-код.
Единственный плюс Юми по сравнению с теми же OpenSource, это сколько-нибудь рабочая интеграция с 1С. А для интернет-магазина с большим товарооборотом она практически необходима. Выбирал Юми только из-за этого.
Если потребуется большая кастомизация, не стоит выбирать эту CMS. Если стандартного функционала хватает, можно потратить несколько месяцев на разработку сайта на ней. Но, быстро сделать сайт, особенно в первый раз, на ней точно не получиться.
Также к своему мнению прикрепляю пост гнева в адрес этой CMS: keltanas.livejournal.com/22250.html
Изучая исходные коды системы понимаешь, что самый любимый (и похоже единственный) шаблон проектирования, который изучила команда разработчиков, это Singleton. Он используется везде, во всех макросах. Местами в сорцах можно видеть турдукен-код.
Единственный плюс Юми по сравнению с теми же OpenSource, это сколько-нибудь рабочая интеграция с 1С. А для интернет-магазина с большим товарооборотом она практически необходима. Выбирал Юми только из-за этого.
Если потребуется большая кастомизация, не стоит выбирать эту CMS. Если стандартного функционала хватает, можно потратить несколько месяцев на разработку сайта на ней. Но, быстро сделать сайт, особенно в первый раз, на ней точно не получиться.
Также к своему мнению прикрепляю пост гнева в адрес этой CMS: keltanas.livejournal.com/22250.html
Любопытный комментарий:
Ждём завтра утром работу отдела маркетинга и комментарии от представителей UMI.
Стыдно признаться, но я вашу ЖЖшечку не читал )))
Просто у нас отдел маркетинга мониторит все упоминания UMI.CMS в сети и сообщает, когда надо вмешаться )))
Ждём завтра утром работу отдела маркетинга и комментарии от представителей UMI.
Очень здорово что вы знаете что такое DI и читали Фаулера. Только это не единственное, что гарантирует качество продукта и говорит о «крутости» программиста.
Вот с чем согласен точно, так это с тем, что не надо использовать CMS там, где она не применима.
Или вы будете делать сайт-визитку на ZF или Yii. Не боитесь получить «паттерн головного мозга»?
Вот с чем согласен точно, так это с тем, что не надо использовать CMS там, где она не применима.
Или вы будете делать сайт-визитку на ZF или Yii. Не боитесь получить «паттерн головного мозга»?
Очень часто работа над сайтом идёт итерационно, то есть сначала нужна визитка с минимальной функциональностью, берётся первая попавшаяся CMS, затем требуется функциональность стандартных расширений, затем нестандартных, затем самописных, а потом натыкаешься на невозможность реализовать нужную функциональность в рамках CMS и стоишь перед выбором то ли «патчить ядро», то ли переписывать всё с нуля, то ли брать другую CMS, которой хватит на нужную сейчас функциональность (но не факт, что на следующей итерации ситуация не повторится).
Как-то фреймворки позволяют избежать такого, хотя для запуска первоначальной визитки приходится больше усилий приложить.
Как-то фреймворки позволяют избежать такого, хотя для запуска первоначальной визитки приходится больше усилий приложить.
Согласен. Если бы я делал проект для себя или это было бы моей основной обязанностью на основной работе, то какие тут могут быть разговоры о CMS. Конечно же своя архитектура с IoC и девочками легкого поведения =)
Но целевая аудитория то у CMS — не я, а студии, которым надо быстро собрать типовой проект.
Но целевая аудитория то у CMS — не я, а студии, которым надо быстро собрать типовой проект.
Кстати, очень похоже, что Вы работаете в UMI?
Так вы считаете, что она не достойна, чтобы в ней были реализованы «своя архитектура с IoC и девочками легкого поведения». На CMS конторы, которая платит тебе деньги пох? Конечно, это же проект не для себя. Пускай там в TS инстанцируются классы и юзаются синглтоны и в них же сосредоточена вся логика. Я бы посмотрел, как к такой системе применяется Unit тестирование.
И что же гарантирует качество продукта по вашему? Крутой маркетинг и гавнокод под капотом?
Так вы считаете, что она не достойна, чтобы в ней были реализованы «своя архитектура с IoC и девочками легкого поведения». На CMS конторы, которая платит тебе деньги пох? Конечно, это же проект не для себя. Пускай там в TS инстанцируются классы и юзаются синглтоны и в них же сосредоточена вся логика. Я бы посмотрел, как к такой системе применяется Unit тестирование.
И что же гарантирует качество продукта по вашему? Крутой маркетинг и гавнокод под капотом?
Нет, я не работаю в юми, но хорошо знаком с ее архитектурой. Согласен, что она не идеальна и требует рефакторинга, но она и не такая ужасная, как вы тут описывайте, а самое главное, что она вообще есть.
Представляю, как вы прочитали умные книжки и побежали моментально рефакторить свои старые проекты конторам которые платят вам деньги.
Если вы такой умный и опытный разработчик, как вы вообще посмотрели в сторону коробки для проекта который пришлось так сильно точить под нее, зачем?
Ну и да, расскажите, как именно DI вам помешало реализовать кастомный функционал? И как бы оно вам помогло? Очень интересно, правда.
Представляю, как вы прочитали умные книжки и побежали моментально рефакторить свои старые проекты конторам которые платят вам деньги.
Если вы такой умный и опытный разработчик, как вы вообще посмотрели в сторону коробки для проекта который пришлось так сильно точить под нее, зачем?
Ну и да, расскажите, как именно DI вам помешало реализовать кастомный функционал? И как бы оно вам помогло? Очень интересно, правда.
Да легко. Я бы смог настроить тестовое окружение, где вместо синглтонов мне бы выдавались заглушки классов, не работающие с БД. А так, чтобы протестировать один не большой класс, мне надо поднимать все standalone окружение и иметь рабочую БД.
А в сторону коробки, про которую столько хорошего пишут и рассказывают, смотришь, когда хочешь сэкономить время, естественно.
И почему все Юмийцы любять сразу переходить на личности? По другому общаться не получается?
А в сторону коробки, про которую столько хорошего пишут и рассказывают, смотришь, когда хочешь сэкономить время, естественно.
И почему все Юмийцы любять сразу переходить на личности? По другому общаться не получается?
Не нужно сваливать с больной головы на здоровую. Вы сами привели ссылку на свой ЖЖ, где перешли на личности и ткнули лицом в г… и разработчиков и руководителей.
Я за здоровую критику, так что закончим переход на личности.
По делу:
Вы мне сейчас описали абстрактный пример, который демонстрирует сложность тестирования ПО, имеющего не идеальную архитектуру с зависимостями. Спасибо.
Я же уже сказал, что не считаю архитектуру идеальной. Она требует рефакторинга.
Кстати, подключить loC в текущую архитектуру юми не составит особого труда.
Я за здоровую критику, так что закончим переход на личности.
По делу:
Вы мне сейчас описали абстрактный пример, который демонстрирует сложность тестирования ПО, имеющего не идеальную архитектуру с зависимостями. Спасибо.
Я же уже сказал, что не считаю архитектуру идеальной. Она требует рефакторинга.
Кстати, подключить loC в текущую архитектуру юми не составит особого труда.
Вы сейчас чушь какую-то сморозили. Считаете, что для визитки применима Umi CMS и не применим ZF или Yii?
Если в Вашем понимании сайт-визитка — это сайт вообще без php или сайт на гавноCMS, то мне Вас очень жаль.
Если в Вашем понимании сайт-визитка — это сайт вообще без php или сайт на гавноCMS, то мне Вас очень жаль.
Я не говорил, что на фреймворках нельзя сделать визитку и я прекрасно понимаю что такое сайт-визитка, не передергивайте.
Мой посыл в том, что всему свое применение и если вы выбрали для себя не тот инструмент, так это не проблема инструмента, а проблема выбора.
Мой посыл в том, что всему свое применение и если вы выбрали для себя не тот инструмент, так это не проблема инструмента, а проблема выбора.
Не вижу проблем делать визитку на yii, даже как-то проще на мой взгляд.
// это сколько-нибудь рабочая интеграция с 1С
Это не такая большая проблема. Я писал и core и интеграцию для www.fprints.ru/ — около 9-и тысяч товаров, в 1С хранится все от картинок, до характеристик. На все про все ушло меньше рабочей недели.
И не думаю, что оно там лучше работает :)
Это не такая большая проблема. Я писал и core и интеграцию для www.fprints.ru/ — около 9-и тысяч товаров, в 1С хранится все от картинок, до характеристик. На все про все ушло меньше рабочей недели.
И не думаю, что оно там лучше работает :)
По всем пунктам согласен.
Когда начал изучать UMI, загорелся и было впечатление, что она крутая, мощная, гибкая и т.д. Когда стал работать с ней дальше и больше, перестал так считать.
Совсем не гибкая система. Почти всегда для выполнения пожеланий заказчиков приходится много чего допиливать. Сейчас когда кто спрашивает, никому не рекомендую выбирать её.
Но есть и плюс. Порог входа высоковат для школоло, и заказчики, готовые купить CMS за 10-20к, готовы и фрилансеру нормально заплатить. Как следствие, за допиливания UMI.CMS хотя бы платят нормально, и конкуренция низкая. :)
Когда начал изучать UMI, загорелся и было впечатление, что она крутая, мощная, гибкая и т.д. Когда стал работать с ней дальше и больше, перестал так считать.
Совсем не гибкая система. Почти всегда для выполнения пожеланий заказчиков приходится много чего допиливать. Сейчас когда кто спрашивает, никому не рекомендую выбирать её.
Но есть и плюс. Порог входа высоковат для школоло, и заказчики, готовые купить CMS за 10-20к, готовы и фрилансеру нормально заплатить. Как следствие, за допиливания UMI.CMS хотя бы платят нормально, и конкуренция низкая. :)
Ещё кстати сильно удручает частота ситуаций, когда возникает проблема, но по ней ничего не гуглится. Приходится либо копаться глубоко самому, либо писать в саппорт, который наверное уже сам утомился этим.
Спасибо за статью, было интересно. Статья и послед. обсуждение дали какую ни есть картинку по UMI.
Пару копеек про теги b и i. Они ничуть не устаревшие с т.з. семантики. Ими выделяют текст, который, допустим, в оригинале автором выделен стилистически или визуально, но при этом не имеет никакого смыслового веса в общем контексте произведения.
Столкнулись с этой системой на двух сайтах — проблем полные штаны!
Я бы на месте разработчиков был благодарен за такую статью. Все проблемы наружу вылезли, и денег за исследования платить не пришлось. Только отзыв получился несколько однобоким. Такое чувство, будто автор совсем ничего хорошего в UMI не нашел, хотя мне в целом продукт нравится.
Было бы неплохо прочитать аналогичную статью про первую пятёрку коммерческих CMS.
UFO just landed and posted this here
Похер, что у них на сайте. Мне не нравиться юми из-за того что не смотря на их заявлении об открытом коде, этот код хер разберешь. Ну и конечно с переносом на домены траблы, с локала на дев хостинг с дев хостинга на сайт, один геммор.
Здравствуйте!
Прежде всего, от лица компании Юмисофт хочу поблагодарить автора статьи за оказанное внимание к нашему продукту и привлечение внимания аудитории :)
Перед тем, как ответить по пунктам, хочу обратить внимание на две вещи:
1. Классическая критика по определению подразумевает поиск не только недостатков, но и достоинств рассматриваемого объекта. Почитайте Белинского, например. Ваша статья в этом смысле несколько однобока — достоинства просто не упоминаются, как будто их нет.
2. Предыдущая статья автора называется «За что я люблю Drupal» и начинается словами «По моему скромному мнению, CMS Drupal наиболее близко подошла к понятию «идеальная CMS».» Это говорит о некоторой предвзятости критика.
Теперь наши ответы по существу критики.
Так, например мне, потребовалось получить уже не один десяток бесплатных лицензий, а поскольку все лицензии привязаны к домену, то при переносе сайтов на рабочие домены лицензию нужно получать заново.
Ключи привязываются к доменам. Чтоб перенести CMS на другой домен нужно написать в Службу Заботы и они вышлют новый ключ. Некоторым пользователям бесплатной версии почему-то проще сгенерить новый ключ.
На главной странице официального сайта написано, что UMI.CMS используют более 10 000 сайтов и приведен список крупных сайтов, которые используют данную систему.
На самом деле уже около 15000 внедрений, просто сайт еще не обновили. Плюс несколько тысяч сайтов на UMI.ru, nastart.ru и в других SaaS. Сейчас мы работаем над новым сайтом и обновим цифры.
Сколково действительно месяц назад переехал на самописный движок, уберем.
Связной — ok.svyaznoy.ru/
Правительство Москвы купило у нас несколько тысяч лицензий для сайтов детсадов и школ (с другими системами пользователи не смогли разобраться). Подробности тут
Сайт вики также сделан не на UMI.CMS, а на open source движке MediaWiki.
Верно. Мы сами не разрабатываем движок для Вики, а пользуемся готовыми отраслевыми решениями.
Чтобы установить UMI.CMS себе на хостинг необходимо скачать файлик install.php, который сам скачает все файлы CMS из интернета. Соответственно не получится иметь у себя в резервных копий UMI разных версий, поскольку скачивается всегда последняя версия.
У большого количество разного софта, в том числе у браузера Google Chrome установщик устроен точно также. И более того, если кому-то зачем-то надо иметь старые версии (что само по себе непонятно зачем), то ничто не мешает раз в месяц скачивать и хранить.
Следует заметить, что UMI.CMS необходимо наличие на сервере расширения php xsl, которое установлено не на всех хостингах.
Верно. Мы ведем учет всех хостингов, на которых система работаем по-умолчанию. Более того, 12 из них имеют специальные тарифные планы «UMI» по ценам, не выше рыночных. Так удобнее и для хостеров, и для клиентов, и для разработчиков. Подробнее тут
Полная пробная версия UMI.CMS без установленных демо сайтов занимает 180 мб (4 985 файлов и 1 277 папок), база данных состоит из 80 таблиц размером 3,5 мб.
Верно. Ничего страшного здесь не видим, при современных каналах связи такой объём выкачивается за несколько минут. Код самой CMS весит значительно меньше, чем файлы контента. Большинство старых проприетарных CMS в разы тяжелее.
При редактировании материалов в UMI.CMS нет простой кнопки «Предпросмотр», зато есть три кнопки «Сохранить»:
Согласен. Эти кнопки сделаны до появления Edit-in-place, который по своей природе не требует предпросмотра. В будущем мы планируем эти кнопки переделать и по месту расположения и по числу.
В UMI.CMS используются макросы, которые вызывают определенные действия (например показ элемента каталога, фотогалереи и т.д.). При вставки этих макросов в визуальный редактор (используется Tinymce) они оборачиваются тегами p. В результате при срабатывании большинства макросов внутри тега p появляются теги div, что приводит к не валидной верстке.
Визуальный редактор — зло с точки зрения кода. Но добро для блондинок. Любой визуальный редактор по определению корёжит код. Мы не обнаружили ни одной CMS, где ВИЗИВИГ работал бы идеально.
К счастью в версии 2.8.5 разработчики предложили новый вариант — помещение всех шаблонов в папку templates.
Приятно, что хоть это вы оценили )
Автоматическое генерировании тегов description и keywords также не поддерживается.
За автогенерируемые тэги поисковики очень легко могут пессимизировать ваш сайт. Тэги должны писать специалисты по SEO, вручную и вдумчиво. Мы много консультировались с лучшими сеошниками страны и выполнили их рекомендации что и как делать.
ЧПУ в UMI.CMS генерируется автоматически, но по умолчанию в качестве разделителей между словами используется знак подчеркивания "_", хотя рекомендованный знак это знак дефиса "-" (возможность включения использования дефиса есть, но она спрятана очень глубоко и настраивается в config.ini).
Настройка любой системы через плэйн-текстовые конфигурационные файлы — это де-факто стандарт и наиболее привычный путь для любого разработчика.
В последние версии UMI.CMS встроена поддержка сервиса MegaIndex и в настройках модуля SEO можно указать свои данные от аккаунта к этому сервису. По умолчанию там стоят данные от UMI — логин и пароль, скрытый за звездочками. Этот пароль можно легко подсмотреть (например через расширение Web Developer для Firefox). В результате можно попасть в аккаунт UMI на сайте MegaIndex, где находится список сайтов, воспользовавшихся этой функцией у себя на сайте. В данных отчетов видны ключевые слова, позиции сайтов и другая информация.
Верно. Сделан отдельный доступ к Мегаиндексу для проверки из UMI.CMS. Аккаунт в Мегаиндексе не требует защиты, т.к. никаких секретных данных в этом аккаунте не хранится, позиции любого сайта в поисковиках — открытая информация.
При использовании xslt шаблона яваскрипты работают только если их вставить в текстовый редактор (чего тоже достаточно, чтобы натворить бед).
Непонятно. Наверное имеется в виду “редактор исходного кода”. Если так, то такое поведение существует в любой системе. Яваскрипты — в исходный код, только так.
Обновления больная тема многих CMS. В UMI.CMS, например, при обновлении старой версии на новую могут пропасть некоторые модули, которые были в раньше данной редакции системы, т.е. помимо платных обновлений (а обновления платные) потребуется доплатить за пропавший при обновлении модули.
Если модуль исключен из редакции или при переходе на другую редакцию, то логично что он отключится. Если закончился триальный срок демо-версии, отключатся все модули, кроме включенных в бесплатную версию. Все логично.
Файлы системы находят в папке classes, большинство функций и классов в них никак не документированы (комментарии есть только в 82 файлах из 786), т.е. глубоко разобраться в UMI.CMS без затраты большого количества времени не удастся.
Признаю, что часть редко используемых классов еще не покрыты документацией, но это делается постоянно. Если вы столкнулись с пробелом документации — просто напишите в СЗ об этом и в короткий срок это будет описано. В последний год-полтора такие запросы стали редкостью.
Все свои дополнительные функции в UMI.CMS следует писать в файлах custom.php, которые следует размещать в системных папках. Со временем файл custom.php разрастается своими функциями, соответственно возникают проблемы с включением/отключением отдельных функций, переносом их между проектами.
Это не так. С версии 2.8.5 вместе с раскидыванием шаблонов мы и эту проблему тоже решили. Теперь кастомы цепляются к шаблону, и к тому же их можно расширять на несколько файлов.
Ошибки и глюки бывают разные, одна из самых забавных — меняешь теги b на strong — получаешь не работающие макросы после того места, где сменены теги.
Описанная ситуация нам не известна. Вероятно, это частный случай или ошибка внедрения, о которой следует написать в СЗ и вам помогут ее решить.
Еще раз спасибо за обзор и критику системы!
Прежде всего, от лица компании Юмисофт хочу поблагодарить автора статьи за оказанное внимание к нашему продукту и привлечение внимания аудитории :)
Перед тем, как ответить по пунктам, хочу обратить внимание на две вещи:
1. Классическая критика по определению подразумевает поиск не только недостатков, но и достоинств рассматриваемого объекта. Почитайте Белинского, например. Ваша статья в этом смысле несколько однобока — достоинства просто не упоминаются, как будто их нет.
2. Предыдущая статья автора называется «За что я люблю Drupal» и начинается словами «По моему скромному мнению, CMS Drupal наиболее близко подошла к понятию «идеальная CMS».» Это говорит о некоторой предвзятости критика.
Теперь наши ответы по существу критики.
Так, например мне, потребовалось получить уже не один десяток бесплатных лицензий, а поскольку все лицензии привязаны к домену, то при переносе сайтов на рабочие домены лицензию нужно получать заново.
Ключи привязываются к доменам. Чтоб перенести CMS на другой домен нужно написать в Службу Заботы и они вышлют новый ключ. Некоторым пользователям бесплатной версии почему-то проще сгенерить новый ключ.
На главной странице официального сайта написано, что UMI.CMS используют более 10 000 сайтов и приведен список крупных сайтов, которые используют данную систему.
На самом деле уже около 15000 внедрений, просто сайт еще не обновили. Плюс несколько тысяч сайтов на UMI.ru, nastart.ru и в других SaaS. Сейчас мы работаем над новым сайтом и обновим цифры.
Сколково действительно месяц назад переехал на самописный движок, уберем.
Связной — ok.svyaznoy.ru/
Правительство Москвы купило у нас несколько тысяч лицензий для сайтов детсадов и школ (с другими системами пользователи не смогли разобраться). Подробности тут
Сайт вики также сделан не на UMI.CMS, а на open source движке MediaWiki.
Верно. Мы сами не разрабатываем движок для Вики, а пользуемся готовыми отраслевыми решениями.
Чтобы установить UMI.CMS себе на хостинг необходимо скачать файлик install.php, который сам скачает все файлы CMS из интернета. Соответственно не получится иметь у себя в резервных копий UMI разных версий, поскольку скачивается всегда последняя версия.
У большого количество разного софта, в том числе у браузера Google Chrome установщик устроен точно также. И более того, если кому-то зачем-то надо иметь старые версии (что само по себе непонятно зачем), то ничто не мешает раз в месяц скачивать и хранить.
Следует заметить, что UMI.CMS необходимо наличие на сервере расширения php xsl, которое установлено не на всех хостингах.
Верно. Мы ведем учет всех хостингов, на которых система работаем по-умолчанию. Более того, 12 из них имеют специальные тарифные планы «UMI» по ценам, не выше рыночных. Так удобнее и для хостеров, и для клиентов, и для разработчиков. Подробнее тут
Полная пробная версия UMI.CMS без установленных демо сайтов занимает 180 мб (4 985 файлов и 1 277 папок), база данных состоит из 80 таблиц размером 3,5 мб.
Верно. Ничего страшного здесь не видим, при современных каналах связи такой объём выкачивается за несколько минут. Код самой CMS весит значительно меньше, чем файлы контента. Большинство старых проприетарных CMS в разы тяжелее.
При редактировании материалов в UMI.CMS нет простой кнопки «Предпросмотр», зато есть три кнопки «Сохранить»:
Согласен. Эти кнопки сделаны до появления Edit-in-place, который по своей природе не требует предпросмотра. В будущем мы планируем эти кнопки переделать и по месту расположения и по числу.
В UMI.CMS используются макросы, которые вызывают определенные действия (например показ элемента каталога, фотогалереи и т.д.). При вставки этих макросов в визуальный редактор (используется Tinymce) они оборачиваются тегами p. В результате при срабатывании большинства макросов внутри тега p появляются теги div, что приводит к не валидной верстке.
Визуальный редактор — зло с точки зрения кода. Но добро для блондинок. Любой визуальный редактор по определению корёжит код. Мы не обнаружили ни одной CMS, где ВИЗИВИГ работал бы идеально.
К счастью в версии 2.8.5 разработчики предложили новый вариант — помещение всех шаблонов в папку templates.
Приятно, что хоть это вы оценили )
Автоматическое генерировании тегов description и keywords также не поддерживается.
За автогенерируемые тэги поисковики очень легко могут пессимизировать ваш сайт. Тэги должны писать специалисты по SEO, вручную и вдумчиво. Мы много консультировались с лучшими сеошниками страны и выполнили их рекомендации что и как делать.
ЧПУ в UMI.CMS генерируется автоматически, но по умолчанию в качестве разделителей между словами используется знак подчеркивания "_", хотя рекомендованный знак это знак дефиса "-" (возможность включения использования дефиса есть, но она спрятана очень глубоко и настраивается в config.ini).
Настройка любой системы через плэйн-текстовые конфигурационные файлы — это де-факто стандарт и наиболее привычный путь для любого разработчика.
В последние версии UMI.CMS встроена поддержка сервиса MegaIndex и в настройках модуля SEO можно указать свои данные от аккаунта к этому сервису. По умолчанию там стоят данные от UMI — логин и пароль, скрытый за звездочками. Этот пароль можно легко подсмотреть (например через расширение Web Developer для Firefox). В результате можно попасть в аккаунт UMI на сайте MegaIndex, где находится список сайтов, воспользовавшихся этой функцией у себя на сайте. В данных отчетов видны ключевые слова, позиции сайтов и другая информация.
Верно. Сделан отдельный доступ к Мегаиндексу для проверки из UMI.CMS. Аккаунт в Мегаиндексе не требует защиты, т.к. никаких секретных данных в этом аккаунте не хранится, позиции любого сайта в поисковиках — открытая информация.
При использовании xslt шаблона яваскрипты работают только если их вставить в текстовый редактор (чего тоже достаточно, чтобы натворить бед).
Непонятно. Наверное имеется в виду “редактор исходного кода”. Если так, то такое поведение существует в любой системе. Яваскрипты — в исходный код, только так.
Обновления больная тема многих CMS. В UMI.CMS, например, при обновлении старой версии на новую могут пропасть некоторые модули, которые были в раньше данной редакции системы, т.е. помимо платных обновлений (а обновления платные) потребуется доплатить за пропавший при обновлении модули.
Если модуль исключен из редакции или при переходе на другую редакцию, то логично что он отключится. Если закончился триальный срок демо-версии, отключатся все модули, кроме включенных в бесплатную версию. Все логично.
Файлы системы находят в папке classes, большинство функций и классов в них никак не документированы (комментарии есть только в 82 файлах из 786), т.е. глубоко разобраться в UMI.CMS без затраты большого количества времени не удастся.
Признаю, что часть редко используемых классов еще не покрыты документацией, но это делается постоянно. Если вы столкнулись с пробелом документации — просто напишите в СЗ об этом и в короткий срок это будет описано. В последний год-полтора такие запросы стали редкостью.
Все свои дополнительные функции в UMI.CMS следует писать в файлах custom.php, которые следует размещать в системных папках. Со временем файл custom.php разрастается своими функциями, соответственно возникают проблемы с включением/отключением отдельных функций, переносом их между проектами.
Это не так. С версии 2.8.5 вместе с раскидыванием шаблонов мы и эту проблему тоже решили. Теперь кастомы цепляются к шаблону, и к тому же их можно расширять на несколько файлов.
Ошибки и глюки бывают разные, одна из самых забавных — меняешь теги b на strong — получаешь не работающие макросы после того места, где сменены теги.
Описанная ситуация нам не известна. Вероятно, это частный случай или ошибка внедрения, о которой следует написать в СЗ и вам помогут ее решить.
Еще раз спасибо за обзор и критику системы!
Автор битриксоид http://dev.1c-bitrix.ru/learning/resume.php?ID=75565379-97723
Сертификаты нужны были по работе, особой симпатии к Битриксу не имею. Можно сказать, что отношение к нему такое же, как и к UMI.CMS.
Да ладно. Тогда ждем от вас теперь такой же неистовой «Критики Битрикс»?
С Битриксом не работал плотно, так что пока не ждем.
Если нашли ссылку на сертификаты Битрикса, то можно было бы найти и это www.free-lance.ru/users/Plazik
Если нашли ссылку на сертификаты Битрикса, то можно было бы найти и это www.free-lance.ru/users/Plazik
Правительство Москвы купило у нас несколько тысяч лицензий для сайтов детсадов и школ (с другими системами пользователи не смогли разобраться).
Я стокнулся один раз с вашей CMS — это когда знакомая женщина из детского сада просила вставить картинку на сайт. Тот еще квест, если честно
Сама CMS дает широкие возможности реализовать вставку картинок. Даже можно просто перетаскивать картинку из файлменеджера ОС в нужный блок на самом сайте (через Edit-in-place).
Конкретная реализация клиентской сайтов детсадов делалось веб-разработчиками со стороны заказчиков. Так что этот вопрос правильнее адресовать им.
Конкретная реализация клиентской сайтов детсадов делалось веб-разработчиками со стороны заказчиков. Так что этот вопрос правильнее адресовать им.
Добрый день.
Классическая критика по определению подразумевает поиск не только недостатков, но и достоинств рассматриваемого объекта. Почитайте Белинского, например. Ваша статья в этом смысле несколько однобока — достоинства просто не упоминаются, как будто их нет.
Я рассматривал достоинства системы по вашему мнению, которые на деле оказались не совсем достоинствами.
Предыдущая статья автора называется «За что я люблю Drupal» и начинается словами «По моему скромному мнению, CMS Drupal наиболее близко подошла к понятию «идеальная CMS».» Это говорит о некоторой предвзятости критика.
Заметьте, я не упоминал его и другие системы, с которыми мне приходилось работать, в данной статье. И система в данном материале не сравнивалась ни с какими другими CMS.
Ключи привязываются к доменам. Чтоб перенести CMS на другой домен нужно написать в Службу Заботы и они вышлют новый ключ. Некоторым пользователям бесплатной версии почему-то проще сгенерить новый ключ.
В техподдержку нельзя написать имея бесплатный ключ, т.к. «Поддержка бесплатных версий UMI.CMS прекращена с 7 июня 2010 года.»
Непонятно. Наверное имеется в виду “редактор исходного кода”. Если так, то такое поведение существует в любой системе. Яваскрипты — в исходный код, только так.
Имеется ввиду, что яваскрипты прекрасно отрабатываются, если их вставить в «редактор исходного кода», т.е. это может привести XSS. Я уже не говорю про автоматическое закрытие открытых тегов.
Если модуль исключен из редакции или при переходе на другую редакцию, то логично что он отключится. Если закончился триальный срок демо-версии, отключатся все модули, кроме включенных в бесплатную версию. Все логично.
Вопрос не в логичности. Получается вытягивание денег. Надо обновление? — Плати. Заплатил — получи отключенный модуль. Надо его обратно? — Плати.
Признаю, что часть редко используемых классов еще не покрыты документацией, но это делается постоянно. Если вы столкнулись с пробелом документации — просто напишите в СЗ об этом и в короткий срок это будет описано. В последний год-полтора такие запросы стали редкостью.
Т.е. в оставшихся 704 файлах находятся «редко используемые классы»?
Классическая критика по определению подразумевает поиск не только недостатков, но и достоинств рассматриваемого объекта. Почитайте Белинского, например. Ваша статья в этом смысле несколько однобока — достоинства просто не упоминаются, как будто их нет.
Я рассматривал достоинства системы по вашему мнению, которые на деле оказались не совсем достоинствами.
Предыдущая статья автора называется «За что я люблю Drupal» и начинается словами «По моему скромному мнению, CMS Drupal наиболее близко подошла к понятию «идеальная CMS».» Это говорит о некоторой предвзятости критика.
Заметьте, я не упоминал его и другие системы, с которыми мне приходилось работать, в данной статье. И система в данном материале не сравнивалась ни с какими другими CMS.
Ключи привязываются к доменам. Чтоб перенести CMS на другой домен нужно написать в Службу Заботы и они вышлют новый ключ. Некоторым пользователям бесплатной версии почему-то проще сгенерить новый ключ.
В техподдержку нельзя написать имея бесплатный ключ, т.к. «Поддержка бесплатных версий UMI.CMS прекращена с 7 июня 2010 года.»
Непонятно. Наверное имеется в виду “редактор исходного кода”. Если так, то такое поведение существует в любой системе. Яваскрипты — в исходный код, только так.
Имеется ввиду, что яваскрипты прекрасно отрабатываются, если их вставить в «редактор исходного кода», т.е. это может привести XSS. Я уже не говорю про автоматическое закрытие открытых тегов.
Если модуль исключен из редакции или при переходе на другую редакцию, то логично что он отключится. Если закончился триальный срок демо-версии, отключатся все модули, кроме включенных в бесплатную версию. Все логично.
Вопрос не в логичности. Получается вытягивание денег. Надо обновление? — Плати. Заплатил — получи отключенный модуль. Надо его обратно? — Плати.
Признаю, что часть редко используемых классов еще не покрыты документацией, но это делается постоянно. Если вы столкнулись с пробелом документации — просто напишите в СЗ об этом и в короткий срок это будет описано. В последний год-полтора такие запросы стали редкостью.
Т.е. в оставшихся 704 файлах находятся «редко используемые классы»?
Заметьте, я не упоминал его и другие системы, с которыми мне приходилось работать, в данной статье. И система в данном материале не сравнивалась ни с какими другими CMS.
То, что вы не упоминаете другие CMS в данной статье не отменяет этот ваш бэкграунд и не делает ваши суждения непредвзятыми.
Имеется ввиду, что яваскрипты прекрасно отрабатываются, если их вставить в «редактор исходного кода», т.е. это может привести XSS. Я уже не говорю про автоматическое закрытие открытых тегов.
Яваскрипты по определению отрабатываются везде, где можно их вставить. Если у админа есть права вставлять яваскрипт — он может вставить. Разве в других системах это по-дугому?
Вопрос не в логичности. Получается вытягивание денег. Надо обновление? — Плати. Заплатил — получи отключенный модуль. Надо его обратно? — Плати.
Так можно назвать любой бизнес «вытягиванием денег». Но у вас всегда есть выбор платить или нет.
Мы работаем по freemium модели, половина софта в мире работает по ней же.
Даже к Друпалу есть платные модули и дополнения.
Т.е. в оставшихся 704 файлах находятся «редко используемые классы»?
Да. Если у вас есть конкретные пожелания, напишите мне названия понадобившихся классов, если мы найдем пробелы в доках — немедленно их закроем.
То, что вы не упоминаете другие CMS в данной статье не отменяет этот ваш бэкграунд и не делает ваши суждения непредвзятыми.
Имеется ввиду, что яваскрипты прекрасно отрабатываются, если их вставить в «редактор исходного кода», т.е. это может привести XSS. Я уже не говорю про автоматическое закрытие открытых тегов.
Яваскрипты по определению отрабатываются везде, где можно их вставить. Если у админа есть права вставлять яваскрипт — он может вставить. Разве в других системах это по-дугому?
Вопрос не в логичности. Получается вытягивание денег. Надо обновление? — Плати. Заплатил — получи отключенный модуль. Надо его обратно? — Плати.
Так можно назвать любой бизнес «вытягиванием денег». Но у вас всегда есть выбор платить или нет.
Мы работаем по freemium модели, половина софта в мире работает по ней же.
Даже к Друпалу есть платные модули и дополнения.
Т.е. в оставшихся 704 файлах находятся «редко используемые классы»?
Да. Если у вас есть конкретные пожелания, напишите мне названия понадобившихся классов, если мы найдем пробелы в доках — немедленно их закроем.
> Полная пробная версия UMI.CMS без установленных демо сайтов занимает 180 мб (4 985 файлов и 1 277 папок), база данных состоит из 80 таблиц размером 3,5 мб.
> Верно. Ничего страшного здесь не видим, при современных каналах связи такой объём выкачивается за несколько минут. Код самой CMS весит значительно меньше, чем файлы контента. Большинство старых проприетарных CMS в разы тяжелее.
Как пользователь и разработчик системы, массово устанавливающей UMI.CMS, должен заметить, что новый установщик, выкачивающий данные при каждой установке, мне кажется деградацией по сравнению с установщиком без дозагрузки.
Имею дело с реальной системой, устанавливащей UMI.CMS несколько сотен раз в сутки, и каждый раз система должна выкачивать эти файлы. Как минимум это нерационально — качать много раз одни и те же файлы.
Кроме того, Сергей, лукавите. «Старые» CMS, где вместо выкачивания копируется дистрибутив и выливается дамп БД быстрее в разы, чем работает ваш инсталлятор с дозагрузкой. Опять же по опыту.
Также согласен с автором статьи, что 180 мегабайт это очень много для болванки CMS.
Кстати, если вы этот размер уменьшите, у вас и скорость загрузки уменьшится.
> Верно. Ничего страшного здесь не видим, при современных каналах связи такой объём выкачивается за несколько минут. Код самой CMS весит значительно меньше, чем файлы контента. Большинство старых проприетарных CMS в разы тяжелее.
Как пользователь и разработчик системы, массово устанавливающей UMI.CMS, должен заметить, что новый установщик, выкачивающий данные при каждой установке, мне кажется деградацией по сравнению с установщиком без дозагрузки.
Имею дело с реальной системой, устанавливащей UMI.CMS несколько сотен раз в сутки, и каждый раз система должна выкачивать эти файлы. Как минимум это нерационально — качать много раз одни и те же файлы.
Кроме того, Сергей, лукавите. «Старые» CMS, где вместо выкачивания копируется дистрибутив и выливается дамп БД быстрее в разы, чем работает ваш инсталлятор с дозагрузкой. Опять же по опыту.
Также согласен с автором статьи, что 180 мегабайт это очень много для болванки CMS.
Кстати, если вы этот размер уменьшите, у вас и скорость загрузки уменьшится.
Любое техническое решение имеет свои достоинства и недостатки. Мы поменяли концепцию инсталляции потому, что считаем, что достоинства такого подхода перевешивают:
1. В наш век быстрых каналов и больших винчестеров 180 мегабайт — это вообще не предмет для обсуждения. Люди легко выкачивают Bluray-образы в десятки гигабайт просто для того, чтобы один раз вечером посмотреть фильм.
2. Установка через download это единственный путь поставлять клиентам всегда последнюю версию. Точно также сейчас принято устанавливать и другой различный софт от разных производителей. Любой Linux-пакет с программным обеспечением скачивается при установке. Это вообще повседневность и реальность, говорить о достоинстве распространения архивов в 2012 году уже не актуально нашему мнению и мнению тысяч других вендоров.
3. Сама CMS без демосайтов в самой полной редакции весит около 70Мб. Но наши пользователи любят, когда вместе с продуктом поставляются и типовые демосайты с демоконтентом. Мы, конечно, можем еще оптимизировать их размер, но не считаем эту задачу приоритетной по вышеназванным аргументам.
В вашем конкретном случае, если вы реально ставите UMI 100 раз в день — рекомендую настроить прокси и положить те же пакеты локально.
1. В наш век быстрых каналов и больших винчестеров 180 мегабайт — это вообще не предмет для обсуждения. Люди легко выкачивают Bluray-образы в десятки гигабайт просто для того, чтобы один раз вечером посмотреть фильм.
2. Установка через download это единственный путь поставлять клиентам всегда последнюю версию. Точно также сейчас принято устанавливать и другой различный софт от разных производителей. Любой Linux-пакет с программным обеспечением скачивается при установке. Это вообще повседневность и реальность, говорить о достоинстве распространения архивов в 2012 году уже не актуально нашему мнению и мнению тысяч других вендоров.
3. Сама CMS без демосайтов в самой полной редакции весит около 70Мб. Но наши пользователи любят, когда вместе с продуктом поставляются и типовые демосайты с демоконтентом. Мы, конечно, можем еще оптимизировать их размер, но не считаем эту задачу приоритетной по вышеназванным аргументам.
В вашем конкретном случае, если вы реально ставите UMI 100 раз в день — рекомендую настроить прокси и положить те же пакеты локально.
> 1. В наш век быстрых каналов и больших винчестеров 180 мегабайт — это вообще не предмет для обсуждения. Люди легко выкачивают Bluray-образы в десятки гигабайт просто для того, чтобы один раз вечером посмотреть фильм.
Опять же из опыта (из реальной картины): на хостинге есть такое понятие как лимит места. Тарифы на 1Гб до сих пор самый популярный (по имеющимся данным у меня). В этот 1Гб может входить вес почты и баз данных, т.о. на файлы цмски может оставаться мало места. И тогда размер в 180Мб может быть критичен. Просто часто сталкиваюсь с тем, что пользователи на не очень крутых тарифах не могут поставить себе эту цмс из-за недостатка дисковой квоты на их уже давно сложившихся сайтах.
И всё бы ничего, просто другие цмски, многие из бесплатных — весят меньше и поставится в таких условиях могут.
> 2. Установка через download это единственный путь поставлять клиентам всегда последнюю версию.
В этом есть также минус — никогда неизвестно, какая же версия таки установится.
Это довольно важно для предложения нам в свою очередь своим клиентам — мы не можем однозначно написать, что версия такая-то, приходится делать ссылку на ваш сайт.
Чтобы сразу к конкретике: эта установка с download работает в среднем 1 минуту. В результате чего пользователю приходится её довольно долго ждать, а мне, как разработчику, всячески обрабатывать эту ситуацию, а мне разумеется, лишней работы не хочется.
Установкой из локальной копии ставитяс менее 10 секунд.
> В вашем конкретном случае, если вы реально ставите UMI 100 раз в день — рекомендую настроить прокси и положить те же пакеты локально.
Не совсем понял про прокси.
Я решил проблему долгой загрузки путём сбора как раз локального пакета вашей цмс в виде дампа и файлов, чтобы она ставилась как все другие. Давно уже, ещё до другой версии инсталлятора. Т.к. предыдущая версия меня тоже не совсем устраивала, она не работала если домен, на который идет установка ещё не был поднят на DNS.
Опять же из опыта (из реальной картины): на хостинге есть такое понятие как лимит места. Тарифы на 1Гб до сих пор самый популярный (по имеющимся данным у меня). В этот 1Гб может входить вес почты и баз данных, т.о. на файлы цмски может оставаться мало места. И тогда размер в 180Мб может быть критичен. Просто часто сталкиваюсь с тем, что пользователи на не очень крутых тарифах не могут поставить себе эту цмс из-за недостатка дисковой квоты на их уже давно сложившихся сайтах.
И всё бы ничего, просто другие цмски, многие из бесплатных — весят меньше и поставится в таких условиях могут.
> 2. Установка через download это единственный путь поставлять клиентам всегда последнюю версию.
В этом есть также минус — никогда неизвестно, какая же версия таки установится.
Это довольно важно для предложения нам в свою очередь своим клиентам — мы не можем однозначно написать, что версия такая-то, приходится делать ссылку на ваш сайт.
Чтобы сразу к конкретике: эта установка с download работает в среднем 1 минуту. В результате чего пользователю приходится её довольно долго ждать, а мне, как разработчику, всячески обрабатывать эту ситуацию, а мне разумеется, лишней работы не хочется.
Установкой из локальной копии ставитяс менее 10 секунд.
> В вашем конкретном случае, если вы реально ставите UMI 100 раз в день — рекомендую настроить прокси и положить те же пакеты локально.
Не совсем понял про прокси.
Я решил проблему долгой загрузки путём сбора как раз локального пакета вашей цмс в виде дампа и файлов, чтобы она ставилась как все другие. Давно уже, ещё до другой версии инсталлятора. Т.к. предыдущая версия меня тоже не совсем устраивала, она не работала если домен, на который идет установка ещё не был поднят на DNS.
на хостинге есть такое понятие как лимит места. Тарифы на 1Гб до сих пор самый популярный (по имеющимся данным у меня). В этот 1Гб может входить вес почты и баз данных, т.о. на файлы цмски может оставаться мало места. И тогда размер в 180Мб может быть критичен. Просто часто сталкиваюсь с тем, что пользователи на не очень крутых тарифах не могут поставить себе эту цмс из-за недостатка дисковой квоты на их уже давно сложившихся сайтах.
Во-первых, большинство хостеров уже дает 1,5-2 гига даже на младших тарифах.
Во-вторых, ставить старшую редакцию UMI.CMS (которая весит 180Мб с демо-сайтом и которая сделана для интернет-магазинов) на самый младший тариф хостинга не совсем корректно.
В-третьих, разница в цене между младшим тарифом хостинга и средним (который обычно мы и рекомендуем как производители) составляет 100-150 рублей в месяц, что для владельца интернет-магазина и покупателя платной CMS не является ощутимой затратой.
В-четвертых, как уже говорилось, можно удалить демо-контент и остаться с 70Мб на систему, что совсем немного.
Во-первых, большинство хостеров уже дает 1,5-2 гига даже на младших тарифах.
Во-вторых, ставить старшую редакцию UMI.CMS (которая весит 180Мб с демо-сайтом и которая сделана для интернет-магазинов) на самый младший тариф хостинга не совсем корректно.
В-третьих, разница в цене между младшим тарифом хостинга и средним (который обычно мы и рекомендуем как производители) составляет 100-150 рублей в месяц, что для владельца интернет-магазина и покупателя платной CMS не является ощутимой затратой.
В-четвертых, как уже говорилось, можно удалить демо-контент и остаться с 70Мб на систему, что совсем немного.
Сергей, это конечно всё верно, но есть другие CMS, у которых нет описанной специфики — там можно получить «красивую болванку» CMS не задумываясь ни о каких редакциях, размерах и времени загрузки.
Много людей на самых разных тарифах, среди которых, открою вам секрет, до сих пор есть тарифы с квотой и менее 1 Гб (такие тарифы уже не предлагаются, но юзеры на них исторически остаются), пытаются ставить UMI.CMS из панелей хостеров, просто чтобы посмотреть как она выглядит.
Им хочется просто нажать кнопку и посмотреть. И хочется, чтобы это произошло быстро, а болванка была красивой и функциональной. Никто из них не будет разбираться в ваших редакциях. Просто поставят какой-нибудь LiveStreet, MODx или SilverStripe и на этом дело закончится.
Много людей на самых разных тарифах, среди которых, открою вам секрет, до сих пор есть тарифы с квотой и менее 1 Гб (такие тарифы уже не предлагаются, но юзеры на них исторически остаются), пытаются ставить UMI.CMS из панелей хостеров, просто чтобы посмотреть как она выглядит.
Им хочется просто нажать кнопку и посмотреть. И хочется, чтобы это произошло быстро, а болванка была красивой и функциональной. Никто из них не будет разбираться в ваших редакциях. Просто поставят какой-нибудь LiveStreet, MODx или SilverStripe и на этом дело закончится.
Можно же запустить инсталлятор из консоли (CLI-режим), положив предварительно конфиг с параметрами установки и запускать это все одно командой. Да, придется подождать, пока все развернется и скачается несколько минут, но это же хорошо, можно идти пить кофе, думать о дальнейших действиях по проекту или почитать хабр, наконец )
Спасибо за милую зарисовку вашего времяпревождения,
но выше я писал, что поддерживаю систему, которая занимается массовой установкой UMI.CMS в автоматическом режиме. Разумеется я знаю про CLI-режим.
Более того, при таком объеме отладочной информации появляются наблюдения и баги.
Инсталлятор UMI.CMS я знаю как облупленный, копался в его коде неоднократно, даже репортил баги.
Например такой при работе в консольном режиме установщик вместо вывода адекватного текста ошибки зачем-то вываливал в консоль html (!) страничку с невнятным сообщением о проблеме с базой данных.
Мне не известно об исправлении ни одного из зарепорченных багов установщика. Баг установки CMS на домен, который не резолвится был принят и его решение ожидалось полгода, но так и не было решено никак. Зато за это время было много радужных постов про смену методологии разработки, введение различных методик тестирования и тп. Всего я репортил сотрудникам UMI.CMS о 4 багах установщика (о самой CMS я вовсе молчу, речь пока только об установщике).
но выше я писал, что поддерживаю систему, которая занимается массовой установкой UMI.CMS в автоматическом режиме. Разумеется я знаю про CLI-режим.
Более того, при таком объеме отладочной информации появляются наблюдения и баги.
Инсталлятор UMI.CMS я знаю как облупленный, копался в его коде неоднократно, даже репортил баги.
Например такой при работе в консольном режиме установщик вместо вывода адекватного текста ошибки зачем-то вываливал в консоль html (!) страничку с невнятным сообщением о проблеме с базой данных.
Мне не известно об исправлении ни одного из зарепорченных багов установщика. Баг установки CMS на домен, который не резолвится был принят и его решение ожидалось полгода, но так и не было решено никак. Зато за это время было много радужных постов про смену методологии разработки, введение различных методик тестирования и тп. Всего я репортил сотрудникам UMI.CMS о 4 багах установщика (о самой CMS я вовсе молчу, речь пока только об установщике).
Как же фигово я раньше верстал =) Это я про связной.
>на Facebook 319 пользователям нравится UMI.CMS.
Это, наверное, сотрудники и партнеры UMI.CMS
Это, наверное, сотрудники и партнеры UMI.CMS
А почему использовать strong и em лучше чем b и i?
Ведь, насколько я знаю, разница между этими тегами в том, что strong и em это теги для придания смысла, например чтобы выделить слово как особо важное, или поставить ударение.
Теги же b и i это просто теги для форматирования текста (чтобы выделить жирным или курсивом).
Таким образом, теги strong и em гарантируют смысловую нагрузку (ударение, важность), но не гарантируют внешний вид — верстальщик может как угодно переопределять внешний вид этих тегов. Например, сделать тег em не курсивом — вполне нормально. Также теги strong и em (теоретически) должны обрабатываться, например, устройствами для чтения веб-страниц. То, что они выводятся жирным и курсивом это просто так исторически сложилось, но по стандартам w3c тег em должен рендериться как «emphasized», что можно перевести как «логически выделенный», и по факту это может означать что угодно, главное выделенный (например у нас на сайте это шрифт обычного начертания, выделенный зеленым цветом). Аналогично тег strong — highlighted, но никак не жирный (bold).
Теги b и i гарантируют внешний вид (b — жирный, i — курсив), но не несут никакой смысловой нагрузки. Верстальщик не должен переопределять поведение этих тегов.
Таким образом, использовать b и i в верстке — совсем не страшно, более того, использовать их для придания жирности (курсива) а не для выделения чего-то как важного — более верно.
Также не вижу ничего страшного в том, что админка не проходит валидацию. Вы пробовали главную страницу яндекса проверить валидатором? А любого другого популярного сайта? Почти ни один из них не проходит валидацию, и в это нормально, если он рендерится так, как задумывалось.
Ведь, насколько я знаю, разница между этими тегами в том, что strong и em это теги для придания смысла, например чтобы выделить слово как особо важное, или поставить ударение.
Теги же b и i это просто теги для форматирования текста (чтобы выделить жирным или курсивом).
Таким образом, теги strong и em гарантируют смысловую нагрузку (ударение, важность), но не гарантируют внешний вид — верстальщик может как угодно переопределять внешний вид этих тегов. Например, сделать тег em не курсивом — вполне нормально. Также теги strong и em (теоретически) должны обрабатываться, например, устройствами для чтения веб-страниц. То, что они выводятся жирным и курсивом это просто так исторически сложилось, но по стандартам w3c тег em должен рендериться как «emphasized», что можно перевести как «логически выделенный», и по факту это может означать что угодно, главное выделенный (например у нас на сайте это шрифт обычного начертания, выделенный зеленым цветом). Аналогично тег strong — highlighted, но никак не жирный (bold).
Теги b и i гарантируют внешний вид (b — жирный, i — курсив), но не несут никакой смысловой нагрузки. Верстальщик не должен переопределять поведение этих тегов.
Таким образом, использовать b и i в верстке — совсем не страшно, более того, использовать их для придания жирности (курсива) а не для выделения чего-то как важного — более верно.
Также не вижу ничего страшного в том, что админка не проходит валидацию. Вы пробовали главную страницу яндекса проверить валидатором? А любого другого популярного сайта? Почти ни один из них не проходит валидацию, и в это нормально, если он рендерится так, как задумывалось.
Хочу заметить, что Сколково довольно неприятно отзывались о службе поддержки UMI.CMS.
У меня другая информация. Разработчики этого сайта не реализовали рекомендации саппорта ЮМИ по каким-то своим причинам. И с самого начала говорили, что будут писать все сами и с нуля, поскольку проект должен иметь сильно кастомный функционал.
Единственный кто мог дать внятные ответы на сложные вопросы по ядру был Виталий Шубин у них в СЗ. И тот уволился =)
На подфм есть хорошее интервью с создателем данной системы http://runetologia.podfm.ru/110/
Интервью в рунетологии хорошее, всё логично и последовательно излагает. Но на сколько я понял, Сергей Котырев больше бизнес-человек, не технический специалист, поэтому удивлён его подробным ответам по техническим вопросам тут комментах… может тех-директор писал, а он публиковал?)
Скорее всего. У меня тоже сложилось мнение что Сергей погружен сугубо в бизнес вопросы. Но интервью оставило более положительное впечетление чем интервью с Битрексом.
Мой первый ВУЗ был технический (судостроение), хотя я никогда не был разработчиком. Тем не менее за 6 лет управления студией, а потом за 5 лет управления софтверной компанией я стал чуточку разбираться в тех. вопросах :)
Хотя с техдиректором по нескольким пунктам, конечно, советовался :)
Хотя с техдиректором по нескольким пунктам, конечно, советовался :)
Я так почитала, и единственная эмоция — это негатив!
Очень долго я уже пользуюсь UMI, меня всегда все устраивало и устраивает до сих пор!
Клиенты в восторге!
Не понимаю что вы так все озлобились?!
Да и что бы сайт перенести на другой домен, не обязательно званого заказывать бесплатную версию. Необходимо только написать в суппорт и попросить их перевязать ключик, пол минутное дело, отвечают бысттро и ключик соответственно перевязывают тоже очень быстро.
Очень долго я уже пользуюсь UMI, меня всегда все устраивало и устраивает до сих пор!
Клиенты в восторге!
Не понимаю что вы так все озлобились?!
Да и что бы сайт перенести на другой домен, не обязательно званого заказывать бесплатную версию. Необходимо только написать в суппорт и попросить их перевязать ключик, пол минутное дело, отвечают бысттро и ключик соответственно перевязывают тоже очень быстро.
С помощью публикации высосанного из пальца негатива легче набрать кармы и самоутвердиться. Старо как мир.
Проблемы с безопасностью, отсутствие документированного ядра, генерирование не валидной верстки — это «высосано из пальца»?
Именно так. И это уже показано тут в комментариях умными людьми. Почитайте внимательнее
Я уже дал развернутый ответ, но мне не сложно повториться.
1. «Проблемы с безопасностью». Вы посчитали таковыми возможность вставки кода АВТОРИЗОВАННЫМ АДМИНИСТРАТОРОМ сайта. Вообще злонамеренный админ сайта может сделать с сайтом что угодно и более простым способом — просто убить сайт. Админ может вставить код в любую CMS. Проблемы с безопасноcтью появляются тогда, когда неавторизованный пользователь может вставить код.
2. Ядро документировано в достаточной степени. Мы не встречались с жалобами на отсутствие документации от 1500 наших партнеров очень давно. Я сделал вам конструктивное предложение написать подробнее что именно вам не хватает от документации, вы его проигнорировали.
Кроме того, ни одна CMS не задокументирована на 100%, даже в 1000 более популярные чем UMI.
3. «Генерирование невалидной верстки» связано с применением Edit-in-place, от которой клиенты в восторге. Если разработчик сайта считает валидность (что само по себе вещь предвзятая) важнее — он может просто не использовать Edit-in-place и делать код нужной валидности под нужный ему валидатор.
Я не утверждаю, что UMI.CMS не имеет недостатков и багов. Мы их знаем и над ними работаем. Я просто считаю, что указанные вами недостатки не соответствуют пафосу их подачи.
А учитывая, что конструктивно на мое предложение написать про документацию вы отвечать не стали, и к другим CMS вы лояльны (партнер Битрикса, хвалебная статья про Друпал) и ни слова не пишете про их недостатки, мне ваша деятельность критика кажется несколько однобокой.
Но в любом случае я не собираюсь вас убеждать в неправоте, ваше мнение — ваше право. Ваша статья все равно имеет определенную ценность для нас )
1. «Проблемы с безопасностью». Вы посчитали таковыми возможность вставки кода АВТОРИЗОВАННЫМ АДМИНИСТРАТОРОМ сайта. Вообще злонамеренный админ сайта может сделать с сайтом что угодно и более простым способом — просто убить сайт. Админ может вставить код в любую CMS. Проблемы с безопасноcтью появляются тогда, когда неавторизованный пользователь может вставить код.
2. Ядро документировано в достаточной степени. Мы не встречались с жалобами на отсутствие документации от 1500 наших партнеров очень давно. Я сделал вам конструктивное предложение написать подробнее что именно вам не хватает от документации, вы его проигнорировали.
Кроме того, ни одна CMS не задокументирована на 100%, даже в 1000 более популярные чем UMI.
3. «Генерирование невалидной верстки» связано с применением Edit-in-place, от которой клиенты в восторге. Если разработчик сайта считает валидность (что само по себе вещь предвзятая) важнее — он может просто не использовать Edit-in-place и делать код нужной валидности под нужный ему валидатор.
Я не утверждаю, что UMI.CMS не имеет недостатков и багов. Мы их знаем и над ними работаем. Я просто считаю, что указанные вами недостатки не соответствуют пафосу их подачи.
А учитывая, что конструктивно на мое предложение написать про документацию вы отвечать не стали, и к другим CMS вы лояльны (партнер Битрикса, хвалебная статья про Друпал) и ни слова не пишете про их недостатки, мне ваша деятельность критика кажется несколько однобокой.
Но в любом случае я не собираюсь вас убеждать в неправоте, ваше мнение — ваше право. Ваша статья все равно имеет определенную ценность для нас )
Добавлю к п2 про документацию. Если возникает вопрос, на который разработчик не может (или не хочет) найти ответ в документации, он всегда может обратиться в поддержку и ему найдут ответ в любом случае.
Вообще поддержка — это ключевое отличие платного софта от бесплатного, гораздо более важное для клиента, чем технические отличия самого софта.
Вообще поддержка — это ключевое отличие платного софта от бесплатного, гораздо более важное для клиента, чем технические отличия самого софта.
1. Любой пользователь, имеющий доступ к админку сможет выполнить любой html, javascript код (для tpl шаблонов), вставив их в поля при редактировании материалов.
Пользователи с правами админа могут сломать верстку простой вставкой кавычек в поля при редактировании материала, поскольку пользовательский вывод никак не обрабатывается. Если вы считаете, что это нормально — тогда все понятно.
2. О чем может быть разговор, если вы написали, что в большей части файлов ядра находятся «редко используемые классы»?
3. Разве нельзя было сделать и edit-in-place и валидную верстку?
Я бы и к UMI.CMS был лоялен, если бы в ней все было нормально. Но на деле это оказывается не так, поэтому и претензии.
P.S. я не партнер Битрикса.
Пользователи с правами админа могут сломать верстку простой вставкой кавычек в поля при редактировании материала, поскольку пользовательский вывод никак не обрабатывается. Если вы считаете, что это нормально — тогда все понятно.
2. О чем может быть разговор, если вы написали, что в большей части файлов ядра находятся «редко используемые классы»?
3. Разве нельзя было сделать и edit-in-place и валидную верстку?
Я бы и к UMI.CMS был лоялен, если бы в ней все было нормально. Но на деле это оказывается не так, поэтому и претензии.
P.S. я не партнер Битрикса.
1. Любой пользователь, имеющий доступ к админку называется администратором. Изначально вы называли уязвимостью то, что не обрабатываются некоторые поля, заполняемые администраторами. То, что поля не обрабатываются никто не спорит, спорят с повешенным ради красного словца ярлыком уязвимости, который неприменим к этой недоработке.
2. Это очередное подтверждение нежелания общаться конструктивно. Проще и приятнее просто критиковать, понимаю. Если передумаете — мы будем очень рады и всячески поощрим конкретную помощь.
3. Если кто-то в других CMS сможет повторить функционал EIP с валидной версткой, нам будет чему у него поучиться. Пока не видели. Будем рады выслушать рекомендации как это делается.
Нет CMS с которой все нормально, особенно если есть сильное желание накопать «ненормального» и прославиться. Было бы желание придраться, а к чему найдется. Особенно если придираться даже к общепринятым вещам, что мы для Вики используем Mediawiki или что не пишем сами драйверы для принтеров.
Кстати, скажите, с Drupal все нормально? Вся документация полна и актуальна? Не используют сторонний софт?
2. Это очередное подтверждение нежелания общаться конструктивно. Проще и приятнее просто критиковать, понимаю. Если передумаете — мы будем очень рады и всячески поощрим конкретную помощь.
3. Если кто-то в других CMS сможет повторить функционал EIP с валидной версткой, нам будет чему у него поучиться. Пока не видели. Будем рады выслушать рекомендации как это делается.
Нет CMS с которой все нормально, особенно если есть сильное желание накопать «ненормального» и прославиться. Было бы желание придраться, а к чему найдется. Особенно если придираться даже к общепринятым вещам, что мы для Вики используем Mediawiki или что не пишем сами драйверы для принтеров.
Кстати, скажите, с Drupal все нормально? Вся документация полна и актуальна? Не используют сторонний софт?
3. Там проблема с лишними атрибутами у тегов? Для этих целей в html5 введены data-атрибуты.
1. Т.е. любой пользователь, которому нужно добавлять материалы на сайт, но не нужно видеть в админке всего остального становится админом? Потенциальная уязвимости есть и ее надо называть своими словами, а не пытаться замять ее словом «недоработка». Конечно, если вы думаете «Подумаешь ерунда какая, что он пристал то. Недоработку устраним», тогда все понятно. Получается отношение к безопасности как к необязательному функционалу.
3. Насколько я знаю в DLE есть возможно редактирования текста материалов не заходя в админку. В Drupal редактирование материалов/блоков осуществляется на страницах, находящиеся в 1 клике от редактируемой странице.
Заметьте, я не придираюсь к тому, что вы используете jQuery, SVN и т.п. в своих проектах. Мне интересно, почему разработчики своей системы для управления сайтами в своих же проектах не использую ее? Сразу приходят на ум мысли о том, что с CMS что-то не так, если даже разработчики не решаются использовать свою систему на своих же сайтах.
Не стоит сравнивать Drupal и UMI.CMS, вы все время будете проигравшей стороной. UMI.CMS это некоторое законченное решение. А Drupal это инструмент для создания того, что нужно заказчику. Причем создание и управление функционалом происходит в админке, а не через код, как в UMI.CMS и в других CMS.
Да, Drupal документирован нормально. Попробуйте найти в ядре функцию или класс, который не документирован. Сравните конфигурационный файл Друпала settings.php, в котором 80-90% это документация и конфигурационный файл юми config.ini, в котором документации нет ни строчки.
Для своих сайтов Drupal использует свой движок, а не движки конкурентов.
3. Насколько я знаю в DLE есть возможно редактирования текста материалов не заходя в админку. В Drupal редактирование материалов/блоков осуществляется на страницах, находящиеся в 1 клике от редактируемой странице.
Заметьте, я не придираюсь к тому, что вы используете jQuery, SVN и т.п. в своих проектах. Мне интересно, почему разработчики своей системы для управления сайтами в своих же проектах не использую ее? Сразу приходят на ум мысли о том, что с CMS что-то не так, если даже разработчики не решаются использовать свою систему на своих же сайтах.
Не стоит сравнивать Drupal и UMI.CMS, вы все время будете проигравшей стороной. UMI.CMS это некоторое законченное решение. А Drupal это инструмент для создания того, что нужно заказчику. Причем создание и управление функционалом происходит в админке, а не через код, как в UMI.CMS и в других CMS.
Да, Drupal документирован нормально. Попробуйте найти в ядре функцию или класс, который не документирован. Сравните конфигурационный файл Друпала settings.php, в котором 80-90% это документация и конфигурационный файл юми config.ini, в котором документации нет ни строчки.
Для своих сайтов Drupal использует свой движок, а не движки конкурентов.
1. Уязвимость — это когда злоумышленник, не обладающий админскими правами, имеет возможность вставить зловредный код. Вы назвали уязвимостью возможность вставить зловредный код администратором сайта.
Любой пользователь, которому нужно добавлять материалы на сайт, не обязательно становится администратором CMS и, соответственно, имеет доступ к редактированию полей админки. CMS позволяет реализовать этот функционал и вопрос разработчика сайта — ставить проверку добавленных пользователем материалов на наличие скриптов или нет. Это вопрос разработчика сайта, а не CMS.
3. В UMI, DLE и Drupal это реализовано по-разному, надеюсь вы это можете заметить. Мы считаем, что наше решение самое удобное для пользователя (редактора контента)
MediaWiki является лучшим движком для Wiki. UMI.CMS является решением для сайтов и интернет-магазинов. Мы не конкурируем с MediaWiki, поскольку не делаем движки для Wiki. Поэтому мы используем MediaWiki для собственных нужд.
Любой пользователь, которому нужно добавлять материалы на сайт, не обязательно становится администратором CMS и, соответственно, имеет доступ к редактированию полей админки. CMS позволяет реализовать этот функционал и вопрос разработчика сайта — ставить проверку добавленных пользователем материалов на наличие скриптов или нет. Это вопрос разработчика сайта, а не CMS.
3. В UMI, DLE и Drupal это реализовано по-разному, надеюсь вы это можете заметить. Мы считаем, что наше решение самое удобное для пользователя (редактора контента)
MediaWiki является лучшим движком для Wiki. UMI.CMS является решением для сайтов и интернет-магазинов. Мы не конкурируем с MediaWiki, поскольку не делаем движки для Wiki. Поэтому мы используем MediaWiki для собственных нужд.
Успех таких компаний как UMI и Битрикс это в тех. поддержка. Остальное у них далеко от совершенства (хотя и тех. поддержка тоже).
Но для простых обывателей тех. поддержка — это как спасательный круг, когда вокург некому помочь? а таких поверьте очень много.
Но для простых обывателей тех. поддержка — это как спасательный круг, когда вокург некому помочь? а таких поверьте очень много.
Если все перечисленное — самые большие проблемы с этой ЦМС, то это просто счастье! Как человек, долгое время поддерживавший проекты на Неткате говорю.
сайт primpogoda.ru/ (крупнейший региональный портал о погоде) поддержкой которого я сейчас занимаю работает на юми уже очень давно. посещаемость до 50 пользователей в сутки. так что вы просто не умеете ее готовить. в umi конечно есть еще минусы, которые автор статьи не упомнил. но в целом юми со своим задачами справляется.
>50 тысяч уникальных пользователей.
поправка
поправка
Портал хороший.
primpogoda.ru/users/registrate — красивая страница. %h1%, Шаблон не найден.
Попробуйте зарегистрироваться под admin — вернется эта же страница, без сообщения об ошибке.
Карта сайта primpogoda.ru/sitemap.xml видно совсем не строится.
primpogoda.ru/users/registrate — красивая страница. %h1%, Шаблон не найден.
Попробуйте зарегистрироваться под admin — вернется эта же страница, без сообщения об ошибке.
Карта сайта primpogoda.ru/sitemap.xml видно совсем не строится.
Я посмотрел Ваши работы на www.free-lance.ru/users/Plazik/
Не заметно что вы сами делали то, за что критикуете других:
www.petron.ru/sitemap.xml
ptk-tehgaz.ru/sitemap.xml
alexeychernov.com/sitemap.xml
дальше даже не стал проверять )))
Общее качество реализации Ваших проектов я оцениваю как ниже среднего. Если не согласны я сделаю аудит и опубликую критику ваших сайтов.
Я вообще считаю что преждевременно критиковать других пока не научитесь это делать сами.
Не заметно что вы сами делали то, за что критикуете других:
www.petron.ru/sitemap.xml
ptk-tehgaz.ru/sitemap.xml
alexeychernov.com/sitemap.xml
дальше даже не стал проверять )))
Общее качество реализации Ваших проектов я оцениваю как ниже среднего. Если не согласны я сделаю аудит и опубликую критику ваших сайтов.
Я вообще считаю что преждевременно критиковать других пока не научитесь это делать сами.
Это яркий пример того, что можно легко прославиться и набрать кармы тупо критикуя других.
И это гораздо легче, чем прославиться, научившись делать что-то самому.
И это гораздо легче, чем прославиться, научившись делать что-то самому.
1) Я не выставлял себя, что я лучше UMI, я привел конструктивную критику системы. Нужно научиться принимать критику, а не тупо сваливать все на разработчиков. Это гораздо легче.
2) Карма была на последнем месте для меня при публикации этого материала и, если заметить, она не увеличилась, а уменьшилась.
2) Карма была на последнем месте для меня при публикации этого материала и, если заметить, она не увеличилась, а уменьшилась.
Мне кажется что Ваша реальная квалификация разработчика не позволяет Вам понимать за что должны отвечать разработчики, а за что платформы разработки.
Пока вы делаете дерьмосайты на Друпале за 5-10 тысяч рублей вы ничему не научитесь и ничего не поймете.
Лучше научитесь делать сайты нормально, сделайте нормальное портфолио, а потом займитесь критикой, раз это вам так нравится.
Это все мое ИМХО, ничего личного :-)
Пока вы делаете дерьмосайты на Друпале за 5-10 тысяч рублей вы ничему не научитесь и ничего не поймете.
Лучше научитесь делать сайты нормально, сделайте нормальное портфолио, а потом займитесь критикой, раз это вам так нравится.
Это все мое ИМХО, ничего личного :-)
Столько комментариев, что даже писать не хочется)).
Коротко скажу, что большое количествок критики высосоно из пальца, и присуще многим cms.
Коротко скажу, что большое количествок критики высосоно из пальца, и присуще многим cms.
Кстати UMI позволяет настраивать административный интерфейс, половина критики может быть протеворечива, потому как любые неудобные моменты UMI можно поменять в шаблоне админки. И кнопки и редактор Tinymce и обработка скриптов… Все зависит от задачи.
Поскольку все лицензии привязаны к домену, то при переносе сайтов на рабочие домены лицензию нужно получать заново.
Ложь! При смене домена. лицензия не меняется, а переносится на новый домен.
Добавление изображений (известная проблема CMS) превращается в сущий ад, если количество изображений становится больше 20-50, поскольку после загрузки изображения его надо сначала найти (по имени или превьюшке), выбрать и только потом вставить. Т.е. нет простого режима — выбрал файл, загрузил, вставил.
Тоже ложь. Фотографии сами подсвечиваются, нажал Enter и загуженная фото выбрана, нет необходимости ее искать.
Поскольку эта статья или очень устарела или писалась непрофессионалом, мне видимо придется написать новую на тему реальных минусов системы, возможных проблем и удобных реализациях задач. Очень надеюсь что возьмусь за это в скором времени.
Не люблю читать такие публикации, так как полезной информации для меня они не имеют. Разве это критичная ошибка b — strong? Смешно, такое ощущение, что статью писал обиженный html верстальщик. Я вот не работал с umi, смотрел один раз демо, что мне лично бросилось в глаза очень не удобный пользовательский интерфейс в системе управления по сравнению с тем же Битриксом. Может есть в ней какие то критичные уязвимости, не вот эти смешные, что можно вставить в редактируемый материал к которому пользователь имеет доступ js, да это бред! Как она себя ведет при сильных нагрузках на сайт? Удобно ли под нее писать модули, если ли хорошая документация, какая в ней вообще архитектура и ее недочеты? А так грязью полить можно кого и что угодно, тем более за не валидный html по ошибкам validator.w3.org, которые и ошибками то не являются. Про битрикс я для примера написал мне он не нравиться на больших каталогах товаров УЖАСТНО РАБОТАЕТ, но они молодци в грамотном пиаре и хорошо поставленном отделе продаж. Что мне не нравится в многих cms — РАЗРАБОТЧИК НЕ ПОНИМАЕТ ЧТО ОН ПИШЕТ СИСТЕМУ ДЛЯ ПОЛЬЗОВАТЕЛЯ-РЕДАКТОРА, а не для разработчика.
Ждем новую статью! За 2 года UMI немного изменилась.
Давно работаю с UMI, так себе система.
Критика UMI.CMS