Процессинг ТВ во всех сниппетах pdoTools включается одинаково:

&processTVs=`1`

А вот здесь вы, похоже, никогда не собирали действительно большие пулы запросов.

Возможно, сколько для вас будет много запросов?

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

думаю пару дней хватит

А вот здесь вы, похоже, никогда не собирали действительно большие пулы запросов.

Я по туризму собирал — 1,5 недели ушло. И это только одна страна.
Если бы было годных проксей с десяток — можно было бы и быстрее. Но проксей, даже приватных, за хорошие деньги, о которых не знает яндекс или гугл — не существует. Просто поверьте. А если они их знают — значит такие прокси забанены. И счёт времени по сбору СЯ растягивается на недели.
Можно, конечно, свой парк vds держать, но шибко уж дорогое удовольствие выходит для такой одноразовой задачи.

Плюс ключи надо пересортировать, выкинуть ненужное, разбить на группы, отсортировать по иерархии (чтобы потом на основе этого продумать структуру). А в кино-сериало-игро тематике ключей можно собирать бесконечно долго и бесконечно дохрена.
Такой подход оправдан для новых сайтов или сайтов, которым нечего терять и надо переделывать всё с нуля.

А у кг уже есть годное ядро. И ему есть что терять — с поиска народу ходит прилично.
Поэтому здесь надо улучшать то, что есть, а не стараться собрать всё, что можно, в конце концов так ничего и не доделав.

А задел на будущее будет всегда)

Так и живут.

Согласен, таких контор полно. Но они сами же себе могилу роют, постоянных клиентов не будет, а прогресс бежит вперед, при их торможении.

Я не знаю, в курсе вы или нет, но собирать СЯ под кино-сериало-игровой сайт обо всём — можно всю жизнь.

Ну не всю жизнь ))), думаю пару дней хватит, если кейколлектор загрузить только этим проектом. Да и как по другому то… можно упустить столько групп слов, что только на них будет хороший трафик без проблем при их нк.

Делать это в воскресенье вечером я желанием особо не горел))

Так все и не углядишь, вы и так дали очень много информации, не каждый так сделает.

*(т.е. даже НЕ 300-500 в месяц, а реально нулевые запросы)

Заказчик просто уверен, что «запрос» просто шикарный и именно его надо продвинуть в топ, а на деле оказывается, что кроме его самого такой «запрос» больше не кто и не ищет.

Это, кстати, не спроста. Именно за счёт этого и живут все эти бесчисленные seo-продвиженцы и конторы по «раскрутке сайтов».

Схема проста.
Менеджер впаривает будущему заказчику, что это очень крутые запросы, по которым на сайт передут 100500 посетителей. Радостный заказчик соглашается, и за 5-10-15 тысяч рублей в месяц (на моей практике были фирмы, которые и 150 т.р. платили) подписывает договор.

А по факту выясняется, что запросы эти липовые — частотность у них, дай б-г, 5-10 в месяц (т.е. даже 300-500 в месяц, а реально нулевые запросы), конкурентов нет.

И, чтобы продвинуть сайт по такому запросу, достаточно одного текста за 50 рублей и прописанные заголовки. Всё.

Если заказчик потом начинает догадываться, что его наё.ывают, то тут в ход идёт:
— либо харизма аккаунт-менеджера и заказчик продолжает жрать кактус;
— либо заказчик расторгает договор и платит неустойку (да, эти seo-конторы те ещё жуки, договора у них составлены хитрожопо в их пользу);
— либо, если сумма неустойки большая, заказчик продолжает жрать кактус и копить на неустойку.
Есть ещё варианты, но это основные.

Так и живут.

есть еще один важный пункт который хорошо бы упомянуть.

Я не знаю, в курсе вы или нет, но собирать СЯ под кино-сериало-игровой сайт обо всём — можно всю жизнь. Даже при наличии кейколлектора (который у меня, конечно же, есть). Делать это в воскресенье вечером я желанием особо не горел))

Но, конечно же, что это я тоже смотрел:

как вы собственноручно размываете семантику

Основная задача — структурировать (гхм) структуру сайта и избавиться от дублей всего и вся. Плюс оптимизировать распределение стат.веса. Это две самые главные задачи, с которыми мы разберёмся.
Исправить это — и можно неху.во поднять посещалку. По новостям, названиям фильмов и проч.
Дальнейшее добавление тематических разделов — дело техники.

Я продумывал структуру новостной ленты. Анализ остальной основной структуры сайта — ещё впереди.
Но и там всё не страшно. Там уже имеются посадочные под фильмы, трейлеры и прочие связанные вещи, разбитые по иерархии и страницам. Это очень хорошо.
Т.к. в СЯ запросы всегда иерархические, то добавить новых подразделов с жанрами или какие-то разделы к уже существующим уровням иерархии — дело той же техники (там главное с редиректами не ошибиться, но и с этим проблемы бывают редко).

Я исхожу из опыта и уже увиденного. Основное СЯ на сайте уже есть. Осталось его только усилить правильной тех.составляющей =)

Все, спасибо! разобрался! я ресурсы не опубликовал...))

Извиняюсь, не сразу понял, что TB — это Twitter Bootstrap.
Я сначала подумал, что имеются в виду ТВ (template variables) MODx =))

