1.1.x Беспокойство от изменений движка и несовместимости старых плагинов

Что-то меня все больше беспокоит изменения движка, когда "мосты ссожены", а его разработчики в принципе не напрягаются с совместимостью плагинов. Как-то боязно делать плагины, которые в любой момент времени могут накрыться. Тогда нафига, спрашивается, было побуждать разработчиков плагинов к использованию расширений классов и т.д., когда родительский класс запросто может измениться, а в итоге все логика плагина может полететь к чертям.

Ситуация с теми же смайлами достала всех. Неужели было трудно оставить обратную совместимость?

Также я не удивлюсь, если появятся функции блогов, альбомов, букмарков или еще чего-то. Но при этом разработчики даже не посмотрят на существующие плагины, реализующие эти вещи. Я практически даже уверен в том, что они и пальцем не пошевелят, чтобы совместить новый функционал ядра (встроенных функций) и существующих плагинов, включая и общение с разработчиками плагинов. А ведь дофига интересных плагинов и решений.
Извините, вырвалось, но снисходительное отношение разработчиков движка к разработчикам из коммьюнити, несколько напрягает.

 

Тоже прошу прощения за оффтоп: давайте в отдельной теме подумаем, как мы можем подстегнуть их? (эти сообщения можно в неё). Меня беспокоит необходимость после обновления часами копаться в коде, восстанавливая работоспособность плагинов, хотя не так уж много дополнений. Запросто могу промахнуться, да и не всё работает в обновлённой версии. Кроме того, боюсь, что удобный и безглючный редактора можно ещё полгода или год ожидать. Что за жизнь... Я понимаю, что мы помогаем отлаживать продукт, так хоть не заставляли бы ждать подолгу, пока исправят. Даже не говорят, когда исправят. Сотрудников, что ли не хватает? Так много народу заплатили за движок, наверно, деньги есть.

 

Есть целая кагорта форумов, где спрайты только мешать будут. Например, не редкость, когда форум "девчачий", а там анимированные смайлы просто как данность. Т.е. спрайты нафиг не нужны. Зато граблей с ними, как все увидели, хоть отбавляй.
Будет достаточно интересно наблюдать, когда разработчики приделают букмарки, например. Думаю, что не нужно загадывать, сколько появится жалоб на то, как теперь перенести уже существующие букмарки.
То же самое - блоки, альбомы, группы (если таковые появятся).
Пример несколько наплевательского отношения - до сих пор отсутствие конвертора с 4-й булки в официальной поставке. А ведь кому, как не им, было бы легко и просто его сделать. Посмотри, сколько времени заняло перетягивание, например, пользовательских полей. Я особо не слежу за ним, потому что аж страшно становится, когда я, наконец, буду готов переносить свой форум с булки. Сильно надеюсь, что все же к тому времени уже более-менее отлаженный конвертор будет.
Идем дальше. Разработчики абсолютно не заморачивались со строгим контролем идентификаторов встроенных шаблонов, фраз, прав и т.д. А ведь нет никакой гарантии, что какой-нибудь разработчик плагина не использует идентификатор, который в будущем разработчики захотят сами использовать. И лови потом глюки.
Отсутствие внятной документации API - тоже минус. Но хотя бы он не большой, так как код открытый и из него можно собрать свою документацию. Естественно, примеров почти нет. Все приходится выковыривать из-под дебаггера, простого пролистывания кучи кусков кода, методом "научного тыка" и т.д. А ведь не всегда все работают в IDE, которая и автокомплит и подсказки по параметрам выдает (к слову, далеко не всегда). А полное отсутствие документации к шаблонам?
Покопавшись уже достаточно в движке, я прихожу к выводу, что он достаточно монументален. Т.е. написан грамотно и добротно. Есть некоторые места, где слишком жестко что-то прописывается, а потому плохо наследуется, но таковых мало. Таким образом, можно сказать, что движок хорошо поддерживает расширение.
А вот с шаблонами, например, засада. Могли бы уже сделать какое-нибудь средство для разработчиков плагинов и шаблонов, которое бы упростило поиск нужного шаблона, а также переменных. Да, найти можно, но иногда на это тратится достаточно много времени. Т.е. некоторые моменты не очевидны. У меня все чешутся руки написать что-то подобное, но жаль, нет времени. В идеале хотелось бы иметь полную структуру загрузки контроллеров, шаблонов и хуков. Причем с выводом всех переменных. Чтобы не через дебаггер искать что-то, а сформировать страницу и изучить уже ее. Я не верстальщик, поэтому мне не всегда очевидно, что и откуда берется. Возможно, верстальщиков это не напрягает.

Я не брюзжю, если что. Это просто мысли вслух В целом мне ксен очень нравится.

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

 

