User Tools

Site Tools

Translations of this page:

Sidebar

Documentation index

ru:new_rotation_faq

Table of Contents

New Rotation FAQ

Что такое реврайты mod_rewrite

mod_rewrite - это модуль для апача, которые позволяет делать “красивые” урлы. Тот же модуль есть и для nginx и для lighttpd.

Например, в дефолтных темпелйтах урлы примерно такие http://domain/gallery/cool-gallery/324kj43/index.html , понятно что реально на серваке таких урлов нет. Мот реврайт преобразовывает этот урл в http://domain/scj/tube/?content_id=324kj43 , а красивый урл - для СЕ и юзеров.

.htaccess который создается в самом начале задает правила реврайтов.

Попоытка просто объяснить как это работает:

И так, как было сказано выше /gallery/cool-gallery/324kj43/index.html такого урла реально на сервере нет. Что бы посмотреть галеру урл должен быть такой: /scj/cgi/out.php?url=content&content_id=324kj43, что не совсем эстетически хорошо. Поэтому мы в специальный файл .htaccess пишем реврайт - это специальное правило, как апач будет преобразовывать урлы. Для этого конкретнго случая у нас есть такой реврайт:

RewriteRule ^gallery/(.*)/(.*)/index.html$ /scj/cgi/out.php?link=images/%{QUERY_STRING}&url=content&content_id=$2

это значит, что если урл начинается с gallery/, а потом идет что угодно (.*) до знака /, а потом еще раз что угодно, и заканчивается это на /index.html - значит это наш случай. каждый из “что угодно” (.*) получает номера - соотв. первое “что-то” это $1 , второе - $2.

В нашем примере $1 будет равно cool-gallery, а $2 = 324kj43. Из этого $1 нам не надо, тк это просто для красоты, а $2 - это ИД галеры, вот именно он нам и надо. Соотвественно апач преобразует этот урл в /scj/cgi/out.php?link=images/тут_цифры_ротации&url=content&content_id=324kj43 и вы увидите галеру.

Урлы вида /gallery/cool-gallery/324kj43/index.html на страницах получаются потому что в сабтемплейтах страниц у вас записано что-то вида

href="/gallery/<!--SAFE_DESC-->/<!--GALLERY_ID-->/index.html

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

Почему в Rotation - Groups у меня показывает в группе 10 галер, а на странице сайта или Rotation - List thumbs 20

1 галера может находится в больше чем 1 групп (категории). Это видно в редактировании любой тумбы - у нее есть main группа (одна) и ext группы (много). Rotation - groups считает только по main. Это сделано что б было ясно сколько точно уникальных галер.

Например, у нас 2 группы А и Б. и 2 галеры - у одной main группа А, у другой main групра Б. Но у обоих в поле ext groups отмечены и А и Б. Rotation - Stats покажет что у нас конкретно 2 галеры , одна в группе А и одна в группе Б.

На сайте же в каждой из групп будет видно по 2 галеры.

Как сделать кастом галю из своего контента

Пока есть тестовый вариант:

  • создать папку scj/gallery/upload/1 (2, 3 и тп)
  • залить туда фотки\мувики названные 1.jpg,2.jpg и тп (1.avi, 2.avi)
  • при импорте указать на месте URL в патерне написать не урл гали, а название папки , например 1

Что такое Init cats в Rotation - Special или почему я добавил категорию в админке, а она не появилась на сайте

Пересчет категорий, а именно выбор лучшей тумбы категории и подсчет сколько же всего тумб в категории, довольно тяжелая задача для сервака, поэтому он это делает раз 15 минут по крону, кладет в кеш и все все остальыне части скрипта юзают кеш. Init cats - это принудительный запуск этой операции.

Если вы добавили новую категорию - она появится максимум через 15 минут, если надо быстрее - жмите эту кнопку.

What is cache

Скрипт не генерит статические 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 увидит в новом дизайне.

Cache Engines (New)

Базовый принцип работы движка - сгенерить нужную страницу, положить ее в кеш на определнное время и показывать ее пока кеш не проэкспарится. Какие движки есть на данный момент:

