This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision | ||
ru:tcms_update_1 [2017/08/19 03:51] admin [Page_main_tag and Return 404] |
ru:tcms_update_1 [2022/12/28 12:01] (current) admin [Search Log Advanced Queries] |
||
---|---|---|---|
Line 1: | Line 1: | ||
+ | **Update 1** | ||
+ | |||
+ | ====== Rotation ====== | ||
+ | |||
+ | ===== Page_main_tag and Return 404 ===== | ||
+ | |||
+ | Есть фича "URLs with 0 result thumbs return 404" общий смысл которой заключается в том, что если у вас есть например 100 тумб, и пагинация по 20, то это 5 страниц. При запросе 6й страницы (например если вручную подправить URL), поскольку тумб для заполнения страницы не будет - скрипт выдаст 404 и покажет темпелйт content_not_found | ||
+ | |||
+ | Так же есть параметр для тага page_main_tag=true, | ||
+ | |||
+ | Получаем следующий пример, | ||
+ | |||
+ | < | ||
+ | < | ||
+ | category template | ||
+ | </ | ||
+ | |||
+ | |||
+ | <thumb num=1-20 search_log=all > | ||
+ | search template (< | ||
+ | </ | ||
+ | |||
+ | |||
+ | <thumb num=1-20 > | ||
+ | regular thumb template | ||
+ | </ | ||
+ | </ | ||
+ | |||
+ | |||
+ | Например, | ||
+ | |||
+ | Опция URLs with 0 result thumbs return 404 Включена. | ||
+ | |||
+ | Итак, в оригинальном варианте на 6й странице у нас возникает вопрос: | ||
+ | |||
+ | Добавим указание какой таг основной | ||
+ | |||
+ | < | ||
+ | <thumb num=1-20 search_log=all page_main_tag=true> | ||
+ | search template (< | ||
+ | </ | ||
+ | |||
+ | <thumb num=1-20 > | ||
+ | regular thumb template | ||
+ | </ | ||
+ | </ | ||
+ | |||
+ | |||
+ | теперь скрипт будет ориентироваться на search_log и на 6й странице выдаст 404. | ||
+ | |||
+ | Если же сделать <thumb num=1-20 page_main_tag=true> | ||
+ | |||
+ | |||
+ | И еще одна ситуация в которой нужен этот таг. | ||
+ | |||
+ | < | ||
+ | < | ||
+ | category template | ||
+ | </ | ||
+ | |||
+ | |||
+ | <thumb num=1-20 search_log=all > | ||
+ | search template (< | ||
+ | </ | ||
+ | |||
+ | </ | ||
+ | |||
+ | |||
+ | Например, | ||
+ | |||
+ | Тут есть как минимум 2 варианта того, что мог хотеть в данном случае дизайнер. Возможно это страница где выводятся поисковые запросы, | ||
+ | |||
+ | С другой стороны возможно search_log это | ||
+ | |||
+ | ===== Toplist ===== | ||
+ | |||
+ | Новая возможность для трейда топлистом. | ||
+ | |||
+ | Идея следующая: | ||
+ | |||
+ | < | ||
+ | <thumb num=1-3></ | ||
+ | тумба трейдера | ||
+ | <thumb num=3-6></ | ||
+ | еще 2 тумбы трейдеров и тд | ||
+ | </ | ||
+ | |||
+ | таким образом можно не делать выделенный топлист и даже поставить ским 100. | ||
+ | |||
+ | Проблема была в том, что для того, что б вывести 1 или 2 тумбы трейдеров надо было делать большое кол-во темпелйтов топа и потом их инклудить в нужном месте темпелйта. Сейчас трейдеров можно выводить прямо в темплейте в нужном кол-ве. | ||
+ | |||
+ | < | ||
+ | <thumb num=1-3></ | ||
+ | |||
+ | <trader num=1> < | ||
+ | |||
+ | <thumb num=3-6></ | ||
+ | |||
+ | <trader num=2-3> < | ||
+ | </ | ||
+ | |||
+ | |||
+ | Итого внутри тага <trader можно использовать | ||
+ | |||
+ | < | ||
+ | < | ||
+ | < | ||
+ | < | ||
+ | < | ||
+ | < | ||
+ | < | ||
+ | < | ||
+ | < | ||
+ | < | ||
+ | </ | ||
+ | |||
+ | |||
+ | Возможные параметры для тага | ||
+ | |||
+ | < | ||
+ | <trader num=1 .... > | ||
+ | num = номер трейдера, | ||
+ | |||
+ | order = сортировка, | ||
+ | |||
+ | </ | ||
+ | |||
+ | Вариант сортировки priority нас интерисует в первую очередь для трейда, | ||
+ | |||
+ | |||
+ | ===== Custom Gallery From A List of Images ===== | ||
+ | |||
+ | Добавлена возможность создавать кастом галеры указывая список картинок, | ||
+ | |||
+ | ===== Category Boost \ Separate Thumb CTR ===== | ||
+ | |||
+ | Тестовый вариант разделения ЦТР для каждой тумбы в категории. | ||
+ | |||
+ | Rotation Settings - Test settings - Boost gallery CTR in category, % | ||
+ | |||
+ | Смысл в том, что в каждой категории ЦТР галеры увеличивается пропорционально кол-ву кликов в категории, | ||
+ | |||
+ | Например у тумбы 10 показов и 1 клик на индексе, | ||
+ | Boost = 50%, общий ЦТР при выводе тумбы на индесе либо без указания категории (1+2+3)/10 = 0.6 | ||
+ | |||
+ | Для категории А (1+2*1.5(boost)+3)/ | ||
+ | |||
+ | Для категории Б (1+2+3*1.5(boost) )/10 = 0.75 | ||
+ | |||
+ | |||
+ | В данный момент это работат только при использовании magic rotation parameter. | ||
+ | |||
+ | |||
+ | ===== Animated Gifs ===== | ||
+ | |||
+ | Добавлена возможность создания анимированных gif файлов для видео что нонче модно для сайтов в стиле пинтерест. | ||
+ | Для использования надо: | ||
+ | |||
+ | - убедиться что у вас на сервере стоит mplayer and ffmpeg и прописать пути в rotation - settings | ||
+ | - добавить галерею с видео (URL) либо сразу урл к видео (FLV URL) и добавлять в preload | ||
+ | - после процесинга в preload 1 можно кликнуть на лубую тумбу и откроется страница редактирования тумбы с плеером и добавленным видео | ||
+ | |||
+ | Можно сделать скриншот с любого момента видео. Либо Сделать там же анимированный гиф любой продлжительности и рейта. Обратите внимание, | ||
+ | ===== Prefix encodehtml2js===== | ||
+ | |||
+ | Добавлен префикс для тагов, которые превращает любой html в закодированный JS код. Наиболее вероятное использование - кодирование ембед кода. Например, | ||
+ | |||
+ | < | ||
+ | |||
+ | исходный вариант | ||
+ | |||
+ | < | ||
+ | |||
+ | можно заменить на | ||
+ | |||
+ | < | ||
+ | |||
+ | </ | ||
+ | |||
+ | |||
+ | ===== Sphinx config ===== | ||
+ | |||
+ | Тк была изменена база немного поменялся конфиг сфинкса | ||
+ | |||
+ | < | ||
+ | |||
+ | sql_query = SELECT gi.gallery_id, | ||
+ | (SELECT group_concat(tag_name) FROM rot_gal2tag g2t \ | ||
+ | LEFT JOIN rot_tags as t on t.tag_id = g2t.tag_id \ | ||
+ | WHERE g2t.gallery_id = gi.gallery_id) as tags, \ | ||
+ | (SELECT group_concat(gss.group_id) FROM rot_gallery_stats1 as gss \ | ||
+ | WHERE gss.gallery_id = gi.gallery_id AND group_id != 0) as categories \ | ||
+ | FROM rot_gallery_info AS gi \ | ||
+ | JOIN rot_gallery_data1 AS gd ON gi.gallery_id = gd.gallery_id \ | ||
+ | JOIN rot_gallery_stats1 AS gs ON gs.gallery_id = gi.gallery_id \ | ||
+ | WHERE gallery_status = ' | ||
+ | and gs.best_thumb = ' | ||
+ | |||
+ | |||
+ | sql_attr_timestamp = date | ||
+ | sql_attr_uint | ||
+ | sql_attr_uint | ||
+ | sql_attr_float | ||
+ | sql_attr_uint | ||
+ | sql_attr_uint = gallery_id | ||
+ | sql_attr_multi = uint categories from field; | ||
+ | </ | ||
+ | |||
+ | |||
+ | |||
+ | |||
+ | ===== Search Log Advanced Queries ===== | ||
+ | |||
+ | В скрипте давно уже есть фича по выводу последних поисковых фраз | ||
+ | |||
+ | <thumb num=1-10 search_log=all ... | ||
+ | | ||
+ | Она выводит лог последних поисковых запросов на вашем сайте. Но сейчас она стала более продвинутой. Теперь можно искать related запросы к текущей странице. Например, | ||
+ | |||
+ | <thumb num=1-10 search_log=all filter=GET_group_name | ||
+ | | ||
+ | На странице тага можно фильтровать по имени тага | ||
+ | |||
+ | <thumb num=1-10 search_log=all filter=GET_tag | ||
+ | |||
+ | На странице поиска можно фильтровать по поисковому запросу | ||
+ | |||
+ | <thumb num=1-10 search_log=all filter=GET_search | ||
+ | |||
+ | Тут надо напомнить что в параметрах то что начинается с GET_ - это переменные из запроса (из урла). | ||
+ | |||
+ | По умолчанию результаты сортируются по кол-ву поисков по конкретному запросу, | ||
+ | |||
+ | <thumb num=1-10 search_log=all filter=GET_search order=items_found | ||
+ | <thumb num=1-10 search_log=all filter=GET_search order=hits | ||
+ | |||
+ | Таким образом на каждой странице создаются линки на другие страницы и общее кол-во страниц на сайте растет. | ||
+ | |||
+ | Конечно, | ||
+ | | ||
+ | Для примера, | ||
+ | |||
+ | 1. тк запросы были взяты из общих источников оказалось что по части запросов в базе ничего не находит. Таким образом была вероятность получить на странице ссылку на которой было 0 результатов поиска. Что бы решить этот вопрос rotation.php, | ||
+ | |||
+ | php rotation.php check_search_queries=true | ||
+ | |||
+ | 2. когда в базе немного поисковых запросов то Mysql справляется без проблем с ними. Однако когда добавили 2М запросов то поиск по такой таблице стал тяжелым и для индексации решили добавить Sphinx - это сделало не только быстрым поиск, но и сам поиск более продвинутым. Что бы добавить Sphinx надо в конфиг сфинкса добавить | ||
+ | |||
+ | < | ||
+ | |||
+ | source search_queries | ||
+ | { | ||
+ | type = mysql | ||
+ | |||
+ | sql_host = ........ | ||
+ | sql_user = ....... | ||
+ | sql_pass = ........ | ||
+ | sql_db = ...... | ||
+ | sql_port = 3306 # optional, default is 3306 | ||
+ | |||
+ | sql_query_pre = SET NAMES utf8 | ||
+ | |||
+ | sql_query = SELECT sq_id, search_query, | ||
+ | |||
+ | sql_attr_uint | ||
+ | sql_attr_uint | ||
+ | |||
+ | } | ||
+ | |||
+ | |||
+ | index search_queries_index | ||
+ | { | ||
+ | source = search_queries | ||
+ | path = / | ||
+ | docinfo = extern | ||
+ | morphology | ||
+ | } | ||
+ | |||
+ | |||
+ | |||
+ | </ | ||
+ | |||
+ | После этого сфинкс сможет проиндексировать имеющиеся у вас запросы. | ||
+ | |||
+ | Что бы SmartCJ смог начать использовать этот индекс надо его указать в настройках ротации Sphinx Search , поле Sphinx Search Log Index = search_queries_index | ||
+ | |||
+ | Все. | ||
+ | |||
+ | |||
+ | ===== Search query limit ===== | ||
+ | |||
+ | На сайте может быть масса вариантов лимитирования поиска, | ||
+ | |||
+ | /? | ||
+ | может превратиться в | ||
+ | /? | ||
+ | или | ||
+ | /? | ||
+ | | ||
+ | и так далее, варианты могут быть разными и комбинированными, | ||
+ | |||
+ | Например, | ||
+ | Добавляем в урл search_query_limit=teen, | ||
+ | |||
+ | при выводе <thumb search_log=all num=1-20> | ||
+ | |||
+ | <thumb search_log=all num=1-20 search_query_limit=teen> | ||
+ | | ||
+ | Можно подставлять & | ||
+ | |||
+ | <thumb search_log=all num=1-20 search_query_limit=GET_your_param> | ||
+ | | ||
+ | **Языковой поиск** | ||
+ | Аналогично можно сделать разделение поиска по языкам что бы выводить на соответствующих языках. Скрипт сам не определяет на каком языке написано конкретное предложение, | ||
+ | |||
+ | |||
+ | domain/? | ||
+ | domain/? | ||
+ | domain/? | ||
+ | domain/? | ||
+ | |||
+ | |||
+ | Таким образом у нас у базе для каждого поиска будет отмечено на каком языке он сделан. Добавлять параметр не составляет труда прямо в темплейте, | ||
+ | |||
+ | В темплейте добавляем | ||
+ | |||
+ | <thumb search_log=all num=1-20 search_query_limit=GET_your_param> | ||
+ | | ||
+ | и открываем страницу как domain/? | ||
+ | |||
+ | test,test1 | ||
+ | |||
+ | |||
+ | тк на них стоит пометка | ||
+ | ===== Subcategories and filter keywords ===== | ||
+ | |||
+ | Небольшая поправка в распределении по субкатегориям (те когад категория является подкатегорией корневой категории, | ||
+ | |||
+ | Вопрос возникает когда надоо импортировать что-то, | ||
+ | |||
+ | Поэтому поправка заключается в том, что если при импорте выделено filter keywords (alt+desc) И (!!!) рут категория, | ||
+ | |||
+ | те для нашего примера по кейворду red она попадает только в субкатегорию cars -> red | ||
+ | |||
+ | |||
+ | ====== Trade ====== | ||
+ | |||
+ | ===== Overclick skimming hold ===== | ||
+ | |||
+ | Допустим у нас ситуация, | ||
+ | |||
+ | |||
+ | ===== Incoming TDS ===== | ||
+ | |||
+ | Для входящего траффика можно указывать список правил, | ||
+ | |||
+ | |||
+ | ===== Auto lock traffic in trade groups ===== | ||
+ | |||
+ | Автоматически и прозрачно, | ||
+ | те если условно трейдер А в трейд группе 1, то все клики пришедших с него серферов будут распределны в пределах группы 1, как если бы автоматически в урле всегда было & | ||
+ | |||
+ | Находится настройка в Settings - Traffic Rules | ||