Ром, извини, но мне тоже трудно с этим согласиться. Начну, пожалуй с того, что есть некоторые принципы поддержки совместимости кода, о которых ZendFramework Community во всю кричит на своих обсуждениях. Крайне неправильно, когда изменения версий "ломают" код независимых разработчиков. Кроме того, если рассматривать конкретно этот случай, то он немного поверг меня в депрессию. Думаю, кодеры меня тут поймут. Так вот, посмотрите, что именно изменилось и почему "поломался" чат.


Было:

PHP:

    $output = array();
    foreach ($smilies AS $smilie)
    {
        $output[reset($smilie['smilieText'])] = array($smilie['title'], $smilie['image_url']);
    }
 
    return $output;

Стало:

PHP:

    $output = array();
    foreach ($smilies AS $smilie)
    {
        $smilieData = (empty($smilie['sprite_params']) ? $smilie['image_url'] : $smilie['smilie_id']);
 
        $output[reset($smilie['smilieText'])] = array($smilie['title'], $smilieData);
    }
 
    return $output;

Как видно из нового кода, результат вывода второго аргумента массива может быть как numeric, так и string, в зависимости от условия, которое вообще толком не описано. Я понимаю, что иногда приходится делать функции, которые могут возвращать ответы разного типа данных. Но если ответ типа boolean|any еще как-то более менее приемлем(хотя тоже не особо валиден), то ответ типа integer|string - это вообще тихий ужас. Думаю, этот вопрос можно было бы легко решить, использовав те же Magic Quotes или что-то подобное. Почему разработчики сделали именно так - остается загадкой.

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

Ну и последнее. Мне кажется, что наличие большого количества рабочих дополнений для движка форума - это очень важно. Потому, любой разработчик должен бы с этим считаться. Если у владельцев форума, при обновлении до новой версии начнет вылетать половина дополнений(в частности, писанных под заказ за деньги), то это большой славы разработчикам не принесет. Вплоть до того, что люди начнут искать более стабильный продукт.

 

Но как бы то ни было, таким параметром как стабильность наиболее сильно обладают мёртвые проекты. К примеру, можно сказать, третья линейка воблы стабильна, потому что больше не будет обновляться. XenForo проект живой и со временем он будет меняться, порой больно бья по форумам с хаками, тормозя, а порой и останавливая, их обновление.

 

Стабильность продукта и его развитие не очень связаны друг с другом. Тут ведь речь идет о стабильности базовых функций, которые используются плагинами. Если постоянно менять что-то в движке таким образом, что это будет приводить к потери работоспособности плагинов, то это быстро приведет к отказу разработчиков писать что-то с использованием движка. Или будут писать сторонние расширения, которые будут тупо сами делать запросы к БД, а вывод осуществлять чисто через хуки. Получим по факту достаточно тяжелые расширения, но зато мало зависимые от MVC ксена. Но это - тупик.
Взять тот же Linux. Новые версии ядра выходят с завидной регулярностью. Но при этом не нужно переписывать кучу софта, чтобы он работал на новом ядре. Да, бывают иногда проблемы, но при общем объеме софта, который использует Linux, это даже не сотые доли процента, а чуть ли не единичные продукты. Обычно в промежуточных версиях указывают специальные комментарии, что какие-то функции в следующих версиях работать не будут, либо будут работать иначе. Это дает возможность разработчикам заранее переписать код, который использует эти функции таким образом, чтобы в дальнейшем при обновлении не получить поломанный продукт. Вот это правильный подход.
Дальше. Допустим, в MySQL решили добавить какую-то новую инструкцию, которая есть в других конкурирующих продуктах. Разработчики стараются по максимуму сохранить ее синтаксис, чтобы обеспечить совместимость и переносимость. Если по каким-то причинам не получается обеспечить полную совместимость, то пишут how to. Потому что беспокоятся о том, что разработчики могут при большом количестве трудностей просто перестанут использовать их продукт.
Также и с ксеном. Сам по себе движок форума без "обвесов" мало, для чего пригодится. Ну разве только для поиграться в форум на локалке. Т.е. он является только основой, но вот в дальнейшем каждый админ "обвешивает" его уже по своему вкусу и потребности. Получается, что популярность ксена прямо зависит от коммьюнити разработчиков расширений. Разработчики расширений и без ксена проживут. А вот сам ксен без расширений быстро загнется.
Кстати, наличие и определенная совокупность расширений обычно и дает некоторую индивидуальность популярным форумам. Поэтому популярные форумы не скупятся на оплату разработки уникальных расширений, либо имеют собственных программистов. То же самое со стилями. Я плохо знаю эту область, но предположу, что и со стилями не редко возникают проблемы при обновлениях, что в общем также не может радовать.