Нажимаю на нее(она ввиде сосуда) и там мне пишут вот это- "У Вас нет прав для доступа к этой странице. Если она Вам нужна, обратитесь к администратору." Что это значит???? Спасибо за помощь.
Что? Где? Когда? Игра така я вас? Ктоже его знает.. дополнение какое то. Ни разу не пользовался.. Наверно у вас какая то тема? Купили? Пишите автору. Не купили, где то скачали? То и помощи где то придется искать. Варез никто не любит если что.
Это модуль, позволяющий грузить и апдейтить модули от автора, Но он там такого нагородил.., что непонятно зачем он нужен. Хотя задумка сама по себе интересная. Единая система установки и выбора модулей от автора. Вы получаете ссылку на загрузку Затем самостоятельно устанавливаете нужный модуль. Не автоматическая установка, а ручная.
Спасибо. А скажите пожалуйста, меня смущает эта фраза "У Вас нет прав для доступа к этой странице. Если она Вам нужна, обратитесь к администратору." Я получается не администратор своего интернет магазина?
Всем привет! Shopunity - это менеджер модулей с поддержкой зависимостей. Идея пришла от NPM и Composer. Есть статья тут https://shopunity.net/post/why-do-I-need-shopunity о том для чего нужна эта система. Немного предистории: Изначально это была система учета внутри компании - хотелось организовать работу с модулями - учет и поддержка отбирали много времени. Потом решили разделять код на пакеты и использовать его в разных модулях и проектах. От сюда и зависимости. Это решило проблему дублирования кода из модуля в модуль. После появилась идея упростить процесс установки для пользователя - все в 1 клик. Так и появился менеджер для пользователей - устанавливаете его как любой другой модуль а после можете устанавливать любые наши модули в 1 клик. Все зависимые модули будут установлены на заднем плане. Позже появились уведомления о новых версиях и возможность обновить модуль до последней версии. Мы используем SemVer. Каждый модуль имеет свой репозитарий на гитхабе или битбакете и у каждого есть extension.json где прописаны все файлы и вся информация о модуле. В будущем мы планируем организовать перенос лицензий из других площадок и открыть доступ для сторонних разработчиков вести свои модули с помощью Shopunity. Благодаря Shopunity наша эффективность выросла в несколько раз. Если Вам интересно принять участие на ранних стадиях развития системы и получить бесплатный девелоперский доступ - пишите нам на info@dreamvention.com или на https://dreamvention.ee/support. Если у Вас возникнут сложности в установке или вы обнаружите баг - пишите нам в поддержку https://dreamvention.ee/support. Всем отличного дня!
ага, потом сервер лицензий, потом.. Что-то отпало, потом что-что купить нельзя, потому что есть зависимость от какого-то модуля. Ваша, но не наша. Попробовал, запутался в двух кнопках.
Такого у нас нет. Идея такая же как и с Composer или NPM - разработчик сам ведет учет и сам определяет какие модули ставить в зависимости. если он решит что нужно ставить платный - он обязан об этом уведомить. На сегодняшний день у нас нет ни одного модуля который ставить платный в зависимость. в основном это библиотеки и модули которые добавляют новые функции работы с евентами, твиг. ip и прочие утилиты. Если Вы подробнее расскажите с чем у Вас возникла трудность - мы постараемся учесть это в следующем обновлении модуля.
Я уже не помню, установил ядро, потом нашел нужный, бесплатный модуль, а оно мне говорит, что установи еще эту , я туда, а там еще одну.. А оно мне надо? и когда соизволит модуль стучаться за обновлениями? и т.д.. Предложите это Даниелю
Вы описали ситуацию которую мы как раз решили с помощью Shopunity - все сторонние модули устанавливаются на заднем плане - вам не нужно о них беспокоиться. Но настройка их действительно остается за пользователем. Я Вас понял. Мы понимаем что для рядового пользователя это может быть немного запутанными процессом и мы ведем работу над UX модуля чтобы и этот процесс был более простым. Наша цель - все в 1 клик. По сути Вам не нужно следить за разными обновлениями. Система вам подскажет что есть новая версия и вам достаточно нажать 1 кнопку чтобы обновить - после этого если будет надобность система сама обновит все зависимости согласно инструкции разработчика главного модуля. Пока модуль "стучится" по вашему заходу в админку модуля. Но мы планируем добавить опции об отключение по желанию. Как вы понимаете - лишние запросы нам совершенно не нужны. Так что скорее всего мы переведем этот процесс на полуавтоматический режим. На счет вопроса "оно мне надо?" конечно нет. Вы можете работать по старинке. Мы просто не хотим тратить время там где в этом нет надобности - мы лучше уделим это время созданию модулей. Без shopunity мы не смогли бы создать Visual Designer, Blog module, SEO Module и тд. вопрос эффективности и скорости разработки.
Я не рядовой пользователь.. Я из тех кто пишет и кто "читает" модули Потому и решил попробовать ваш.. В своей разработке вы можете сколько угодно пользовать свои наработки. В том числе, конечно и наработки стилей и и различных компонентов и скриптов. Да, для вас это удобно в одной среде разработки. А другим - это не комфортно, иметь зависимость от кого-то. Т.е. Если я захочу с вами работать, то мне нужно придерживаться ваших правил, я должен пользовать ваши разработки Мне это неудобно. Я не у видел что-то особенного в ваших модулях. Не.. я не говрю что они плохие или хорошие. Особенного я не вижу, кроме как зависимостей. И.. непонятно, как это может потом повлиять на переносимость. Только что, например установить блог, мне понадобится еще 10 модулей загрузить (я условно) Я понимаю, конечно, что например ваш livesearch уже заточен под поиск в блоге, но если нет блога, то и не ищет. Но о ведь будет искать только в своем блоге, а если у кого-то уже есть сторонний модуль?
Вы выбрали отличный пример - давайте разберем Blog module https://shopunity.net/extension/blog-module "Только что, например установить блог, мне понадобится еще 10 модулей загрузить (я условно)" вот зависимости у блога "d_shopunity": ">= 3.0.52", - уже стоит и так "d_event_manager": ">=1.0.0", - нужен чтобы портировать евенты на старые версии опенкарта - редактировать не обязательно - главное наличие кода. включение поддержки происходит автоматически - в блоге есть предложение активировать (без разрешения пользователя мы не активируем его) "d_twig_manager": ">= 1.3.0", - твиг - блог разработан на твиге. активировать не обязательно - включение происходит автоматически - в блоге есть предложение активировать (без разрешения пользователя мы не активируем его) "d_bootstrap_rating": ">= 1.0.0", - библиотека - активации нет "d_fileinput": ">= 1.0.0", - библиотека - активации нет "d_bootstrap_bootbox": ">= 4.4.0",- библиотека - активации нет "d_bootstrap_switch": ">= 3.3.3",- библиотека - активации нет "d_tinysort": ">= 2.3.6",- библиотека - активации нет "d_rubaxa_sortable": ">= 1.4.0",- библиотека - активации нет "d_bootstrap_colorpicker": ">= 2.5.0",- библиотека - активации нет "d_twig_partial": ">=1.0.0"- библиотека - активации нет То есть 3 модуля которые не нужно даже включать и 8 библиотек которые можно было бы закинуть в один модуль но потом другой модуль с такой же библиотекой - и вы уже храните копию одной и той же библиотеки и так далее. именно от этих дублей кода мы хотим уйти. Но я хотел бы обратить Ваше внимание на то что это не Shopunity навязывает какие либо стандарты. Это мы - Dreamvention, разработчики Blog module решили так сделать. Если скажем Вы будете разработчиком в Shopunity, Вы можете не ставить зависимостей вообще. Ваше право. Shopunity не навязывает правила - оно лишь дает возможность. Не более. На счет "не комфортно иметь зависимости" - В эпоху гитов это попросту неизбежно. Если Вы разработчик - то вы постоянно используете чужой код - Вы работаете с зависимости и так, даже если Вы этого не осознаете. Увы - это уже реальность. Мы же пытаемся этот процесс организовать для себя и упростит установку пользователю. На счет переносимости я не совсем понимаю о чем идет речь. Но возможно о конфликтах в разных версиях опенкарта. Если речь об этом, то мы и это продумали. Каждый модуль может иметь несколько архивов. Каждый архив должен соответствовать конкретному списку версий опенкарта. И когда вы ставите на свой опенкарт модуль из Shopunity, он установит тот, который соответствует вашей версии опенкарта. Если же такого архива нет - то и установка не состоится.
Вот и вы показали замесательный пример Чтобы установить блог, мне нужно еще 10 подсистем. Ну и .. блог на твиге? и с кешированием шаблонов? А время генерации? Не, просто чтоб поговорить - всегда рад. Но вы меня не убедите.. Или вы покрываете все возможные потребности с ревизией (модерацией) кода Или это будет только ваша ниша. Удачи!
Не совсем понял что именно вы называете подсистемой - 8 js библиотек которые имеют своих разработчиков и свои репо на гите трудно назвать подсистемой. Мы переключились с Shopunity на блог. Блог это всего лишь один из наших модулей. И да, он на твиге но это уже совершенно другая тема для обсуждения. Что касается модерации - у нас она строится из 2х этапов. 1 этап - системные тесты. Проверка на правильность кода. нет ли лишних файлов. Нет ли типовых ошибок в коде и так далее. 2 этап - тестер. Тестер устанавливает и тестирует модули на чистом опенкарте с разных версий. Кстати у нас установлен генератор опенкарт магазинов - за 3 секунды генерируется любая версия что упрощает процесс тестирования. Любя версия для продакшен обязательно проходит процесс "Сабмита". Если тест был неуспешным тестер отпишет причину отказа и после исправления разработчик снова может подать ту же версию на повторное тестирование. Процесс повторяется до тех пор пока тестер не утвердит версию. Этот процесс происходит постоянно - каждый день мы принимаем по 5-10 версий разных модулей. Это позволяет нам быстро выкатывать обновления с фиксами и внедрять новые функции. Я хочу поблагодарить вас за беседу. Даже если мне не удалось Вас убедить в удобстве использования нашей системы, надеюсь разговор все же навел вас на новые интересные идеи. Shopunity это всего лишь инструмент оптимизации работы. Не более. То как его использовать зависит только от разработчика. Приятного вам вечера!
Да это нужно было сделать в самую первую очередь. И не надо ничего планировать В крайнем случае, это можно сделать до первой записи настроек. Т.е для регистрации "клиента". Не забывайте, что частично разработки идут на тестовых доменах, которые далеки от реальных. Вашей работы, но не работы пользователя. Я вам показал пример, на блоге, что для этого мне нужно самостоятельно усттановить еще 10 зависимостей. Если вы имеет свою систему установки - то доведите ее до логического окончания Каждая подсистема имеет уникальный id с номером версии Каждый модуль тянет с собой весь комплект зависимостей, а система инсаляции самостоятельно разбирается с версионностью Тогда все будет хорошо. Но я сужу по первому впечатлению первое впечатление меня не впечатлило.
Я видимо Вас сейчас удивлю, но именно так и работает Shopunity если вы устанавливаете через Модуль Shopunity. Если же вы по старинке закачали один из наших модулей через FTP или Extension Installer - Вам придется действительно активировать каждый нужный модуль руками. Но этот процесс мы не можем контролировать без подключения магазина к системе - а это происходит при активации шопюнити. Тут Вам решать как вы хотите устанавливать. Вы мыслите так же как мы при создании системы. Если же Вы зашли в Shopunity модуль и активировали его - то вам достаточно открыть таб Маркет где вы можете в один клик установить все модули и все зависимости модуля и все зависимости зависимости модуля и так далее... Все в 1 клик. Именно об этом Вы так настойчиво говорите и именно так и работает наша система. Я надеюсь я смогу прояснить порядок работы для Вас и вы сможете с большей уверенностью пользоваться ей.
10 минут назад.. Захожу в админку, где установлена ваша система. Ну ладно гляну, еще раз Нажимаю на иконку - прдлагает куда-то подключиться.. А не пошли ли вы в ж...? Не надо меня заставлять делать то что я не хочу!!!! Я хочу зайти сразу в систему, и потом!!!! Я может быть захочу посмотреть то что вы мне предлагаете! Простейший пример с гуглофонтами которые находятся в облаках. Как только маршрут до облаков отпал - сайт тормоз. Я пытаюсь пояснить каждый раз заказчикам, верстальщикам - пользуетесь сторонними шрифтами, библиотеками - таскайте все за собой. Пусть это будет чуть медленней, но это будет свое. Зачем мне фонт с облака, если сайт неживой Или зачем мне тормоз, если облако потерялось. Видимо вы мало сталкивались когда люди не могут войти в админку, потому что отпал сервер валют. Я вам привожу реальный пример работы. К любым данным, настройкам на своем сервере, я должен иметь максимально быстрый и простой способ и не зависеть от придумки авторов о "10" кликах Вот когда вы доведете UA до ума - приходите.. Хотя, конечно, спасибо что зашли и услышали.
Вы немного путаете понятия. Ничего страшного просто это разные вещи. Когда вы говорите о google fonts - Вы говорите о CDN - но это совершенно другой подход. Там вы используете ресурсы неспоредственно при работе вашего приложения. Shopunity - это исключительно менеджер приложений. Его задача установить все то что решил разработчик нужно чтобы его модуль работал. Сам Shopunity не выступает как CDN и никогда не будет выступать. Но никто не застрахован от работы серверов. И даже гугл. Но таковы реалии. Думаю вы не будете отрицать что если лег сервер у NPM или Composer то ими тоже не получится воспользоваться. Еще не придумали такое облако))) Если вдруг легло облако - то ничего страшного не произойдет - Вы просто не сможете обновлять модуль или устанавливать новый. Вот и все. Работа самих модулей не зависит от Shopunity и никогда не будет зависить. Проверки на обновления внутри модуля реализованы через JS - как Facebook widget. Я думаю вы понимаете что даже если ляжет Facebook - ваш сайт сможет спокойно работать. Точно по такому же принципу работает и Shopunity. Другими словами наши модули независимы от Shopunity после установки. Надеюсь я смог доступно это объяснить. Если же у вас все еще есть недопонимание - пожалуйста, скажите. С удовольствием объясню Вам.