Тестируем InstantCMS 1.9.1 (UTF8) beta

Когда планируется вторая версия?

maxisoft, это не ответ, это дополнение предыдущего поста. Чтобы вам было понятнее.
Хочется стабильных версий, только исправление ошибок. Я уже об этом говорил.
Чую я будет icms 2 и первая ветка умрет моментально… Fuze, может первой ветке LTS присвоить? На годик)) Не все захотят переводить на двойку...

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

но самое главное, то что если нет поддержки кириллицы у пользователя, то сайт отображает крякозябры, в utf русский всегда русский)
это наверно тоже влияет...
ну и вообще www.w3.org/International/articles/unicode-migration/Overview.ru.php

Чую я будет icms 2 и первая ветка умрет моментально…

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

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

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

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

Поверь, после выхода не пройдет и 2 месяцев, как перейдет более 90% на Инстант 2. Связано это с тем, что собственно терять то, как раз таки такому количеству сайтов и нечего особо. Доработки, как правило это все так себе, главное контент и премиум компоненты, будет его миграция значит переходить можно.

Что будет в 2012 году в Instant CMS
Выйдет 2 и все там будут (134)
Все останутся на 1.9 (33)
Чота в панике, чо делать? (41)

Вот небольшой опрос я делал с марта кажется.

Что будет в 2012 году в Instant CMS
Выйдет 2 и все там будут (134)
Все останутся на 1.9 (33)
Чота в панике, чо делать? (41)

Тут не хватает пунктика:
Выйдет 2 и все там будут но некоторые старые проекты оставят на 1.9/1.9.1

в этом случае статистика опросы была бы иной!)

Поверь, после выхода не пройдет и 2 месяцев, как перейдет более 90% на Инстант 2. Связано это с тем, что собственно терять то, как раз таки такому количеству сайтов и нечего особо.

Дабы не флудить, сообщаю баг: не возможно в "корневом" разделе форума создавать треды. "корень" форума находится по адресу /forum/1000 а нужно, чтобы был в /forum (не всем нужны подфорумы)

… теперь по теме: letsgo судя по тому, что я вижу, 1.9.1 не сильно будет отличаться от 2.0 по скорости работы. Посему, так как многим просто нужен UTF нет уверенности в прямо в 90% перевода на 2.0 НЕТ!

Рассуждаю так, ибо проекты мои были переведены на 1.9 с 1.6.1 вот совсем недавно, потому что 1.7 и уж тем более 1.8 были крайне не стабильны и содержали много "недочетов"…

Если вникнуть в нумерологию то сама по себе цифра 2.0 очень не удачна. Инстанту 5 лет в этом году? — назвать нужно: 5.0 — и тогда будет праздник! Будет успех и дело быстро будет делаться…

и еще, думаю, основным критерием перехода на более новую систему будет (в том числе) возможность подключать скрипты ТОЛЬКО ТАМ где это нужно, а не везде (как сейчас с этим JQUERY) и пусть все говорят что файл 1 раз загрузился и все — ответ мой уже много лет один и тот же: 1000 заходов на сайт — 1500 просмотров. Где 1 000 загрузок этого самого jquery… К чему грузить его мне на главной? Или странице форума если он там не используется? А вес его пусть даже в сжатой nginx форме — 30 килобайт.

Минона, мы работаем на унифицированность. Каждый раз при загрузке/написании какого-либо скрипта думать о том, подключил ли я JQUERY — глупо, если все скрипты, используемые в InstantCMS его используют.

Где 1 000 загрузок этого самого jquery

И что? У вас это тормозит загрузку сайта? Создает большую нагрузку на сервер? Не нужно экономить на спичках.

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

Было бы очень кстати максимально уменьшать вес страницы. К тому же, было бы кстати использовать кэширование, так, чтобы не пришлось внедрять "подгрузку контента на jquery" (видимо по этому в два.ноль убран smaty в шаблонах?)

К тому же, было бы кстати использовать кэширование, так, чтобы не пришлось внедрять "подгрузку контента на jquery"

Кеширование будет. Но к сожалению, не совсем верно люди воспринимают кеширование. А так же не верно воспринимают/интерпретируют много чего еще.
Это от нехватки знаний, нужно тогда просто изучать матчать, прежде чем что-то предлагать...

p.s. больше всего удивляет когда человек пытаясь увеличить скорость загрузки сайта начинает оптимизировать js скрипты, css, разбивать/сливать в один и т.п., в то время как сам процесс генерации php скрипта у него длиться 1-5 секунд. Чтобы выстроить правильное кеширование нужно понимать как работает браузер, как веб сервера отдают что-либо и с какими заголовками и много чего еще. ~70% кеширования на стороне клиента и так есть у всех по умолчанию.

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

Поисковики к этому относятся лучше. Вот тулзла от гугла developers.google.com/speed/pagespeed/
это известный факт, чем выше показатель тем лучше ранжирование, надеюсь по этому поводу letsgo не будет спорить?
зарубежные cms давно оптимизируют сайты...

попробуйте проанализируйте ваши сайты, балы будут плачевными, а к примеру на немецкой cms я выжал 96 балов из 100
developers.google.com/speed/pagespeed/insights

в icms очень много http запросов, куча картинок и тп...
нужно все системные картинки пихать в одну, и показывать каждую через css

насчет jquery, навязывать принудительно это неправильно, Минона вот не хочет чтобы он на главной грузился сразу, и в этом ее право. а те кто делают дополнения и прочее должны сами подгружать нужное для своего дополнения, так же и для cms это нужно там где оно нужно. Не пойму в чем проблема? Правильнее было бы дать возможность совсем не использовать jquery если она не нужна. Как во многих cms. Да что там, во многих cms даже можно выбрать mootools или jquery или все вместе. Не кажется что это правильно?

все эти js фреймворки это всего лишь красявости, cms должна работать без них

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

Да как самый простой пример 2 скрипта на одной странице. Как вы себе представляете рядового пользователя, который при установке какого либо скрипта должен помнить о том, что перед этим он уже ставил что-то и поэтому подключение jQuery из второго скрипта ему нужно ликвидировать?

Pasha, теперь понял. Для этого в cms должны быть переменные. Которые проверяются.

в icms очень много http запросов, куча картинок и тп… нужно все системные картинки пихать в одну, и показывать каждую через css

никто не спорит, но дефолтный шаблон как бы не предназначен для установки на боевой сайт. В своем шаблоне ведь можно сделать и спрайты и т.п. У нас не было задач оптимизировать css+html — это дается на откуп конечному пользователю icms. Дефолтный шаблон лишь пример функционала.

никто не спорит, но дефолтный шаблон как бы не предназначен для установки на боевой сайт. В своем шаблоне ведь можно сделать и спрайты и т.п. У нас не было задач оптимизировать css+html — это дается на откуп конечному пользователю icms. Дефолтный шаблон лишь пример функционала.

Речь идет о том, чтобы подключать JQUERY подключать только там, где он нужен. Но как?! В шаблоне, понятно, встраивается в шапку скрипт или "кусочек кода" и все.

А в компонентах?