1 (13.03.2015 23:21 отредактировано ShNURoK)

Тема: PunBB next

Здравствуйте.

Так как скрипт форума уже давно не поддерживается, а мой форум крутится на нем, то я решил переписать его.
Мной рассматривался вариант перехода на fluxbb, но они разрабатывают вторую версию на фреймворке laravel.
Этот фреймворк занимает лидирующие позиции в мире ссылка. Очень хороший выбор.

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

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

Спасибо за внимание.

Поделиться

2

Re: PunBB next

Мне интересен любой вариант развития. С любым фреймворком лучше чем без, но в тоже время любой фреймворк для задач форума в силу своей универсальности избыточен. Простое использование некоторых  компонентов в своём окружении может быть выгоднее - меньше зависимость от фреймворка, меньше накладных расходов.
Не знаком с yii, бегло посмотрел http://www.yiiframework.com/doc-2.0/gui … ecord.html и обнаружил большое сходство с eloquent orm из laravel.  В тоже время eloquent самодостаточный компонент, который можно использовать без laravel, да и весь laravel построен модульно, так же как и zf2 и symfony2 со слабыми зависимостями и с возможностью использовать любые компоненты без привязки ко всему фреймворку, указал зависимость в composer и используешь нужный компонент.  В yii этого не обнаружил, это так?

Захочешь — найдешь время, не захочешь — найдешь причину.

Поделиться

3 (15.03.2015 09:54 отредактировано ShNURoK)

Re: PunBB next

hcs, в плане модульности yii2 далеко не лучшее решение. В этом плане наверно лидирует sf2.
Я давно уже ничего не разбивал на компоненты, но когда это делал, то все сводилось к достаточно большим проблемам. А если учитывать, что для форума необходима большая часть компонентов, то это не является особой проблемой.
Разве что вопрос занимаемого места неработающим кодом.
С laravel я работал поверхностно, читал, что у него достаточно много зависимостей и если, там что-то выковыривать, наверное тоже будет много костылей.
Но в плане laravel, повторюсь, есть fluxbb и разрабатывают они его как bundle. С punbb можно уйти на fluxbb. Делать копию не вижу смысла.
sf2 я не знаю, а так конечно отличный вариант.
zf2, ну это монст, и по первой версии, с которой я работал, оставил не очень хорошее впечатление в плане багов. Он скорее на запчасти хорошо идет.

Так сложилось, что я пишу на yii2 и менять его я не буду. Что касается производительности, то он на вполне хорошем месте. Лидирует здесь phalcon.

Поделиться

4 (16.03.2015 20:48 отредактировано Otto.Zukamoto)

Re: PunBB next

лично я не вижу проблем с интеграцией Yii или какого либо другого решения с punbb.
какой смысл в переписывании готового функционала на фреймворк?
проблема с фреймворками - пока вы будете переписывать под версию N, выйдет новая.
еще будет тормозить из-за всей этой модульности и прослоек.

Добавлено спустя 3 минуты 54 секунды:

ShNURoK пишет:

Что касается производительности, то он на вполне хорошем месте. Лидирует здесь phalcon.

А вот это еще один потенциально мертвый проект. Сам php новый подтянулся уже по производительности.
Намного перспективнее сделать punbb совместимым с hhvm или альтернативными платформами - Phalanger, Quercus.

Сайт Otto.Zukamoto

Поделиться

5

Re: PunBB next

Otto.Zukamoto пишет:

лично я не вижу проблем с интеграцией Yii или какого либо другого решения с punbb.
какой смысл в переписывании готового функционала на фреймворк?
проблема с фреймворками - пока вы будете переписывать под версию N, выйдет новая.
еще будет тормозить из-за всей этой модульности и прослоек.

Скажите, как мне подружить punbb и php 5.5.x? Я серьезно, перепишите для меня регулярки.

Otto.Zukamoto пишет:
ShNURoK пишет:

Что касается производительности, то он на вполне хорошем месте. Лидирует здесь phalcon.

А вот это еще один потенциально мертвый проект. Сам php новый подтянулся уже по производительности.
Намного перспективнее сделать punbb совместимым с hhvm или альтернативными платформами - Phalanger, Quercus.

