Sitealert, ничего не мешает, спасибо, я над этим подумаю! Правда все настройки форума сохраняются в базу данных с помощью своего отдельного унифицированного (слово какое-то странное, но другое не могу подобрать) алгоритма в зависимости от того, какой тип данных у переменной. То есть, нужно писать исключение именно для этого конкретного случая.
Хотя я замеряла скорость преобразования этой строковой переменной в массив с удалением пробелов и т.п. Время выполнения ничтожно малое, так что можно со спокойной душой пренебречь подобной оптимизацией (теперь корректировка белого списка выполняется только 1 раз при загрузке страницы, а не для каждого тега, как было раньше).
К тому же, если я захочу отделить группы сайтов друг от друга для моего лучшего визуального восприятия, при следующей загрузке этой настройки из базы данных всё опять сбросится к "идеальному" массиву без пустых строк.
----------
Только что посмотрела, чтобы реализовать собственный алгоритм сохранения переменных (вместо встроенного в SMF), нужно писать отдельную страницу настроек для этой модификации, плюс шаблон оформления к ней, плюс переделывать языковые переменные и т.д. Нецелесообразный труд и много лишнего кода ради выигрыша в 0,00000443 секунд при генерации одной страницы топика на форуме...
Sitealert, нет, не изменяется постоянно. $modSettings - это массив, в который однократно загружаются несколько сотен настроек из таблички 'smf_settings' и далее он используется во всех частях форума. То есть, это базовый функционал SMF.
Примерно вот такое может быть: /ru/forum/comment/14978341
По своему опыту могу сказать, что многие из моего круга общения используют vBulletin® Version 3.8.7 и вроде никто из них никогда не жаловался на проблемы с правообладателями.
Вполне может быть! Так как совершенству никогда нет предела! Но лучшего решения я пока, к сожалению, ещё не придумала... Если интересно, вот так это всё выглядит на практике:
До этого был сумбурный код, который повторял одни и те же действия для каждого тега помногу раз. Даже обработанный массив с белым списком сайтов не был вынесен "за скобки" в отдельную переменную и каждый раз составлялся заново (и не умел убирать пустые строки посреди текста). Слишком "тяжёлый" код был...
Sitealert, вряд ли по ту сторону монитора без нашей помощи будут в состоянии реализовать адекватный shuffle страниц.
Если речь идёт об отображении рекламы (например, landing page), то вполне себе нормальная затея.
В идеале там ещё нужно вести автоматический учёт конверсии по каждой из этих страниц и в дальнейшем чаще показывать те, которые приносят наивысшую прибыль (желательно для каждой отдельной категории трафика).
Нужно сохранять в cookies браузера данные о последней посещённой странице (полный адрес или лучше её индекс в массиве) и не учитывать её при случайной выборке (например, предварительно удалить из массива).
silicoid, вот так:
Данные можно заполнять и аккуратно, но всё равно требуется защита от случайных пробелов в конце названий и пустых строк (например, если захочется отделить группы сайтов друг от друга).
Такие защиты от "дурачков" по всему коду форума присутствуют, там даже переменные так и называются.
LEOnidUKG, админ сервера сказал, что вот такой:
Я там просто одну модификацию переделываю. Очень хорошая и полезная модификация, но написанная каким-то криворучкой... Она занимается тем, что проверяет ссылки в тегах [ URL ] и т.п., и если они не находятся в белом списке, кодирует их и перенаправляет через промежуточную страницу, к которой нет доступа у поисковиков.
Мне нужно было увеличить скорость работы этой модификации, потому что на странице могут быть сотни таких тегов и каждый раз к ним применяется одна и та же функция.
LEOnidUKG, у меня SMF 2.0.13 (и полсотни установленных модификаций), он не работает на PHP 7. Если выполнить обновление, там столько проблем возникнет, что проще будет повеситься...
