EVMedvedev

Есть такой прием построения алгоритмов, как рекурсия. Минимум труда на любое количество вложений. Остальное делается версткой.

Если ни кто так и не взялся, пишите на [email protected]

Попробуйте тестовые версии разных прог для магазинов здесь http://www.prestashopmanager.com/

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

Отправил. Только он соответственно без кряков.

Это похоже не ошибка, а просто предупреждение которое выскакивает из-за неправильной настройки отображения ошибок в PHP.

Могу куда нибудь выложить setup, если укажете куда. Он 22Мб весит.

Самое простое решение - забить в шаблоне в поля значения по умолчанию, а сами поля просто скрыть настройками CSS. Средство универсальное, сработает на любой версии и не только в ОС.

Если вы и дальше будете игнорировать интересы пользователей, то движок не станет популярным ни когда. Любой движок популярен не разработчиками, а пользователями. А по аудитории OC пока видно что он проигрывает Престе и это факт, какие бы иллюзии вы себе не строили. Хотите это изменить? Придется понять что нужно в развитие движка думать над тем что нужно его пользователям. А это те, кто создает свой бизнес и им нужна достоверная информация для принятия их решений по использованию того или иного инструмента. Обманывая пользователей популярности движку не добавить (так что скорее всего помехой в его развитии являетесь вы а не я). Чтобы реально изменить положение к лучшему, нужно сначала объективно взглянуть на вещи. Поскольку я не производитель того или иного движка, я могу смотреть на вещи не предвзято и действовать в интересах пользователя. Я решаю их проблемы и не зацикливаюсь на одном движке, поэтому лучше представляю сильные и слабые стороны каждого. Если посчитаю правильным буду настаивать на применении OC, но делать это буду обоснованно и просчитано с точки зрения выгод заказчика, а не пытаться разводить его на деньги впаривая единственный движок, который более или менее знаю (вот сайт http://ebayamerican.ru/ который заказчик хотел сделать на Престе, но послушал меня и в результате за пару дней получил то, что в полном объеме решает его бизнес задачи, но на Joomla) . Так что если действительно радеете за дело, избавляйтесь от иллюзий. Иначе в конкуренции с другими движками вы проиграете. Вы не пытаетесь бороться с другими движками, а убегаете от этого. Пока вы не пытаетесь выявлять сильные и слабые стороны своего движка и оппонентов и вырабатывать какую-то конкурентную стратегию, вы обречены на проигрыш. Другие движки сильны не просто так. В развитие Мадженты вливают ресурсы помимо eBay (главного акционера) еще и Zend потому что Маджента построена на ZF, а это десятки миллионов долларов инвестиций. Вокруг Престы на шаблонах и модулях уже сформировался многомиллионный бизнес, потому что в ней удобно реализована шаблонизация (за счет использования Smarty) и очень проста установка модулей, поэтому разработкой магазинов на Престе занимается много людей, весьма далеких от программирования (посмотрите по соответствующим форумам. Сайты на заказ ляпают даже те, что в процессе разработки осваивал CSS. Дилетанты достали, дальше не куда). Что OC на данный момент может противопоставить этому? Да ни чего. Пока ОС пишется без заимствования опенсорс решений сторонних разработчиков (того же Smarty) методом изобретения велосипеда, он будет всегда в проигрыше. Потому что при заимствовании таких решений в конкуренцию на стороне OC включаются в том числе и разработчики этих решений. А пока что разработчики OC фактически действуют в одиночку, а значит шансов на победу в этой борьбе за пользователя при такой стратегии у них нет.

С помощью билдера можно управлять внесением изменений. Это не откат а пересборка с альтернативной конфигурацией модификаций. Модули под VQMOD ведь опираются на эталонный код, а если он будет модифицирован, то уже могут возникать проблемы. Я уже сталкивался с ситуацией, когда вставляемый код добавлялся например вместо закоментаренного кода. В результате комментарии естественно сыпались и весь код не работал. Использование vQMOD в том виде как он задуман изначально по целому ряду причин имеет много ограничений, поэтому использовать его в серьезных масштабах в и продакшн версиях кода не целесообразно. Это инструмент разработки. А для отката по версиям действительно лучше применять средства управления версиями.

Дело не только в этом. Можно параллельно налаживать автоматизацию документирования изменений например или тестирования средствами типа PHPUnit ну и т.п. То есть перейти к промышленным методам разработки от кустарных.

Не спешите, а то я недавно сделал человеку такой магазин, а как вернули антитабачный закон на доработку в ГД, так он пока всю деятельность вынужден был приостановить до осени.

Закрывай код обфускатом с ограничениями по времени и проблем не будет.

Я решил делать другой вариант. Переделал VQMOD как пакетный редактор для сборки конечного кода. Заливаешь в один каталог дистрибутив, в другой описания изменений, а в третий при запуске скрипта выливается конечный код сайта. В общем получился некий аналог Apache Ant. Конфигурация задаю в build.xml. Правда еще не доделал.

Человеку нужно не развитие движка, а развитие его бизнеса. Хотите чтобы движок развивался, научитесь думать о пользователях, а не о движке.

Писать придется с нуля, потому что в престе используется шаблонизатор Smarty, а с ОС нет. Поэтому тема от престы не подойдет к ОС, да и состав данных, выгружаемых для шаблонов Престы сильно отличается от состава данных выдаваемых для шаблонов OC.

Нужны подробности желаемого алгоритма интеграции (SOAP, файловый обмен через почту). 1С личный дескопный или арендованный аккаунт в сети?

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

Такая программа была для PrestaShop 1.3. Называлась PrestaClient. Распространялась на платной основе. Ветка загнулась. Они строили работу исходя из того, что есть прямой доступ к СУБД, но многие хост провайдеры такой доступ не дают или сильно ограничивают возможности модификации данных. Сам пробовал написать приличный интерфейс для работы с данными (тоже на примере PrestaShop) с помощью MS Access и ODBC для MySQL. Быстро стало понятно, что это утопия и я бросил это бессмысленное занятие. Для решения подобных задач серьезные платформы (PrestaShop, Magento) имеют REST или SOAP интерфейсы. Тогда есть возможность строить внешние приложения, использующие этот интерфейс. Так например сделаны клиенты ведения блогов в WP, такие как Zoundery Raven, MS Word и некоторые другие с использованием XMLRCP или Atom. В Битриксе есть SOAP.

Дело не только в количестве посетителей, но и в количестве товаров, и организации обработки данных. Например некоторые движки позволяют разделить операции на запись и на чтение в БД между разными физическими серверами, устанавливая 2 MySQL и настраивая их как master и slave. То есть в конечном итоге вы получаете возможность распределить всю вычислительную нагрузку по трем железкам как минимум (web-сервер и два сервера БД). Если вы рассчитываете при такой базе на тысячи посетителей в день и сотню покупок, то боюсь здесь одной железкой, а тем более простым виртуальным хостом, не обойтись. Если конечно у вас предполагается по одному посетителю в день, то и ОС подойдет. Внешне будет то же самое. Но потенциала для наращивания производительности не будет. На счет того, что будет при переборе - все просто, скрипты начнут отваливаться по таймауту, загрузка страниц будет тянуться по минуте, начнут вываливаться 500 ошибки nginx ну и прочие радости.

Какая именно интеграция нужна? По каким каналам? Файловый обмен или через SOAP интерфейс? Поподробнее.

Бюджет работы какой?

Поэкспериментируйте сначала с "рекомендуемыми" в закладке "связи" при редактировании товара. Может это будет простым решением?

Стоит такой гипермаркет не одну сотню тысяч рублей. На ОС такого не сделать (по крайней мере если предполагать большое количество посетителей). Движок не потянет.

Дорого. Считайте от 100 000 руб. Сайт здесь вряд ли фигурировал так как сделан на комбинации WordPress+Prestashop с серьезными доработками. Если под концепцией понимать не только фронт-енд, но и админку, то указанную сумму можно смело умножать в разы, потому что в админке OC нет и половины того, что есть в админке Престы.