Файловый Базово кеш хранится в файлах (scj/cache - файловый кеш). Плюсы - он работает везде и сразу. Минусы - это именно файловый кеш, он он не так быстр, не так эффективно кешится системой как хотелось бы и приходится отдельлно заботиться о размере папки с кешем.

Memcached В свое время это конечно был большой шаг вперед в плане кеширования. Плюсы - все его знают, админы без проблем ставят на хостиинг, его просто администриировать и тп. Минусы - никакого понимания о реально занимаемой памяти получить практически невозможно, при перегрузке сервака весь кеш удаляется и нужен тн “разогрев кеша” те положить туда наиболее используемые данные. При перегрузке сервака из-за нагрузки это серьезная проблема - сервак и так нагружен, а тут еще и всесь кеш исчез.

Все данные одинаково прокешены - не важно это наиболее используемые или использзуемые раз в час - они все висят одинаово в памяти и сервис не умеет их скинуть на диск например.

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

Поэтому сейчас появились новые движки которые рекомендуются к использованию

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

Решение на которое наиболее просто перейти - Couchbase CouchBase - это продолжение MemBase, видимо ближайщего потомка memcachedb, который в свою очередь родом из memcached.

Главное - от вас не требуется практически никаких движений дабы начать его использовать. Вы ставите CouchBase и он работает точно так же как мемкеш. Те для того что бы начать его использовать надо

  1. попросить админа поставить CouchBase
  2. прописать в конфиге мемкеш
$config['memcached_host'] = '127.0.0.1';
$config['memcached_port'] = '11211';

и все, вы уже используете современную версию мемкеш. Вы можете это использовать даже с версией 48-49.

Чем это лучше чем memcached

  • Нет понятия “разогрев кеша”. По факту это файловый кеш,но сделанный на порядок правильнее, который намного меньше грузит диск, просчитывает когда и как лучше записать данные блоком на диск и тп. Данные при этом лежат как бы в нескольких файлах, а не сотнях файлов как файловый кеш.
  • Проэкспаренные данные исчезают с диска\памяти сами, не надо самостоятельно заботиться об этом.
  • Можно так же как и с мемкешем ограничить кол-во памяти выделенное под кеш, но при этом кеш не будет ограничен этим кол-вом. Даже если данных будет больше - оно оставит самые активные в памяти, а остальное сгрузит на диск. И подгрузить нужный элемент с диска - быстрее чем сгенерить его по новой.
  • Можно быстро и просто масштабировать систему из вебадминки
  • Можно легко завести несколько кешей. В варианте Couchbase - это как несколько мемкешей, но делается все опять же из вебадминки, что быстро и удобно. те можно завести например 10 кешей, каждый из которых будет на своем порту и просто указать для каждого сайта свой порт. В этом случае осуществиться желание о внопке “Удалить весь кеш” - вы сможете из вебадминки удалять весь кеш для одного сайта.
  • При перезде кеш легко скопировать поскольку копируется не масса мелких файлов как с файловым кешем, а одна база.

Redis - отдельный написанный с 0 проект NoSQL базы. Смысл его для наших целей практически тот же (в реальности couchBase это уже больше document oriented хранилище, а Redis - чисто key-value хранилище ). Для работы с ним функционал был добавлен в версии 50.

Для того что бы начать его использовать надо

  1. попросить админа поставить Redis
  2. попросить его же поставить модуль redis для пхп
  3. прописать в config.php
$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

  • Все теже плюсы и в случае couchbase.
  • Redis более заточенное под кеш решение, но у CouchBase готовая удобная админка (говоря о версии 2+).

Где хранится кеш ? (memcache)

