Василий Наумкин

Через несколько дней придется за деньги просить кого-то из сообщества создать такой компонент.

Компонент Office делает так из коробки и умеет еще много чего дополнительно.

Не знаю, зачем нужно писать новый компонент.

Да и разместив его на главном репозитории и на modstore.pro, увеличится популяризация как этого сообщества, так и MODX в целом.

Нет, не увеличится, проверено много раз.

По вашему компоненту Tickets тоже будет не мало «хотелок», не сложных, но важных. Сейчас, пока, собираю их в кучу, скоро буду к Вам стучаться!

Вряд ли я чем-то смогу помочь, у меня работа расписана до следующего года.

Да, на этот раз виноват не MySQL, а PHP. Разбираюсь, принимаю меры.

Понимаю, что это звучит глупо, но сэмулировать такое никак не получается, поэтому читаю логи и пытаюсь понять, как такое могло выйти.

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

Так мы и делаем это на каком-нибудь фреймворке — MODX.

Если вдруг (вдруг) с ним что-то случится, то уже сделанные решения всё равно будут работать, никуда не денутся.

Если есть желание тащить на себе альтернативную ветку — в добрый путь. Я не потяну.

Но вот где выставить время их хранения? Найти не могу. Нужно что бы лежали «вечно» пока их либо не удалят, либо не оформят.

Товары хранятся в сессии. Пока жива сессия, в ней будут лежать товары.

Параметры сессии живут в настройках системы.

Я и так много всего рассказываю, но вот конкретно про внутреннее устройство нашего закрытого коммерческого проекта рассказывать не очень хочу.

Мне кажется, ты должен это понять.

Только что получил донат от, по всей видимости, первой продажи сборки блога.

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

В методе getChunk его просто негде указывать, но можно написать свой сниппет, который будет запускать pdoTools, менять в нём tplPath и возвращать $pdoTools->getChunk(имячанка);

Дальше всё примерно так же:

{$chunk = $_modx->runSnippet('getChunk', [
	'chunk' => 'mychunk.tpl',
	'tplPath' => '/my/path/'
])}

Конечно:

{$chunk = $_modx->getChunk('@FILE my_chunk.tpl')}

Файл my_chunk.tpl должен лежать в MODX_ASSETS_PATH. 'elements/chunks/', то есть, по умолчанию, в /assets/elements/chunks/.

С одной стороны, может и непривычно, но зато правильно — ведь фильтруются товары, а не категории, и ты видишь сколько всего остаётся именно товаров.

В принципе, можно расширить и переписать все фильтры, чтобы выводились цифры категорий, но это очень трудозатратно и бессмысленно. Гораздо лучше и скрыть это дело, чтобы никого не смущать.

Категорий обычно не очень много, так что показ предсказаний им не нужен.

Не подскажу.

Напиши мне письмо на bezumkin@ya.ru

Это я о том, что нигде не видел никаких ограничений на путь для загрузки конфига.

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

As I see, resource2formit checks resource id in the $_GET array, but you specifying it in the parameter &resId. And you specifying not an id, but link to current resource.

So, you need to remove &resId from FormIt call and load edit form with an id at the $_GET. For example, your link for create a new resource can be

http://mysite.com/ad/resource

And for update it must be:

http://mysite.com/ad/resource?resId=15

Than you need to fix your snippet resource2formit. Just replace

else {
		if ($field == "[[+fi.IMAGE]]" & $docarray[$field] !== null) { 
			$hook->setValue($field,$docarray[$field]);
		}
	}

to

else {
		$hook->setValue($field,$docarray[$field]);
	}

After this your snippet will set [[!+fi.id]] placeholder and you will be able to update an existing resource.

Нет, не должен.

За 5000 рублей могу написать и выложить сегодня готовое решение.

Конфиг nginx можно разделять на разные файлы.

Да, у меня складывается ровно такое же впечатление, потому что кроме тебя больше этот вопрос никто не поднимает.

Моё личное мнение, что если тебе настолько важно качество и размер фотографий, то лучше подготовить файлы самостоятельно, а не швырять всё подряд с iPhone и надеяться на лучшее.

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

bezumkin.ru/sections/components/2903/

Все pdoTools сниппеты стараются выбрать данные за один запрос. Соотвественно, для генерации меню сначала выбираются все нужные ресурсы, а уже потом строится дерево.

Через это получается, что ограничить размер подменю можно только после выборки, когда в этом уже нет особого смысла. Просто что-то скрыть, для красоты, но скорости это не даст. Если так нормально, то да, Fenom поможет.

А если нужно именно экономить ресурсы сервера на сложных меню, то я бы посоветовал написать свой уникальный сниппет, который решит конкретно эту задачу. Типа, выбрать везде всё, а вот в подменю с id = 10 только первые 5 ресурсов.

Если непонятен мой вопрос, повторяю еще раз: зачем пережимать уже загруженный оригинал?

Ресайз на клиенте нужен для экономии времени и трафика, а что экономит пережимка на сервере?
Если нужно мега-качество, то просто отключи пережимку на клиенте.