Documentation index
- ReadMe
- Things To Know
-
- New Style Rotation
mod_rewrite - это модуль для апача, которые позволяет делать “красивые” урлы. Тот же модуль есть и для nginx и для lighttpd.
Например, в дефолтных темпелйтах урлы примерно такие http://domain/gallery/cool-gallery/index.html , понятно что реально на серваке таких урлов нет. Мот реврайт преобразовывает этот урл в http://domain/scj/tube/?slug=cool-gallery , а красивый урл - для СЕ и юзеров.
.htaccess который создается в самом начале задает правила реврайтов.
Попоытка просто объяснить как это работает:
И так, как было сказано выше /gallery/cool-gallery/index.html такого урла реально на сервере нет. Что бы посмотреть галеру урл должен быть такой: /scj/cgi/out.php?url=content&slug=cool-gallery, что не совсем эстетически хорошо. Поэтому мы в специальный файл .htaccess пишем реврайт - это специальное правило, как апач будет преобразовывать урлы. Для этого конкретнго случая у нас есть такой реврайт:
RewriteRule ^gallery/(.*)/index.html$ /scj/cgi/out.php?url=content&slug=$1
это значит, что если урл начинается с gallery/, а потом идет что угодно (.*) до знака /, и заканчивается это на /index.html - значит это наш случай. каждый из “что угодно” (.*) получает номера - соотв. первое “что-то” это $1 , второе - $2.
В нашем примере $1 будет равно cool-gallery. Соотвественно апач преобразует этот урл в /scj/cgi/out.php?url=content&slug=cool-gallery и вы увидите галеру.
Урлы вида /gallery/cool-gallery/index.html на страницах получаются потому что в сабтемплейтах страниц у вас записано что-то вида
href="/gallery/<!--GALLERY_SLUG-->/index.html
Их всего этого следует, что если вам надо поменять виды урлов на сайте надо поменять сабтемплейт и сменить реврайт, что б он подходил под ваш сабтемплейт.
1 галера может находится в больше чем 1 групп (категории). Это видно в редактировании любой тумбы - у нее есть main группа (одна) и ext группы (много). Rotation - groups считает только по main. Это сделано что б было ясно сколько точно уникальных галер.
Например, у нас 2 группы А и Б. и 2 галеры - у одной main группа А, у другой main групра Б. Но у обоих в поле ext groups отмечены и А и Б. Rotation - Stats покажет что у нас конкретно 2 галеры , одна в группе А и одна в группе Б.
На сайте же в каждой из групп будет видно по 2 галеры.
Пересчет категорий, а именно выбор лучшей тумбы категории и подсчет сколько же всего тумб в категории, довольно тяжелая задача для сервака, поэтому он это делает раз 15 минут по крону, кладет в кеш и все все остальыне части скрипта юзают кеш. Init cats - это принудительный запуск этой операции.
Если вы добавили новую категорию - она появится максимум через 15 минут, если надо быстрее - жмите эту кнопку.
Скрипт не генерит статические html страницы (см выше вопрос по mod_rewrite), все страницы динамические. Дабы не пересоздавать страницу для каждого пользователя скрипт создает ее один раз и сохраняет в кеше на опредленное время (CACHE_TIME), следующий посетитель в течение времени жизни кеша - получит эту страницу уже из кеша, не нагружая сервак.
Время кеша задается в common.php CACHE_TIME, начиная с апдейта 46 время в common.php можно не указывать, а указывать в сетингах ротации. Обратите внмиание, что время указаннное в common.php имеет преимущество, те если указано в common.php то настройки ротации скрипт игнорирует.
Дабы посмотреть какую-то страницу без кеша надо добавить в урле параметр skip_cache=true. Например, http://domain.com/?skip_cache=true
Начиная с апдейта 46 появила recreate cookie - Rotation - Special - Recreate visited pages - скрипт ставит секретную куку вашему браузеру на 10 часов (можно снять куку в любой момент там же). Если вы зайдете с этой кукой на любую страницу вашего сайта, эта страница будет пересоздана (те сброшен кеш именно для этой страницы). Бывает полезно при изменении дизайна какой-то одной определенной страницы.
Те разница между skip_cache и recreate cookie в том, что skip_cache покажет страницу без кеша только вам и все, а recreate cookie покажет страницу без кеша, потом такой какую вы ее видете положит в кеш и другие пользователи будут видеть ее из кеша в таком виде.
Еще раз: страница создава в 00 минут. Время кеша 10 минут. в 05 вы меняете дизайн. если вы в 05 посмотрели его со skip_cache - то увидите новый дизайн, но пользователь, который пришел в 06 (те ДО времени когда проэкспарится кеш) - увидит старый дизайн. если вы в 05 открыти страницу с recreate cookie - то пользователь который пришел в 06 увидит в новом дизайне.
Базовый принцип работы движка - сгенерить нужную страницу, положить ее в кеш на определнное время и показывать ее пока кеш не проэкспарится. Какие движки есть на данный момент:
Файловый Базово кеш хранится в файлах (scj/cache - файловый кеш). Плюсы - он работает везде и сразу. Минусы - это именно файловый кеш, он он не так быстр, не так эффективно кешится системой как хотелось бы и приходится отдельлно заботиться о размере папки с кешем.
Memcached В свое время это конечно был большой шаг вперед в плане кеширования. Плюсы - все его знают, админы без проблем ставят на хостиинг, его просто администриировать и тп. Минусы - никакого понимания о реально занимаемой памяти получить практически невозможно, при перегрузке сервака весь кеш удаляется и нужен тн “разогрев кеша” те положить туда наиболее используемые данные. При перегрузке сервака из-за нагрузки это серьезная проблема - сервак и так нагружен, а тут еще и всесь кеш исчез.
Все данные одинаково прокешены - не важно это наиболее используемые или использзуемые раз в час - они все висят одинаово в памяти и сервис не умеет их скинуть на диск например.
В мемкешем невозможно прибить кещ для одного сайта. У сайтов общее пространство кеша и прибивая кеш - прибивается кеш для всех сайтов сразу. Можно конечно руками запустить несколько инстансов мемкеша на разных портах, но это надо просить админа и часто это проблема и в целом неудобно.
Как установить:
$config['memcached_host'] = '127.0.0.1'; $config['memcached_port'] = '11211';
Поэтому сейчас появились новые движки которые рекомендуются к использованию
В новых движках которые базово называются NoSQL решения существует намного больше возможностей нежели будет описано ниже, но для текущих целей кеширования будут описаны базовые.
Решение на которое наиболее просто перейти - Couchbase CouchBase - это продолжение MemBase, видимо ближайщего потомка memcachedb, который в свою очередь родом из memcached.
Главное - от вас не требуется практически никаких движений дабы начать его использовать. Вы ставите CouchBase и он работает точно так же как мемкеш. Те для того что бы начать его использовать надо
$config['couchbase_host'] = '127.0.0.1'; $config['couchbase_port'] = '11210'; $config['couchbase_username'] = 'testuser'; $config['couchbase_password'] = 'testuser'; $config['couchbase_bucket_name'] = 'test';
и все, вы уже используете современную версию мемкеш. Вы можете это использовать даже с версией 48-49.
Чем это лучше чем memcached
Redis - отдельный написанный с 0 проект NoSQL базы. Смысл его для наших целей практически тот же (в реальности couchBase это уже больше document oriented хранилище, а Redis - чисто key-value хранилище ). Для работы с ним функционал был добавлен в версии 50.
Для того что бы начать его использовать надо
$config['redis_host'] = '127.0.0.1'; $config['redis_port'] = '6379'; $config['redis_database'] = 0; $config['redis_password'] = ''; если redis висит на сокете то выглядеть будет примерно так $config['redis_host'] = '/tmp/redis.sock'; $config['redis_port'] = '0';
и все.
В данным конфиге кроме понятных полей есть несколько новых. redis_password - в большинстве случаев не актуально посколько сейчас все на dedicated servers. redis_database - у Redis нет буквенных названий баз, а есть номера. те если у вас несколько сайтов - вы можете указать каждому сайту свой номер. Но можно и не указывать и использовать одну базу для всех сайтов. Разница будет в том, что если вы захотите скинуть весь кеш и у вас используется одна база для всех сайтов - кеш удалится для всех сайтов. Если же у каждого сайта будет своя база - кеш скинется для одного.
Чем это лучше чем memcached
По умолчанию используется файловый кеш (храниться в /scj/cache), но можно использовать и например Memcache. Для этого надо только добавить в scj/includes/config.php
$config['memcached_host'] = 'localhost'; $config['memcached_port'] = '11211';
адрес и порт могут меняться (уточните у вашего админа), но в большинстве случаев они будут такими же.
Имеет смысл настроить memcache на работу через сокт - это быстрее. В этом случае конфиг будет примерно такой
$config["memcached_host"] = "unix:///tmp/memcache.sock"; $config["memcached_port"] = 0;
Есть несколько ньансов:
При одинаковой сортировке порядок должен быть одинаковым с учетом следующих ньансов:
1. в админке показывает имено так как оно есть в базе по цтр например, на странице сайта в каких то местах могут стоять “новые тумбы”, которые тестируются. Например, на странице тумба 123 стоит на 15м месте, а в админке на 50м. Вероятно это новая тумба, которую скрипт тестирует.
2. Новая тумба может получить неожиданно большой цтр. Например, показали 2 раза и 1 раз по ней кликнули = цтр 0.5 , однако 2 показа это не повод судить что тумба хорошая. Потому по дефолту “новые” тумбы не показываются на первых местах. Изменить это можно в сетингах (New Rotation: New thumbs placement : Place new thumb (shows less then New thumbs timelive) on places other then Test positions start if it has good CTR. ). Проверить легко если в List Thumbs выбрать New Thumbs = dont show new.
Облако тагов генерится из активных тагов раз в 30 минут и кладется в кеш. Соответственно варианты:
cd /PATH_TO_/scj/bin/; env HTTP_HOST=yourdomain.com php rotation.php process_deleted=true
Скорость удаления гадер сложно прогнозируема и зависит от кол-во и нагрузки сервака, есть ли кастом гали, на текущем серваке они или на фтп и так далее.
Не обязательно отротировать все до конца, чтобы прода была хорошая, но в целом посчитать сколько надо трафа очень легко.
Тумба считается отротированной, когда ее показали New thumbs timelive раз , по дефолту 500. Допустим на странице - 200 тумб, а % of test places on page по дефолту 15, те из 200 мест на старнице новые будут показываться на 30 местах. Те каждый заход на старницу это +30 показов для новых тумб. Например у нас 10 000 тумб, что б их отротировать нам надо 10000*500 = 5000000 показов. Одиз заход на старницу - это 30 показов, те что б отротировать базу в 10к нам надо 5М /30 = 167к загрузок страницы.
Если не считать банальной нехватики трафика, речь обычно о том, что у галеры например 10 тумб, но показы только у одной. Как это происходит: например у нас 100 галер по 10 тумб, на странице 20 тумб. Начинаем ротацию. У всех цтр 0. Вывели первую тумбы с галер ИД 1 - 20. Они получили цтр больше 0. Нам надо обновить страницу. тестовых например 5 на странице.
Мы выводим ИД 1 - 15 как 15 лучших (а там пока цтр и показы получила только пурвая тумба с галеры). А потом 5 тестовых - тут мы можем взять тумбу номер 2 с галер ИД 16-20
Получилось так что эти тумбы набрали меньше чем тумба 1 галер ИД 1-15, мы берем например 3ю тумбу с галер ИД 16-20.
Таким образом получается что у галер ИД 1-15 показы есть только у пурвой тумбы. Когда их ЦТР будет меньше чем ЦТР других - их “выдавит” из топа.
У них там же есть возможность быть показанными на странице 2 пагинации, но опять же при условии что ваш траффик доходит до 2й страницы.
Изначально у out.php есть параметр &link=blabla смысл которого в том, что статистику по blabla можно видеть Stats - Links. Но ротация использует его для передачи параметров ротации (12x123x1234). Выглядит это на практике очень просто: например линк /gallery/cool-desc/index.html?12x345x567 реврайтом (см выше что это такое) преобразуется в урл вида out.php?slug=cool-desc&link=12x345x567 и позже скрипт обрабатывает статистику по линкам преобразуя это в статистику по тумбам. Соответсвенно если у вас урл вида out.php?member=domain.com&link=top то такой вариант все такое же работает, однако для линков ротации его использовать не получается. Дабы решить эту ситуацию был введен еще один пармтер &link2 смысл которого в том, что вы можете делать out.php?slug=cool-desc&link=12x345x567&link2=blabla и все так же смотерть статистику по линкам и одновременно ротировать тумбы.
Тумба категории - это по-дефолтлу лучшая тумба из категории. Однако, есть возможность поставить тумбой категории не лучшую, а например 2ю по ЦТР или 3ю и тп, эти настройки можно найти в Rotation - CMS - Settings.
Pool - Active - Old - фактически надо для работы Shift settings в группах ротации. Смысл в том, что бы наполнять сайт автоматически. Те вы добавили много галер в статус pool, поставили добвлять раз в день 10 галер и сайт их доабвляет из пула в активные, и они появляются на сайте. Получается видимость ежедневного обновления. Old - если вы хотите убирать старые галеры с сайта сохраняя общее кол-во одинаковым.
На сайте в листинге показываются галеры только со статусом active.
preload - галеры добавляются в Preload (в админке) что б вы могли выбирать какие из сграбеленных тумб по итогу будут на сайте. Те которые вы не выберете - будут удалены.
to_grab - когда галеры добавляются в базу они получают этот статус прежде чем граббер создаст тумбы для них. В момент создания тумб они получают статус processing. to regrab - галера ожидает реграба.
to delete - галера ожидает удаления. Часо на удаление помечается много галер, и мгновенно удалить их невозможно, особенно
grab error - если при грабе тумбы что-то пошло не так галера или удаляется или получает статус grab error в зависимости от ваших настроек.
Banned - урл остается в базе и не будет добавлен снова. Как и grab error это имеет смысл только в том случае, если вы добавляете галеры через import sets и есть вероятность что какие-то галеры будут добавлены снова и снова. Например, вы добавляете через импорт сет, галеры идут в preload. Вы отобрали часть галер, а какие то решили не добавлять. Через час этот импорт сет добавляется снова, а там есть та же галера снова - она опять попадет в preload и вам придется опять ее отсеивать. Что б этого не было - можно добавить в banned. Минус в том, что база в этом случае растет и там есть галеры которые не используются, но занимают место в базе.
Inactive (и аналог hidden в версии 1.X ) - галера не показывается в листинге, но при прямом заходе на урл - видна. Смысл следующий: например у нас была галера, она проиндексирована, но она хотлинковала контент откуда-то. В какой-то момент контент удалили и галерея стала нерабочей. Ранее чекер удалял такие галереи (точнее 2 варианта - удалить сразу или inactive), но был минус в том, для СЕ спайдеров старый урл теперь стал 404. Возможно лучше если будет возвращать страницу без контента, но не 404. Для этого и есть статус “Hidden” - это значит галера будет видна по прямому урлу, но тумбы этой галеры не будут в ротации. те попасть на нее можно будет только по прямому урлу. Этот статус можно выставить в импорт сете, который удаляет галереи.
Аналогичная опция есть у Gallery Checker.
Точный эффект от этого для СЕ - неизвестен.
Версия 2.* умеет добавлять большие файлы через importset самостоятельно (теоретически любого размера). Просто добавляете урл и он постепенно все добавит.
Если при заходе на любую страницу у вас пишет что-то вроде “Parse error: some error, in /some/path/scj/tube/index.php(0) : eval()'d code on line 1717” - это 100% значит что у вас ошибка в вашем пхп коде в темплейте.
По опыту наиболее частой проблемой является несоблюдение ковычек. http://smartcj.com/wiki/doku.php?id=ru:new_rotation_hints#php_code_in_template
Это наборы параметров для обработки тумб.
Если вам надо размер только по одной стороне, но вторую сторону ставим 0. Например, если указана ширина, а высота 0, то ширина будет фиксированной, а высота будет меняться под размер тумбы. Это актуально для сайтов типа пинтерест.
Image Command - это команда которая применяется ДО того как сделана тумба. единственный параметр {FILE} - это текущая картинка. Например,
/usr/bin/your_command -some_param {FILE}
Thumb Command - аналогично только для уже сделанной тумбы.
Face Detect - см FaceDetect
Иногда по какой-то причине вы не хотите делать другой сайт слейвом, а хотите сграбить кастом галеры с другого своего сайта, а например исходные урлы уже недоступны. При этом галеры у вас сделаны с картинками на отдельной старнице - в этом случае единственный вариант сграбить их это использовать Deep fetch. Проблема тут однако в том, что с таких страниц обычно стоят ссылка на страницы тагов, категорий и прочего, где очень много других тумб, в при deep fetch скрипт пытается их все скачать. Другой вариант - если на кастом галере есть какой-то ским. В этом случае такой граб может быть весьма длительным процессом.
Лучше сделать так:
Данные по ротации хранятся в таблицах rot_gallery_stats*, таким образом если вам надо скопировтаь данные по ротации с одного слейва на другой вам надо
Проблема обычно в использовании тага категории на страницах галеры, например <!–CATEGORY_NAME–>, при этом галера может иметь более одной категории и не ясно какую из них надо выводить. Поэтому используется либо таг вида <!–CATEGORY_1_NAME–> либо конструкция <groups … >…</groups>
Допустим у нас есть мастер на котором группы А и Б. Мы подключаем слейв на котором деактивируем группу Б. При выборке для слейва у нас есть 2 варианта:
на первый взгляд это одно и тоже. Однако если у нас галера состоит в обоих группах то в одном случае она попадет в выборку, а в другом нет.
Поэтмоу в сетингах есть настройка Group Exclusion
Когда это надо: вариант hard - это когда у нас условно 3 группы: страйт, гай и тин. на слейве мы хотим например только страйт. Понятно что серфер гай видеть вообще не хочет. Те тут жесткое исключение.
Некоторые страницы могут быть сделаны таким образом, что автоматически их сграбить не получается.
В этом случае можно сделать тн гейт что бы преобразовать ее в более понятный вид:
Пример:
Условно у нас есть галера http://gallery/ со странными тагами
<html> <body> <dont_grab_this src='http://gallery/0.jpg'></dont_grab_this> <some_strange_tag src='http://gallery/1.jpg'></some_strange_tag> <some_strange_tag src='http://gallery/2.jpg'></some_strange_tag>
стандартным парсер скрипта такое разобрать не может, поэтому мы делаем гейт http://my_server/gate.php который разбирает эту галеру и показывает тумбы оттуда (код упрощен для примера, конечно надо больше проверок)
<?php if (!isset($_GET['url']) or !$_GET['url']) die("Need url"); if ($html = file_get_contents($_GET['url']) ) { preg_match_all("|<some_strange_tag src='(.*?)'>|", $html, $out); $image_num = (isset($_GET['num'])) ? $_GET['num'] : 1; if ($out[1][$image_num-1]) { header("Content-type: image/jpeg"); echo file_get_contents($out[1][$image_num-1]); } }
проверяем что гейт работает
http://my_server/gate.php?url=http://gallery/ http://my_server/gate.php?url=http://gallery/&num=2
по этим урлам в браузере должны отобразиться соответственно http://gallery/1.jpg и http://gallery/2.jpg с нашей галеры.
Теперь импортируем эту галеру, паттерн: url|thumb_url
http://gallery/|http://my_server/gate.php?url=http://gallery/,http://my_server/gate.php?url=http://gallery/&num=2
Как тут видно урл будет http://gallery/, а для тумб мы возмем изображения, которые видны по урлами http://my_server/gate.php?url=http://gallery/ и http://my_server/gate.php?url=http://gallery/&num=2.
Тк мы не знаем сколько точно будет картинок на галере, то в список тумб можно добавить и например http://my_server/gate.php?url=http://gallery/&num=123 (те номер несуществующий) - просто скрипт не сможет его сграбить и пропустит.
Вариант 2: замена на стадии импорта
Допустим у нас есть import set http://sponsor/dump.php который выдает дамп вида
url|thumb_url|desc
и мы решили делать кастом галеры из этого контента, однако проблема опять же в том, что галера имеет тот же вид что и в предыдущем примере, те граббер в штатном режиме не может ее сграбить.
Делаем гейт - вариант 2:
Вариант 3: импорт с использованием XPath
Например, у нас есть новый туб который дает урлы вида http://tube/gallery.html, экспорта у него нет, мы сграбить оттуда flv_url и flv_thumb_url и сделать из них свои кастом галеры.
http://tube/gallery.html|XPath://html/body/div[3]/section/div[1]/div/div[1]/div[2]/a[2]/@href|XPath://html/head/meta[5]/@content если вставить эту строку в импорт появиться кнопка Test Xpath. Если на нее нажать, то скрипт вытянет урл галеры и вычислит указанные поля. Это надо для проверки того, что вы верно прописали xpath.
Таким образом можно добавить сколько угодно урлов вида
http://tubesite.com/gallery.html|XPath://html/body/div[3]/section/div[1]/div/div[1]/div[2]/a[2]/@href|XPath://html/head/meta[5]/@content http://tubesite.com/gallery222.html|XPath://html/body/div[3]/section/div[1]/div/div[1]/div[2]/a[2]/@href|XPath://html/head/meta[5]/@content http://tubesite.com/gallery333.html|XPath://html/body/div[3]/section/div[1]/div/div[1]/div[2]/a[2]/@href|XPath://html/head/meta[5]/@content
и таким образом галеры будут добавлены. Но это конечно не очень красиво. Поэтому можно добавить Import Replacements где
url contains = tubesite.com replace FLV Url = XPath://html/body/div[3]/section/div[1]/div/div[1]/div[2]/a[2]/@href
Таким образом можно будет импортировать просто http://tubesite.com/gallery.html а скрипт уже будет заменять для этого сайта нужные поля при импорте.
Как обычно наилучший способ - это добавить одну галеру и смотреть лог граба.
Вариант 4: ааааа, все сложно, я ничего не хочу читать и разбираться
Если вы не хотите делать самостоятельно вы всегда можете заплатить и работу сделают за вас. Сделать гейт или скопировать xpath в браузере сможет любой школьник. Если не хотите обращаться к школьникам - обращайтесь к суппорту с конретными сайтами. Ориентировочная цена - $100 за сайт.
Все эти варианты основаны на том, что при скроле до конца страницы подгружается новый контент и у пользователя не перегружается страница, а добавляется новый контент в конце страницы.
Выглядит это так: условно темплейт index в котором 50 тумб
<thumb num=1-50> <a href='/...'><img src='<!--THUMB_URL-->'></a> </thumb>
В темплейт мы добавляем например jquery.wookmark (не единственный вариант конечно) как на http://demo.smartcj.com/scroll/
по достижении конца страницы он должен подгрузить дополнительный контент, для этого мы указываем откуда
var P_BASE = '/?force_template=index_scroll_ajax&page=';
как видно подгружается темплейт index_scroll_ajax и указывается &page=.. Каждый раз по достижении конца страницы jquery.wookmark будет подгружать этот урл меняя номер страницы
Темплейт index_scroll_ajax где мы выводим по 10 тумб
<thumb num=1-10> <a href='/...'><img src='<!--THUMB_URL-->'></a> </thumb>
Проблема проявляется на базе где еще тумбы вообще не набрали цтр\показы: открываем страницу 1, после этого страницу 2 (той же выборки) и видим повторяющиеся тумбы. Происходит следующее:
Например у нас на странице 3 позиции для тумб (упрощаем для примера), а тумб всего 9, те на 3 страницы. тестовая позиция -1 на страницу, 1 тестовая 2 отротированных тумбы. На странице 1: берем 2 тумбы по цтр, тк у всех цтр 0 получаются тумбы 1 и 2. Берем первую тестовую - 3. Получается 1 2 3.
Страница 2 - берем со сдвигом на страницу , те следующие 3 по цтр, но опять же тк цтр не то это получаются 4 5 подряд. И теперь надо одна тестовая - смотрим с самого начала , а у тумбы 1 нет показов, она тестовая еще. Получается 4 5 1. Отсюда и повтор.
Как только база набирает немного цтр - получается что по цтр достаточно тумб что б набрать страницу и таким образом тумбы не повторялись.
Если у вас большая база то имеет смысл заменить <pagination> на просто <!–PREV_PAGE–> <!–NEXT_PAGE–>
Разница в том, что если у нас есть навигация, нам надо сначала посчитать сколько всего галер по конкретному запросу, это определнная нагрузка на базу.
Если же у нас только ссылки на следующую\предыдущую страницы то ничего считать не надо в базе.
Обратите внимание, что в этом случае таг total_items будет показывать просто кол-во галер на текущей странице.
Допустим у вас в импорте много тумб, но трафа что бы их отротировать все недостаточно (так бывает в большинстве случаев). Но хотелось бы оставить все тумбы для ролинга тумб. Для этого в импорте есть вариант с User Thumbs - смысл его в том, что указанные тумбы скачиваются, применяется кроп профайл, но в базе их нет, они сохраняются только на диске в каталог /scj/thumbs/user_thumbs/.
Те мы можем импортить как URL|THUMB_URL|USER_THUMBS
Есть ньюанс - если в импорте нет возможности сделать 2 поля в тумбами, то можно импортить просто как URL|USER_THUMBS и How Many Thumbs from each gallery ?= Х. Таким образом все тумбы из этого поля будут сохранены на диск, а Х тумб будут добавлены в базу для ротации.
Таким образом база не растет и не надо ротировать лишние тумбы.
При этом надо понимать, что скрипт ничего не знает про тумбы которые сохранены в user_thumbs, поэтому для роллинга тумб у вас есть 2 варианта. Либо для каждой галеры кол-во тумб должно быть одинаковым, либо при роллинге скрипт должен делать preload тумб для роллинга и таким образом понимать сколько их там всего.
В темплейте урл к каталогу с юзер тумбами для данной галеры можно получить тагом
<!--USER_THUMBS_FOLDER-->
Например, у вас сайт на английском и есть форма поиска, куда люди вписывают поисковые запросы на сайте. Лог поисковых запросов выводится где-то на сайте. Часть людей пытаются искать например на русском и это выводится в логах запросов, а вы не хотели бы что б бы это было видно. Можно неугодные символы фильтровать на этапе запроса.
Добавляем в common.php
if (isset($_GET['search'])) $_GET['search'] = preg_replace('|[^a-z,0-9,\s]|is','',$_GET['search']);
и это будут только латинские символы
Так же есть опция “Log empty search queries ” и если по запросу ничео не найдено то логгить его не будет.
Рассмотрим что есть в скрипте для поддержания мультинишевых сайтов с новой ротацией, кроме непосредственно наличия категорий.
Входящий редирект на нишевую страницу - скрипт может редиректить траффик с трейдера сразу нужную нишу у вас на сайте (redirects).
Отправка клика на нишемвую страницу трейдера - если трейдер не можетавтоматически редиректить ваши хиты на нужную старницу, можно самостоятельно настроить такой редирект, хотя это несоклько сложнее, чем просто включить опцию. Для начала надо, что б при клике скрипт понимал с какой группой он имеет дело, те добавить к ауте &group=… . Тут 2 варианта:
далее в настройках каждого терйдера можно задать Special Urls для каждой группы. Те если для группы А у трейдера указан урл http://trader/a/ и в параметрах аута определило что текущая группа А, то к трейдеру пошлет не на http://trader/, а на http://trader/a/
Note про что забывают при разборе этих функций
Трейдер 1 в группе А, однако я вижу в рефах трейдера 1 рефы с моего сайта с категории B - трейдит не по группам ! Обычно топ трейдеров составляется общий, а не по группам и этот топ инклудится на всех страницах сайта. Те на странице B так же будет топ ВСЕХ трейдеров, даже тех которые могут быть только в группе A. Toplist
Кроме этого если в группе A например 2 трейдера, серфер побывал на обоих, то при сл клике его будет слать на всех трейдеров. Те если в группе нет активных трейдеров, на которых серфер не был - шлет на всех.
Ротация предполагает наличие большого кол-ва страниц.
Вот обычная ситуация: у вас 200к галер в 300 категорий, пусть в среднем по 7 страниц в категории, 3 варианта сортировка (ctr, data, duration) = 6300 возможных страниц + 200 000 страниц самих галер.
Понятно, что создавать по крону такое кол-во страниц как статику - бессмысленно, поэтому страницы создаются динамически и кешируются. Время кеша вы выставляете в конфиге. Чем меньше время кеша - тем больше страниц каждую секунду надо создавать скрипту. Те вы напрямую влияете на нагрузку на сервер.
Кроме этого есть тн “разогрев” сайта. Например, вы только все собрали и собираетесь пускать траф. Если влить сразу много трафа, например сразу же форсировать туда 5к - это 5к разойдутся по всем страницам и скрипту надо будет быстро создать все эти страницы, потому что вы только что собрали сайт и кеша на многие страницы нет. Поэтому при разгоне нового сайта дабы избежать излишней нагрузки на сервак важно разгонять понемногу. Те сначала например слить 1-2к за час, за это время будет создан кеш по осн страницам, а потом уже можно лить сколько надо.
Сколько сервак выдержит трафа: после того как создан кеш страницы отдаются условно мгновенно. Выглядит это так: 1 человек пришел на новый сайт на индекс, мы создали индексную страницу и положили ее в кеш на время указанное вами в конфиге. Все остальные посетители получат эту страницу из кеша практически не нагружаяя сервак. Даже если на эту страницу придет 1М пользователей за время кеша - они без проблем получат страницу.
Те если у нас условно 1 сайт то скажем 50к или 500к трафа - не имеет значения, потому что все равно нам надо создать практически одно и тоже кол-во страниц как для 50к, так и для 500к.
Но если у вас 50 сайтов по 10к трафа - по нагрузке это не одно и тоже что 1 сайт на 500к, потому что для 50 сайтов надо создать в 50 раз больше страниц, чем для одного (при одинаковых размерах базы, кол-ве категорий и тп).
Так же прямым образом влияет размер базы на нагрузку: если у вас 100к в базе то в зависимости от дизайна это будет пусть тех же 3000 страниц, 200к - 6000 страниц.
Переводы и слейв сайты: технически это как еще 1 сайт, тк что перевод, что слейв это другие описания или дизайн и тп, одним словом надо пересоздавать страницу. Есть одно “но” чем они немного отличаются от просто 2го сайта. 2 полностью разных сайта по 100к галер, это не тоже самое что мастер 100к галер + слейв, тк часть инфы у них совпадает, следовательно база может какую-то часть кешировать = меньше нагрузки.
Ответить на вопрос “сколько трафа выдержит сервак с конфигом Х” невозможно тк не ясно сколько это сайтов, какой диз и тд и тп., выясняется только опытным путем. Конечно, мы прилагаем все усилия что бы максимально оптимизировать скорость работы скрипта.
Тут стоит помнить о том, что сервак перегружается лавинообразно. Это значит что не будет такого что работает например сервак на 100% нагруженный и просто все начало немного тормозить. В какой-то момент запросы накапливаются и сервак падает. Проще всего это представить как вы раскручиваете двигатель машины, вот на 20% он работает, вот в красной зоне, работает во всю, а потом, если добавить еще, но не мощность падает от перегрузки, а двигатель клинит и он не работает совсем. Поэтому мониторинг серваков это важно.
Часто в темплейты включат много своего PHP кода и в какой-то момент становится не совсем ясно, что конкретно больше грузит сервак: скрипт или свой код. Что бы примерно посмотреть на это в сетингах ротации есть
Performance Log Writes performance info into logs/perfomance.log Adds some load at HDD as it writes each hit.
При включении он пишет в logs/perfomance.log, те создает небольшую доп нагрузку, поэтому без надобности оставлять включенным не стоит. Однако на какое-то время его можно включить что бы проверить текущее состояние.
Основной плюс в том, что позже в Maintenance -Logs вы можете посмотреть этот лог и скрипт автоматически сгруппирует показатели что бы вы могли видеть общую статистику, а не просто много текста. Названия полей там меняются по мере того, как дописывается этот лог, но в 99% случаев не составляет проблем понять что значит каждая запись. Если что-то не ясно - всегда можно спросить на форуме.
Классический урл выглядит примерно как http://domain/gallery/asd.html что через реврайт получается как out.php?url=content&slug=asd, при этом скиминг берется из дефолтного или может быть задан в реврайте, главное что при рефреше страницы галеры может средиректить на трейдера.
Автоматически избежать этого невозможно тк рефреш - это когда браузер посылает точно такой же запрос и отличить на стороне скрипта никак нельзя.
В целом я не считаю это проблемой тк рефрешит галеру только сам вебмастер в процессе дизайна, но если вы хотите этого избежать то можно добавить в страницу код, который будет выполняться при нажатии рефреш
вместо alert(“refresh button is clicked”); можно поставить свой код который будет редиректить например на http://domain/gallery_PERMANENT/asd.html , а в реврайтах добавить gallery_PERMANENT который будет делать урл с &p=100
Перевод сайта на другие языки.
Довольно просто сделать перевод меню сайта (те ссылок типа Most Popular, Order By date и прочее) на другие языки. Например у нас есть фраза “Самые популярные”. И несколько языков для которых эту фразу надо переводить.
Rotation - CMS - TPL Custom Vars создаем переменную most_popular, ее можно будет использовать в темплейте как <!–CUSTOM_VAR_MOST_POPULAR–> (это подписано прямо с созданной переменной). Там же можно указать перевод для языковых слейвов.
По стандарту урлы - case sensitive, те большая или маленькая буква - имеет значение. Однако, большинство людей почему-то считает, что нет, поэтому урлы в базу попадают в разных вариантах, при этом возникают вопросы “почему я ищу http://domain/aaa и не находит? когда в базе запись http://domain/AAA. Что бы избежать этого по умолчанию в базе поле урла - case insensitive что б не было вопросов с поиском.
Однако бывает, что урлы действительно разные и надо что б база отличала регистр. Для этого надо в базе выполнить
ALTER TABLE `rot_gallery_info` CHANGE `url` `url` VARCHAR(255) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL; ALTER TABLE `rot_gallery_info` CHANGE `source_url` `source_url` VARCHAR(255) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL;
и помнить что после этого урлы из примера выше станут разными и при поиске урла надо будет смотреть на регистр букв.
По умолчанию тумбы сохраняются в /scj/thumbs. Если вы хотите сменить место хранения тумб после того как добавили контент то надо
Для высоконагруженных сайтов значительно помогает кешить страницы в уже выполненном виде. Например, у нас есть темплейт
<thumb num=1-2> <!--THUMB_URL--> </thumb> <?php echo "date: " . date("Y-m-d"); ?>
Скрипт парсит темплейт и заменяет данными из базы и кладет в кеш, что б для следующего серфера, который будет смотреть эту же страницу уже не заменять таги скрипта
/thumbs/img1.jpg /thumbs/img2.jpg <?php echo "date: " . date("Y-m-d"); ?>
при этом пхп код кешится в исходном виде. Те для каждого серфера этот пхп код будет выполняться.
В большинстве случаев это мелочи по нагрузке, однако при большом трафе, когда надо снизить нагрузку на проц, можно кешировать и пхп код, те страница будет закешена уже с выполненном виде, например
/thumbs/img1.jpg /thumbs/img2.jpg date: 2023-01-01
В большинстве случаев - это ок, тк результат выполнения кода одинаковый для всех серферов.
Однако бывают редкие ситуации когда в темплейте есть код, который должен быть выполнен для каждого юзера тк зависит например от текущего IP пользователя. Для этого есть опция
$config['full_page_cache'] = true;
В этом случае в темплейте можно использовать таг
<php_code no_cache=true> <?php echo "user IP: " . $_SERVER['REMOTE_ADDR']; ?> </php_code>
и именно этот код не будет закеширован.
Например темплейт
<thumb num=1-2> <!--THUMB_URL--> </thumb> <?php echo "Rand: " . rand(0, 100); ?> <php_code no_cache=true> <?php echo "user IP: " . $_SERVER['REMOTE_ADDR']; ?> </php_code>
будет закешен как
/thumbs/img1.jpg /thumbs/img2.jpg Rand: 22 (тут надо обратить внимание что этот пхп код закешен в выполненном виде) <?php echo "user IP: " . $_SERVER['REMOTE_ADDR']; // а тут пхп код в исходном виде и будет выполнен для каждого серфера ?>
Надо что надо обратить внимание при изменении темплейта под full_page_cache. Например, у вас код
<?php $img_src_hash = md5($_SERVER['REMOTE_ADDR']); ?> <img_src='get_img.php?hash=<?=$img_src_hash?>' some more HTML
закешировать полностью мы не можем тк этот код должен быть разным для каждого серфера. Что бы хэш не кешировало хочется сделать
<php_code no_cache=true> <?php $img_src_hash = md5($_SERVER['REMOTE_ADDR']); ?> </php_code> <img_src='get_img.php?hash=<?=$img_src_hash?>' some more HTML
однако тут надо обратить внимание на то, что get_img.php?hash=<?=$img_src_hash?> запишется в кеш уже в выполненном виде, условно get_img.php?hash=322jjJ!…. , те ту часть, где надо выводить оперативные данные так же надо переносить внутрь и код должен быть
<php_code no_cache=true> <?php $img_src_hash = md5($_SERVER['REMOTE_ADDR']); ?> <img_src='get_img.php?hash=<?=$img_src_hash?>' </php_code> some more HTML
Вероятные ошибки
Нельзя включать <php_code no_cache=true> в другой блок <php_code no_cache=true>. Например,
<php_code no_cache=true> <?php $img_src_hash = md5($_SERVER['REMOTE_ADDR']); ?> some HTML <php_code no_cache=true> Another code </php_code> more HTML </php_code> some more HTML
В этом случае это очевидно, но может быть вариант
<php_code no_cache=true> <?php $img_src_hash = md5($_SERVER['REMOTE_ADDR']); ?> </php_code> <!--INCLUDE_TEMPLATE... some more HTML
в том темплейте который вы инклудите - так же есть <php_code no_cache=true>