Forums / National / Russian / Переезд на сиену. Нужен ли?

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

Kort, есть свое мнение? Рад за вас. Но, во-первых, прошу общаться более уважительно! Во-вторых, не стоит забывать, что ваше мнение и "хочу" ваших клиентов - это ваше личное дело. Движок должен быть универсальным и учитывать интересы всех.

Отбивание абзацных отступов вводами и прочие "достоинства бибикодов" выглядят паршиво -- это три.

И что же вы предлагаете? Прямо в текстах делать форматирование? Типа, надо абзац, извращаемся, делаем его на HTML? Это не грамотно по ряду причин. Кроме того, завтра вам понадобится поменять дизайн сайта, где абзацные отступы будут уже не актуальны. Что тогда делать? Править все тексты?

BB-код - оптимальный способ создавать контент с минимумом кода. Все остальное делается стилями. Благодаря этому, изменить вид контента в последствии можно очень легко и быстро. Нужен вам какой-нибудь супер абзац в текстах, - создайте дополнительный тег и обыграйте его стилями, пусть этот тег юзеры наполняющие сайт используют. Это гораздо лучше, чем заставлять их заниматься оформлением прямо в тексте.

Поддержка bbcodes для любителей старины остается -- это четыре.

Ок, но только пусть это будет правильная поддержка. Любители старины не должны потом переписывать код, чтобы заменить, например, стандартную вставку файла из PFS с тегами HTML на ту которая для них должна быть, т.е. вставка файла в виде bb-кодов.

SEO-описание и "человеческое" описание -- две разные вещи

Это ваше дело. Хотите, пусть у вас это будут разные вещи. Движок должен быть максимально гибким, чтобы его можно было использовать по-разному.

А page_desc умные мальчики заполняют отдельно для -- еще раз повторю -- метатега description.

Лишняя работа! Наполняться сайт должен легко. Если вы этого еще не поняли, то поймете потом, а тем временем не надо ограничивать свободу другим. Добавление новой страницы не должно встречать пользователя кучей текстовых полей и прочего. Заголовок, описание для сео, описание для человека, текст, ключевые слова,... А для организации загрузки единственного файла сколько полей... Надо все упрощать и максимально автоматизировать! Ну ладно, с ключевые словами еще можно согласиться, лучше чтобы их человек продумано написал сам. Но описание.... Вообще-то описание для человека и так в идеале должно содержать основную мысль и ключевые слова, куда уж лучше для описания для сео?

Добавлено 1 Минута спустя:

Собственно плюс хтмл - это скорость, его не надо парсить перед выводом, в отличии с ббкода

Один раз пропарсить надо сразу после публикации. Это не серьезно.

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

Добавлено 7 Минут спустя:

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

Зачем же его отключать? Пусть дублирует. Не просто же так это сделано, чтобы раздуть базу.

конечно не просто так, но базу в 300 мегов, из за производительности иметь не хочется, поэтому сиена и привлекает.

Конечно, bbcodes -- это верх удобства. И я не забываю про волшебные p и /p. Только сперва я должен объяснить заказчику, что для того, чтобы разметить текст как абзац, ему необходимо:
1. Выделить его
2. Кликом по меню выставить вокруг волшебные p
А еще мне придется объяснить, что абзац убирается путем удаления этих p вручную или при помощи пометки и еще одной волшебной кнопки -- удалить разметку.
А еще мне придется "заэкранировать" br'ы для поля page_text. Я бы экранировал и для комментариев, но объяснять все это посетителям сайта будет еще сложнее. А еще сложнее будет снова объяснить заказчику что в комментариях волшебные p ставить не нужно. Или нужно, но переводы строк будут работать не так, как в тексте, вернее они будут работать, потому что гости не смогут оставлять комментарии по такой сложной схеме, и между волшебными p вводы ставить не надо чтобы не было лишних дыр.
Да, при этом периодически у заказчика будут возникать вопросы из-за того, что съехала верстка или весь текст стал b из-за того, что где-то не был закрыт волшебный p или b из-за того, что их слишком сложно увидеть.
Насколько сложнее получить размеченный html-код и оформить его типовыми стилями?

вопросы по переезду:
1. какие могут быть проблемы с конвертацией базы? что будет с текущими страницами которые в page_text, они конвертнуться в HTML?
2. как сложно переделать плаг от седитио? Как я понял просто поменять префиксы и запустить не получиться?
3. текущие условия шаблонизатора будут работать?
4. производительность кто-нибудь тестировал на повышенных нагрузках?

1. Форумы тоже конвертируются?

2. По шаблонам поддерживаются ли в страницах, форумах и листах разные дизайны, как ранее? page.list и header.list, header.forums?

3. помню был спор, не помню чем закончился, оправдано ли разделение на модули и плагины? смотрю структура там схожа, папка, шаблоны..

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