sv2109

Какая разница в скольких контроллерах используется этот языковый файл? В шаблоне вы берете те перемнные, которые вам нужны, что не нужно просто не используете. Если вам больше нравится присваивать каждую перменную отдельно и писать десятки строк ($this->data[''] = $this->language->get('');) в каждом контроллере - пишите.

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

Наверное самым нудным в создании любого модуля является присвоение языковых переменных в контроллерах. Сначала все эти переменные нужно внести во все языковые файлы, после чего каждую(!) переменную нужно прописать в контроллере, а в модулях их десятки (а например в контроллере товара в админке больше сотни!), после чего каждую переменную прописать в шаблоне.. Я уже начал писать свой хелпер для этого, как нашел одно очень простое решение: Вместо: $this->language->load('path/file'); $this->data['foo1'] = $this->language->get('bar1'); $this->data['foo2'] = $this->language->get('bar2'); // еще 100500 строк с $this->language->get() учитывая то, что лоадер языка возвращает массив всех языковых переменных, можно сделать: // для 1.5.x $this->data = array_merge($this->data, $this->language->load('path/file')); // для 2.0 $data = array_merge($data, $this->language->load('path/file')); Это присвоит все языковые переменный в $this->data автоматически. Нужно помнить, что $this->language->load('path/file') возвращает не только массив из файла 'path/file' но и все языковые файлы загруженные до него, например главный языковый файл в корне. Но конфликтов быть не должно, так как если вдруг и попадется какая-то ненужная языковая переменная с одинаковым названием с переменной контроллера то учитыая то, что языковые файлы грузятся с самого начала, эта перменная потом просто переопределиться в контроллере. Проверено на admin/controller/catalog/product.php и catalog/controller/product/product.php как 2-х самых больших контроллерах с большим к-вом языковых перменных. Почему это не используется в движке? Неужели кому-то проще писать десятки ненужных строк кода в каждом контроллере?..

Есть готовый модуль https://opencartforum.com/files/file/682-%D0%BF%D0%BE%D0%B8%D1%81%D0%BA-%D1%81-%D0%BC%D0%BE%D1%80%D1%84%D0%BE%D0%BB%D0%BE%D0%B3%D0%B8%D0%B5%D0%B9-%D0%B8-%D1%80%D0%B5%D0%BB%D0%B5%D0%B2%D0%B0%D0%BD%D1%82%D0%BD%D0%BE%D1%81%D1%82%D1%8C%D1%8E/

Эти 2 моудуля посмотрите: https://opencartforum.com/files/file/526-attribute-category/ https://opencartforum.com/files/file/525-attribute-select/

Скиньте мне в ЛС 1. старницу сайта на которой у вас что-то не срабатывает 2. опишите ваши действия 3. доступ в админку чтобы посмотреть настройки этого товара Подуль поддерживает много опций, но если выбраны 2 и больше опций то картинка меняется тогода, когда пользователь выберет все присвоенные для этой картинки опции, а не только какую-то одну.

Есть вот такой модуль https://opencartforum.com/files/file/599-%D1%80%D0%B0%D0%B7%D0%BD%D1%8B%D0%B5-%D1%86%D0%B5%D0%BD%D1%8B-%D0%B4%D0%BB%D1%8F-%D0%B3%D1%80%D1%83%D0%BF%D0%BF-%D0%BF%D0%BE%D0%BA%D1%83%D0%BF%D0%B0%D1%82%D0%B5%D0%BB%D0%B5%D0%B9/ В новой версии умеет менять цены для производителя. Но цены он меняет "на лету" не меняя цену в базе, цену в базе он может менять только для категорий и для 1 группы покупателей (потому что цена в базе 1) и никак не рабоатет с курсом. Установить разный курс для разных производителей достаточно проблематично - нужно много кода переписывать.

Если человек профессионально занимается программированием то и инструмент должен быть профессиональный. Вместо простых редакторов с подсветкой кода лучше использовать полноценные IDE (Integrated Development Environment) Например в NetBeans кроме обычной подсветки кода есть: управление проектами, отладка (можно запустить весь проект и поэтапно смотреть каждый шаг, какие переменные инициализированы, какое у них значение итд.), разные подсказки по php функциям, подсказки, замечания и ошибки в коде показываются сразу, автодополнение (по функциям php и файлам проекта), история (можно смотреть как менялся код по времени в графическом виде, видно что когда добавлялось), работа с репозиториями из самого редактора (checkout, commit, push, pull итд), рефакторинг, автоформатирование, применение и создание патчей, тесты и многое другое. Если вы с кодом работаете по 8 часов в сутки то хороший инструмент сможет сэкономить очень много времени. К ним сначала трудно привыкнуть то потом переходить на какой-то notepad++ (или я долго пользовался bluefish) уже не захочется.

