Наверняка много кто пользуется компонентами типа phpThumbof. Компонент действительно очень удобный, но имеет несколько минусов:
1. Формируемые пути к картинкам имеют всякие примеси (типа md5-хеша пути к файлу, параметров всяких и т.п.).
2. При изменении каких-либо параметров модификации изображения, меняются и формируемые ссылки на картинки, что как бы убивает генерируемые картинки. А это почти неизбежно при смене дизайна сайта (как один из вариантов).
Самое плохое в этом — плохое отношение поисковиков к таким картинкам. Вот буквально вчера выяснилось, что на одном сайте целый раздел с большим количеством картинок не проиндексирован вообще, и это при том, что разделу несколько месяцев. Причем другие картинки, которые имеют абсолютные пути (о чем и пойдет речь в этом топике), проиндексированы, то есть речи о том, что сайт не индексируется в принципе нет.
Итак, задача: формировать пути на картинки таким образом, чтобы они были как бы абсолютные, и при изменении любых параметров ресайзинга (или даже компонента, выполняющего эту функцию), пути никогда не менялись бы.
В этом нам поможет .htaccess с функцией подмены УРЛов.
Если у вас не используется Apache, то вам нужно будет прописать правила подмены для своей версии веб-сервера.
У меня вот такие правила прописаны:
RewriteEngine On
RewriteBase /
# Картинки
RewriteRule ^images/resized/big/(.*)$ assets/components/gallery/connector.php?action=web/phpthumb&w=1200&h=800&zc=0&far=0&q=100&src=$1
RewriteRule ^images/resized/thumb/(.*)$ assets/components/gallery/connector.php?action=web/phpthumb&w=150&h=150&zc=1&far=0&q=100&src=$1
То есть когда на сервер выполняется запрос в разделы images/resized/big/ или images/resized/thumb/, то УРЛы обрабатываются, подменяются, и запрос фактически отправляется на коннектор компонента Gallery (да, в нашем случае необходимо установить компонент Gallery, но если вы используете для таких целей какой-то другой ресайзер, можете его использовать).
На самом деле мне не очень понравилась идея использовать Gallery для этого, так как в MODX-е ведь есть родной коннектор для этого, и можно его использовать, передав в него параметром ctx имя контекста, к которому пользователи имеют доступ (по умолчанию web). Имейте ввиду, что если у пользователя не будет доступа к этому контексту, то ему будет возвращено 401 (ориентируйтесь особенно на анонимов). Вот такая строчка получилась:
RewriteRule ^images/resized/thumb/(.*)$ connectors/system/phpthumb.php?&ctx=web&w=150&h=150&zc=1&far=0&q=100&src=$1
Ну а далее уже дело техники: в шаблоне набиваете картинки, подставляя префиксом свой фейк-путь. У меня это вот так выглядит:
<ul class="gallery">
{foreach $object.gallery as $gal_item}
{$image = $gal_item.image}
<a class="highslide thumb" href="images/resized/big{$image}" rel="prettyPhoto[_company{$object.id}_]">
<img src="images/resized/thumb{$image}" title="{$gal_item.title}" alt="{$gal_item.title}">
</a>
{/foreach}
</ul>
Как делать выборки из Gallery, я писал совсем недавно. А если вы используете MIGX или типа того для хранения своих галерей в TV-шке, вот так у меня выглядит расширенный getdata-процессор, который сразу набивает эти данные в массив документа.
И еще момент: я использую prettyPhoto, и чтобы каждый раз его с собой не тянуть и вообще особо не заморачиваться с его подключением, я использую компонент DirectResize (у него сразу три галерейки в комплекте идет). Правда его тут есть такой момент, что он подключает JS-ы только если находит в документе картинки, которые будет ресайзить, поэтому чтобы JS-ы подключались всегда, я создаю копию оригинального плагина, в нем делаю мелкую правку, а оригинальный деактивирую.
Пример работы всего этого можно увидеть здесь: http://gorodskie-bani.ru/. И вот такие пути к картинкам формируются:
gorodskie-bani.ru/images/resized/thumb/assets/images/companies/1275-sokolinaya-gora/1%20%281%29.jpg
gorodskie-bani.ru/images/resized/big/assets/images/companies/1275-sokolinaya-gora/1%20%281%29.jpg
Много раз замечал, что документы товаров нельзя быстро обновить через дерево документов, то есть при вызове контекстного меню нет пункта "Быстро обновить". Так как понимал, что вряд ли я здесь виноват, не копал это дело. Но тут что-то надоело совсем и решил посмотреть где же подвох? Оказывается, виной служит свойство документа-товара public $allowChildrenResources = false; и логическая ошибка MODX-а. Вот посмотрите этот блок. Типа только если allowChildrenResources (разрешено создавать дочерние документы), то только тогда добавляются некоторые пункты, включая быстрое обновление документа. Ясное дело, что здесь логическая ошибка, ибо никакое отношение быстрое обновление самого документа не имеет к дочерним документам. Вроде как это поправили но не знаю, накатят они это и на MODX2.2, или только на MODX2.3. А пока, если кому не удобно, просто сдвиньте эту строчку за пределы условия и все, меню появится.
Еще в прошлом году я писал про работу с Gallery средствами xPDO. Считаю такой метод более гибким и прозрачным, так как вызывать сразу два сниппета, для которых править несколько чанков, чтобы получить какую-то галерею, по мне - это все как-то сложно. Все должно быть проще - сделал выборку картинок, набил их в конечный HTML как захотелось и все. В прошлом топике вероятно было все слишком сложно (зато все подробно изучено :)), а вот здесь я хочу просто выложить небольшое готовое решение - процессор на выборку картинок из галереи. Он не большой, расширяет getlist-процессор из компонента modxSite, легко вызывается в Smarty, где уже вы можете оформлять вывод как угодно.
Итак, сам процессор:
<php require_once dirname(dirname(dirname(dirname(__FILE__)))). '/site/web/getlist.class.php'; class modWebGalleryItemsGetlistProcessor extends modSiteWebGetlistProcessor{ public $classKey = 'galItem'; public function prepareQueryBeforeCount(xPDOQuery $c){ $c = parent::prepareQueryBeforeCount($c); $where = array(); $c->innerJoin('galAlbumItem', "AlbumItems"); $c->innerJoin('galAlbum', "Album", "AlbumItems.album = Album.id"); if($album_id = (int)$this->getProperty('album_id')){ $where['Album.id'] = $album_id; } if($where){ $c->where($where); } return $c; } public function prepareRow(xPDOObject $object) { $object->set('relativeImage', $object->get('relativeImage')); return parent::prepareRow($object); } } return 'modWebGalleryItemsGetlistProcessor';
У меня расположение файла процессора - core/components/modxsite/processors/web/gallery/items/getlist.class.php, отсюда и пляшем с именем класса и путями.
Пример вызова в Smarty-шаблоне:
{$params = [ "album_id" => 1, "limit" => 36 ]} {processor action="web/gallery/items/getlist" ns="modxsite" params=$params assign=result} <ul class="thumbnails"> {foreach $result.object as $object} {$image = $object.relativeImage} {$thumb = $modx->runSnippet('phpthumbof', [ "input" => $image, "options" => "w=100&h=100&zc=1" ])} <li > <a class="thumbnail" href="{$image}" rel="prettyPhoto[_{$object.id}_]"> <img alt="{$image.name}" src="{$thumb}"> </a> </li> {/foreach} </ul>
Возвращаемый результат из процессора (естественно количество элементов в object будет зависеть от количества полученных картинок):
Array ( [success] => 1 [message] => [count] => 2 [total] => 147 [object] => Array ( [0] => Array ( [id] => 238 [name] => DSC_0450.JPG [filename] => 64/238.JPG [description] => [mediatype] => image [url] => [createdon] => 2013-11-20 19:46:03 [createdby] => 1 [active] => 1 [duration] => [streamer] => [watermark_pos] => tl [object_id] => 238 [relativeImage] => assets/components/gallery/files/64/238.JPG ) [1] => Array ( [id] => 239 [name] => DSC_0439.JPG [filename] => 64/239.JPG [description] => [mediatype] => image [url] => [createdon] => 2013-11-20 19:46:04 [createdby] => 1 [active] => 1 [duration] => [streamer] => [watermark_pos] => tl [object_id] => 239 [relativeImage] => assets/components/gallery/files/64/239.JPG ) ) )
Вот и все, оформляем галерею как хотим. Так же очень удобно результат процессор отлаживать в модуле Console. Напомню скрипт для вызова процессоров с отладкой: https://gist.github.com/Fi1osof/328469331b5258ff009a.
Спасибо! Наверняка пригодится.
Отпишу тут ответы на вопросы, может кому пригодиться. Итааак, как и написано в документации процессоры ищутся в вышеуказанных папках. Рассмотрим такой вариант:
core/components/[yourpackage]/processors/mgr/[customfolder]/
[yourpackage] - это тот самый пакет который указывается в настройках MIGX на вкладке MIGXdb-Settings в поле Package
и вот далее, если в вашей схеме баз данных одна таблица или же, вы планируете работать только с одной таблицей или же вывод в админке только один (к примеру вы собираете несколько таблиц из БД в одну таблицу MIGX) то вы можете не переопределять [customfolder] а действительно ждаст копи процессоры из папки migxdb в папку default, где названия процессоров соответствуют действиям (например getlist.php вызывается когда нужно, как ни странно, получить список) и запрограммировать в них нужный функционал.
А вот если у вас несколько таблиц в админке которые выводят разные данные, вы можете указать Processors Path и этот путь будет подставляться вместо [customfolder] при поиске ваших процессоров.
Да, естественно. Попробую поподробнее познакомиться с Рево для начала, и станет понятнее.
Холиварить и я не буду. Но скажу просто: будете делать на Эво, не придется рассчитывать на помощь здесь, ибо в Эво технологии используются, с которыми мы уже давно не работаем. А далее уже все от вас зависит. И на сколько легким переход будет - тоже не знаю, так как зависит и от вашего текущего уровня, и от способностей к обучению.
Холиварить, я, конечно, не собирался. Передо мной стоит другая задача.
Медленно, но верно у меня зреет проект регионального сайта недвижимости. В общем-то, стандартный сайт, его особенность разве что в некоторых чисто маркетинговых нюансах подачи УТП сайта.
Я даже понемногу делаю прототип, на котором отрабатываю идеи юзабилити и понимаю встречающиеся трудности. Для реализации прототипа избрал Эво по по причине её изящества и минимального "входного порога" знаний.
И заранее начинаю думать - на чем реализовывать продакшн? Эво или Рево?
И если Рево - насколько лёгким будет дальнейший переход?
P.S. Объекты пока реализованы в дереве документов, их, наверное, потом придётся переносить в свои таблицы.
Число объектов предполагается... ну... максимум 5000, но ведь вы прекрасно понимаете, что при успешном старте проекта эти 5000 могут вылиться и 10, и в 20000, как вы совершенно резонно заметили в одном из своих топиков.
Вот и думаю.