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

Тема: PunBB next

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

Так как скрипт форума уже давно не поддерживается, а мой форум крутится на нем, то я решил переписать его.
Мной рассматривался вариант перехода на fluxbb, но они разрабатывают вторую версию на фреймворке laravel.
Этот фреймворк занимает лидирующие позиции в мире (Please log in or register to see this URL). Очень хороший выбор.

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

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

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

(Please log in or register to see this URL)

Поделиться

2

Re: PunBB next

Мне интересен любой вариант развития. С любым фреймворком лучше чем без, но в тоже время любой фреймворк для задач форума в силу своей универсальности избыточен. Простое использование некоторых  компонентов в своём окружении может быть выгоднее - меньше зависимость от фреймворка, меньше накладных расходов.
Не знаком с yii, бегло посмотрел (Please log in or register to see this URL) и обнаружил большое сходство с 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.

(Please log in or register to see this URL)

Поделиться

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 - это немного другое.

(Please log in or register to see this URL)

Поделиться

6

Re: PunBB next

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

(Please log in or register to see this URL)

Моя (Please log in or register to see this URL) FluxBB 1.5, (Please log in or register to see this URL), (Please log in or register to see this URL).

Поделиться

7

Re: PunBB next

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

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

Поделиться

8

Re: PunBB next

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

Не будет его уже smile 
(Please log in or register to see this URL)
Они объединяются с Flarum project.

Моя (Please log in or register to see this URL) FluxBB 1.5, (Please log in or register to see this URL), (Please log in or register to see this URL).

Поделиться

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

Re: PunBB next

Visman пишет:

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

(Please log in or register to see this URL)

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

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

hcs пишет:

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

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

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

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

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

(Please log in or register to see this URL)

Поделиться

10

Re: PunBB next

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

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

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

А в спаме?

Моя (Please log in or register to see this URL) FluxBB 1.5, (Please log in or register to see this URL), (Please log in or register to see this URL).

Поделиться

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

Re: PunBB next

Visman пишет:

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

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

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

А в спаме?

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

(Please log in or register to see this URL)

Поделиться

12

Re: PunBB next

ShNURoK пишет:

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

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

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

Поделиться

13

Re: PunBB next

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

(Please log in or register to see this URL)

Поделиться

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

Re: PunBB next

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

Скажу за ВП. У него есть отличный (Please log in or register to see this URL) и система (Please log in or register to see this URL) и (Please log in or register to see this URL).

Для пользователя движка (админа) написание плагина проще пареной репы: (Please log in or register to see this URL)

Поделиться

15

Re: PunBB next

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

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

Поделиться

16

Re: PunBB next

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

(Please log in or register to see this URL)

Поделиться

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. Сделано, чтобы на ходу обдумать нужность тех или иных функций и несколько ускорить процесс.

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

(Please log in or register to see this URL) открыты, кому интересно пишите.
Поддержу новой установки можно сделать, можно сделать конвектор с punbb, но вот сохранение идеологи punbb не обещаю.

(Please log in or register to see this URL)

Поделиться

21

Re: PunBB next

just yet another forum

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

Поделиться

22

Re: PunBB next

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

(Please log in or register to see this URL)

Поделиться

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, но это не то.
Для примера  (Please log in or register to see this URL), добавляем к модели юзера репутацию:

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

Это же круто.

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

Поделиться

25

Re: PunBB next

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

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

вот рабочая реализация
(Please log in or register to see this URL)

опробовано на расширении для врапера форума
(Please log in or register to see this URL)

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

(Please log in or register to see this URL)

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

Сайт Otto.Zukamoto

Поделиться