Здравствуйте!
18 метров файл… Как раз сегодня ночью импортировал 15-тиметровый XML. Правильно ли я понимаю, что у вас там 1C-формат? По цене: файл большой, на отладку уходит много времени с такими. 10 000 будет строить настройка импорта (в стоимость уже входит наш компонент modImporter, он 3000 стоит). Возможна настройка импорта по крону.
У меня например сработало только после добавления % &tvFilters=`newsidebar==%onet%`
Есть файл.xml(висит на ftp каждый день обновляется) Нужно сделать импорт категорий и товаров в модкс, и желательно с последующим обновлением этого каталога.
Не интернет магазин. Сколько будет стоить такое дело?
Прочитал XML ~500 килострок, создал записи для 191 категории с вложенностями и обновил 4+ килострок товаров, указав им их категории.
Совсем коротка заметка, но может много кому пригодиться.
Возникла задача импортировать каталог со стороннего ресурса, и там используется авторизация. Простой запрос по УРЛу типа protocol://user:pass@host/path/ не прошел. Вот решил заюзать для этого родной MODX-овый cURL-клиент. Оказалось все очень просто:
$filename = 'test.txt'; $path = MODX_BASE_PATH; $file = "{$path}{$filename}"; $user = 'user'; $pass = 'xxx'; $url = 'http://some.host'; $url_path = "/export/v2/catalogue/{$filename}"; $client = $modx->getService('rest.modRestCurlClient'); if( $result = $client->request($url, "/export/v2/catalogue/{$filename}", 'GET', array(), $params = array( modRestClient::OPT_USERPWD => "{$user}:{$pass}", )) AND file_put_contents($file, $result) ){ print_r($result); // Debug } else{ print "Не удалось скачать файл" }
Надо сделать расширенный фильтр, как здесь — www.fl.ru/projects/
При чём надо подобным образом в админке присваивать нужную подкатегорию в карточке и на лицевой стороне сайта фильтровать подобным образом Может у кого есть какието соображения? доработать существующее расширение или же придётся с нуля писать? Заранее спасибо за советы )
В любом случае, у вас есть какая-то точка сохранения. Если это плагин — значит надо просто передать в вызов нужные данные. Если у вас отдельный интерфейс на все это, в любом случае, у вас есть и коннекторы/процессоры на прием данных и выполение логики, а значит в импортере выполняется вызов этих процессоров. Самый плохой вариант, который встречался в моей практике — это использование магазином компонента, который не имел процессоров на создание данных для нового объекта. То есть там по логике сначала создается документ обычным способом и для него сразу создаются записи-остатки с нулевыми значениями, а потом остатки обновляются через отдельный интерфейс, при чем надо указывать не только id документа, но и id конкретной записи-остатка, передавая туда и конечное значение остатка. Вот тут уже пришлось работать с объектами напрямую. Но это крайне редкий случай. В большинстве своем достаточно вызова процессора с передачей всех необходимых данных.
1. Не поймите меня не верно, я ни разу не пытался принизить возможности Вашего импортера. Я даже на 100% уверен что он очень хорош) 2. Такой вариант не подойдет, я не буду делать TV для каждого размера, поэтому храню все в отдельной таблице. Размерный ряд моделируется динамически. И также подхватывает в фильтр абсолютно все размеры имеющиеся в категории или поиске.
Наша аудитория на имопртер — это не те, кто умеет писать импортеры, и это не один человек. Но спрос есть. Не было бы спроса — не было бы предложения.
он учтет мои размеры, он знает где лежит база с остатками?
Нет, сам не догадается. Ему надо будет прописать $object->setTVValue($id, $value); Но это все, что надо будет сделать в этой области. Сам механизм импорта от этого переписывать не придется.