Самое неблагодарное это рассуждать о технологиях. Я про предложенные вами и не слышал даже. Дата релизов у них не особо впечатляет. Ну это первое что смотришь.
А про phalcon, даже не знаю, если вы так заявляете, значит вы компетентны в этом. Я - нет. Я указал лишь факт, что он быстрее. hhvm - это немного другое.

Поделиться

6

Re: PunBB next

Скажите, как мне подружить punbb и php 5.5.x? Я серьезно, перепишите для меня регулярки.

Помогите с ошибкой

Моя сборка FluxBB 1.5 * Parserus - BBCode parser

Поделиться

7

Re: PunBB next

Вот именно, переписывание под фреймворк ради фреймворка возможно нужно разработчикам, но это не то что нужно punbb.
Основная проблема дальнейшего развития уперлась в лапшу кода с адским смешением php и html.  Лапша - это хорошо или плохо? Например что лучше, делать запрос к бд фактически прописав его на нативном sql, снова и снова проверяя и перепроверяя передаваемые переменные, или довериться прослойке, которая сделает это за тебя и ты обойдешся 1 строкой кода, получишь требуемый объект с нужными связями и не будешь переживать, что где-то допустил брешь для инъекции? Лично у меня не подымаются руки как-то развивать код, где всё безнадежно устарело и требует существенно больших усилий. В то же время  переписать на модном фреймворке - это просто сделать модуль, бандл или еще что. Это может носить гордое имя PunBB, но это уже будет не то. Поэтому FluxBB на laravel ждет забвение и новые форки.
При компонентной архитектуре не основываясь на конкретном фреймворке мы можем и избежать недостатков связывания с фреймворком и решить проблемы препятствующие развитию. Что сейчас является одним из главных недостатков (по версии веб-мастеров)? Отсутствие полноценных шаблонов?  Какой именно шаблонизатор надо внедрить?  А может надо внедрить менеджер, который сможет работать с разными движками обеспечив свободу веб-мастеру? Эту задачу проще решить взяв  например Templating из Symfony2, чем изобретать велосипед или вступить в брак с одним из шаблонизаторов.

Захочешь — найдешь время, не захочешь — найдешь причину.

Поделиться

8

Re: PunBB next

Поэтому FluxBB на laravel ждет забвение и новые форки.

Не будет его уже smile 
https://fluxbb.org/forums/viewtopic.php?id=8282
Они объединяются с Flarum project.

Моя сборка FluxBB 1.5 * Parserus - BBCode parser

Поделиться

9 (17.03.2015 00:27 отредактировано ShNURoK)

Re: PunBB next

Visman пишет:

Скажите, как мне подружить punbb и php 5.5.x? Я серьезно, перепишите для меня регулярки.

Помогите с ошибкой

Спасибо, но если не ошибаюсь вы не исправили регулярки с list.

Добавлено спустя 8 минут 22 секунды:

hcs пишет:

Вот именно, переписывание под фреймворк ради фреймворка возможно нужно разработчикам, но это не то что нужно punbb.
Основная проблема дальнейшего развития уперлась в лапшу кода с адским смешением php и html.  Лапша - это хорошо или плохо? Например что лучше, делать запрос к бд фактически прописав его на нативном sql, снова и снова проверяя и перепроверяя передаваемые переменные, или довериться прослойке, которая сделает это за тебя и ты обойдешся 1 строкой кода, получишь требуемый объект с нужными связями и не будешь переживать, что где-то допустил брешь для инъекции? Лично у меня не подымаются руки как-то развивать код, где всё безнадежно устарело и требует существенно больших усилий. В то же время  переписать на модном фреймворке - это просто сделать модуль, бандл или еще что. Это может носить гордое имя PunBB, но это уже будет не то. Поэтому FluxBB на laravel ждет забвение и новые форки.
При компонентной архитектуре не основываясь на конкретном фреймворке мы можем и избежать недостатков связывания с фреймворком и решить проблемы препятствующие развитию. Что сейчас является одним из главных недостатков (по версии веб-мастеров)? Отсутствие полноценных шаблонов?  Какой именно шаблонизатор надо внедрить?  А может надо внедрить менеджер, который сможет работать с разными движками обеспечив свободу веб-мастеру? Эту задачу проще решить взяв  например Templating из Symfony2, чем изобретать велосипед или вступить в брак с одним из шаблонизаторов.

