• Mike •

Причем тут платформа ?!
…дело скорее всего не в ней а в параметрах вашего хостинга и/или настройках окружения…
так как обычно “тормозов” нет в большинстве случаев и при самых рапространеных ситуациях

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

В статьях нет ББ-кодов, поэтому нет дополнительной обработки( ‘парсинга’ ) перед записью в таблицу в БД.

А в блоге происходит ОБРАБОТКА ВСЕГО ТЕКСТА НЕЗАВИСИМО ОТ НАЛИЧИЯ в нем ББ-кодов, то есть принудительно и как раз зависит от количества букв и слов так как метод конечных автоматов в коде сторонней либы обрабатывает ВЕСЬ ТЕКСТ ПОСИМВОЛЬНО.

Значит, все упирается в саму передачу инфы от страницы к Базе ( хостинг и тп ), то есть медленное соединение или через даВайВайФайАй который не любит “длинную” инфу передавать через себя или все это в совокупности каким-то образом объединилось…
В самой системе ( CMS ) нет узких мест, кроме тех, что я упомянул выше постом_/\/\/\_

Можете,, например, логин “приплюснуть” в нижний регистр и сравнивать в коде с настоящим но также “приплюснутым”…
будет хоть небольшая помеха…
А “по-большому“ ( счёту ) •Странник• прав — нет смысла его задавать в роуте, это не компонент «Юзеры», где это кажется логичным…

Недостаточно информации для формирования содержательного ответа.
Общее количество постов в БД, размер самой БД, процент форматированного ( оформленного ББ-кодами ) текста к общему и целому и тп…

Из очевидных и «капитанских»:
1) Обработка ББ-кодов (в коде сторонней либы) по не особо шустрому алгоритму…
2) В БД (в таблицу постов) записываются два варианта текста одного и того же поста с ББ-кодами и с HTML-тэгами…

Поздравляю команду InstantCMS, коллег, всех причастных и сочувствующих с первым 8-ми битным днём года. С Днём Программиста!
Удач, успехов всем на любимом поприще. Новых знаний и приятных дружелюбных технологий!

Выскачил из Завтра
Во что-то наступил
Сразу видно — Новенький
Кто-то пошутил…

Всех с Наступлением чего-то Нового и Свежего, а не во что-то “непонятное”… )
Удачи, успехов, непрерывного позитива! )))

у вас за символом начала строки что-то присутствует до этой самой квадртаной скобки ?
— по условию присутствует 'что-то "в кавычках",
после этого вы уточнили что текст может быть многострочным,
и что есть обязательный пробел до самой первой квадратной скобки…

паттерн тогда должен быть такой: '/^[^\[]+?\s\[([^\]]+?}\]/mu' вернется он к вам в matches[2]

То есть, даже если строка содержит юникодные символы, но поиск и замена идёт по однобайтным символам, то можно использовать однобайтные функции без риска потерять юникод?

— чаще всего — да, но есть еще параметры внутренних функций самого PHP и тп, надо проверять в реальном серверном окружении…
«безопсными» я бы назвал только первые 127 символов для ASCII они одинаковы для любой кодировки…

Если вы окончательно разобрались, то конечно можете закрыть тему…

я бы не сказал что это «рабочий» вариант )

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

— Ваша задача и была для одной строки сформулирована )

Если нужна многострочная обработка, нужно использовать модификатор в паттерне “m” как во второй задаче.
И внутри условия прогонять циклом…
Или так же с помощью preg_replace_callback();

Для юникода можно использовать модификатор “u” в хвосте паттерна, но повторюсь в вашем случае не критично так как вы анализируете и заменяете однобайтные символы из обычной раскладки ASCII

«Эхо слушать не нужно (echo)», это для отладки, просто забирайте $_tt «из эха» в нужную локацию…

то есть в первом случае кавычки ( 039 ) на ( 034 ),
во втором случае пробелы удваиваете ( 032 )…

Менять предполагаю функцией mb_ereg_replace(), так как в строке будут символы в Юникоде.

— в данном случае не критично, ибо меняете вы обычные ASСII символы ( однобайтные )…