sitecreator

Так в том то и дело, что заказчик сам пожелал ocStore 1.5.5.1.2. Заказчик опытный, это не первый его магазин на ocStore. Выбор версии движка был четко согласован - последняя версия ocStore, а 1.5.5.1.2 и есть последняя, все это прописывали, к номеру версии вопросов нет у заказчика. И я за три года работы с веткой 1.5.* (начиная с 1.5.4.1 в 2013-м) не встречал в дистрибутиве движка встроенного компонента по выгрузке yml. Нет его там, это совершенно точно. Возможно, что был года четыре назад в других версия и по определенной причине его не стали добавлять в новые сборки. Может быть несовместимость или бага/глюки тому причина.

вот это меня устроит. функционал полностью настроен в магазине, все необходимые таблицы есть.

И это правильный подход на мой взгляд. главное чтобы еще и картинки были к этому моменту скачаны и имели бы имена такие же как в файле парсинга. Иначе закачка картинок может превратиться иногда в песню... о-о-очень долгую. кстати, не знаю импортеров (модулей), способных переварить взаимосвязанные опции. Точнее, не приходилось это делать через модули импорта напрямую.

интересуюсь вполне конкретно. там взаимосвязанные опции. для разных цветов (опция) загружаются свои картинки (основная и дополнительные). артикул для каждой связки опций размер+цвет разный, не смотря на то, что карточка товара одна. В каком виде сможете предоставить информацию на выходе? интересуюсь вполне конкретно. Просто не хотелось бы потом услышать, что "там все сложнее..." В идеале - залить результат на сайт с работающими взаимосвязанными опциями.

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

обсуждаем мы именно то, т. к. топикстартер все равно ничего про донор не сказал. скажите, пожалуйста, вот это сделаете за 900 руб (?): bergamo*ua Товаров много, построение нестандартное. Загрузка не блещет скоростью. что-то меня смутные сомнения берут... сколько вам часов нужно для настройки самого парсинга в данном конкретном примере?

т. е. любой сайт за 900 руб? точнее, все товары с одного сайта. если не более 50000 товаров? Даже не знаю как вам это удается. т. к. даже при полной автоматизации копирование 50000 товаров может занять даже очень приличное время. 50 потоков ведь не любой сервер выдержит. а уж если еще опции взаимозависимы, да картинки к опциям аяксмом подгружаются..... И ежели этих картинок на десяток гигов.... то все равно 900 руб?

Не знаю как сейчас, но в 2013-м в этом модули никаким парсингом и не пахло. Парсингом в привычном понимании. Сомневаюсь, что сейчас что-то кардинально изменилось, ибо это был бы уже другой модуль. Но автор в описании пишет про парсинг. Опять же из своего опыта 2-х летней давности по этому модулю скажу, что и тогда многое заявленное автором работало вовсе не так как это можно было предположить из названия функций и фич. Неужели теперь им можно спарсить товары из магазина, на кастомном движке, т. е. не на Opencart или на сильно измененном Opencart? Сам работаю с парсингом. использую свои инструменты. И как же одно может помешать другому? Например, спарсил я все товары с картинками, атрибутами, опциями и т. д и т. п. Разместил эти товары на сайте заказчика. ну а дальше пользуйтесь сколько угодно какими угодно "Автоматическая обработка прайс-листов". Или "парсинг" - это по мнению определенной категории, вытаскивание данный из прайс-листа? Так это никакой не парсинг САЙТА. Парсинг сайта - это когда у вас есть сайт с товарами на неизвестном движке, и доступа к админке у вас нету, ибо не ваш это сайт. Вот перенос с сайта всего (с созданием категорий, производителей и т. д.) - это и есть парсинг сайта, а не прайс-листа. не понял. за парсинг 50000 товаров с другого сайта стоимость 900 руб. всего? В моем понимании 1 донор = 1 сайт. Так сколько же стоит один товар спарсить?

Вы уж потрудитесь составить ТЗ. А то совсем непонятно, что вам нужно. О какой верстке может идти речь если вы показываете магазин с кучей нестандартных модулей?

