Расширения - это просто!

[LBeaver]

Нужно в файл message_parser к стандартным проверкам содержимого текста добавить ещё одну, свою.
Как я понимаю, нужных событий нету?

https://github.com/phpbb/phpbb/pull/3114
Ждем-с.

Для 3.0 я делал мод, который брал url из bb-кода img, кэшировал изображение на хостинге форума и заменял ссылку в img на локальную. Решалась эта задача добавлением нескольких строк в функцию bbcode_img в message_parser. Я правильно понимаю, что на данный момент в 3.1 нет подходящих событий для этого?

[HAMMER663]

Да. Пока нету

[Shredder]

Вот это будет основная жопа с модификациями для 3.1+. Захочешь добавить что-нибудь, а тут хлоп, и "нету". И не факт, что появится, в отличие от обсуждаемого выше.

[HAMMER663]

ПР уже есть. Предположительно в 3.2 будет включено. Еще имеет смысл посмотреть на события в файле posting.php. Возможно там уже что-то есть

[Татьяна5]

а тут хлоп, и "нету"

Создавать PR, и как только его одобрят - можно добавлять вручную в код, при обновлении ничего не слетит

[Shredder]

как только его одобрят

не факт, что

[Борис Бердичевский]

Захочешь добавить что-нибудь, а тут хлоп, и "нету". И не факт, что появится, в отличие от обсуждаемого выше.

Смело добавлять собственные события. И отправлять на них запросы. Я уже добавил. Правда, с запросом пока не поспешил...

[Anvar]

Shredder, Думаю что тут спасёт "Чем больше подобных обращений". Осталось только разобраться с этим.

[Борис Бердичевский]

Запрос на события уже отправил.

Добавлено спустя 4 минуты 14 секунд:
Не надо бояться обновлений. Есть Araxis, я им и пользуюсь. Обновлялся в 3.0 при наличии довольно противоречивых (т.е. конфликтующих с обновлением) правок кода. А добавленное событие -- это вообще ерунда, пустяковая правка.

[Shredder]

Shredder, Думаю что тут спасёт "Чем больше подобных обращений". Осталось только разобраться с этим.

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

Не надо бояться обновлений.

Вопрос не в страхах, а во всё том же банальном удобстве.

[Anvar]

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

[Shredder]

Вот такая "интересная" проблема:
В phpBB 3.0.x константы новых логов (да и вообще любые константы) вносились вручную в файл constants.php, поэтому админ форума мог видеть, что и куда он вносил, и если какая-то из констант конфликтовала, то заменить её на первый свободный номер. В 3.1 ситуация иная: константы определяются где-то глубоко в коде расширений, поэтому "подсмотреть" первую свободную, чтобы заменить в случае конфликта, админу будет трудновато. Как решается эта проблема? Конечно, можно сделать для лога "рандомный номер, который вряд ли кто-то займёт", типа 223, но что-то уж больно косое это решение.

[Sheer]

Shredder
+1 Я тоже ломаю репу над этим. Вплоть до того, что log_type - это tinyint(4), теоретически можно отрицательное число.

Добавлено спустя 2 минуты 35 секунд:
С другой стороны, можно вычислить максимальное значение, и использовать на единицу большее, но это должно стать обязательным правилом для всех авторов расширений. Но при этом нет никакой гарантии, что разработчики не внесут в ядро новый тип логов.

[Борис Бердичевский]

А как можно предотвратить повторное создание страницы в Админке (если она, скажем, уже была создана в версиях 3.0)?
Т.е. в миграторе добавлен в функции update_data() ACP модуль, а вот как проверить его наличие?

Добавлено спустя 3 минуты 19 секунд:
Насчёт дефиниции переменной типа лога -- разработчики расширений-логов должны вставить предупреждение и указать, что править. Вечером внесу это в своё собственное расширение.

Добавлено спустя 3 минуты 7 секунд:
Моё мнение -- надо вносить константы логов в файл constants.php, как и делалось раньше. Т.е. продолжать это править вручную.

[rxu]

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