Дело не в компонентах, дело в том, что в самом начале надо определится, какие цели и задачи у скрипта форума. И самое сложное, потом придерживаться этого.
Я так понял вас не устраивает фреймворк из-за того, что надо потом будет постоянно поддерживать код? Или скорость?
Какой выигрыш от компонентов в данном случае? Соберете вы все, а зависимости то все равно надо будет поддерживать. И мне кажется геморроя будет побольше, чем с изменениями у фреймворка, где все документировано.

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

Добавлено спустя 13 минут 21 секунду:

П.С. Я подписан на тему, но сообщения не приходят sad

Поделиться

10

Re: PunBB next

Спасибо, но если не ошибаюсь вы не исправили регулярки с list.

Я вообще ни чего там не правил smile Там предложено решение от заграничного автора.

П.С. Я подписан на тему, но сообщения не приходят

А в спаме?

Моя сборка FluxBB 1.5 * Parserus - BBCode parser

Поделиться

11 (17.03.2015 01:17 отредактировано ShNURoK)

Re: PunBB next

Visman пишет:

Спасибо, но если не ошибаюсь вы не исправили регулярки с list.

Я вообще ни чего там не правил smile Там предложено решение от заграничного автора.

П.С. Я подписан на тему, но сообщения не приходят

А в спаме?

Понял, виноват, ошибся.
В спаме тоже нет.
Я понял в чем проблема, я ошибся с вводом почты.

Поделиться

12

Re: PunBB next

ShNURoK пишет:

Я так понял вас не устраивает фреймворк из-за того, что надо потом будет постоянно поддерживать код? Или скорость?
Какой выигрыш от компонентов в данном случае? Соберете вы все, а зависимости то все равно надо будет поддерживать. И мне кажется геморроя будет побольше, чем с изменениями у фреймворка, где все документировано.

Фреймворк накладывает свои ограничения и определяет архитектуру модуля-бандла-приложения, т.е. punbb становится частью фреймворка и подчиняется его идеологии, появляется ещё одна "свистелка-перделка" под модный фреймворк с порогом вхождения не ниже кандидата наук.  Можно было бы сказать, что это абстрактная идея не имеющая ничего общего с реальностью, но тем не менее пример fluxbb+laravel наглядно её подтверждает.
При заимствовании компонентов этого не должно произойти, т.к. мы сами определяем что включить, куда, в каком порядке. Зависимости можно зафиксировать и внепланово обновлять только критические ошибки.  Я не вижу с этим никаких проблем. Кроме того внедрение компонентов даёт шанс рефакторингу, при этом сохраняется дух проекта.
Безусловно это не касается форка, там можно делать что угодно и как угодно без ущерба.

Захочешь — найдешь время, не захочешь — найдешь причину.

Поделиться

13

Re: PunBB next

hcs, вашу идею понял. Хороший вариант, сейчас полно всяких библиотек.
У меня есть вопрос, в котором я полный ноль, скажите, как в современных скриптах (joomla, wp, ipb, etc) реализована поддержка расширений?
Лично мне не нравится как это сделано в punbb, по причине того, что поддержка становится адовой при их большом количестве. Файл, манифест, который без подсветки. Это откуда идея, из java? Насколько она оправдывает себя?

Поделиться

14 (17.03.2015 04:47 отредактировано SeVlad)

Re: PunBB next

как в современных скриптах (joomla, wp, ipb, etc) реализована поддержка расширений?

Скажу за ВП. У него есть отличный АПИ и система фильтров и экшенов.

Для пользователя движка (админа) написание плагина проще пареной репы: миниман

Поделиться

15

Re: PunBB next