кстати, в opencart 2.0 как раз таки 4 колонки при максимальном разрешении. И на мой взгляд, реализация адаптивности в нем сделана довольно примитивно, неоптимально и грубо. достаточно посмотреть на тот же футер. Зато на бутстрап. Я считаю, что для магазина как раз таки удобный вариант в 5 колонок, а не в 4 или 6. получается максимум юзабилити и информации. И бутстрап "в топку". Либо использовать бутстрап в его нестандартном варианте, что равносильно "не бутстрап", т. к. другие модули, построенные на стандартном бутстрапе не будут дружить с нестандартным бутстрапом. Ну и нафига он тогда нужен? Вообще бутстрап - не единственный вариант создания адаптивности, и самое главное - он НЕоптимальный! Зато звучит красиво и у всех на слуху вроде той же вездесущей Джумлы.

И почему уперлись в бутстрап? Я вижу, что в макете используются пять колонок. И как это в бутстрапе будете реализовывать? В классическом бутстрапе или 4 или 6, но никак не 5. Сами себе противоречите. Ибо классический бутстрап построен на 12-ти колоночной модели, а не на 10-ти или 20-ти, потому и невозможно сделать 5 колонок. Поэтому для начала разберитесь со своими противоречивыми требованиями, либо доверьтесь опытному верстальщику и, пожалуйста, "не учите" его как нужно правильно "держать мастерок". Под ключ с адаптивной версткой по индивидуальному макету со всякими фильтрами и пр.? Даже при старом курсе доллара (в два раза дешевле) и то не взялся бы. Слишком не дооцениваете вы сложность работы. несерьезно. ваши 5 колонок:

так вот он какой "конец света"!

Хм... а ведь замечательно четкий алгоритм! Уважаемый автор, обращайтесь. Помогу решить вашу проблему. Много лет работаю с выделенными серверами.

Я, например, не пользуюсь ParseMX. У меня другие средства и, думаю, что более эффективные. Могу сделать парсинг. Всех товаров с картинками, с атрибутами, опциями и пр. из указанных вами категорий. Но все инструменты на моей стороне, у вас только конечный результат будет. дешево не будет. качество гарантирую. для связи пользуйтесь личкой.

Ну разработчики то с верстальщиками это понимают.... Да и заказчик скромно молчит про "другую цмс". И чем обоснован такой странный выбор? Дешевый шаблон для OC переделать для другой цмс? Неужели на том же темплитмонстре нет шаблонов для "другой цмс"? Или автор всерьез думает, что кто-то переделает шаблон дешевле чем стоит готовый? Сама постановка задачи выглядит сомнительно. Может быть надо по другому решать вопрос? Начать с выбора самой цмс. И чем OC не угодил?

Да вы серьезно не воспринимайте это. вполне достаточно HTML + CSS. сохранение сгенерированного (в том числе и за счет JS) HTML. Вот вам и готовая верстка. В Opencart JS активно используется для формирования страниц. например, на странице "категория". Никуда вы просто так не денете JS. Корзина так вообще без него не работает. Можно удалить нафиг вообще корзину.... только так. Просто сама постановка задачи несколько абсурдна. И некорректно вообще говорить о переносе верстки на другой движок. Не выйдет переноса. Нужно верстать именно под соответствующий движок. Но такая задача весьма странно выглядит на этом форуме. невозможно просто так сделать "абстрактную" верстку, которая сама собой налезет на любую другую "цмс".

отжиматтинг... разбойно-нападаттинг... кандидат в мастера спорта? есть. но нужно видеть сайт-донор. и нужно знать какие категории нужно переносить.

И сколько денег дадите за извлечение чего то там из шаблона за 50 (или дешевле?) долларов? Могу дать совет как сделать все самому. В браузере есть кнопочка "сохранить как...". Сохраняете в HTML с картинками и JS. вот вам и готовая "верстка".

вот уж эти цифирные и литерные! а еще говорят, что в бизнесе работают... понимать должны ведь, что такой ник невозможно запомнить. хотя... может быть именно это и нужно? По началу темы уже было понятно, что это пустозвонство и ничего серьезного.

Апаче в данном случае не ключевое слово. ключевое - php x64. И мне как разработчику он очень даже нравился до столкновения с проблемами, вызванными модулями под ioncube. на win если любопытно.

