Я с вами не в коем случае не спорю, но во-первых, сколько надо посадить в штат людей, чтобы они проверяли пользуется ли клиент лицензией или нет? Во-вторых, маркетинг юми конечно расчитан на конечного потребителя, но все процессы заточены на работу со студиями, в студиях не покупают лицензии чтобы пару дней поиграться (при этом есть триалка на крайний случай) и забыть на год.
Конечно жаль 30 000 человека, но думать надо головой, чтобы он не купил, сейчас бы уже не работало.
PS. Могу попробовать предложить решение. Разверните триалку и вбейте в неё свой ключик. В теории должно прокатить.
Сугубо мое мнение, но в том же битриксе это достаточно удобно. Все быстро, все фильтруется, нужные поля можно показать сразу в таблице. В юми вывод максимум по 50 строк, фильр есть, но на больших объемах между поисками можно чашечку кофе попить. Там много проблем, не посмотреть в таблице нужные поля заказа. Если объект дочерний, то его поля не вытащить в таблицу, только родителя и так далее и тому подобное. Надо "самописеть". В движках заточенных под работу с номенклатурой и заказами по дефолту все это удобнее сделано. Про остальные системы "общего назначения" ничего не скажу - не пробовал.
На кой? Вся идея скрытого поля в другом.
Спамеры - боты. И они просто заполняют все поля без разбора абракадаброй или какой то другой лабудой. А если поле скрыто, не type=hidden, а именно стилями display:none, то пользователь это поле не увидит и никак заполнить не сможет.
Вот если поле заполнено, значит 100% спам, если не заполнено, значит не спам. Работает в 99% случаев.
xslt это не технология движка и в нем все строго, не соответствует спецификации объявленной вначале - белый экран. Как говорится ненадо перекладывать с больной головы на здоровую.---------- Добавлено 13.04.2017 в 01:15 ----------SmirnovAN, есть разные бизнес модели и у них самая распространненая. То что вы не пользовались лицензией это не проблема юми и вы её активировали, если бы не активировали, то она бы работала, а раз активировали, значит пользовались :)
Я собрал не один десяток сайтов на ней. Знаю её достаточно хорошо. Могу примерно дать свой отзыв. Сама система не плоха, удобна для клиентов, все интуитивно и клиенты в ней могут работать сами, даже если им 40-50 лет. На этом наверное положительные стороны закончились (хотя интуитивность для разных поколений это и был основной критерий выбора работы с ней, так как кучу времени тратилось на поддержку клиентов по обновлению контента на других системах). Поддержки 0, ТП как с луны, они не программеры и не технари, обращатся к ним бесполезно. Слал им баги ядра, в ответ просили доступ к сайту, на кой - не понятно, видимо там бот на том конце. Делать сложные проекты сейчас бы на ней не стал.
Юми наверное одна из последних систем, на которой я бы делал интернет магазин, но это уже пришло с опытом. Там очень неудобно и медленно становится на больших объемах данных. Управлять несколькими тысячами товаров - ад, и еще больший ад управлять несколькими сотнями тысяч заказов :) Лично у нас система работает медленно на одном проекте, даже не используя все ресурсы сервера, просто уперлась в архитектуру своей БД. Мы все же решили переносить проект на symfony. НО! корпоративные сайты - просто идеальная система, все просто, легко и быстро. Ну и достаточно легко и быстро допиливается.
Потому что кто то не пользуется сессиями вообще, или не пользуется сессиями от самого php, логично же? Многие сессии хранят в БД например.---------- Добавлено 12.04.2017 в 23:49 ----------
Такая проблема не у всех сайтов на хостинге а у конкретных, например которые открывают сессию даже ботам которые сайт индексируют и показать таким сайтам что им лучше перенести сессии в редис - это как минимум полезно. Сами клиенты об этом могут и не знать, а клиентов терять.---------- Добавлено 12.04.2017 в 23:52 ----------
Верно, Учить школьников использовать сессии правильно и не открывать их на каждый чих. Вот это будет "решением проблем в корне". Зачем такая статистика хостеру? Эта статистика как раз таки нужна клиенту, чтоб он принял какие то меры. И от ресурсов это мало зависит, дело в том, что это зависит от кривоты использования штатного механизма сессий, и рано или позно вы упретесь в железку, а вот показать клиенту, что у него с сайтом что то не то, это полезно.---------- Добавлено 12.04.2017 в 23:54 ----------
Мемкашед для сессий - зло. Там множество проблем и багов появляется, связанные с вытеснениями. Попробовал на одном очень посещаемом ресурсе - отказался. Мемкеш все же для "горячего" кэша, который не надо греть и можно просто слить если что.
Все просто: на винде не работаю опкэшеры. По той причине я работаю с докер\вагрант\etc. Очень заметно на symfony2 отсутствие опкешеров.---------- Добавлено 04.04.2017 в 00:24 ----------
Иногда бывает потребность в разном софте и в разных его версиях. Докер очень выручает, когда можно поднять за раз несколько разных контейнеров с разными версиями поисковых движков и посмотреть какой в данном случае подойдет больше. Да и например под винду можно не найти нужного. А еще у тебя все работает на том же окружении что и продакшен с теми же версиями софта. И не делаешь под nginx а потом переносишь под апач.---------- Добавлено 04.04.2017 в 00:26 ----------
Зачем вам openserver? как только я открыл вагрант и докер (одновременно они не работают вместе) для себя, я забыл что такое опенсервер как страшный сон, а вы жалеете)))
OpenServer здорого на флешку поставить и на призентации с готовым прототипом ездить в остальных случаях в нем толку нету)))
SEOCOR, круто, но я начал бы с выявления ЦА и её интересов. А уже потом топ3, смм и контекст
У меня сейчас на umi табличка весит 18Гб, вместе с индексами база занимает 110Гб и ничего, сайт работает :)
Посмотрите на Grav
Для лендосов я бы искал по таким требованиям:
Во-первых, блочность. Возможность создавать области на страницах в неограниченных количествах, а не 15 страниц с последующим выводом на одной.
Во вторых, фронтед редактирование. Без админки, чтоб сразу на стороне сайта, как бы смешно не звучало но тот же битрикс, umi.cms, а так же pimcore это умеют делать. Это те из которых знаю, скорее всего есть и множество других.
Лучше конечно собрать что то свое на фреймворке, впелить на фронт что нибудь компонентное, типо vue.sj и сделать свой lpgenerator
PS. Я не знаю зачем заказчику что то менять на лендосе, ну вот как то не сталкивался за много лет, если только какой нибудь телефон (хотя там обычно колтрекинг), ну или цену. Но для этого не нужна админка от слова совсем. Обычно изменения вносим мы сами, делаем десятки вариантов для сплитов и тут уже помогает нода, шаблонизаторы и сборщики, на выходе голый html, на входе все удобно как в cms.
Битрикс это прежде всего фреймворк и сказать по количеству товаров характер нагрузки достаточно сложно.
Есть у меня битриксы на ihor, на младших тарифах летают.
Я бы ориентировался на характер нагрузки и на прямоту рук человека собирающего вам сайт. Можно на каждом хите 1200 товаров пересчитывать, а можно все в кэш сложить и железо не мучать. В битриксе нет кода с комментариями /* Функция насилует процессор */ или /* Функция убивает 6 SSD дисков за год */. В 99% случаях скорость работы и потребление ресурсов зависит от того как собрали сайт, внутреннее апи там за столько лет вылизано достаточно хорошо и прошло испытания на крупных хайлоадах, хоть при этом и не читабельно.
