Все пользователи MODX Revolution знают основной инструмент для работы с документами сайта - getResources. Возможности его почти безграничны, параметров и настроек хватает для любых ситуаций.
Однако, есть один неприятный момент: иногда скорость работы этого сниппета бывает недостаточной. Его нельзя назвать прям тормозом, но хотелось бы побыстрее.
Учитывая, что мы уже довольно давно используем pdoTools для разработки быстрых сниппетов в своих компонентах, написание аналога getResources было только вопросом времени.
И вот, наконец-то, новый сниппет pdoResources включен в пакет по умолчанию и является самым главным изменением в новой версии pdoTools. Поэтому, с него и начнем.
Это сниппет, написанный на pdoTools и входящий в состав пакета. Он предназначен для получения и вывода документов сайта и, насколько это возможно, повторяет функционал getResources.
Основное отличие - работа с ТВ параметрами: - Нет &processTVs=``
Особая работа с ТВ обусловливается тем, что все ТВ выбираются в том же запросе, что и ресурсы, то есть, используется &leftJoin=``. Все параметры с описаниями нужно смотреть вот тут.
Ну а теперь - про скорость!
Простая выборка из БД, без оформления, без ТВ параметров, чистый тест скорости получения данных. Вызовы сниппетов:
[[!getResources?
&parents=`2`
&limit=`n`
]]
[[!pdoResources?
&parents=`2`
&limit=`n`
]]
Результаты: | Limit | getResources | pdoResources | |---|---|---| | 10 | 0.1592 s | 0.1304 s | | 50 | 0.3502 s | 0.1495 s | | 100 | 0.5500 s | 0.1762 s | | 500 | 2.1891 s | 0.3045 s |
Благодаря работе через PDO и выборку всего необходимого в один запрос, pdoResources уверенно лидирует, особенно при больших объёмах.
Та же выборка, но с указанием чанка, в котором всего два плейсхолдера:
<p>[[+idx]] - [[+pagetitle]]</p>
Вызовы сниппетов:
[[!getResources?
&parents=`2`
&tpl=`tpl.Test.row`
&limit=`n`
]]
[[!pdoResources?
&parents=`2`
&tpl=`tpl.Test.row`
&limit=`n`
]]
Результаты: | Limit | getResources | pdoResources | |---|---|---| | 10 | 0.1721 s | 0.1384 s | | 50 | 0.3994 s | 0.1687 s | | 100 | 0.6915 s | 0.2047 s | | 500 | 2.7538 s | 0.4851 s |
Тут ситуация никак не меняется.
Добавляем 2 ТВ параметра в наш чанк и выборку:
<p>[[+idx]] - [[+pagetitle]].<br/>
[[+tv.meta_description]] [[+tv.meta_keywords]]</p>
Вызовы сниппетов:
[[!getResources?
&parents=`2`
&tpl=`tpl.Test.row`
&includeTVs=`1`
&includeTVList=`meta_description,meta_keywords`
&limit=`n`
]]
[[!pdoResources?
&parents=`2`
&tpl=`tpl.Test.row`
&includeTVs=`meta_description,meta_keywords`
&limit=`n`
]]
Результаты: | Limit | getResources | pdoResources | |---|---|---| | 10 | 0.2029 s | 0.1383 s | | 50 | 0.5014 s | 0.1747 s | | 100 | 0.8860 s | 0.2230 s | | 500 | 4.0989 s | 0.5248 s |
А вот тут pdoResources вообще выбегает за пределы стадиона, благодаря присоединению ТВ к основному запросу, а не отдельной выборке в цикле через xPDO.
Дальнейшие тесты проводить не вижу смысла, ибо в зависимости от чанков и условий выборки разрыв будет только увеличиваться.
Это достигается благодаря двум основным составляющим: 1. Выборка всего нужно за один запрос, через PDO. 2. Предварительная обработка чанков, когда значения из ресурса заменяются в чанке без парсера MODX.
Есть конечно и еще много разных оптимизаций\улучшений, но эти 2 - принципиальные. Именно они дают такой прирост производительности.
Обращаю ваше внимание, что это работа без fastMode и быстрых плейсхолдеров.
Внимание, это изменения, которые влияют на работу всех сниппетов pdoTools. То есть, новые свойства можно использовать и у miniShop2 и у Tickets!
Параметр sort теперь принимает массивы в виде JSON строк, например:
[[!msProducts?
&sortby=`{
"publishedon":"desc"
,"pagetitle":"asc"
}`
]]
Добавлена автоматическая замена имён ТВ в &where. Тут нужно немного пояснить: из-за того, что ТВ присоединяются к запросу в БД, используются псевдонимы, и при указании
&includeTVs=`test`
в запросе мы получаем
`TVtest`.`value` as `test`
То есть, для работы с присоединённым ТВ нужно было указывать вот такое условие:
&includeTVs=`test`
&where=`{
"TVtest.value:!=":"0"
}`
С версии 1.4.0 вы можете указать просто:
&includeTVs=`test`
&where=`{
"test:!=":"0"
}`
и замена в запросе будет произведена автоматически.
Новый метод pdoTools::defineChunk(), который позволяет назначить кучу чанков для вывода результатов, согласно логики getResources. Этот метод выдает имя чанка, используя параметры: &tplFirst - чанк для первой строки результатов &tplLast - чанк для последней строки результатов &tplOdd - чанк для каждой второй строки &tpl_N - чанк для n строки, например для 4й строки будет &tpl_4= &tpl\_nN - чанк для каждой n строки, например для каждой третьей будет &tpl\_n3=
Эта возможность не включится автоматически - для нее сниппеты нужно апгредить. Конечно, новый pdoResources это уже умеет.
В лог менеджеру теперь выводится потребление памяти. Не знаю, пригодится это кому то, или нет - но мне нравится. Для просмотра лога нужно быть авторизованным в админке у вызвать сниппет с параметром
&showLog=`1`
С версии 1.4.0, pdoTools стал не только библиотекой для написания быстрых сниппетов, но и гораздо более быстрой заменой getResources.
Текущая версия - бета. Возможны ошибки и недоработки, но уверен, вместе мы их поправим. В дальнейшем я планирую добавить сниппеты pdoMenu и pdoSitemap, которые, надеюсь, будут повторять функционал Wayfinder и GoogleSiteMap, только более быстро.
По GoogleSiteMap, кстати, уже есть наработки.
Список вещей, которые есть в getResources, но пока не реализованы в pdoResources: - @FILE и @INLINE чанки - не уверен, что кто-то этим пользуется
&toSeparatePlaceholders - тоже самое. (Появилось в 1.4.1)
&tvFilters - не реализовано, но работает при указании ТВ в &where, например
[[!pdoResources? &includeTVs=`test` &where=`{"test:!=":""}`]]
&sortbyTV, &sortdirTV и &sortbyTVType - не реализовано, но работает при указании сортировки в обычном &sortby, например:
[[!pdoResources? &includeTVs=`test` &sortby=`{"test":"desc"}`]]
&prepareTVs, &prepareTVList, &processTVs, &processTVList - этого нет, и скорее всего, не будет.
&debug - есть гораздо более мощный и удобный &showLog=1
&sortbyAlias, &sortbyEscaped - не знаю, зачем они.
&tplCondition, &conditionalTpls и $tplOperator - чанки с условием, в документации не описаны, но скорее всего - сделаю. (Появилось в 1.4.1)
Всё остальное в наличии.
Часто при работе использую tpl_N, tpl_nN — не всё вместе, но всё таки. То есть шаблон для конкретного ресурса, или каждого n-ого ресурса. Добавите?Фильтры работают в чанках?Если с getPage работает, то результаты очень хорошие! Вы молодец, Василий!
UPD: в магазине не указаны параметры tpl_N и tpl_Nth, в посте есть.
А как их указать? Ведь таких параметров нет, а могут быть &tpl_4, &tpl_4th и т.п.
Фильтры и getPage, как и у всех остальные pdoTools сниппетов - работают.
Также, как и в посте. По моему мнению, этого вполне достаточно.
Спасибо, что радуете расширениями.
Там параметры выводятся прямо из сниппета. Если они в нем не прописаны - их нет и на странице.
Это позволяет не следить за их актуальностью, все обновляется само, вместе с пакетом. Подумаю, как это улучшить, в будущем.
А если указать их в сниппете в закомментированном виде?
Садых, не выноси мозг.
Если можно было бы так сделать - сделал бы. У getResources они тоже не указаны.
Мне для переезда помню не хватало tvFilters, обошелся вот таким -
а если прикрутить оригинальные операторы:
то будет полноценная замена
Зачем, если это можно писать прямо в &where=``?
Просто попробуй, и напиши, что именно не работает. Учитывая, что запрос один, я не вижу смысла делать отдельный параметр для фильтрации по ТВ. Разве что, для более плавного перехода с getResources.
В общем, пока под вопросом.
Да, для более плавного перехода и было сделано, да и проще(привычнее) это чем каждый раз писать все это в where. К тому же не надо лезть в сниппет, достаточно подредактировать вызов.
Не нужно лезть в сниппет, &where=`` задается снаружи.
Чуть более сложный пример:
И можно даже так, напрямую:
На мой взгляд, это интереснее, чем &tvFilters.
Аааа, да, согласен, к тому же можно применять CAST, что иногда необходимо, так что единственное преимущество моего вариант именно легкость переезда. К тому же стоит упомянуть что конструкцию 'TV'.$filter[0].'.value' придумал сам, поскольку нигде нет никакой документации о том как делать фильтрацию по тв параметрам через pdoTools.
Ну, ты же видишь, что в нашем случае ТВ - это просто поле выборки из приджойненной таблицы. Если это знать - никаких особенных инструкций не нужно, просто фильтруй по этому полю.
В getResources ТВ обрабатываются отдельно, там такой параметр необходим.
Василий проверь сортировку при Asc ... чет чудит помоему/ p.s. пардон это я накосячил)
а в "sortby" автозамены ТВ нету? В mSearch2 работает если просто указать ТВ, а в pdoResources только если "TVtest.value" (ну по крайней мере у меня)
Насколько я понимаю, тут автозамена не нужна, ибо сортировка ведется по извлекаемому полю, у которого уже есть псевдоним.
По нему и сортируем, вот рабочий пример:
пишу так:
ресурсы не выводятся и в error.log получаю вот что:
Но если напишу "TVdate.value" то всё ок..
Не знаю, почему у меня работает, видимо уже что-то накрутил на сервере. Ну или версии ПО разные.
В любом случае - обновляй пакет, теперь автозамена включена и в сортировке.
У меня &sortby=
TVимятвшкиt.value
работает при фильтрации, а &sortby=имятвшки
- нет ("пустой лист"), но при этом меня такой вариант очень даже устраивает))В версии 1.4.0 beta1 уже должно работать.
Всегда можно вывести лог (&showLog=
1
) и там будет видно, какой реальный запрос отправляется в БД. Если в нем ошибка - то она будет в логе сайта.Ну и можно скопипастить и проверить запрос самостоятельно, в phpmyadmin.
Братья и сестры! Я сейчас сойду с ума! Заменил getProducts на pdoResources и скорость возрастала с 4 секунд первой загрузки до 1.5 и из кэша render time: 0,6472 s При этом ни одна TVшка не пострадала. Василий! Ты сотворил чудо! Офигеть)))
Очень рад!
Не, ну в 3 раза!!! Вот где Revolution!
Скорее, вот где прямые руки!
... вот в эти прямые руки Василия отправлю ка я >, как ниже сказано "в похрустывающем эквиваленте")))
tplLast , tplFirst надо ... нужная штука при оформлении каталогов ..ибо черезщ css3 невсе браузеры понимают last irstChild модификаторы, да и четный не четный элемент Tpl тоже бывает нужен.
Заметку прочитай, параметры сниппета посмотри.
а бля )) пардоньте много букав не осилил действительно все есть)
Вот это славные вести, Василий, вери биг сенкс!
П.С. Сегодня-завтра зашлю спасибо и в похрустывающем эквиваленте.
П.П.С. И всем советую так сделать/делать, хоть по паре-тройке сотенок в месяц - кто что может. Не жмотьтесь, подерживайте, нам же самим выгодно-полезно, чтобы Василий не сайтики делал, а MODX Revo развивал.
Если что: всё в П.П.С. ИМХО, никого не хотел обидеть.
Напишу-ка я сюда.. Василий, в списке параметров к pdoTools в магазине есть такой момент, цитирую:
Т.е. неизвестно какой плейсхолдер-то) Система его вырезала.
[[+output]]
Спасибо!
Many thanks for developing this. In initial tests pdoResources has improved page load times considerably. Will be trying a wider implementation tomorrow.
You are welcome!
Are conditional templates currently supported?
getResources functions &tplCondition and &conditionalTpls ?
At this moment - no. You is the first, who asked about it.
Отличный скрипт, увеличил производительность в 1.5 раза по сравнению с getProducts Еще бы сделать pdoWayfinder и тогда цены бы не было, готовые решение из одной коробки) А так большое спасибо за активное развитие modx revo )
На здоровье!
Спасибо большое ) не знаю как другим но мне не хватает параметра - показать родителя в результате выборки, как &displayStart в Wayfinder...
А у getResources такое есть?
нет, в Wayfinder только..
Ну вот и ответ.
Нетривиальный вопрос:
Необходимо достать таблицу, с пагинацией результатов. Все прекрасно работает, однако если к этой таблице приджойнить другую (к каждому элементу из первой соответствует несколько элементов из второй таблицы), то пагинация нарушается. Есть догадка, что нужно вторую таблицу не джойнить, а за каждую итерацию добавлять новый запрос через pdotools, тогда пагинация будет правильно работать.
Как действует вездесущий гуру в таких ситуациях?
Смотри в лог на предмет ошибок.
У меня ни с джойнами, ни с пагинацией проблем нет - вот реальный пример.
Полагаю, группировка нужна. Это параметр &groupby=``
группировка "съедает" все результаты, с одинаковым группируемым столбцом (http://www.sql-ex.ru/help/select4.php#group\_by) это не то... а так да, пагинация начинает работать
Ну так группировать можно по разным столбцам, не так ли?
Если тебе нужны все строки из второй таблицы - нужно группировать по ней.
у меня ТРИ коробки. лежат в 1й таблице во 2й таблице сведения о том что в ПЕРВОЙ коробке находится: 1.1 пустота, 1.2 вакуум во ВТОРОЙ 2.1 шайба, 2.2 шпилька, в ТРЕТЕЙ лежит 3.1 зажигалка и 3.2 сигареты. если я джойню эти таблицы - у меня в результате 6 строк. если я группирую по айди то выводятся только результаты 1.1, 2,1, 3,1 (в результате 3 строки) а мне нужно вывести в таком формате 3 строки: строка1: коробка ПЕРВАЯ, содержимое коробки 1.1, 1,2 строка2: коробка ВТОРАЯ, содержимое коробки 2.1, 2,2 строка3: коробка ТРЕТЬЯ, содержимое коробки 3.1, 3,2 т.е. чтобы каждая строка содержала подробные сведения о коробке.
В таком формате нужны дополнительные запросы или самостоятельный разбор данных.
Напиши для этого случая свой сниппет, используя pdoTools, он изначально так и придумался.
не получилось запустить 2 pdoTools - один внутри другого, а сверху getPage. Похоже не хватает гибкой настройки как у RowBoat:
(http://rtfm.modx.com/display/ADDON/Rowboat.Rowboat)
Так и появляются рассказы "о тормознутости" Revolution, от таких вот извращений.
если честно, хотелось бы сделать просто рабочий скрипт, а потом либо его оптимизировать, либо доплатить до лучшего тарифа на вдс"ке. через один сниппет не получается, а через сниппет => чанк => сниппет работает, но через раз, причем при четком указании параметров
и
у вложенного
Сделай 1 сниппет, а внутри него:
Это схематично, но принцип должен быть понятен.
немного не понял -) но вся эта писанина всетаки натолкнула на правильную и тривиальную мысль как запустить два pdotools без джойна. единственно что бы хотелось - замена стандартному
в режим "fastmode"
Даже без fastMode это работает быстрее, чем обычный modX::getChunk();
Василий привет. Подскажи а pdoResources можно вывести изображения товара minishop, по аналогии как ты писал для imageGallery? спасибо!
Нет, нужно использовать сниппет msProducts, работающий на том же pdoTools.
Здравствуйте. Есть вот такая проблема, не знаю уже, как решать: Есть объект имеющий свойства (в лк указывает, пишется в introtext через ||), до 200 свойств. Есть пользовательский фильтр - список чекбоксов (свойств объекта, до 200, соответственно). Гетресом, через сниппет пихнутый в where передаём выбранный массив и хотим получить список объектов имеющих отмеченные свойства, но кроме первых двух свойств не видит он, т.к. в json получаем вот это: [{"AND:introtext:LIKE":"%1%", "OR:introtext:LIKE":"%2)%", "OR:introtext:LIKE":"%3%", "OR:introtext:LIKE":"%4%", "OR:introtext:LIKE":"%5%",}] Уже понятно, что он видит только два, т.к. для него в массиве выше, по факту, только 2 пары ключ-значения, первая строка AND и OR. Пихнуть что-то типа "OR: "1":introtext:LIKE":"%2)%" не получится вроде как, PDO не кушает такое. Может можно как-то решить задачу при помощи pdoResources? Или я что-то не так делаю? Сориентируйте, пожалуйста.
Само по себе так хранить 200 параметров - это, конечно, не очень удобно.
У тебя выходит массив с одинаковыми ключами. Хорошо, что в параметр можно передать массив с готовой строкой:
Для контроля правильности запроса нужно использовать &showLog=
1
Спасибо, Василий, помог Ваш pdoResources (гетрес такой материал не кушает, в этом корень проблемы был)!
Ура!
Здравствуйте! Подскажите пожалуйста, как с помощью pdoResources выводить media tv с правильными путями? ситуация такая: по умолчанию используется источник файлов с basePath /files/. при использовании pdoResources и подключении tv, путь до изображения/файла указывается относительно папки /files/, т.е. например: images/img1.jpg, а не /files/images/img1.jpg. как можно выводить правильный путь, кроме как писать сниппет для исправления пути?
pdoTools работает с базой напрямую, без всяких преобразований - отсюда и скорость.
Нужно путь в чанке:
с этим понял. решил так: сделал сниппет, который возвращает путь с фиксом, что бы например для изображения можно было применить phpthumbof например.
Этот метод выдает имя чанка, используя параметры: ... &tpl_Nth — чанк для каждой n строки, например для каждой третьей будет &tpl_3th=``
Так не работает, работает как у getResources: &tpl_nN — чанк для каждой n строки, например для каждой третьей будет &tpl_n3=``
Спасибо, поправил.
Василий, столкнулся с тем, что при переходе с getResources на pdoResources пропали выводы даты. У pdoResources другие плейсхолдеры?
Они не пропали, ты скорее всего юзаешь [[+publishedon:strtotime:date=``]]
Так как pdoResources работает с чистыми данными в БД, то он и так получает timestamp, поэтому нужно [[+publishedon:date=``]].
Есть такое.
Спасибо!
По образу параметра tpl_nN очень не хватает параметра tplWrapper_nN - обертывать каждые N ресурсов. Подобные обертки часто используются в различных слайдерах.
Сортировка больших чисел (в моем случае миллионов), ведет себя как-то странно... Заменил DECIMAL(10,3) на DECIMAL(12,3)- стало нормально
Поди не туда написал, это актуально с версии 1.5
Если хочешь это изменение в новых версиях - пиши.
ага, отписался
1
Василий добрый вечер! Не смог найти выход из одного момента... Можно заставить pdoResources вывести только не опубликованные ресурсы? А точнее решить бы этот момент с msProducts.
Легко!
Шикарно, спасибо большое! Немного поясню, зачем это надо, может быть кому то пригодиться. Любому сеошнику должна быть известна аксиома, чем больше страниц на сайте, тем лучше (почему и как, это другая тема). Так вот, некоторые товары устаревают, снимаются с производства и т.д., их надо убрать, но при этом сама страница выходит из индекса. Простой и удобный способ убрать страницу при этом оставив ее поисковикам, это сделать раздел под названием например, "архив", где и будут собираться все товары, срок реализации которых закончен (два зайца одним ударом).
Василий здравствуйте!
Не могу разобраться как работает pdoResource с тв параметрами множественного выбора с условием вывода html tag в теле основной страницы тв параметры выводятся верно значение1 значение2 значение3 А вот в родительском ресурсе выводятся так значение1||значение2||значение3 то есть в обход выбранного варианта вывода. вывод в родителе:
вывод в дочке:
Что я делаю не так?
Не читаешь документацию?
Как так то? Выше аж целых 2 раза упомянается про отсутствие этого параметра в принципе:
но спасибо, что на самом деле он есть)
Ничего, что заметка про версию 1.4, а в репозитории 1.9?
Смотри документацию, а не старые заметки.
Здравствуйте Василий. Подскажите пожалуйста как сделать выборку по tv с типом date Пробовал:
сам сниппет
но не выводит ничего. пробовал и через &where, но так как мучаюсь с этим уже 3 или 4 день как именно не вспомню.
Спасибо огромное! Действительно, кешированный вызов я и не пробовал. единственное что, не выводит сегодняшнюю дату, но с этим решу.
И ещё один надеюсь последний вопрос, работает ли pdoResource с плагином tagLister? tagLister использует вывод getResource а вызов на одной странице pdoResource и getResource
практически останавливаеточень тормозит загрузку страницы.Без понятия.
Но pdoResources может заменить getResources в 99% случаев - так что, проверяй.
Здравсвуйте! с tagLister обломились так как этот плагин сам по себе не подходит под требования. Но речь не об этом.
(немного введу в курс дела) Суть такова: Есть афиша, есть дата начала мероприятия(всегда заполнено), и дата его завершения(заполняется если это не однодневное мероприятие). Мероприятия бывают разные Фильмы, Выставки, Вечеринки, Концерты
pdoResource вызывается на странице 4 раза каждый в своем блоке соответствующий where для всех один
!today:
!tomorrow:
в общем выборка работает отлично, выводит только те мероприятия которые проходят "сегодня" с 0:00:00 сегодня до 0:00:00 завтра.
Проблема в следующем: после выборки, ресурсы начинают выводится не в своем блоке а везде, или не выводиться. Если where поставить только в 1 из 4ех блоков, или же выводить без выборки вовсе, то в все нормально, а если во всех то беда. &parents у каждого блока естественно свой.
проблема в множественном вызове? или я опять что то делаю не так? Извините за столь частые вопросы. Просто мне как верстальщику ну очень сложно разобраться =(
1. В сниппетах MODX не нужно использовать echo:
2. Условие лучше задать через BETWEEN:
Возможно, после этого заработает как надо.
если обе даты заполнены выводит по блокам правильно если есть только дата начала то пихает во все блоки...
то есть он по условию правильно делает выборку, берет все сегодняшние мероприятия или берет те у которых дата окончания больше сегодняшнего дня. но почему лепит в кучу понять не могу...
Все - разобрался корректно работает вот так
Спасибо за помощь =)
А мне вот очень очень нужно чтобы была возможность работы с @FILE и @INLINE чанками.
Заметка написана год назад. Уже давно всё есть - http://docs.modx.pro/components/pdotools/general-settings.
а почему же не работает?
Вот бы узнать.
я прошу прощения, не то чтобы я хотела обидеть вас ). это замечательно, что вы сделали pdoTools. и да, я не программист, ни каким боком, потому использую готовое решение.
Подскажите мне вот что, я вызываю сниппет следующим образом
и у меня ничего не происходит на странице а если поставить
, то просто вываливается массив со всеми данными. Что я не так делаю?
Василий, можете подсказать что я не так делаю?
Разобралась в чем дело. 1. Сниппет не хочет работать с чанками типа @FILE 2. Я почему-то ждала, что в первом уровне будут выводится все внтуренние ресурсы со всех уровней, но этого не происходит.
Так почему @FILE не работает? у меня самый свежий пакет pdoRecources и revo 2.3
И еще вопрос, как сделать так чтобы в самом каталоге выводились все ресурсы со всех уровней подкаталогов?
Заработало!
нужно было правильно указать путь к чанкам
и поставить глубину больше нуля
без косых кавычек
когда-то давным давно, когда я работала с evo,
0
обозначал бесконечную глубину, почему здесь не так?Я же не зря ссылку дал на документацию.
Потому что это не Evo. Глубина 0 означает выбрать только прямых потомков ресурса в системном методе modX::getChildIds().
Спасибо за разъяснения про modX::getChildIds(). Этого я не знала. И я все-таки рано радовалась. У меня так и не заработал шаблон из чанка @FILE. Я указала путь, но забыла указать сам файл, так что чанк брался из базы. Что же все-таки не так в моем вызове шаблона-чанка из файла?
И да, документацию я изучила вдоль и поперек еще до того как сюда написала, но все равно спасибо.
Ну конечно, вдоль и поперек.
Вызов сниппета:
Файл в корне сайта /test.tpl
Вызываем - и, как ни странно, работает!
странно, теперь работает. извините за оторбранное у вас время, чувствую себя дебилом ), спасибо.
Магия.
зато я могу подсказать все, что угодно по верстке и дизайну :), обращайтесь ).
Василий здравствуйте! pdoResources выдает ошибку на выборке из 3-х ресурсов: Could not process query, error #1104: The SELECT would examine more than MAX_JOIN_SIZE rows; check your WHERE and use SET SQL_BIG_SELECTS=1 or SET MAX_JOIN_SIZE=# if the SELECT is okay
С чем это может быть связано?
Ошибка возникает при подключении более 9 TV-параметров.