так потому у меня скайп выключен совсем последнюю неделю. Как же я мог отписаться не получив вашего сообщения?

Ну или Стива Круга во взрослой жизни, на худой конец. :-) Про братьев то многие знают... Стив - большой специалист по юзабилити, много полезного написал на эту тему.

Если кто-то читал мое предыдущее сообщение, то в нем описана малая часть проблем для разработчика. Я уважаю выбор авторов модулей использовать ion-cube, но... проблемы возникшие из-за использования ion-cube авторами модулей не решаются, к сожалению. Еще очередной пример. очень известный модуль под ion-cube от уважаемого автора не работает на моих серверах с php 5.5 и 5.6 64-bit. И ничем автор не может в этом плане помочь. И так почти со всеми модулями под ion-cube. ion-cube установлен на сервере, прекрасно отрабатываются тестовые варианты от самого производителя ion-cube, магазин работает пока ... не появляется закодированный модуль. Я думаю, что проблема в том, что господа просто не знают всех особенностей использования php 5.5 и 5.6 64-bit совместно с ion-cube. Предполагаю, что максимум проверяют под некоторые версии php 32 bit. Я не против кодировки в принципе. Я лишь прошу не создавать лишних проблем разработчикам. Уважаемый tabook, вы уверены, что ваши модули будут работать на 64-битном сервере Апаче + 64-битном php? соответственно на php 5.5 и 5.6 У меня на этих серверах многие закодированные и очень популярные модули вообще не работают! Вы этим вопросом интересовались?

И в чем дизайн у вас? формат? pdf? html? не претендую на звание исполнителя "за пару дней", ибо занят сейчас, просто любопытно. И судя по всему вы посредник?

То, что проблем масса появляется у разработчика, делающего кастомную верстку - это факт. Вот совсем недавний мой пример. Модуль под ioncube. Нужно было сделать довольно простую по сути кастомизацию: вместо вывода в inline-потоке информации (как сделал автор модуля) необходимо сделать вывод в виде таблицы. Казалось бы чего проще... изменить CSS, переопределив inline-элементы на элементы таблицы и при необходимости добавить где нужно обертки. Но возник просто облом.... потому что автор сделал вывод так: <span><img></span> <span><img></span> <span><img></span> <span><img></span> <span><img></span> и весь этот код поместил в модель, а модель закрыл ioncub-ом. великолепно! Верстальщики обломитесь. Невозможно использовать в CSS before/after к тегу img. его бы обернуть сперва в div, да и воспользоваться before/after, а нельзя!!! тут только хардкор с использованием jquery. В последнем проекте у меня было 5 модулей под ioncube. И это просто издевательство было над разработчиком магазина. Ибо работаю всегда по схеме: 1) магазин на локалке 2) магазин на моем тестовом домене 3) магазин на хост-площадке заказчика. Так вот перенос данных с локалки на тестовый домен для демонстрации заказчику - это просто ужас! Каждый раз для всех заионенных модулей нужно вводить заново лицензионный ключ при перенесении. Более того часть модулей ругается, что с локалки перенесся ключ от локальной версии и пока его не удалишь новая регистрация не пройдет. Это еще пол-беды. Есть модули, которые на правильный ключ ругаются, но при этом молчат как партизаны, что им не нравится присутствие ключа от локальной версии. поди догадайся... а если догадался, то еще найди его. занимательное дело! И пока не удалишь его.... Но автор модуля молчит об этом, не предупреждает заранее. И каждый автор создает свой ключ либо в собственном месте в файле либо в БД. Казалось бы чего проще - сделайте так чтобы одновременно можно было заливать несколько ключей и модуль сам нашел бы нужный для соответствующего домена. Такое впечатление, что авторы модулей сами сайты не делают и кроме своего модуля ничего не используют. Это я все к тому пишу, что уж если решили сделать ioncube, то сделайте это грамотно и удобно для верстальщика. Иначе верстка в кошмар превращается. Попробуйте сайт с 5-ю заионенными модулями показать заказчику (скопировать с локалки) 5 раз в день и поймете о чем я... при этом 25 раз будете удалять ключи от локального домена и все время вспоминать какой ключ где лежит и постоянно путаться....