sv2109
-
Публікації
3 692 -
З нами
-
Відвідування
Тип публікації
Профілі
Форум
Маркетплейс
Статті
FAQ
Наші новини
Магазин
Блоги
module__dplus_manager
Усі публікації користувача sv2109
-
нет, пока нету версии для 2.3
-
есть
-
Модуль работает как заявлено, установите модуль на чистый движок и дефолтную тему и вы в этом убедитесь. Даже если сайт не очень стандартный, модуль обычно тоже отлично работает. Но если у кого-то очень! нестандартный сайт, установлено десятки модулей и движок изменен до неузнаваемости, то вот в таком случае ни один разработчик модулей не сможет гарантировать, что модуль будет работать на таком сайте из коробки. В таком случае нужно приложить доп. усилия, чтобы заставить вообще что-то работать на таком сайте. Этот модуль работает на сотнях (!) сайтов с всевозможными конфигурациями, модулями, темами итд. и отлично работает. Человек 30 у меня этот модуль купили повторно для других своих сайтов. То есть пользователь купил модуль, увидел что он реально работает и реально ускоряет работу сайта и купил другой модуль для другого своего сайта. Если бы модуль не работал то зачем бы они это делали? Поэтому, модуль 100% рабочий, автор никого не обманывает, что модуль работает, все, что написано в описании модуля - все правда.
-
а что мешает этому программисту самому написать этот модуль, отвечать на профильных форумах и получить эти самые ден. знаки в полном объеме и без вашей участи? :) чесно, не понял смысла сотрудничества. Найти программиста, который сам напишет модуль, будет оказывать всю поддержку, а деньги поделить :) умно, конечно, с вашей стороны, но зачем это программисту, мне например, совсем не понятно.
-
вы купили модуль, получили его, он у вас работал пол года, потом вы сами его куда-то потеряли и в воскресенье, выходной день требуете что вам его выслали и чем-то недовольны?
-
Добавил поддержку 1.5 для третьей версии модуля: https://opencartforum.com/files/file/3267-%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-pro/
-
Добавил поддержку opencart / ocstore 1.5.5.1
-
весь кеш
-
на почту ответил
-
именно с этим шаблоном я не работал, но я не помню шаблона с которым модуль бы не работал, обычно с разными шаблонами модуль работает нормально.
-
сложно сказать, пока не реализовано, будет время сделаю.
-
информация по обновлению есть в описании этого модуля. Читайте описание модуля поисковой системы, там все написано, все отличия да
-
нет поддержка OpenCart 2.2
-
Вы про маркетинговую кампанию (/admin/index.php?route=marketing/marketing)? В разных сборках перевод может отличаться. 1. вы создаете рекламную кампанию в админке, указываете название, описание и получаете код, а также ссылку уже с этим кодом, напр. www.адрес_сайта/?tracking=57b6dcdcae066 2. вы создаете какую-то рекламу, напр. вешаете свой банер на каком-то партнерском сайте (или даже вешаете банер на своем сайте на какую-то акцию или распродажу). Но ссылку на него добавляете уже с вашим кодом из п.1. 3. когда кто-то заходит на сайт через этот банер с кодом, то опенкар фиксирует это посещение и на странице Маркетинга в адмике вы видите и сколько человек зашло через этот банер к вам на сайт и сколько человек что-то купило на сайте. Таким образом вы можете анализировать эффективность рекламы, какая работает лучше и ее нужно заказать больше, какая не работает и от нее лучше вообще отказаться. Очень простой и удобный инструмент.
-
никакого отказа не было, я с самого начала готов был оказывать вам поддержку, просто вы под поддержкой понимаете то, чем она не совсем является. В посте выше я все объяснил.
-
если вы установили модуль по инструкции то модуль не может не отобразится в админке если это происходит значит вы что-то сделали не так, поэтому я вам и дал ссылку на статью где все пошагово описано что нужно сделать и что проверить.
-
Все правильно. Поддержку я оказываю каждому покупателю. Проблема в том, что некоторые покупатели (к счастью их немного) неправильно понимают значение слова "поддержка". В их понимании поддержка - это дать автору доступ к сайту и пусть сам автор устанавливает модуль и решает все проблемы, потому что "я в этих ваших кодах ничего не понимаю" (так иногда пишут) А на самом деле поддержка - от слова поддерживать, помогать, это когда покупатель сам устанавливает модуль, сам делает всю работу, а когда у него возникают какие-то проблемы или вопросы, то он обращается с ними к разработчику, который помогает их решить - подсказывает что нужно сделать, куда посмотреть, что проверить итд. Но делает все покупатель. Если же покупатель хочет, чтобы разработчик самостоятельно установил модуль на его сайт - ОК, многие разработчики предоставляют такую услугу, но естественно за доп. плату.
-
как раз таки и наоборот. Если будет нормальный движок, с отличной архитектурой, который будет хорошо поддерживаться, модули не будут так конфликтовать, он будет стабильным итд. То он будет и намного более популярным! Мало того, его будут использовать для больших магазинов, а это уже корпоративный рынок, в котором денег в разы больше. Денег и для Даниела и для разработчиков.
-
Люди, которые во всем хвалят опенкарт, рассказывая какой это идеальный во всех смыслах супер движок, что он сам является офигенным фреймворком и почти ничем не отличается от современных фреймоворков, мне напоминают человека, который 30 лет назад купил горбатый запорожец, всю жизнь на нем проездил, а теперь с пеной во рту доказывает какой это офигенный и идеальный во всех смыслах автомобиль, который практически ничем не отличается от современных автомобилей, там ведь тоже есть руль, колеса и двигатель.. Мне кажется, что любой, кто серьезно работал (а не просто где-то о нем слыша, это важно) и с современными фреймворками (symfony, yii) и с опенкартом, согласится с этой аналогией. Для меня опенкарт это никак не фреймворк, который почти ничем не уступает symfony, для меня опенкарт так относится к symfony, как горбатый запорожец к какой-то BMW X6. Делать свой фреймворк можно. Если бы этого никто не делал, то у нас бы не было сейчас такого к-ва реально классных фреймворков. Но делать новый фреймворк может тот, кто изучил все существующие фреймворки, поработал с ними, ни один ему не подошел (по объективным причинам) и он, имея достаточное к-во знаний и опыта (это чрезвычайно важно), делает свой, лучше существующих. Но когда я смотрю что делает Даниел, то я вижу, что лучше он или вообще никогда не сделает или сделает лет через 20, когда самостоятельно наступит на сотни граблей, наконец то решит изучить другие фреймворки и получит достаточно опыта. А все это время он будет трепать нервы пользователям его движка новыми версиями, каждая новая которая будет несовместима с предыдущей.. Поэтому в случае с Даниелом самый лучший способ - это просто взять готовый код и использовать его.
-
Как я вас понимаю. Не знал, что преста начала переходить на симфони, супер, нужно будет еще раз посмотреть на этот движок. Друпал уже давно перешел на симфони, выкинув на свалку все свои велосипеды, выкинуть которые было дешевле, чем дальше поддерживать. Только Даниел продолжает пились свое, считая себя непризнанным гением... А ведь реально, есть симфони, ладно, не нравится симфони, бери yii, kohana, та даже мега простой Code Igniter. И вместо того, чтобы в который раз изобретать (и потом еще тестировать, отлаживать, изменять и 150 раз совершенствовать, испытывая нервы разработчиков и пользователей) свои велосипеды, бери полностью готовый да еще и бесплатный код! С отличной архитектурой. Причем мало того, что он готовый и отлаженный на миллионах сайтов, он еще также бесплатно поддерживается огромным сообществом, которое постоянно будет исправлять баги, выпускать новые версии, новые компоненты, библиотеки итд. Все готовое, бери и пользуйся. И все свои усилия сконцентрируй не на создании 50-ой версии Событий, а на функционале и модулях самого магазина. Но нет, нужно свое пилить, где логика? Не понимаю.
-
чтобы изменять sql нужна какая-то объектная модель формирования sql запросов, чтобы запрос создавался напр. так: $sql->select('..')->where('..')->limit('..'); тогда можно бы было из своего модуля получить доступ к объекту $sql и сделать что-то типа: $sql->leftJoin('..')->addWhere('..'); иначе если изменять текстову sql строку то это будет тот же ocmod с кучей конфликтов.
-
вроде есть :) см. класс лоадера, обратите внимание на класс Proxy, а также на метод callback(); (там кстати уже замыкания используются) если я правильно понимаю, то события есть для каждого метода модели и называются: 'model/' . $route . '/before' и 'model/' . $route . '/after' напр. 'model/catalog/product/getProduct/before' и 'model/catalog/product/getProduct/after' вот так вызывается "after": $result = $registry->get('event')->trigger('model/' . $route . '/after', array_merge(array(&$route, &$output), $args)); где $output - это уже результат работы метода модели, например массив с полями товара для getProduct, то есть уже можно добавить какие-то свои поля для товара или изменить существующие не используя ocmod и это есть уже с версии 2.2
-
ну если 2.3 == 3.0 то тем более зачем было делать 2.3? Правильнее было бы сразу делать 3.0. Но 3.0 не может быть такой же. И в 3.0 по любому сейчас добавят какие-то косметические изменения и совместимости с модулями опять не будет, потому что если ее нету в минорных версиях, то в мажорной тем более не будет. И разработчикам опять придется делать новые версии но уже под 3.0. вопрос не в том чтобы сделать или не сделать, вопрос в том, чтобы сделать с умом, чтобы было удобно и разработчикам и пользователям. А версия 2.3 она никакая. Она неудобна не тем ни другим. Если пользователь на нее перейдет (а многие пользователи берут последнюю версию, потому что считают что чем новее, тем лучше, плюс на оф. сайте всегда предлагают последнюю версию устанавливать) то получат во-первых кучу проблем с совместимостью модулей, во-вторых через 2 месяца выйдет 3.0 и пользователям придется переходить уже на 3.0, как на более новую версию и под которую подозреваю со временем будет модулей больше, чем для проходной 2.3. А нужно было бы или делать 2.3 оставляя совместимость модулей (как делают все нормальные движки на минорных версиях) или не выпускать 2.3 вообще, а все изменения уже выпустить в 3.0, тогда и в 3.0 было бы действительно много изменений и она реально тянула бы на мажорную версию (а не была бы почти копией 2.3) и разработчикам было бы проще и пользователям не пришлось бы страдать.
-
Тем более спрашивается - зачем вообще было делать 2.3?! Ведь прямо сейчас на нее никто не перейдет, потому что еще нету всех необходимых модулей совместимых с ней. Какая-то часть модулей будет месяцев через 2-3 минимум. И вот через 2-3 месяца когда разработчики потратят кучу своего времени, чтобы сделать версии модулей для 2.3 и покупатели надумают на нее переходить, что сделает опенкарт? Правильно, исправит все ошибки 2.3, добавит пару косметических мелочей, которые опять нарушат совместимость и выпустит 3.0, после выпуска которой смысла переходить на 2.3 уже не будет никакого. В результате тем разработчикам, кто потратил время на перенос модулей на 2.3 теперь опять придется писать новые версии уже для 3.0, а версии для 2.3 просто останутся невостребованными, так как смысла на нее переходить после выпуска 3.0 уже не будет.
-
а я наоборот что-то очень в этом сомневаюсь, ведь то, что для каждой новой версии движка нужно писать новую версию модулей плохо не только для разработчиков, но и для пользователей и как следствие для движка и новой версии, потому что так как разработчикам нужно создавать новые версии модулей для каждой новой версии движки то делать они это будут очень медленно, некоторые и пол года и даже больше, учитывая загруженность, нехватку времени, небольшую популярность новой версии итд., поэтому переходить на новую версию пользователям еще минимум пол года я бы вообще не советовал, так как очень вероятно что нужного модуля просто не будет, да и что такого супер важного, без чего жить нельзя есть в 2.3, чего нету в 2.2 или даже в 2.1? Тогда зачем вообще переходить на 2.3 и получить кучу проблем с совместимостью модулей? Поэтому 2.3, мне кажется, ждет точно такая же судьба как и 2.2, где тоже не было совместимости модулей.