Я не знаю как расширения реализованы в перечисленных продуктах, в ВП вроде какието фильтры у функций, аналог событий,  не могу утверждать.
В PunBB сделано не вполне удачно: манифест, тысячи хуков, в этом есть и плюсы и минусы. Для лапшы пойдет. Откуда идея не знаю.

Захочешь — найдешь время, не захочешь — найдешь причину.

Поделиться

16

Re: PunBB next

В IPB сделано также как в punbb, через xml. Принцип такой же, а по технической реализации не знаю.

Поделиться

17 (18.03.2015 22:36 отредактировано Otto.Zukamoto)

Re: PunBB next

ShNURoK пишет:
Otto.Zukamoto пишет:

лично я не вижу проблем с интеграцией Yii или какого либо другого решения с punbb.
какой смысл в переписывании готового функционала на фреймворк?
проблема с фреймворками - пока вы будете переписывать под версию N, выйдет новая.
еще будет тормозить из-за всей этой модульности и прослоек.

Скажите, как мне подружить punbb и php 5.5.x? Я серьезно, перепишите для меня регулярки.

Otto.Zukamoto пишет:
ShNURoK пишет:

Что касается производительности, то он на вполне хорошем месте. Лидирует здесь phalcon.

А вот это еще один потенциально мертвый проект. Сам php новый подтянулся уже по производительности.
Намного перспективнее сделать punbb совместимым с hhvm или альтернативными платформами - Phalanger, Quercus.

Самое неблагодарное это рассуждать о технологиях. Я про предложенные вами и не слышал даже. Дата релизов у них не особо впечатляет. Ну это первое что смотришь.
А про phalcon, даже не знаю, если вы так заявляете, значит вы компетентны в этом. Я - нет. Я указал лишь факт, что он быстрее. hhvm - это немного другое.

Go быстрее php - может тогда сразу переделывать форум под Go? (это сарказм если что)
и как тут переписыват форум из за того что регулярки не работают? это чтото

Добавлено спустя 9 минут 10 секунд:

hcs пишет:

Вот именно, переписывание под фреймворк ради фреймворка возможно нужно разработчикам, но это не то что нужно punbb.
Основная проблема дальнейшего развития уперлась в лапшу кода с адским смешением php и html.  Лапша - это хорошо или плохо? Например что лучше, делать запрос к бд фактически прописав его на нативном sql, снова и снова проверяя и перепроверяя передаваемые переменные, или довериться прослойке, которая сделает это за тебя и ты обойдешся 1 строкой кода, получишь требуемый объект с нужными связями и не будешь переживать, что где-то допустил брешь для инъекции? Лично у меня не подымаются руки как-то развивать код, где всё безнадежно устарело и требует существенно больших усилий. В то же время  переписать на модном фреймворке - это просто сделать модуль, бандл или еще что. Это может носить гордое имя PunBB, но это уже будет не то. Поэтому FluxBB на laravel ждет забвение и новые форки.
При компонентной архитектуре не основываясь на конкретном фреймворке мы можем и избежать недостатков связывания с фреймворком и решить проблемы препятствующие развитию. Что сейчас является одним из главных недостатков (по версии веб-мастеров)? Отсутствие полноценных шаблонов?  Какой именно шаблонизатор надо внедрить?  А может надо внедрить менеджер, который сможет работать с разными движками обеспечив свободу веб-мастеру? Эту задачу проще решить взяв  например Templating из Symfony2, чем изобретать велосипед или вступить в брак с одним из шаблонизаторов.

зачем прослойки:
- для работы с БД есть PDO с prepared statement, да можно какие то модели сделать users post category - но опять же нафиг компоненты. обычные классы с инъекцией PDO

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

- расширения - самое сложное для доработки - тут надо нормальную систему хуков чтобы как то переменные передавать и использовать обычные функции с префиксом например.
сейчас они работают через eval это не ок, и код задается через xml и хранится в БД насколько я знаю.
лучше бы просто файл php c функциями префиксами
к примеру do_hook('hookname')
вызывает все функции начинающиеся на hookname_
поменять код функции и не надо ниче переустанавливать, обновлять кеш кода

