Видимо вопрос был не корректный) просто хотел услышать твое отношение к расширение админки через фронт. А про «не все реализуемо», это конкретно мной не все, я достаточно слабо знаю extJS, и времени затрачу больше, хотя я тоже считаю, что через апи админки это правильнее сделать.

Я не знаю какую ты цену берешь и за сколько времени ты сделаешь для них то, что они хотят, потому ничего не могу тебе сказать на счет рентабельности. На счет не все реализуемо: странное предположение. Мне совсем не ясно что можно во фронте сделать такого, чего нельзя сделать в бэкэнде. Не нравится родное редактор документов — напиши свой. Плюс ко всему во фронте многие элементы придется писать самому с нуля, а в админке практически все необходимое есть. Но это так, мысли вслух. Разговор ни о чем, так как нет четких задач, а одни рассуждения. Но и в конкретику не готов вдаваться сейчас. Обсуждение написания или ненаписания альтернативы админки — слишком большая тема, чтобы на нее кучу времени тратить и бесплатно обсуждать.

Привет, Николай! Сейчас собираюсь писать редактор товаров на frontend'е (Полностью ajax для ускорения работы). Все же через админку это делать нереально, клиенты постоянно ругаются. Как считаешь, это рентабельная идея или лучше потратить время на проработку адмики? С моим знанием extjs времени займет очень много, и не все скорее всего реализую.

На стороннем магазине столкнулся вот с таким случаем: некоторые товары (которые раньше были заведены как тип Товар) были переделаны в обычные документы, то есть их тип ресурса был изменен на Документ. Вот этого нельзя делать. Основная причина заключается в том, что когда создается новый документ-товар, для него создается сопутствующий объект ShopmodxProduct. И этот допобъект не только содержит необходимые данные, но и является главным критерием для отличия товаров от основных документов, то есть в процессоре web/catalog/products/getdata таблица товаров джоинится к выборке и если для документа есть запись в этой таблице, значит этот документ — товар. По этой причине на данном сайте документов-товаров сейчас меньше десятка, а выборка товаров возвращает 5 десятков товаров. Табличный редактор товаров тоже видит их пять десятков. Для тех, кто все-таки эту ошибку допустил, публикую скрипт для чистки (удаления лишних записей товаров). Имейте ввиду, что записи с этими товарами так же удалятся из заказов. <?php print '<pre>'; ini_set('display_errors', 1);

$q = $modx->newQuery('ShopmodxProduct');

$q->innerJoin('modResource', 'Resource');

$q->where(array( "Resource.class_key:in" => array("modDocument", "modWebLink"), ));

print $modx->getCount('ShopmodxProduct', $q);

foreach($modx->getIterator('ShopmodxProduct', $q) as $product){ $product->remove(); }

Сорри, нет времени на это. Вряд ли появится в обозримом будущем. Да и нечего в админке делать всем подряд.

Пожалуйста. Но вот использовать зарезервированные поля под хранение данных, не для которых они были созданы — это не правильно. Хотите в ресурс сохранять, изучайте эту статью: habrahabr.ru/post/253737/

Автору респект!!! В голову не приходило что так можно сделать, нарадоваться не могу. Но вот не люблю создавать лишний раз тв, пришла идея записывать превью в неиспользуемое поле, например introtext или link_attributes. Сниппету каталога не придется обращаться к тв за картинкой, тем самым еще больше ускорим загрузку. В php я не силен, сделал как смог, поправьте говнокод, буду очень признателен) $TV_source = 3; $target = 'introtext'; $resource = & $scriptProperties['resource']; $photo = $resource->getTVValue($TV_source);

    if($photo){
        $thumb = $modx->runSnippet('phpthumbon', array(
            'input'     => $photo,
            'options'   => 'w=113&h=115&q=100&zc=1',
        ));
        $resource->set($target, $thumb);
        $resource->save();
    }

Не за что.

у вас виртуальный сервер или сайт уже на реальном сервере? в любом случае проверьте настройки php в файле «php.ini», а именно — строчку «memory_limit». У меня недавно такая проблема была и это помогло. тоже только начал)

Спасибо!