По умолчанию используется файловый кеш (храниться в /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. файловый кеш не такой медленный как можно подумать. Смысл в том, что работа с ним эффективно кешируется системой и разница не глобальна, можно так же вероирть\поднять vnodes на серваке
  2. при этом кеш перманентно лежит на диске и в случае перегрузки сервера никуда не пропадет и скрипту не придется по новой генерить весь кеш по новой. Те ситуация такая: у нас много трафа, вдруг что-то пошло не так и мы перегружаем сервак. После поднятия сервака какая-то часть сайта уже есть в кеше и все продолжает работать, в случае же в мемкешем конечно весь кеш утерян и скрипту надо на лету создать массу страниц которые до этого лежалди в кеше, что опять создает нагрузку
  3. если вы все же ставите мемкеш - убедитесь, что ему выделено достаточно памяти. Сложно сказать конкретно сколько надо памяти, тк это прямо зависит от размера базы и веса шаблонов (в кеш кладет уже сгенерированную страницу, html), потому что как только законится доступная память - страницы будут генериться на лету.
  4. размер мемкеша должен быть достаточным, иначе данные будут “выдавливаться” из кеша. Например у нас кеш 10 метров, и есть 10 записей по 1 метру. Добавление еще одного в кеш - выдавит первый из кеша. Проблема тут в том, что у мемкеша есть понятие фрагментации памяти, когда даные занимают в реальности больше, чем говорит статистика. Мемкеш сохраняет грубо говоря блоками. Для простоты понимания если блок 100 байт, а мы сохраняем 1 байт, то репортит оно что занят 1 байт, но в реальности оно занимает 100 байт. Для скрипта проблема в том, что если вытесняются какие то данные то никакой ошибки мемкеш не возвращает и обработать такую ситуацию в скрипте невозможно. Примерно наблюдение - 15% фрагментация. Те если мнеьше 15% свободно - скорее всего память уже закончилась.

Почему rot.php выполняется так долго

Непосредственной работы там намного меньше конечно, однако в целях равномерного распределения нагрузки он работает минуту. Например, у нас стоит сграбить 3 галеры в минуту: скрипт грабит одну, спит 20 сек, грабит вторую - спист еще 20 сек, и грабит 3ю. Это помогает сделать нагрузку более равномерной.

Почему у меня в админке и на такой-то странице сайта тумбы стоят в разном порядке

При одинаковой сортировке порядок должен быть одинаковым с учетом следующих ньансов:

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 минут и кладется в кеш. Соответственно варианты:

  • нет активных тагов
  • не прошло 30 минут
  • вы прибили кеш

Тумбы (галереи) не удаляются

  • до 46 была проблема при удалении большого кол-ва тумб, например у спонсора 10к тумб, вы удаляете спона, скрипт пыдается это удалить сразу, но не успевает - получается таймаут. Это усугубляется если надо удалить не просто тумбы, а кастом гали.
  • начиная с 46 тумбы удаляются по крону. Те когда вы жмете в админке “удалить” тумбы не удаляются мгновенно, а переходят в статус 'Marked for deletion', раз в 10 минут крон смотрит есть ли такие и удаляет
  • если надо удалить “прямо сейчас” - запускаем rot.php с параметром process_deleted=true
  • cd /PATH_TO_/scj/bin/; env HTTP_HOST=yourdomain.com php rot.php process_deleted=true 
  • единственое исключение: если вы удаляете тумбы в Rotation - List thumbs и удаляется меньше 30 тумб - то удаление происходит сразу.

Скорость удаления гадер сложно прогнозируема и зависит от кол-во и нагрузки сервака, есть ли кастом гали, на текущем серваке они или на фтп и так далее.

Сколько надо траффика чтобы отротировать тумбы

Не обязательно отротировать все до конца, чтобы прода быда хорошая, но в целом посчитать сколько надо трафа очень легко.

Тумба считается отротированной, когда ее показали New thumbs timelive раз , по дефолту 500. Допустим на странице - 200 тумб, а % of test places on page по дефолту 15, те из 200 мест на старнице новые будут показываться на 30 местах. Те каждый заход на старницу это +30 показов для новых тумб. Например у нас 10 000 тумб, что б их отротировать нам надо 10000*500 = 5000000 показов. Одиз заход на старницу - это 30 показов, те что б отротировать базу в 10к нам надо 5М /30 = 167к загрузок страницы.

Изначально у 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.

How to turn a slave into a master

  1. Делаем дамп базы мастера
  2. Отсоединяем нужный слейв от мастера
  3. Заливаем туда этот дамп из пункта 1
  4. Смотрим в rot_linked_db номер слейва, который мы отсоединяем(Х)
  5. Удаляем все rot_gallery_stats кроме данного номера
  6. Удаляем rot_gallery_stats, а rot_gallery_statsХ переименовываем в rot_gallery_stats
  7. В rot_linked_db удаляем все записи кроме записи с ИД 0

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. Для этого и есть статус “Штфсешму” - это значит галера будет видна по прямому урлу, но тумбы этой галеры не будут в ротации. те попасть на нее можно будет только по прямому урлу. Этот статус можно выставить в импорт сете, который удаляет галереи.

Аналогичная опция есть у Gallery Checker.

Точный эффект от этого для СЕ - неизвестен.

Как импортировать очень большой дамп

Версия 2.* умеет добавлять большие файлы через importset самостоятельно (теоретически любого размера). Просто добавляете урл и он постепенно все добавит.

Для версии 1.* рекомендуется следующий вариант:

Например у нас есть задача импортировать много тысяч галерей, достаточно много что бы они не влезали в просто импорт (например сервер не успевает пройти их все по таймауту или размер POST ограничен и тп.). В Import Set так же добавить большой нельзя тк импортсет предполагает видеть какие-то апдейты, а не 100 000 новых галер постоянно. Одна из причин ограничений в ImportSets в том и заключалась, что люди добавляли массу импортсетов по 100к галер, которыя парсились постоянно все 100к * соклько там было импортсетов таких , это все проверялось в базе и таким образом создавало нагрузку на сервак.

Дабы импортировать большой файл равномерно и хорошо для сервака надо:

  • Создать и залить на сервак файл cut.php следующего содержимого
<?php

error_reporting(E_ALL & ~E_NOTICE);

if (!$_GET['file']) die("\n You have to pass file=... parameter in URL");
if (!file_exists($_GET['file'])) die("\n File {$_GET['file']} does NOT exists. Check path. ");
if (!is_writeable($_GET['file'])) die("\n File {$_GET['file']} is NOT writeable. Set 666 permissions. ");

if (!file_exists('./tmp.file') or !is_writeable('./tmp.file')) die("\n File tmp.file does not exists OR is NOT writeable. Set 666 permissions. ");

echo passthru("head -n500 {$_GET['file']} ");
if (!$_GET['test']) exec("tail -n +500 {$_GET['file']} > tmp.file; cp tmp.file {$_GET['file']} ");
  • Залить туда же дамп и поставить 666 на этот файл
  • Залить туда же пустой файл tmp.file и так же 666 на него
  • Добавить ImportSet с урлом http://yourdomain/path_to/cut.php?file=имя_файла_дампа&test=true
  • Нажать Test и распределить поля как надо.
  • cut.php выдает по 500 строк из большого дампа и урезает файл на эти же 500 строк. Таким образом каждый раз когда импортсет будет запрашивать новые строки - он будет получать по 500 строк, равномерно добавляя их в базу.
  • Наличие &test=true надо дабы в момент теста файл не обрезался на 500 строк. После тестирования &test=true надо убрать из урла те урл станет http://yourdomain/path_to/cut.php?file=имя_файла_дампа

Все.

Через какое-то время весь дамп будет добавлен и сам файл дампа станет нулевым по размеру и даже если вы забудете убрать его из импортсетов он будет выдавать пустой ответ и не будет нагружать сервер.

Как назначить разные категории разным тумбам одной гали

По структуре скрипта тумбы - это свойства галеры, и категории это свойства галеры, а не тумб. Таким образом в текущем виде назначить категории тумбам - нельзя.

Но существует обход этого ограничения - для этого надо тумбы одной галеры представить как тумбы разных галер. Такая возможность есть в Preload 2. Если вы выбираете разные группы для разных тумб одной гали - скрипт создаст дубликаты как бы этой гали, но с разными тумбами, атким образом считая каждую тумбу отдельной галей. Минус в том, что если вывестив се тумбы без групп - на страницу могут попасть разные тумбы одной гали, тк сейчас скрипт считает что эти тумбы разных галер.

Проделать такую операцию с уже добавленными тумбами нельзя.

eval()'d code

Если при заходе на любую страницу у вас пишет что-то вроде “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_%D0%B2_%D1%82%D0%B5%D0%BC%D0%BF%D0%BB%D0%B5%D0%B9%D1%82%D0%B0%D1%85

How to grab custom galleries

Иногда по какой-то причине вы не хотите делать другой сайт слейвом, а хотите сграбить кастом галеры с другого своего сайта, а например исходные урлы уже недоступны. При этом галеры у вас сделаны с картинками на отдельной старнице - в этом случае единственный вариант сграбить их это использовать Deep fetch. Проблема тут однако в том, что с таких страниц обычно стоят ссылка на страницы тагов, категорий и прочего, где очень много других тумб, в при deep fetch скрипт пытается их все скачать. Другой вариант - если на кастом галере есть какой-то ским. В этом случае такой граб может быть весьма длительным процессом.

Лучше сделать так:

  1. создайте отдельный темпелйт, например plain_gallery где все ссылки будут прямо на картинку, а не на отдельную страницу
  2. Rotation - export даст вам урлы вида http://domain/scj/tube/?content_id=0a5cf5010394ea3a0111f3cce9cca0b7
  3. в любом редакторе поиск\замена и у вас http://domain/scj/tube/?force_template=plain_gallery&content_id=0a5cf5010394ea3a0111f3cce9cca0b7
  4. и уже эти урлы отдаете на граб в другой скрипт

How to copy rotation info

Данные по ротации хранятся в таблицах rot_gallery_stats*, таким образом если вам надо скопировтаь данные по ротации с одного слейва на другой вам надо

  1. посмотреть какой ИД у слейва с которого копируем
  2. какой ИД слейва на который копируем
  3. скопировать(!) таблицу условно rot_gallery_stats2 в rot_gallery_stats3

Category tags does not work

Проблема обычно в использовании тага категории на страницах галеры, например <!–CATEGORY_NAME–>, при этом галера может иметь более одной категории и не ясно какую из них надо выводить. Поэтому используется либо таг вида <!–CATEGORY_1_NAME–> либо конструкция <groups … >…</groups>

Group Deactivation

Допустим у нас есть мастер на котором группы А и Б. Мы подключаем слейв на котором деактивируем группу Б. При выборке для слейва у нас есть 2 варианта:

  • выборка все галеры КРОМЕ группы Б
  • или все галеры из группы А

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

Дабы решить этот вопрос так, что бы можно было сделать оба варианта сайты скрипт работает так:

  1. если НЕ указана категория то выборка идет как “все галеры КРОМЕ группы Б” (те тут галера состоящая в обоих группах не попадает в выборку)
  2. если группа указана - то выборка идет по 2му варианту, те “все галеры из группы А” (те галера попадает в выборку)

Что это значит в реальных условиях: если у вас жесткое разделение и галеры из деактивированных групп вообще не должны быть - это вариант 1. Если разделение не жесткое и допустимо такое попадание то можно даже не деактивировать, а просто в common.php дописать $_GET['group_id'] = …; и будет постоянно включен лимит по группе.

Некоторые страницы могут быть сделаны таким образом, что автоматически их сграбить не получается. Например, если большая картинка открывается каким-то JS и тп. По мере возможностей мы стараемся сделать что бы граббер мог разбирать распространенные JS варианты, но сделать это на 100% невозможно.

В этом случае можно сделать тн гейт что бы преобразовать ее в более понятный вид:

Пример:

Условно у нас есть галера 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:

  • гейт получает урл фида, грабит его, обрабатывает каждую строку как галеру и добавляет поле с картинками для кастом галеры, те в данном случае гейт выдает дамп сразу в виде url|thumb_url|desc|image_list
  • мы добавляем в импорт сет сразу gate.php?url=http://sponsor/dump.php

Lazy load, load on scroll, pinterest and so on

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

Выглядит это так: условно темплейт 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>

Duplicate test thumbs

Проблема проявляется на базе где еще тумбы вообще не набрали цтр\показы: открываем страницу 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. Отсюда и повтор.

Как только база набирает немного цтр - получается что по цтр достаточно тумб что б набрать страницу и таким образом тумбы не повторялись.

ru/new_rotation_faq.txt · Last modified: 2017/09/05 21:15 by admin