Вы что-то путаете. Причем тут еще гипервизор Xen и продукты на нем построенные? Мой топик о форумном движке, а не о гипервизоре. Внимательно посмотрите на заголовок поста, пожалуйста.
А приставка xen обозначает «странный, чужой, другой». Не нужно думать, что гипервизор Xen монополизировал ее использование.
Бесплатных форумов, может, и до дури, но XenForo платный, а по возможностям превосходит многие платные и бесплатные.
Я думаю, вам лучше пощупать движок самому. Конечно, скажем, альбомов там пока еще нет. Зато есть удобный и интуитивно понятный Ajax интерфейс. Полный SEO из коробки. Крайне удобные инструменты модерирования. Четкий и красивый API для модулей расширения. До недавнего времени я считал, что VBulletin имеет довольно мощную систему расширения, но, похоже, до XenForo в этом смысле ему далеко.
2) Настройки темы — интересно сделано, но усложнит создание собственных стилей; с другой стороны — в некоторых случаях позволит обойтись стандартной темой…
3) Те куски кода которые можно заметить — радуют.
4) добрался до плагинов, не понравилось:
* Все через админку[1]
* build id вручную… зачем?! неужели так сложно автоматизировать это?[1]
* Длинные_Названия_Классов — почему не использовать пространства имен? (код устарел до релиза)
* У event-ов похоже нет интерфейсов — придется постоянно лазить в админку чтобы посмотреть что он принимает.
[1] — По опыту работы с IPB — очень надоедает постоянно переключаться между редактором и браузером и искать на нужных страницах нужные кнопки (это отнимает время и отвлекает внимание). Очень надеюсь что со временем это будет автоматизировано.
1. да, пока только MySQL. Не исключено добавление поддержки других БД, но это будет нескоро
2. Согласен.
4. Не обязательно через админку. Можно сделать XML по шаблону и автоматом его залить так, как сделано в VBulletin. Т.е. установка плагина = загрузка его файлов на FTP + импорт XML из админки. Разработчик же может и сам XML написать при наличии опыта.
XenForo требует PHP 5.2.4. В нем еще нет поддержки пространства имен. Не думаю, что на этом основании можно считать код устаревшим. Друпал 7, WordPress и многие другие серьезные проекты в своих будущих версиях тоже требуют 5.2 и при написании кода разработчики будут ориентироваться на возможности этого релиза PHP. Согласен, без пространств имен все несколько неудобно, но… думаю, это оправдано с точки зрения конечных пользователей.
Что касается модификаций, то система похожа на IPB 3.x. А это значит геморрой для разработчиков, которые хотят встроить что-то, о чём не догадался разработчик движка. И начнётся как обычно «не хочу я в это место хук добавляться».
Что касается настройки стилей, то не стоит забывать, что это сделано для стандартных стилей. Если в вашем стиле будут другие размеры изменяться, не факт что это будет работать. Эта проблема есть и в IPB, и в Друпале.
Разве можно предложить что-то принципиально более гибкое, чем система хуков, как в Друпале, VB, IPB и так далее? Конечно, все зависит от авторов движка, насколько много хуков они туда напихали, но в VB3 у меня редко возникали ситуации, где нужен был отсутствующий хук. Да, конечно, визуальный редактор у них почти не расширялся ни хуками, ни без них, никак. Но я нашел довольно гибкое решение.
Настройки стилей, я так понял, на предложенных демках — это фактически визуальное редактирование CSS файла стиля. Думаю, это будет работать на всех стилях, созданных вменяемыми авторами.
Всё зависит от авторов движка, и они нас пока не радуют. Я немного скептик, так что не думаю что автор этого будет на каждую просьбу разработчиков отвечать положительно.
Это создаст ненужные рамки для разработчиков сильно кастомных стилей. Либо для них придётся писать свой интерфейс редактирования/парсинга и включать в поставку, как это можно сделать в Друпале. Не думаю, что многие верстальщики будут это делать.
Наверное, вы правы. Будь я автором движка, я бы явно не отвечал на каждую просьбу положительно :) Это только приведет к добавлению в движок кучи возможностей, которые нужны 1-5% пользователей.
Чтобы конкурировать им придется увеличить скорость разработки, а это приведет к ухудшению кода и появлению ошибок, что еще больше снизит скорость… Более того, из-за малого количества разработчиков (всего двое?) начало реализации любого доп компонента полностью оставит развитие самого ядра/форума (нечто подобное сейчас происходит с IPB и IP.Nexus)
Не думаю, что это так. Посмотрите, что Кир с Майком вдвоем сделали за год и что целая команда VB сделала за два с четверкой. Скорость разработки, если и зависит от количества разработчиков, то не напрямую. Уровень подготовки девелоперов имеет большое значение. Кроме того, Кир говорил, что все будет зависеть от уровня продаж. Если все пойдет хорошо (а я уверен, что так и будет), они будут нанимать еще людей.
С нуля всегда проще начать, чем исправлять существующее… но вообще я буду очень рад если XenForo:
* или позволит отказаться от IPB;
* или заставит IPB улучшить качество собственного кода и более серьезно относится к тестированию.
Наверное, сразу вряд ли на XenForo удасться перепрыгнуть, если форум большой. Функционал пока не полностью эквивалентен. У меня есть пара маленьких форумов. Попробую их первых перевести и послушать комментарии пользователей.
Не могут, но в одном из обзоров я его видел (там, где Кир показывал, как аддоны писать). Архитектура — MVC. Код практически полностью объектно-ориентирован (мне так показалось, подробнее смогу сказать после релиза).
XenForo: назначена дата релиза публичной беты и объявлены цены