Максим

Мне сегодня как раз пришла в голову та же идея, хотя именно для ms2Gallery я ее удачной не считаю (: Но у меня есть отличие — $timestamp записывается в отдельную таблицу modx_temporary_ids, а при сохранении ресурса удаляется. Это как раз позволит решить проблему «если менеджер загрузил 200 файлов и ушел гулять»: при входе в админку просто удаляем записи из modx_temporary_ids (и связанные файлы), которые старше чем время жизни сессии.

Поддержал и я немного в WMR.

поделитесь, кто как справляется с этой непосильной задачей?

Я писал расширение для catalogFill, но не могу сказать, что получилось хорошее решение. Работать работает, но по-хорошему нужно основательно переделать.

Если таблица MyISAM, то можно сбрасывать запросом:

ALTER TABLE имя_таблицы AUTO_INCREMENT = 1

Так рисунок может браузер кэширует? Тогда можно попробовать что-нибудь типа image.jpg?4654654

А зачем мне оригинал, повернутый не так как надо?

У тебя сейчас пережимка при загрузке, а потом еще пережимка при создании превью.

У меня получается меньше операций — 1 поворот оригинала, а превьюшки ворочать уже не нужно. Кроме этого, если не трогать оригинал, то в базу попадут неправильные размеры картинки, которая повернута на 90 градусов.

Если речь о потере качества, так она уже случилась, когда ресайзил браузер перед загрузкой — и то, много ли людей увидят эти потери?

Опять же ворочать можно через jpegtran, тогда потерь при повороте не будет вообще, заодно можно и дополнительное сжатие сделать. Или вообще поворачивать на клиенте, а тут уже мешает plupload.

В общем, проблема решается минимум двумя способами — кому актуально, тот пусть сам и решает как лучше.

Тогда будет создаваться папка с названием x и в ней уже повернутая картинка — из метода saveThumbnail(). Для других превью придется дописывать «ar»:«x» и править заодно window.gallery.js — чтобы там картинка тоже переворачивалась. Тоже не очень хорошо.

Не такая и проблема поворачивать по EXIF автоматически при загрузке. Я делал некрасивый хак в файле core/components/ms2gallery/processors/mgr/gallery/upload.class.php перед строкой $product_file->save():

if ($product_file->get('type') == 'image') {
	require_once  MODX_CORE_PATH . 'model/phpthumb/modphpthumb.class.php';
	$phpThumb = new modPhpThumb($this->modx);
	$phpThumb->initialize();
	$image = MODX_BASE_PATH.$url;
	$phpThumb->setSourceFilename($image);
	$phpThumb->setParameter("ar", "x");
	if ($phpThumb->GenerateThumbnail()) {
		$phpThumb->renderToFile($image);			
	}
}

А на картинке-то вордпресс (:

А версия PHP случаем не ниже, чем 5.3?

Сталкивался не раз на хостингах заказчиков; проблема в том, что на сервере включен mod_security (или его аналог). Пишите в поддержку, чтобы отключили или откорректировали правила.

www.markhamstra.com/xpdo/2011/preparing-custom-snippets-for-getpage/

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

Как ни крути, pdoTools не может быстрее работать, чем чистый xPDO, без которого сам pdoTools работать не может. Он может кому-то быть удобней в использовании, но не быстрее, потому что к выполнению первого варианта еще плюсуйте кучу методов отсюда, а второй вариант — конечный.

Это я и хотел сказать, но за разъяснение нюансов все равно спасибо.

Но факт останется фактом — pdoTools никогда не будет работать быстрее и более гибко, чем чистый xPDO. Это можно даже тесты не проводить.

pdoTools это же просто библиотеки для разработки компонентов, что тут тестировать-то. Их или используют, кому это удобно, или не используют для разработки своих компонентов. Я не использую, ты тоже не используешь — ни хуже, ни лучше они от этого не становятся. А если кто-то пишет вместо слова getResources слово pdoResources и радуется разнице, то что в этом плохого? Ты же не думаешь, что количество скачиваний pdoTools означает, что столько людей используют их для разработки?

Как-то не совсем я корректно ответил. Во втором случае от xPDO только формирование запроса, не хватает getCollection.
Ну и fetch(PDO::FETCH_ASSOC) лучше было бы заменить на fetchAll, а потом пройтись по массиву, как в первом случае. Так условия для сравнения были бы ровнее (:

А вопрос — откуда разница такая берется, так? Из метода $pdoFetch->run(), который кроме запроса в базу выполняет еще различные операции. Опять же в первом случае метод вернул массив, по которому прошлись для вывода pagetitle, во втором случае данные сразу отправляются из результата запроса на вывод. Тут уже сами решайте, какой способ для вашей задачи по выводу pagetitle лучше.
P.S. Второй способ у вас — PDO, а не xPDO.

Есть еще такое исправление, пока не принятое: github.com/Qwarble/revolution/commit/df1902d5b68e02d760842c19f3a6e647f38ff6ab

В общем, придумал я такое решение.
В папке /core/components/msearch2/custom создаем файл custom.class.php:

<?php
class _mse2FiltersHandler extends mse2FiltersHandler {
    public function filterNumber(array $requested, array $values, array $ids) {
        $requested = array_diff($requested, array(''));
        return empty($requested) ? $ids : parent::filterNumber($requested,$values,$ids);
    }
}

В настройках указываем обработчик фильтров: _mse2FiltersHandler
Теперь если ms|price ничему не равен, то выведутся все товары.

Тут не все так просто. Для конкретной ситуации такой костыль сойдет, но лучше и правильнее сделать, как написал Василий (т.е. расширить класс).

Попробуйте в сниппете mFilter2 добавить в самом начале строку $_REQUEST = array_filter($_REQUEST);