Sitealert, нет, не изменяется постоянно. $modSettings - это массив, в который однократно загружаются несколько сотен настроек из таблички 'smf_settings' и далее он используется во всех частях форума. То есть, это базовый функционал SMF.
atteizzt: Вот есть необходимость поставить форумный движок - булку и ипб. Стоят они дорого, но в сети куча валяется нуленных. Каких последствий можно ожидать если поставлю нуленный скрипт любой из них? Как палятся именно эти движки на лицензионность?
По своему опыту могу сказать, что многие из моего круга общения используют vBulletin® Version 3.8.7 и вроде никто из них никогда не жаловался на проблемы с правообладателями.
silicoid: Подозреваю, что есть более оптимальное решение, чем сплитом гонять строковые данные
Вполне может быть! Так как совершенству никогда нет предела! Но лучшего решения я пока, к сожалению, ещё не придумала... Если интересно, вот так это всё выглядит на практике:
До этого был сумбурный код, который повторял одни и те же действия для каждого тега помногу раз. Даже обработанный массив с белым списком сайтов не был вынесен "за скобки" в отдельную переменную и каждый раз составлялся заново (и не умел убирать пустые строки посреди текста). Слишком "тяжёлый" код был...
Sitealert: Но ТС может предъявить претензию и по поводу предпоследней страницы. И по поводу предпредпоследней... Почему и надо сначала алгоритм придумать, а уже потом скрипты писать.
Sitealert, вряд ли по ту сторону монитора без нашей помощи будут в состоянии реализовать адекватный shuffle страниц.
miketomlin: Кстати, и то, и то весьма сомнительная затея, но дело ваше.
Если речь идёт об отображении рекламы (например, landing page), то вполне себе нормальная затея.
В идеале там ещё нужно вести автоматический учёт конверсии по каждой из этих страниц и в дальнейшем чаще показывать те, которые приносят наивысшую прибыль (желательно для каждой отдельной категории трафика).
totamon: "случайная страница" не равно "всегда разная"...
Нужно сохранять в cookies браузера данные о последней посещённой странице (полный адрес или лучше её индекс в массиве) и не учитывать её при случайной выборке (например, предварительно удалить из массива).
silicoid: а как входные данные и массив с разрешенными ссылками выглядят в жизни?
silicoid, вот так:
Данные можно заполнять и аккуратно, но всё равно требуется защита от случайных пробелов в конце названий и пустых строк (например, если захочется отделить группы сайтов друг от друга).
Такие защиты от "дурачков" по всему коду форума присутствуют, там даже переменные так и называются.
Я там просто одну модификацию переделываю. Очень хорошая и полезная модификация, но написанная каким-то криворучкой... Она занимается тем, что проверяет ссылки в тегах [ URL ] и т.п., и если они не находятся в белом списке, кодирует их и перенаправляет через промежуточную страницу, к которой нет доступа у поисковиков.
Мне нужно было увеличить скорость работы этой модификации, потому что на странице могут быть сотни таких тегов и каждый раз к ним применяется одна и та же функция.
LEOnidUKG, у меня SMF 2.0.13 (и полсотни установленных модификаций), он не работает на PHP 7. Если выполнить обновление, там столько проблем возникнет, что проще будет повеситься...
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. Если выполнить обновление, там столько проблем возникнет, что проще будет повеситься...
прошу прощения, что не получилось запустить?
silicoid, извините меня, была моя ошибка...
Ваш код запустить получилось, но он всё равно выполняется слишком долго и к тому же оставляет пустые элементы в массиве. Вот смотрите:
Результат тестирования времени выполнения:
Вариант предложенный webjey работает правильно и быстрее всего.
Благодаря описанным выше примерам, у меня получилось увеличить скорость нужного мне участка кода в 8 раз!