Дайте мне в ЛС доступы к вашему сайту, посмотрю, только уже завтра.

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

я не вижу вас в списке купивших модуль, поддержка оказывается только покупателям моудля

NetBeans IDE 8.0

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

https://github.com/opencart/opencart https://help.github.com/articles/using-pull-requests/ достаточно лаконичный ответ? :)

Пробовал сегодня перенести один модуль на 2.0.0.0 АДЪ )) 1. нужно полностью переделывать админку модуля под бутстрап, там где раньше можно было написать что-то типа: <?php echo $field; ?>: <input type="text" name="field" value="" /> <input type="text" name="field2" value="" /> теперь нужно писать (и примерно так же для каждого поля в админке!): 2. вместо $this->data['foo'] = $foo; нужно $data['foo'] = $foo; 3. вместо $this->template = 'module/module.tpl'; нужно $this->response->setOutput($this->load->view('module/module', $data)); 4. вместо $this->children = array( 'common/header', 'common/footer' ); нужно (появилась левая колонка в админке и теперь можно загружать через load контроллеры) $data['header'] = $this->load->controller('common/header'); $data['column_left'] = $this->load->controller('common/column_left'); $data['footer'] = $this->load->controller('common/footer'); 5. вместо $this->redirect($this->url->link('extension/module', 'token=' . $this->session->data['token'], 'SSL')); нужно $this->response->redirect($this->url->link('extension/module', 'token=' . $this->session->data['token'], 'SSL')); 6. поле "статус" для модулей (enable, disable) оно теперь обязательное? Если так то почему бы не вынести его за модуль, как кнопку "установить" чтобы не прописывать это в каждом модуле. 7. Схемы для модулей. Они теперь отдельно. Нужно заходить в каждую схему и добавлять вручную модули. Чтобы модуль появился в списке нужно чтобы он был установлен и в него была настройка "module_name_module" с настройками модулей. Если нету то модуль не появится и нужно эту настройку обязательно добавить. 8. jquery-ui, его теперь нету в движке. Мне нужен был ui-autocomplete, вместо него какой-то самописный велосипед в common.js. это то с чем пока столкнулся. ПС. нет, в общем все понравилось, просто много мелких изменений, которые делают процесс переноса модулей очень трудоемким.

нужно просто потратить немного времени и сделать 1 раз простую базовую тему без бутстрапа (что-то типа друпаловкой zen) после чего все темы делать на основе этой базовой темы.

Если я правильно понял: некоторые верстальщики привыкнув к column_left будут и дальше делать column_left во всех своих темах в то время как другие под новый стандарт будут делать col-sm-6. А создателю модуля, который привязывал свой модуль к column_left непонятно к чему привязывать теперь.

То что так сделать можно совсем не означает что нужно делать именно так. 1. Это идеологически не правильно, поле sku это sku и использоваться оно должно по назначению. 2. Это не правильно по отношению к другим разработчикам, которые потом столкнуться с поддержкой этого магазина 3. Поле sku очень широко используется в самом магазине, с ним работает многие модули, не исключено что завтра возникнут конфликты с этими модулями. 4. Решение, которое предложено в простонародье называется словом "говнокодинг" это "костыль" а не решение.

Это не правильно, так нельзя делать. SKU это текстовое поле, оно в базе прописано как varchar(64) то есть всего 64 символа.

1.Разработчику своей темы совсем не обязательно в своей теме использовать бутстрап, тем более что он его не знает. А разработчику который не зная бутстрапа свою тему делает изменяя стандартную, написанную на бутстрапе, добавлением туда старого кода "<div class="box-product">" нужно руки оторвать. Это не проблема бустрапа. 2. Разработчик модуля не может быть уверено что все сверстано по бутстрапу потому что совсем не обязателььно во всех темах использовать бутстрап. Разработчик модуля должен быть готов к любой теме. Для этого лучше писать такие модули, которые никак не зависят от верстки, а если это невозможно то вместо изменять тему с помощью vqmod можно написать инструкцию для пользователя: в таком-то фале добавить вот эту строчку кода вот в это место.

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

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

Есть изменения в стандартах кодирования: В 2.0 больше не нужен закрывающий php тег ?> в конце файлов! Оно и правильно, давно так нужно было сделать, в других движках давно так.

Уже кто-то руссификацию выложил http://www.opencart.com/index.php?route=extension/extension/info&extension_id=16735 Что такое opencart-russia.ru?

Recurring Profiles (повторяющиеся профили?) появились. Я так понял это как на этом сайте - возможность покупателю платить за какой-то товар регулярно, например через каждых 2 недели вносить какую-то сумму. ПС во и баги полезли Notice: Undefined variable: text_edit in /home/i/iliyanik/opencart.brenk.ru/public_html/2_0/admin/view/template/setting/setting.tpl on line 29