+ опционально можно было бы сделать добавление удаление обработчиков - но это фишка не думаю что насколько востребована.

подумываю чтото пилить - но все лень. покачто устраивает готовый форум

Добавлено спустя 25 минут 58 секунд:

ShNURoK пишет:

hcs, вашу идею понял. Хороший вариант, сейчас полно всяких библиотек.
У меня есть вопрос, в котором я полный ноль, скажите, как в современных скриптах (joomla, wp, ipb, etc) реализована поддержка расширений?
Лично мне не нравится как это сделано в punbb, по причине того, что поддержка становится адовой при их большом количестве. Файл, манифест, который без подсветки. Это откуда идея, из java? Насколько она оправдывает себя?

да реализация расширений неудачна.

в joomla используются компоненты - имеющие свои точки входа в приложение и плагины на основе событий (которые каким либо образом меняют передаваемые значения или состояние приложения)

в worpdress - сделано на основе добавления удаления обработчиков весь список таких обработчиков вызывается как do_action

имхо для конечного приложения типа форума было бы проще завязать обработчики на префиксах функций
приэтом нет необходимости в динамическом добавлении функции в список обработчков.
просто называем функцию eventname1_bla_bla(....)
и она сама вызовется при вызове event_trigger('eventname1', ...)

но проблема при таком способе передача контекста.
в punbb переменные нет необходимости передавать тк. используется eval

Сайт Otto.Zukamoto

Поделиться

18

Re: PunBB next

Otto.Zukamoto пишет:

зачем прослойки:
- для работы с БД есть PDO с prepared statement, да можно какие то модели сделать users post category - но опять же нафиг компоненты. обычные классы с инъекцией PDO

Убрать существующие class DBLayer под разные БД и вместо него использовать прослойку PDO? Это наверное шутка. Зачем тогда вообще что-то переделывать? У нас же нативненько сейчас всё, без "идиотских" прослоек, которые видимо придумывают какие-то идиоты от безделья.

Otto.Zukamoto пишет:

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

Нативный php для веб-мастера работающего с твиг-смарти-ещёкакаяневедомаяфигня является поводом искать другой движок. Я согласен с этой идеей только как с промежуточным этапом рефакторинга.

Otto.Zukamoto пишет:

- расширения - самое сложное для доработки - тут надо нормальную систему хуков чтобы как то переменные передавать и использовать обычные функции с префиксом например.
сейчас они работают через eval это не ок, и код задается через xml и хранится в БД насколько я знаю.

Написав не один десяток расширений я точно знаю, что одна из самых неприятных задач - работа с бд. Если  модифицировать запрос, подменив какойто элемент массива query, ещё туда-сюда, способ несложный для кул-хацкеров и перекрывающий половину его потребностей, то например сджойнить что-то, не продублировав чужой джойн или  непреднамеренно не изменив и ничего не поломав, заранее не зная кто там следующий будет что-то джойнить - это задача гораздо сложнее. Может она вызывает творческий  оргазм у прошареных разработчиков, но лично мне хочется продуктивно работать, а не тратить время на мазохизм и изобретение велосипедов. Поэтому здесь на ум приходят прослойки ОРМ, в число которых чистый PDO не входит. А передача параметров, так это не проблема, если уж на то пошло, в рамках нынешней лапшы сгодится суперглобальный массив. Кому надо сам найдет себе в нем нужные данные, а в функциях передавать хуку внутренние переменные через аргументы.

Таким образом, уважаемый коллега, вы недооцениваете проблему работы с БД, в том числе с учетом её активного использования расширениями.

Захочешь — найдешь время, не захочешь — найдешь причину.

Поделиться

19

Re: PunBB next

Otto.Zukamoto пишет:

имхо для конечного приложения типа форума было бы проще завязать обработчики на префиксах функций
приэтом нет необходимости в динамическом добавлении функции в список обработчков.
просто называем функцию eventname1_bla_bla(....)
и она сама вызовется при вызове event_trigger('eventname1', ...)

но проблема при таком способе передача контекста.
в punbb переменные нет необходимости передавать тк. используется eval

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

