[PHP] Элегантный способ преобразования многострочной переменной в массив

LEOnidUKG, админ сервера сказал, что вот такой:

Я там просто одну модификацию переделываю. Очень хорошая и полезная модификация, но написанная каким-то криворучкой... Она занимается тем, что проверяет ссылки в тегах [ URL ] и т.п., и если они не находятся в белом списке, кодирует их и перенаправляет через промежуточную страницу, к которой нет доступа у поисковиков.

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

а как входные данные и массив с разрешенными ссылками выглядят в жизни?

Подозреваю, что есть более оптимальное решение, чем сплитом гонять строковые данные

silicoid, вот так:

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

Такие защиты от "дурачков" по всему коду форума присутствуют, там даже переменные так и называются.

Вполне может быть! Так как совершенству никогда нет предела! Но лучшего решения я пока, к сожалению, ещё не придумала... Если интересно, вот так это всё выглядит на практике:

До этого был сумбурный код, который повторял одни и те же действия для каждого тега помногу раз. Даже обработанный массив с белым списком сайтов не был вынесен "за скобки" в отдельную переменную и каждый раз составлялся заново (и не умел убирать пустые строки посреди текста). Слишком "тяжёлый" код был...

На Вашем форуме постоянно изменяется этот самый $modSettings? Иначе записали бы его в базу в нормализованном виде, и использовали спокойно, без постоянных дёрганий.

Sitealert, нет, не изменяется постоянно. $modSettings - это массив, в который однократно загружаются несколько сотен настроек из таблички 'smf_settings' и далее он используется во всех частях форума. То есть, это базовый функционал SMF.

И что мешает хранить в базе нормализованный элемент этого массива, из которого раз и навсегда удалены все пробелы?

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

Хотя я замеряла скорость преобразования этой строковой переменной в массив с удалением пробелов и т.п. Время выполнения ничтожно малое, так что можно со спокойной душой пренебречь подобной оптимизацией (теперь корректировка белого списка выполняется только 1 раз при загрузке страницы, а не для каждого тега, как было раньше).

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

----------

Только что посмотрела, чтобы реализовать собственный алгоритм сохранения переменных (вместо встроенного в SMF), нужно писать отдельную страницу настроек для этой модификации, плюс шаблон оформления к ней, плюс переделывать языковые переменные и т.д. Нецелесообразный труд и много лишнего кода ради выигрыша в 0,00000443 секунд при генерации одной страницы топика на форуме...

Весь древний софт рекомендуется по возможности переводить на пхп5.6 в силу того что это единственная версия пхп5 которая все еще (и довольно долго) находится на поддержке (секьюритификс).

Перенос древнего говнокода на пхп7 вызывает проблемы часто. А вот в рамках мажорной цифры (например с пхп5.1 на пхп5.6) проблемы бывают, но редко.

Опять же у вас пхп5.4 разводится, значит вероятность того что будут проблемы с пхп5.6 невелика. Тут не так много капитальных изменений было (в плане новых фич много, но в плане совместимости не так чтобы очень).

Так что по возможности советую таки до 5.6 повысить.