sv2109
-
Публікації
3 686 -
З нами
-
Відвідування
Тип публікації
Профілі
Форум
Маркетплейс
Статті
FAQ
Наші новини
Магазин
Блоги
module__dplus_manager
Усі публікації користувача sv2109
-
Добавил поддержку 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, где тоже не было совместимости модулей.
-
я не против косметики, но пусть она не изменяет сам движок до такой степени, что для каждой версии движка нужно создавать новые версии модулей. Это класти и решают события. Потому что когда модуль для какого-то действия вызывает какое-то событие, то ему абсолютно все равно как это событие работает внутри, ему главное получить результат. И тогда, если бы все в движке работало на событиях, то даже серьезные изменения движка бы не влияли на работу модулей. Теперь же, когда все делается через ocmod любое, даже самое незначительное изменение движка, порождает кучу конфликтов. Поэтому на событиях должно работать все в движке, чтобы модуль через события мог изменить все что угодно. Так работает например Drupal, так работает Symfony, другие движки и фреймворке, вот только в одном опенкарте решили изобрести свой велосипед - vqmod.
-
Боюсь показаться маразматиком, но мне кажется это перебор. Обычно в движках небольшие, минорные изменения версии (с 2.2 на 2.3) это небольшие изменения самого движка, которые практически не сказываются на работе модулей и почти все модули, которые работают на 2.2 должны работать на 2.3, потому что движок кардинально не изменяется, изменяются какие-то мелочи, проблемы безопасности, исправляются баги итд. А уже изменения мажорной версии (напр. с 2.x на 3.x) несет более глобальные изменения самого движка. Что мы видим в опенкарт? В последнее время каждая(!) новая минорная версия практически полностью несовместима с предыдущей. Модули, написаны на 2.1 совсем не будут работать на 2.2, модули написанные на 2.2 также совсем не будут работать на 2.3.. И приходится с каждой новой версией писать новые версии для каждого модуля. А что если у кого-то модулей 2-3 десятка?.. Короче, имхо, идиотизм, о разработчиках никто вообще не думает. Неужели не было бы проще все новые модные изменения на протяжении нескольких месяцев вести в какой-то дев. ветке, а потом пакетом все обновить и выпустить новую версию движка - 3.0. А разработчикам пришлось бы делать всего 2 версии модуля - для 2.х и для 3.х, а не для 2.0, 2.1, 2.2, 2.3 итд.. + как мне кажется, глупо делать кучу косметических улучшений, когда сам движок написан криво, неужели было бы не лучше сначала сделать нормально события (и отказаться от ocmod из-за которого куча конфликтов), добавить какие-то хелперы, например для форм, улучшить работу с языками (а не добавлять по 100 строк в каждом контроллере), добавить какую-то простую орм для работы с базой (чтобы не писать сотни идентичных запросов), добавить какой-то класс валидации, чтобы он автоматом входящие данные проверял согласно правилам итд. итп. Все это есть практически в любом, даже самом простом фреймворке. А уже потом делать всю косметику. так, просто мысли вслух.
-
терперть можно, когда ты живешь например с родителями, которые тебя полностью обеспечивают, а деньги с форума ты тратишь на какие-то ненужные вещи и даже месяц задержки ничего особо не изменят. но когда у тебя семья, постоянные расходы и на деньги эти ты рассчитываешь, что вот 20-25 число будут деньги, за которые можно заплатить за то и это, а тут задержка 5 дней, 10, 15 и больше, то тут уже терпеть сложно, тем более зачем терпеть, свои деньги заработанные нужно не выпрашивать и тем более не терпеть, а требовать. ИМХО.
-
Все, деньги получены, подтверждаю. Пока только часть, другая была отправлена и пока не дошла, жду.
-
Если владелец бизнеса откровенно плюет на своих клиентов, которые ему приносят деньги, потому что "лето, солнце, море, пляж" итд. то очень скоро он свой бизнес просто потеряет. Это крайне не серьезный подход к ведению бизнеса. Мне сложно представить какой-то магазин, который закрылся или отменил поддержку на месяц, потому что решил отдохнуть, все его клиенты сразу перейдут к конкурентам и никогда к нему не вернуться. Мне сложно представить любой другой бизнес, который может сделать тоже самое и ничего не потерять. Я сам был месяц назад в отпуску. Что я сделал? 1. доделал всю недоделанную работу 2. что не успел, тех клиентов предупредил, что не успеваю 3. написал у себя в профиле что в такой-то период я в отпуску. 4. даже в отпуску с мобильным интернетом оказывал какую-то базовую поддержку Все. 99% клиентов отлично это восприняли, желали хорошо отдохнуть. Никаких проблем. Потому что я переживаю за своих клиентов и не хочу никого подставить. Что мог сделать dinox, если он действительно в отпуску? 1. перед уходом рассчитаться со всеми и спокойно уйти в отпуск. 2. в своем профиле написать, что "в такой-то период я в отпуску, выйду, решу все проблемы" 3. идеально посадить какого-то помощника на этот период или хоть изредка заходить и отвечать на вопросы, хотя бы отвечать, что "я сейчас в отпуску и ничего сделать не могу до хх числа", это уже было бы в сто раз лучше чем обычный игнор. И все, никакой проблемы, все бы отлично это восприняли. Взять для примера оф. сайт. Там же ведь тоже работают люди, которые также отдыхают, у которых тоже "лето, солнце, море, пляж", но почему-то оф. сайт работает в штатном режиме, поддержка оказывается, выплаты делаются, никаких задержек и никаких неудобств, все работает. Точно так же в штатном режиме работают и другие сайты. Но почему-то не этот.. пс. минус вам не я поставил.
-
это о чем? отписал, спасибо
