Пофлудим о выходе phpBB 3.1.x/Ascraeus

[rxu]

Скачать текущий снэпшот версии 3.1 можно по ссылкам:
https://github.com/phpbb/phpbb3/tarball/develop (tar.gz)
https://github.com/phpbb/phpbb3/zipball/develop (zip)

Процедура установки аналогична установке phpBB 3.0. Системные требования: PHP 5.3.3 и выше.

Категорически не использовать на рабочих форумах. Данные снэпшоты предназначены только для ознакомления и тестирования!

На текущий момент в 3.1 наличествуют следующие новшества:

• Ability to delete auto login keys RFC Ticket
• Plural Forms RFC Ticket
• Copy post text in report when reporting posts RFC Ticket
• Enhanced Team Page RFC Ticket
• Attachments Management RFC Ticket
• Resume support for attachments / HTTP range support RFC Ticket
• Link global announcements to forums RFC Ticket
• AJAX RFC
• Extensions RFC Ticket
• Improved Page Titles RFC Ticket
• Switch to PHP timezone handling RFC Ticket
• Rename MSNM to WLM RFC Ticket
• STARTTLS for emails Ticket
• Delete "Confirm e-mail address" from registration form RFC Ticket
• Preview from QR RFC Ticket
• Extensions Front Pages RFC
• Modular Cron RFC Ticket
• HTML5 Doctype RFC Ticket
• Normalise internet protocol version 6 addresses RFC Ticket
• No db storage of themes and stylesheets RFC Ticket
• Inclusion of jQuery RFC Ticket
• Optionally use jQuery from Google RFC Ticket
• Template tag to include JS files RFC
• Require PHP 5.3 RFC
• Enable template inheritance by default (also will appear in 3.0.11) RFC Ticket
• Unlimited styles tree (template inheritance) RFC
• Merge style components RFC
• Removal of imagesets RFC
• Support for X-Accel-Redirect and X-Sendfile headers for attachment downloads Ticket
• Dependency Injection Container RFC Ticket
• Coding Guideline Modifications RFC Ticket
• Autoloading & Class Naming Convention RFC Ticket
• Request Class RFC Ticket
• Improved template engine RFC Ticket
• Template locator and path finder RFC
• Resource locator RFC
• Javascript Coding Style RFC Ticket
• Get rid of eval in Javascript RFC Ticket
• General Hook Architecture RFC Ticket
• Extensions Admin RFC
• Change maximum subject length RFC
• Improve User Pruning feature RFC Ticket
• Last topic title on forum list RFC

В разработке:

1. Avatar improvements, Gravatar RFC Ticket
   Статус: v1 не принята - ожидается v2 с улучшенной реализацией
2. SQLite 3.0+ Support RFC Ticket
   Статус: требуются дополнительные доработки
3. Updated BBcode engine RFC Ticket
   Статус: реализовано частично - требуется завершение
4. Cleaning up the ACP UI RFC Ticket
   Статус: ожидает проверки
5. HipHop for PHP compatibility RFC Ticket
   Статус: патч ожидает проверки
6. Soft Delete RFC Ticket
   Статус: патч требует устранения конфликтов кода и проверки
7. Migrations (UMIL) RFC Ticket Data Providers RFC
   Статус: реализовано частично, в работе
8. WYSIWYG Editor/Rich Text Editor RFC
   Статус: 2 частично готовых варианта реализации. 1 требует добавления поддержки смайлов и пользовательских BBcode. 2 заморожен.
9. Log Class RFC
   Статус: в процессе доработки
10. Extension Meta-data file RFC
    Статус: не готов
11. Remove un-necessary permissions RFC
    Статус: работа над списком ненужных прав
12. Style Specific Language Variables RFC
    Статус: ожидает проверки
13. Contact Form RFC
    Статус: в работе
14. Reply to PMs Permission RFC
    Статус: ожидает проверки

Только запросы:

• Changing IP banning to use "longest prefix matching" RFC Ticket
• Session Backend Abstraction (memcache support) RFC Ticket
• Pre-Compile Template Includes RFC
• Overridable imageset and theme paths for CDNs RFC
• Simple message API RFC Ticket
• Use composer.json for styles and track phpBB version RFC Ticket

[Mr. Anderson]

Альтаир Бергадлер
да хоть 3.0.99 - это разные ветки.

[Альтаир Бергадлер]

Пардон, я вас не совсем понимаю. Зачем параллельно с основным обновлением делать еще одно?
*я совсем не понимаю, так что если не лень по клавиатуре постучать...*

[Mr. Anderson]

Альтаир Бергадлер
Я же написал - это разные ветки. 3.0.х - одна, 3.1.х - другая.
Как 2.0.х и 3.0.х были в свое время (правда разница функционально и архитектурно не настолько велика).