Через less можно исправить и подвести к нужному виду 90% TB, на мой взгляд это единственно верный путь работы с ним, чтобы не плодить тонны лишнего кода и всякие important. По поводу сеток всегда можно найти нужную и универсальную, теже 20 колонок дают и 5 и 2 и 4 одинаковых, а при использовании offset будет 3 колонки, учитывая более мелкий размер самой колонки в 1 будет все корректно и нормально отображаться

Вариант))

я извиняюсь если туплю, но ничего не выходит(

Ну 20 тогда или 30 :)

что касается pdoResources получил вот что

0.0002031: pdoTools loaded
0.0000529: xPDO query object created
0.0006790: Included list of tvs: user_id
0.0004389: leftJoined modTemplateVarResource as TVuser_id
0.0006521: Added selection of modResource: SQL_CALC_FOUND_ROWS `id`, `type`, `contentType`, `pagetitle`, `longtitle`, `description`, `alias`, `link_attributes`, `published`, `pub_date`, `unpub_date`, `parent`, `isfolder`, `introtext`, `content`, `richtext`, `template`, `menuindex`, `searchable`, `cacheable`, `createdby`, `createdon`, `editedby`, `editedon`, `deleted`, `deletedon`, `deletedby`, `publishedon`, `publishedby`, `menutitle`, `donthit`, `privateweb`, `privatemgr`, `content_dispo`, `hidemenu`, `class_key`, `context_key`, `content_type`, `uri`, `uri_override`, `hide_children_in_tree`, `show_in_tree`, `properties`
0.0000181: Added selection of modTemplateVarResource: IFNULL(`value`, '') AS `user_id`
0.0000470: Replaced TV conditions
0.0007989: Processed additional conditions
0.0013630: Added where condition: `TVuser_id`.`value`=1, modResource.id:IN(6,7,8,9), modResource.parent:IN(2,4,5,6,7,8,9), modResource.published=1, modResource.deleted=0
0.0000379: Replaced TV conditions
0.0001740: Sorted by modResource.publishedon, DESC
0.0000050: Limited to 10, offset 0
0.0003519: SQL prepared «SELECT SQL_CALC_FOUND_ROWS `modResource`.`id`, `modResource`.`type`, `modResource`.`contentType`, `modResource`.`pagetitle`, `modResource`.`longtitle`, `modResource`.`description`, `modResource`.`alias`, `modResource`.`link_attributes`, `modResource`.`published`, `modResource`.`pub_date`, `modResource`.`unpub_date`, `modResource`.`parent`, `modResource`.`isfolder`, `modResource`.`introtext`, `modResource`.`content`, `modResource`.`richtext`, `modResource`.`template`, `modResource`.`menuindex`, `modResource`.`searchable`, `modResource`.`cacheable`, `modResource`.`createdby`, `modResource`.`createdon`, `modResource`.`editedby`, `modResource`.`editedon`, `modResource`.`deleted`, `modResource`.`deletedon`, `modResource`.`deletedby`, `modResource`.`publishedon`, `modResource`.`publishedby`, `modResource`.`menutitle`, `modResource`.`donthit`, `modResource`.`privateweb`, `modResource`.`privatemgr`, `modResource`.`content_dispo`, `modResource`.`hidemenu`, `modResource`.`class_key`, `modResource`.`context_key`, `modResource`.`content_type`, `modResource`.`uri`, `modResource`.`uri_override`, `modResource`.`hide_children_in_tree`, `modResource`.`show_in_tree`, `modResource`.`properties`, IFNULL(`TVuser_id`.`value`, '') AS `user_id` FROM `modx_site_content` AS `modResource` LEFT JOIN `modx_site_tmplvar_contentvalues` `TVuser_id` ON `TVuser_id`.`contentid` = `modResource`.`id` AND `TVuser_id`.`tmplvarid` = 14 WHERE ( `TVuser_id`.`value` = '1' AND `modResource`.`id` IN (6,7,8,9) AND `modResource`.`parent` IN (2,4,5,6,7,8,9) AND `modResource`.`published` = 1 AND `modResource`.`deleted` = 0 ) ORDER BY modResource.publishedon DESC LIMIT 10 „
0.0000951: SQL executed
0.0001540: Total rows: 0
0.0000131: Rows fetched
0.0000210: Prepared and processed TVs
0.0000012: Returning processed chunks
0.0044611: Total time
17 301 504: Memory usage

В tvFilters, в отличии от where пишется не JSON, а специальная строка — смотри документацию.

В pdoResources можно так:

[[!pdoResources?
	&showHidden=`1`
	&tpl=`order`
	&includeContent=`1`
	&includeTVs=`user_id`
	&resources=`6,7,8,9`
	&showLog=`1`
	&tvPrefix=``
	&where=`{"user_id":[[!+modx.user.id]]}`
	&processTVs=`1`
]]

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

Интересно, а темная тема будет какая-нибудь? Вроде обещали.
А то от этой только глаза болят.

Сразу 12ти и 15ти колоночный макет будет работать?
Хотя при любом раскладе лично мне было бы очень интересно посмотреть на работу less с использованием ТВ.

Если просто сгенерировать 15-ти колоночный макет мы потеряем 12-ти колоночный, а он необходим, чтобы страницу, например, делить пополам: col-md-6 и col-md-6
По сути с этого я и начал.

Можно это сделать и без nginx — плагином на OnHandleRequest.

getbootstrap.com/customize/ Поменять @grid-columns на 15 и все.