Есть еще админка и она весьма важна, функционал нужен большой, хотя и его надо дорабатывать. По совокупности факторов наш путь проще. По сути все сводится к точкам входа и если разработчик может их назвать сразу, то все не так уж страшно.
Как раз таки админка это наименьшая проблема. Доработать админку CMS в сотни раз сложнее, чем накидать свою с функциями которые нужны и удобны вам. У топовых фремворков давно есть админгенераторы, которые просто и легко кастомизируются. Что что, а админка как раз не проблема в данном случае.
Вы нигде не найдете ТП по доработке под вас. Любая ТП CMS с которой я сталкивался, могут ответить только по своему функционалу, например объяснить почему у вас новости не работают. Но как вам завести ваши даннные в хитром формате, никто вникать даже не будет. Возьмите ТП от топовых партнеров, они вам за денюшку накидают любые точки входа.
SmirnovAN: Неа, не так, есть куча внешних скриптов и сводных БД, написанных нами и всё это надо поженить воедино. Есть лишь одна связка людей для максимально быстрой реализации, это разработчики скриптов + разработчики CMS. Всем остальным требуется время на изучение.
Вы не правильно подошли к выбору. С таким подходом вам не нужна CMS в принципе, так как любая CMS заставит вас нагородить костылей, так как у вас уже сформированы процессы, которые с 99% вероятностью не впишутся в архитектуру CMS. Возьмите фреймворк и подружите на нём все так, как надо именно вам.
melkozaur: Мультисайтовость - это такой параметр, который, грубо говоря, является просто одной из фич в списке "преимуществ" системы. Каких-то плюсов лично я не вижу вообще.
Просто вы не сталкивались с такого рода задачами. Это местами удобно. Не надо пилить интеграции между сайтами и передачей данных между ними. У вас из коробки будет общая авторизация на все сайты, одна база клиентов, работать с которой из одной админки намного удобнее. Ну и контент, он общий, а значит управлять им проще, проще строить карты интересов клиентов, проще показывать таргетированные предложения и т.д и т.п
melkozaur: Только разве что возможность один раз купить и сделать несколько магазинов.
Вот несоклько магазинов я бы не делал на одной лицензии. Вот например примеры из практики. У клиентов есть и корпоративный брендовый сайт с техникой, характеристиками, презентациями для партнеров, и есть интернет магазин для розницы, где зашел и купил. Можно сделать на разных системах, а можно сделать чтоб добавлялось в корзину с корпоративного сайта, или показать баннер когда человек перешел в ИМ той продукции, которой он интересовался на презентационном сайте.
PS. ну и поддерживать 2 сайта сложнее чем 1 ровно в 2 раза.
Jaf4: "активировали" и "пользуетесь" - "две очень большие разницы", вы согласны?
А то, что у клиента нет сайта на этой системе - им пофиг. Но покупал -то он ее не активировать, и не в саппорт обращаться. Он заплатил, чтобы на ней работал сайт.
Я с вами не в коем случае не спорю, но во-первых, сколько надо посадить в штат людей, чтобы они проверяли пользуется ли клиент лицензией или нет? Во-вторых, маркетинг юми конечно расчитан на конечного потребителя, но все процессы заточены на работу со студиями, в студиях не покупают лицензии чтобы пару дней поиграться (при этом есть триалка на крайний случай) и забыть на год.
Конечно жаль 30 000 человека, но думать надо головой, чтобы он не купил, сейчас бы уже не работало.
PS. Могу попробовать предложить решение. Разверните триалку и вбейте в неё свой ключик. В теории должно прокатить.
Сугубо мое мнение, но в том же битриксе это достаточно удобно. Все быстро, все фильтруется, нужные поля можно показать сразу в таблице. В юми вывод максимум по 50 строк, фильр есть, но на больших объемах между поисками можно чашечку кофе попить. Там много проблем, не посмотреть в таблице нужные поля заказа. Если объект дочерний, то его поля не вытащить в таблицу, только родителя и так далее и тому подобное. Надо "самописеть". В движках заточенных под работу с номенклатурой и заказами по дефолту все это удобнее сделано. Про остальные системы "общего назначения" ничего не скажу - не пробовал.
mendel: Добавляете скрытое поле, в нем выводите некий уникализированный под клиента код, например мд5 от айпи.
На кой? Вся идея скрытого поля в другом.
Спамеры - боты. И они просто заполняют все поля без разбора абракадаброй или какой то другой лабудой. А если поле скрыто, не type=hidden, а именно стилями display:none, то пользователь это поле не увидит и никак заполнить не сможет.
Вот если поле заполнено, значит 100% спам, если не заполнено, значит не спам. Работает в 99% случаев.
Onecontent: Был клиентский сайт на UMI - падал от добавления кода метрики в шаблон) Больше не сталкивались, к счастью.
xslt это не технология движка и в нем все строго, не соответствует спецификации объявленной вначале - белый экран. Как говорится ненадо перекладывать с больной головы на здоровую.
---------- Добавлено 13.04.2017 в 01:15 ----------
SmirnovAN, есть разные бизнес модели и у них самая распространненая. То что вы не пользовались лицензией это не проблема юми и вы её активировали, если бы не активировали, то она бы работала, а раз активировали, значит пользовались :)
Я собрал не один десяток сайтов на ней. Знаю её достаточно хорошо. Могу примерно дать свой отзыв. Сама система не плоха, удобна для клиентов, все интуитивно и клиенты в ней могут работать сами, даже если им 40-50 лет. На этом наверное положительные стороны закончились (хотя интуитивность для разных поколений это и был основной критерий выбора работы с ней, так как кучу времени тратилось на поддержку клиентов по обновлению контента на других системах). Поддержки 0, ТП как с луны, они не программеры и не технари, обращатся к ним бесполезно. Слал им баги ядра, в ответ просили доступ к сайту, на кой - не понятно, видимо там бот на том конце. Делать сложные проекты сейчас бы на ней не стал.
Юми наверное одна из последних систем, на которой я бы делал интернет магазин, но это уже пришло с опытом. Там очень неудобно и медленно становится на больших объемах данных. Управлять несколькими тысячами товаров - ад, и еще больший ад управлять несколькими сотнями тысяч заказов :) Лично у нас система работает медленно на одном проекте, даже не используя все ресурсы сервера, просто уперлась в архитектуру своей БД. Мы все же решили переносить проект на symfony. НО! корпоративные сайты - просто идеальная система, все просто, легко и быстро. Ну и достаточно легко и быстро допиливается.
dimsog: Генерация страницы на VPS 0.4 секунды, та же страница в OpenServer с тем же набором: PHP 7.1 / MySQL 5.5 создается за 3 секунды. Магия.
Все просто: на винде не работаю опкэшеры. По той причине я работаю с докер\вагрант\etc. Очень заметно на symfony2 отсутствие опкешеров.
---------- Добавлено 04.04.2017 в 00:24 ----------
Дикий пионер: Эм, а нафига тогда вообще сборки-то, если умеешь сам всё настраивать?
Иногда бывает потребность в разном софте и в разных его версиях. Докер очень выручает, когда можно поднять за раз несколько разных контейнеров с разными версиями поисковых движков и посмотреть какой в данном случае подойдет больше. Да и например под винду можно не найти нужного. А еще у тебя все работает на том же окружении что и продакшен с теми же версиями софта. И не делаешь под nginx а потом переносишь под апач.
---------- Добавлено 04.04.2017 в 00:26 ----------
webiumpro: OpenServer. Работаю в Ubuntu, и иногда прямо жаль становится, что для линукса нет сборки OpenServer)
Зачем вам openserver? как только я открыл вагрант и докер (одновременно они не работают вместе) для себя, я забыл что такое опенсервер как страшный сон, а вы жалеете)))
OpenServer здорого на флешку поставить и на призентации с готовым прототипом ездить в остальных случаях в нем толку нету)))
Alex Klo: подумаешь, 38Мб или даже 100Мб...
вон у меня на одном из сайтов - на UMI.CMS - одна из таблиц, если ничего не делать, растёт бесконечно, в зависимости от посещаемости, видимо, аналогично как у Devvver, - была до 7Гб !
разработчики посоветовали каждую минуту в кроне запускать скрипт очистки...
У меня сейчас на umi табличка весит 18Гб, вместе с индексами база занимает 110Гб и ничего, сайт работает :)
Есть еще админка и она весьма важна, функционал нужен большой, хотя и его надо дорабатывать. По совокупности факторов наш путь проще. По сути все сводится к точкам входа и если разработчик может их назвать сразу, то все не так уж страшно.
Как раз таки админка это наименьшая проблема. Доработать админку CMS в сотни раз сложнее, чем накидать свою с функциями которые нужны и удобны вам. У топовых фремворков давно есть админгенераторы, которые просто и легко кастомизируются. Что что, а админка как раз не проблема в данном случае.
Вы нигде не найдете ТП по доработке под вас. Любая ТП CMS с которой я сталкивался, могут ответить только по своему функционалу, например объяснить почему у вас новости не работают. Но как вам завести ваши даннные в хитром формате, никто вникать даже не будет. Возьмите ТП от топовых партнеров, они вам за денюшку накидают любые точки входа.
Неа, не так, есть куча внешних скриптов и сводных БД, написанных нами и всё это надо поженить воедино. Есть лишь одна связка людей для максимально быстрой реализации, это разработчики скриптов + разработчики CMS. Всем остальным требуется время на изучение.
Вы не правильно подошли к выбору. С таким подходом вам не нужна CMS в принципе, так как любая CMS заставит вас нагородить костылей, так как у вас уже сформированы процессы, которые с 99% вероятностью не впишутся в архитектуру CMS. Возьмите фреймворк и подружите на нём все так, как надо именно вам.
Мультисайтовость - это такой параметр, который, грубо говоря, является просто одной из фич в списке "преимуществ" системы. Каких-то плюсов лично я не вижу вообще.
Просто вы не сталкивались с такого рода задачами. Это местами удобно. Не надо пилить интеграции между сайтами и передачей данных между ними. У вас из коробки будет общая авторизация на все сайты, одна база клиентов, работать с которой из одной админки намного удобнее. Ну и контент, он общий, а значит управлять им проще, проще строить карты интересов клиентов, проще показывать таргетированные предложения и т.д и т.п
Только разве что возможность один раз купить и сделать несколько магазинов.
Вот несоклько магазинов я бы не делал на одной лицензии. Вот например примеры из практики. У клиентов есть и корпоративный брендовый сайт с техникой, характеристиками, презентациями для партнеров, и есть интернет магазин для розницы, где зашел и купил. Можно сделать на разных системах, а можно сделать чтоб добавлялось в корзину с корпоративного сайта, или показать баннер когда человек перешел в ИМ той продукции, которой он интересовался на презентационном сайте.
PS. ну и поддерживать 2 сайта сложнее чем 1 ровно в 2 раза.
"активировали" и "пользуетесь" - "две очень большие разницы", вы согласны?
А то, что у клиента нет сайта на этой системе - им пофиг. Но покупал -то он ее не активировать, и не в саппорт обращаться. Он заплатил, чтобы на ней работал сайт.
Я с вами не в коем случае не спорю, но во-первых, сколько надо посадить в штат людей, чтобы они проверяли пользуется ли клиент лицензией или нет? Во-вторых, маркетинг юми конечно расчитан на конечного потребителя, но все процессы заточены на работу со студиями, в студиях не покупают лицензии чтобы пару дней поиграться (при этом есть триалка на крайний случай) и забыть на год.
Конечно жаль 30 000 человека, но думать надо головой, чтобы он не купил, сейчас бы уже не работало.
PS. Могу попробовать предложить решение. Разверните триалку и вбейте в неё свой ключик. В теории должно прокатить.
Это вообще характерно для всех cms.
Сугубо мое мнение, но в том же битриксе это достаточно удобно. Все быстро, все фильтруется, нужные поля можно показать сразу в таблице. В юми вывод максимум по 50 строк, фильр есть, но на больших объемах между поисками можно чашечку кофе попить. Там много проблем, не посмотреть в таблице нужные поля заказа. Если объект дочерний, то его поля не вытащить в таблицу, только родителя и так далее и тому подобное. Надо "самописеть". В движках заточенных под работу с номенклатурой и заказами по дефолту все это удобнее сделано. Про остальные системы "общего назначения" ничего не скажу - не пробовал.
Добавляете скрытое поле, в нем выводите некий уникализированный под клиента код, например мд5 от айпи.
На кой? Вся идея скрытого поля в другом.
Спамеры - боты. И они просто заполняют все поля без разбора абракадаброй или какой то другой лабудой. А если поле скрыто, не type=hidden, а именно стилями display:none, то пользователь это поле не увидит и никак заполнить не сможет.
Вот если поле заполнено, значит 100% спам, если не заполнено, значит не спам. Работает в 99% случаев.
Был клиентский сайт на UMI - падал от добавления кода метрики в шаблон) Больше не сталкивались, к счастью.
xslt это не технология движка и в нем все строго, не соответствует спецификации объявленной вначале - белый экран. Как говорится ненадо перекладывать с больной головы на здоровую.
---------- Добавлено 13.04.2017 в 01:15 ----------
SmirnovAN, есть разные бизнес модели и у них самая распространненая. То что вы не пользовались лицензией это не проблема юми и вы её активировали, если бы не активировали, то она бы работала, а раз активировали, значит пользовались :)
Я собрал не один десяток сайтов на ней. Знаю её достаточно хорошо. Могу примерно дать свой отзыв. Сама система не плоха, удобна для клиентов, все интуитивно и клиенты в ней могут работать сами, даже если им 40-50 лет. На этом наверное положительные стороны закончились (хотя интуитивность для разных поколений это и был основной критерий выбора работы с ней, так как кучу времени тратилось на поддержку клиентов по обновлению контента на других системах). Поддержки 0, ТП как с луны, они не программеры и не технари, обращатся к ним бесполезно. Слал им баги ядра, в ответ просили доступ к сайту, на кой - не понятно, видимо там бот на том конце. Делать сложные проекты сейчас бы на ней не стал.
Юми наверное одна из последних систем, на которой я бы делал интернет магазин, но это уже пришло с опытом. Там очень неудобно и медленно становится на больших объемах данных. Управлять несколькими тысячами товаров - ад, и еще больший ад управлять несколькими сотнями тысяч заказов :) Лично у нас система работает медленно на одном проекте, даже не используя все ресурсы сервера, просто уперлась в архитектуру своей БД. Мы все же решили переносить проект на symfony. НО! корпоративные сайты - просто идеальная система, все просто, легко и быстро. Ну и достаточно легко и быстро допиливается.
Генерация страницы на VPS 0.4 секунды, та же страница в OpenServer с тем же набором: PHP 7.1 / MySQL 5.5 создается за 3 секунды. Магия.
Все просто: на винде не работаю опкэшеры. По той причине я работаю с докер\вагрант\etc. Очень заметно на symfony2 отсутствие опкешеров.
---------- Добавлено 04.04.2017 в 00:24 ----------
Эм, а нафига тогда вообще сборки-то, если умеешь сам всё настраивать?
Иногда бывает потребность в разном софте и в разных его версиях. Докер очень выручает, когда можно поднять за раз несколько разных контейнеров с разными версиями поисковых движков и посмотреть какой в данном случае подойдет больше. Да и например под винду можно не найти нужного. А еще у тебя все работает на том же окружении что и продакшен с теми же версиями софта. И не делаешь под nginx а потом переносишь под апач.
---------- Добавлено 04.04.2017 в 00:26 ----------
OpenServer. Работаю в Ubuntu, и иногда прямо жаль становится, что для линукса нет сборки OpenServer)
Зачем вам openserver? как только я открыл вагрант и докер (одновременно они не работают вместе) для себя, я забыл что такое опенсервер как страшный сон, а вы жалеете)))
OpenServer здорого на флешку поставить и на призентации с готовым прототипом ездить в остальных случаях в нем толку нету)))
SEOCOR, круто, но я начал бы с выявления ЦА и её интересов. А уже потом топ3, смм и контекст
подумаешь, 38Мб или даже 100Мб...
вон у меня на одном из сайтов - на UMI.CMS - одна из таблиц, если ничего не делать, растёт бесконечно, в зависимости от посещаемости, видимо, аналогично как у Devvver, - была до 7Гб !
разработчики посоветовали каждую минуту в кроне запускать скрипт очистки...
У меня сейчас на umi табличка весит 18Гб, вместе с индексами база занимает 110Гб и ничего, сайт работает :)