[Альтаир Бергадлер]

ааа...допер, и все таки насколько рационально разбрасывать сила на разные ветки? Или развитием занимаются разные команды?

[Mr. Anderson]

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

[Альтаир Бергадлер]

аааа, т.е. с двойкой была история дебаггирования, так?

[Mr. Anderson]

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

Разве это плохо?

[Альтаир Бергадлер]

Ну а что вам мешает посмотреть чейнджлог?

при живом-то админе?

Разве это плохо?

я имел ввиду, что вместо развития линейки, закрывались дыры.
Ну в общем мне понятно теперь. Спасибо.

[Mr. Anderson]

я имел ввиду, что вместо развития линейки, закрывались дыры.

Развитие было в ветке 2.2, она же (после пересмотра фич-листа) - 3.0
А на счет закрывания дыр: я даже боюсь представить что бы было с phpBB, если бы дыры не патчились или патчились, но не так оперативно. Есть мысль, что трешки, скорее всего бы не было, ибо (во-первых) от беспросветно дырявого форума отвернулись бы все, а кроме того (во-вторых) 2.2 - это все-таки не совсем 3.0, да и многие архитектурные изменения были "ответом" на найденные дыры.
Впрочем, 1.0.х в этом смысле была вообще решетом, именно поэтому в 2.0.х появились стандарты кодирования, первые намеки на архитектурные базисы и разделение уровней обработки (код и шаблоны). Трешка просто продолжила данный процесс...

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

PS:
Некоторые, кстати, считают, что в тройке нет ничего такого, что нельзя было бы сделать с двойкой с помощью модов... Чтож - про 3.1 (в сравнении с 3.0), теоретически, можно сказать это же (и быть даже более правым). Остается только один вопрос - "Зачем?" (с) ОЧГМ. Про двойку не говорим - архитектурно и морально она устарела, да и не поддерживается. Но с 3.1... Век 3.0 рано или поздно закончится, а любые даже самые эксклюзивные самописные моды можно будет без труда портировать - архитектурно это та же тройка. Так что не вижу причин не использовать "новейший" движок, который мало того, что функционально "интереснее" (хуки - вообще супер-вкусно для разработчиков), но и, очевидно, приоритет в дебаге будет иметь наивысший.

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

[Альтаир Бергадлер]

Т.е. гипотетически проблем с переходом с 3,0 на 3,1 не возникнет? Архитектура ведь одна и та же.
Если уже заговорили о переходе, то насколько опасен будет переход на 4?

[Mr. Anderson]

гипотетически

Не гипотетически, а не возникнет. Даже с двойкой особых проблем не припомню - все решаемо, не смотря на переход к utf.

насколько опасен будет переход на 4

Опасен? Хыхыхы Ну уж точно не опаснее прочих, типа того же 2.0 -> 3.0
Только вот загвоздка - про 4.0 пока вообще ничего не известно кроме кодового имени релиза и используемого фреймворка. Даже кода ни строчки не написано.

[MenX]

Предлагаю сделать в версии 3.1 еще более запутанную систему прав пользователей и при том дублировать один и тот же функционал прав доступа везде где только возможно! А то знаете ли, текущая система управления правами как-то слишком уж упрощена до невозможности!
Можно например добавить возможность разрешать/запрещать группам пользователей пить кофе при посещении форума, ну или ограничить количество кликов по заголовкам форумов.
Права необходимо расширить до:
Глобальных, Локальных, Реальных, Виртуальных, Галактических, Межзвёздно-галактических, Вселенско-паралельных

Кроме масок доступа, необходимо добавить:
Каски доступа, краски доступа, салазки доступа, и обязательно смазки доступа (может хоть со смазками легче будет въехать в эту систему)

P.S. 3 года работаю с phpbb3 и до сих пор плаваю в системе прав доступа. UNIX отдыхает просто!

Лучше бы юзабильность форума повышали, а не этот идиотизм на грани кретинизма!

[владимир1983]

3 года работаю с phpbb3

Очень сочувствую вам.
За столько продолжительное время не разобраться со всеми возможностями прав доступа, не понять мощность этой системы, прискорбно...

Добавлено спустя 5 минут 44 секунды:
MenX, можно вас попросить сделать примерный набросок системы прав доступа которая на ваш взгляд была бы проста и понятна, можете обрисовать в общем как вы видите это?

[Alek$]

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

[MenX]

Подведу итог: я хочу видеть в phpBB 3.1 функцию генерации графического (схематического) отображения всех параметров прав доступа в виде карты. Чтоб видеть всю картину прав как одну сводную схему.

Ну конечно кроме индивидуально назначенных прав.