Прям в точку! Обычно люди выбирают Битрикс по трем признакам:
- Битрикс это 1С (на самом деле нет, они их купили)
- Битрикс это дорого, значит круто
- Битрикс это удобно
Да, по последнему пункту правда. Регулярно сталкиваюсь с пожеланиями клиента "сделайте как в Битриксе" и какие-то прикольные фишки, которые пишутся минут за 15. Нет, ну правда полезные. Но под капотом ад, и всё дорого.
У меня была ЦМС "чисто для своих", для гос.конторы, юзеров к сайту не подпускали, они только материал на почту присылали. Решил сделать минималистично. На файликах, и только на файликах. Сейчас глянул - работает, живая.
Авторизация на htpasswd.
Внутри ACE, файл-аплоадер, и собственно всё.
Ну еще сделал две копии этого файлика "админки", чтобы если напортачить при правках админки то была возможность без фтп исправить, и отдельный конфиг с названиями закладок и цветами для них, чисто для удобства. Выглядит оно вот так:
Зачем? Без тысячи бездумно налепленных плагинов его выдерживает любой хостинг на любой приемлимой нагрузке.
Ну я и не включаю никогда. И ничего не происходит. А ведь там "сотни запросов" сразу)
А зачем их регулировать если и с кривыми запросами всё прекрасно работает?
Вы впадаете в страшный грех. Грех преждевременной оптимизации, он же "нанооптимизация". У нас визитка на 25 страниц, которая по факту разрастется в 50 страниц по сути и 200 статей на разные группы ключей.
Ну какая тут к черту оптимизация запросов?
То это не сайт на 25 страниц который вообще хотели сделать без ЦМС))
Да и в тяжелом проекте время отклика в 10 секунд это надо умудриться.
Последний раз у меня дикие тормоза были в 6 секунд. Лажа была в том, что был включен подробный лог, который писал все вызовы АПИ движка, а это под тысячу записей, при этом он открывал и закрывал поток при каждой записи, ибо так надежнее, а дело было на перегруженной облачной ноде, где файловую систему куда писался лог умудрились утянуть в сеть, и на другую ноду.
В час пик у хостера были такие тормоза. SQL запросы тоже были не оптимизированны, их было чуть больше сотни. Но уменьшение уровня лога с параноидального до подробного вернуло скорость в рамки 200мс.
Ну не знаю я как нужно издеваться чтобы иметь 10 секунд. Не знаю. При современных серверах то.
Да еще и на статейнике/визитке, который мы обсуждаем.
Еще раз. У нас СТАТИЧНЫЙ САЙТ. Тут даже проблему инвалидации решать не нужно. При задержке в 1сек (а больше затормозить сайт думаю вам не удастся даже если специально будете навешивать плагины для тормозов) мы пройдем все 25 страниц по разу, а дальше она будет возвращаться из кеша. Сильно зависит от механизма кеширования, но большую часть проблем заберет на себя банальный нгинкс, который хостер поставит перед нами из экономии)
Понимаю. Есть один проект на ОпенКарт. Прекрасно понимаю. По этой причине я ушел от всяких ВП и т.п.
Понимаю дважды, ибо в моей ЦМС средства отладки слабоваты в сравнении с тем же юии. Но я и не агитирую ПИСАТЬ на ВП.
Я говорю что оно приемлимо для заказчика. Не более.
Ну в большинстве ЦМС больше времени уйдет чтобы понять что и откуда нужно импортировать чем на написание самого импорта)
Совсем не показательный.
Это были дизайнеры (оффлайновые: архитекторы по образованию, планировка квартир, оформление, полиграфия и т.п.). А исполнители были слабоваты, да еще и с клиентом спорить не стали. В результате - верстка на таблицах, вся перелинковка картинками без альтов и т.п.
Ну и да, поскольку это таки близкие, то я таки честно потратил часа два-три на попытки это распарсить на что-то хоть отдаленно единообразное и выдавить из этого хоть какую структуру, пока не плюнул и не похоронил.
В целом я с аргументом соглашусь. Как правило перенос статики в динамику проще. Просто вспомнилось.
Теоретически да.
Практически - был у меня один сайт.
Пытался натянуть на ЦМС.
На 150 страниц там было около 60(!) разных вариаций верстки.
Короче закончилось всё новым сайтом с существенной деградацией разнообразия и ручным копипастом контента со старого сайта.
Ибо нефиг. (Ибо нефиг было со мной не советоваться - старые школьные друзья))
Прям сотни запросов?)
И прям в Yii их нет?)) Про schemaCachingDuration помните?)
Нет, неоптимизированный план запросов бывает у всех.
Но дело даже не в том.
Не помню как с этим делом в Юии2. Но помню неоднократные и справедливые разговоры мейнтейнеров, что незачем за них волноваться, что и кеширование решает, и СУБД закеширует и драйвер и даже если ничего не закешируется, то это такие копейки в скорости все эти десятки мусорных запросов, что не о чем беспокоиться.
Так вот, даже в столь нелюбимом всеми нами ВП кеширование решает.
Ерунда это всё и вздор.
На микросайтах никто и никогда не заметит разницы производительности с кешем или без. А уж между кешированным ВП и кешированным Юии так точно не заметят разницы.
И да, я говорил не о множестве файлов. Я говорил о том, что даже в нужном коде много "лишнего", что нужно только на случай функций которые нам не нужны именно в этом проекте.
Неа.
Вы ошиблись в самом начале.
Вы уже решили какой вам нужен сайт, т.е. вероятно составили СЯ, изучили профиль ЦА и т.п.
Ведь так? Или нет? Или цифра 25 взята с потолка?
Вы уже определились со стратегией продвижения, и какие метатеги будут нужны, какая схема перелинковки, уже заказали все тексты?
Нет?
Вы УЖЕ ошиблись решив что сначала нужен сайт, а потом СЕО.
А потом вы будете делать сайтмеп. В блокноте, потому что выбрали вариант без ЦМС.
А потом будете переделывать ВСЕ страницы потому что сеошник скажет что без микроразметки никуда.
А потом выйдет апдейт, и стратегия поменяется. Нужна будет лишь чуть другая структура сайта, часть текстов подправить и т.п.
Вы уже ошиблись говоря о дизайнере. 90% что вам не нужен дизайнер, что даже если у вас есть деньги на ДЕЙСТВИТЕЛЬНО хороший дизайн и действительно качественную верстку всего, и чтобы адаптивно и т.п., то именно этой суммы потом не хватит на СЕО или переделку сайта.
Но даже если хватит... хорошие дизайны вылизываются месяцами. Со всеми мелочами. И купленный готовый дизайн с версткой за 16$ будет все равно красивее для пользователей, и все равно больше процент конверсии посетителей.
А подружить всех очень просто.
Нужно заказать всё в одном месте. И дальше уже их головная боль как всех подружить.
privetetoya, вам уже несколько раз повторили что выбор технологии в вашем случае абсолютно не важен. Я уверен что вы УЖЕ совершили пару более тяжелых ошибок вроде маркетинговых планов и т.п. Не тратьте время, бросьте монетку. Шанс ошибиться одинаков.
Aisamiery, про то что сами вы не местные, и под самописом называете "слегка поднастроить Yii" я уже понял давно. Вы упорно избегаете ответа на вопрос чем ваш гибрид вашего кода (вашего или Gii-шного, не важно) и кода Yii будет лучше чем готовая CMS. (Кстати то что вы называете самописом это тоже CMS, только самописная). Тонны кода который не будет использоваться. Тонны. И если вы думаете что раз он не исполняется, то это ерунда, то вы не правы. Да, вы не юзаете драйвера к другим СУБД для построителей. Но код построен так, что выполняет дополнительные проверки. Да, вы не ставите смарти с твигом, а пользуетесь инлайновым шаблонизатором. Но вы дергаете его через ДИ, который в свою очередь обернут в сахар, который имеет кучу настроек... Да, вы не переопределяете урлконтроллер, но весь этот код который определяет стратегию разбора урлов выполняется. Да, вы не создаете две копии компоненты ДБ. Но возможность такая имеет свою цену... Вы не пользуетесь аякс-валидацией? Но код проверки отрабатывает. Вы не забыли убрать Gii с прода? Или забыли? И дебагпанель не забыли, и даже модуль защиты от XSRF не забыли, и пурифаер на месте... ой. А мы ведь начали с того что в самописе нет ничего лишнего.
Не находите что немного противоречите себе? Так что у нас с трусами и крестиком?))
Оверхед у нас влияет на две вещи - производительность и безопасность.
По производительности вы от желания похвастаться сами себя и опровергли - вагоны лишнего кода на производительность влияют лишь в ооооочень больших проектах. С безопасностью все проще - что в юии, что в вп вы пользуетесь стабильным проверенным кодом ядра который одинаково безопасен и уязвим, чужими плагинами (да, да, то что вы юзаете композер не отменяет вашей зависимости от стороннего кода, и недавняя история с маленькой библиотекой в нод - тому подтверждение), и от вашего кода. Риски абсолютно идентичны. Только под ВП только что моя кошка не говнокодит, а под юии уже нужен хоть какой, но уровень. А значит и з/п можно просить выше...
Давно диагноз по фотографии научились ставить?)
Бла-бла-бла-бла... Но нет ответа на вопрос:
Прелестно. А ваш самопис не будет иметь "излишней функциональности"? Никаких активрекорд, никаких активформ и прочего? Всё самопис, всё ручками. Никакого оверхеда? Или таки Юии2? Вы уж голубчик определитесь и либо трусы наденьте либо крестик снимите.
Лишний багаж у фреймворка не меньше, а как правило даже больше чем у простенькой CMS вроде вордпресса. Отчасти соглашусь с мыслью о лишней функциональности. Часто она проблемна. Но - не тот случай.
Не покрыта. :) TDD не единственная рабочая парадигма. У меня v0.3.8 имею право. SemVer разрешает.
Так что да. Мои клиенты от меня зависимы. Партнер мой считает это плюсом. Я минусом. Но факт, да.
Так а чем меряться то? Вы этими словами только подтверждаете мои слова) Спасибо вам за это)))
Довольно понятно кому?) все пишут что у них MVC, а на практике Тупые Жирные Контроллеры у каждого первого. А бывает и вообще некоторые пишут OpenCart который потом не гнушаются называть ООП и MVC, поэтому и уточняю.
Угу. Знаем. Плавали. В следующем периоде вашей жизни вы или вернетесь обратно к готовым фреймворкам или соберете свой собственный, где всё это уже будет.---------- Добавлено 25.08.2016 в 16:37 ----------
Т.е. SSI вас тут не удивил?)