Захочешь — найдешь время, не захочешь — найдешь причину.

Поделиться

20

Re: PunBB next

Я не буду влезать в споры. Скажу, что запустил переписанный вариант у себя на сайте. Пока функционал близок к нулю. Это регистрация, вход, добавление темы и сообщения, перевод сообщений на markdown. Сделано, чтобы на ходу обдумать нужность тех или иных функций и несколько ускорить процесс.

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

Исходники открыты, кому интересно пишите.
Поддержу новой установки можно сделать, можно сделать конвектор с punbb, но вот сохранение идеологи punbb не обещаю.

Поделиться

21

Re: PunBB next

just yet another forum

Захочешь — найдешь время, не захочешь — найдешь причину.

Поделиться

22

Re: PunBB next

hcs, согласен, но оставаться на punbb тоже не выход.

Поделиться

23 (25.03.2015 21:40 отредактировано Otto.Zukamoto)

Re: PunBB next

1) шаблоны - незнаю насколько сложно вычленить данные, а если выводить json вместо html, и добавить обработчик контента - который будет этот json превращать в шаблон?
если не сложно то может  все собирать и передавать в обработчик для рендера при этом может быть любым и изменяемым, чтобы был выбор дали данные - а что с ними делать уже решает каждый сам. ктото твиг юзает ктото php
+ но с json легче будет реализовать встраиваемость в любой сторонний сайт на уровне http.

2) расширения
>Придется вести реестр функций и файлов для прямого вызова, иначе нужно проходить весь каталог с расширениями и >проверять наличие функции во избежание краха.
файл /extension/init.php

с функциями типа

function event1_hook1($vars) {
extract($GLOBALS, EXTR_SKIP | EXTR_REFS);
...а тут код который был раньше в xml файле
}

пока можно добавить фиксы в get_hook(
чтобы было совместимо со старыми расширениями

function get_hook(...) {
  $handlers = тут берем из списка или кеша
  $prefix = $name . '_';
или же формируем
    foreach (get_defined_functions as $f) {

       if (substr($f, 0, strlen($prefix)) == $prefix) {         
         добавим обработчик в кеш

         или выполним $f(...); // если перебор по массиву функций каждый раз не критичен
         
       }
    }

    тут старый код
  }
}

3) ок. я сильно в код с БД не лазил.
БД может тогда использовать medoo.in ?
я бы просто выделил типовые части в запросе как ACL и тп. в функции как то.
чтобы не копипстить саму строку запроса


куда слать пул реквесты (там вижу несколько веток) и есть ли смысл?

Сайт Otto.Zukamoto

Поделиться

24

Re: PunBB next

1) Вычленить сложно, много переделывать - как говорится проще написать заново - но даже если не писать заново, то не понятно как быть с частью хуков в вёрстке. Если их не сохранить, то идея совместимости со старыми расширениями утрачивает смысл.
2) Вынос расширений из манифестов очевидно не нанесет ущерба совместимости.
3) Любая смена прослойки бд ломает совместимость и забота о ней снова теряет смысл.
Реализация только п2 это окончательный тупик развития - дальше двигаться просто некуда.
Поэтому я считаю, что забота о совместимости должна быть брошена в жертву развитию.
medoo.in посмотрел. Это лучше чистого PDO, но это не то.
Для примера  Ardent, добавляем к модели юзера репутацию:

// В расширении
User::relationsData['reputation] = [self::HAS_MANY, 'Reputation'];
// В ядре
$User = User::find($user_id);

Это же круто.

Захочешь — найдешь время, не захочешь — найдешь причину.

Поделиться

25

Re: PunBB next

буду тогда потихоньку пилить под старую ветку.
надеюсь что текущая ветка не будет сильно менятся и будет ли вообще менятся чтото?

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

вот рабочая реализация
https://github.com/punbb/punbb/pull/113

опробовано на расширении для врапера форума
https://github.com/rivetweb/punbb-exten … um_wrapper

еще
запилил конвертер для manifest.xml в init.php

https://github.com/rivetweb/punbb-exten … nifest2php

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

Сайт Otto.Zukamoto

Поделиться