Облако Вебасист = наручники для проекта Есть решение

Дико бесят ограничения в облаке Вебасист. Для проектов, которые висят там, нельзя залить свой хелпер или плагин. Если это читает кто-то из сторонних разработчиков, который тоже занимается разработкой сайтов "под ключ", то он понимает, что ни 1 подобный проект не обходится без своих хелперов или индивидуальных плагинов.

И как тут быть? Вот конкретный пример:
Нужно вывести часть категорий отдельно от всех в меню. Да, в {$catmenu=$wa->shop->categories()} можно указать ID родителя, внутри которого делать выборку, а этот ID вынести в настройки темы оформления. Но вот конкретно в моем случае это не катит. Могу долго объяснять почему, но просто поверьте на слово - не подходит такой вариант. Вывести нужно с десяток категорий, при этом они динамические и поэтому их нельзя просто перенести в другого родителя и сделать выборку по нему. При этом фиксировано сверстать тоже не вариант. Клиент не обязан в этом разбираться. И с учетом всех особенностей задачи самым простым способом было бы скрывать категории. То есть они не выведутся в основном списке, т.к. скрытые, но с помощью хелпера в пару строк я бы вывел в отдельном месте лишь скрытые. Ну или с помощью плагина я мог бы доп. настройку сделать для категории. Но нет, мы в облаке. И крутись тут, как хочешь. Да, я конечно нашел решение этой задачи самым адекватным методом. Самым адекватным среди костыльных... То есть делать настройку в шаблоне, где админ через запятую укажет ID категорий для отображения в отдельном месте. В самом шаблоне 2 раза делать вывод и имитируя РНР в одном из них скрывать эти категории, а в другом наоборот выводить... Через пол года клиенту нужно будет изменить эти категории и он хрен вспомнит всё это. Да и без этого минусов хватает.

И это далеко не единственный пример. Буквально в каждом проекте приходится прятать "выбираемые" характеристики из списка. Например есть у куртки 2 цвета, которые юзер сам выбирает. Зачем писать это в списке характеристик товара? Минимум не логично. А может еще и отпугнуть. Скажите в цикле вывода {$product.features} сделать условие и не выводить по ID? А я вам усрусь, но найду пример с практики, где такой способ ломал всю страницу. То есть расположение элементов на странице зависит от наличия характеристик. Если {if !empty($product.features)} вернет ложь, то у нас отрисуется блок с заголовком и таблицей характеристик. А он и вернет ложь, если там будет только этот выбираемый размер. То есть блок с таблицей нарисуется, но содержимого не будет. В результате - багнутая страница какая-то. И адекватное решение тут - писать хелпер, который пройдется unset'ом по лишним характеристикам(которые мы хелперу через запятую и указали). И тогда всё отлично будет и без проблем. Ах да... Хелперы же зло и не имеют право на существование в облаке.

Частенько из-за особенностей товара нужно 1 из его характеристик выводить еще в категории. Без хелперов не сделать. Через summary? Так тогда надо свой плагин для прямого импорта писать. А нельзя, ага...
Вебасист в таком случае конечно может сказать "Ничто не мешает вам этот плагин в магазине опубликовать и клиент его скачает". Но те, кто публиковал свои плагины там, поймут, что это звучит как "Отвалите, по договору мы ни чем не обязаны". Зачем мне ждать неделю на проверку очень индивидуального плагина? Зачем мне засирать магазин? А потом еще и объяснять третьим лицам, скачавшим плагин, что он сделан не для них и выпускать обновления я к нему не собираюсь?


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

3 ответа

  • 6
    Леонид Вакуленко Webasyst 8 апреля 2015 06:52 # Решение

    Облачный хостинг - это надёжный и безопасный способ открыть новый интернет-магазин. Его ценность в том, что сломать его сложно, а починить, обратившись в техподдержку, очень легко. Чтобы обеспечить это условие, приходится жертвовать гибкостью настройки. Когда/если магазин перерастает эти ограничения, значит, пришло время купить лицензию, переехать на свой отдельный хостинг и настроить там всё под себя. Но и отвечать за все косяки своих разработчиков тоже придётся владельцу магазина.

    • +1
      Виталий . Виталий . 6 декабря 2015 14:59 #

      Так нет техподдержки больше, как таковой.

      И где плюсы вышеописанного???

      • +1
        Алексей Алексей Webasyst 6 декабря 2015 15:58 #

        Общие запросы, которые могут быть полезны другим пользователям, лучше задавать здесь.
        Персональные по оплате или работе своего аккаунта(в том числе и восстановление из бэкапа) через Центр заказчика.

  • 1
    Михаил Ушенин Webasyst 8 апреля 2015 07:03 #

    >>> Нужно вывести часть категорий отдельно от всех в меню.

    Видимо, вам не хватает возможности указать массив ID категорий при вызове $wa->shop->categories()? Отправляйте пожелания в службу поддержки, чтобы нужные вам возможности добавляли в магазин. Чем больше людей будут присылать пожелания, тем больше полезных для всех хелперов будет добавляться.

    >>> приходится прятать "выбираемые" характеристики из списка

    А зачем для них вообще вносили значения, если их не нужно отображать? Или я неверно понял суть задачи?

    >>> из-за особенностей товара нужно 1 из его характеристик выводить еще в категории. Без хелперов не сделать

    Этот хелпер вам не подходит: $wa->shop->features()? Если он не очень удобен для отображения именно одной характеристики, воспользуйтесь плагином.

    • 0

      >>> Видимо, вам не хватает возможности указать массив ID категорий при вызове $wa->shop->categories()?

      Массив тут не поможет. Да и не совсем понимаю, что он выдаст в итоге. Нужна возможность выбрать скрытые категории. То есть для public function categories($id = 0, $depth = null, $tree = false, $params = false, $route = null) добавить еще 1 параметр $show_hidden=false. Это только для этого случая. Но вполне может быть полезно в будущем для других.

      >>> А зачем для них вообще вносили значения, если их не нужно отображать? Или я неверно понял суть задачи?
      Вот тутпример. Зачем система насильно отображает характеристику "Объем встроенной памяти" с тремя вариантами, когда это явно разные для каждого артикула значения? При некоторых условиях дизайна и типе товаров, это может вызвать вопросы у покупателя.

      >>> Отправляйте пожелания в службу поддержки, чтобы нужные вам возможности добавляли в магазин
      Я год назад просил разрешить использование unset() в шаблонах. Полтора года назад я просил внедрить правила именования CSS классов и айдишников для разработчиков плагинов, а сейчас у каждого второго имеются конфликты(иногда нерешаемые). Если я что и понял за почти 3 года общения с Вебасист, так это то, что проблему можно решить только обнародавав её на публику(как и всё в этой упитой стране). Чем я сейчас и занимаюсь.

      • +4
        Михаил Ушенин Михаил Ушенин Webasyst 8 апреля 2015 07:54 #

        >>> Вот тут пример. Зачем система насильно отображает характеристику "Объем встроенной памяти" с тремя вариантами, когда это явно разные для каждого артикула значения?

        Не вводите значения этой характеристики для всего товара (на вкладке "Характеристики"). У артикулов они пусть останутся, но отображаться на странице товара уже не будут.

        >>> Я год назад просил разрешить использование unset() в шаблонах.

        Видимо, было принято решение так не делать. Просьба не обязательно означает выполнение как бы ни хотелось пойти вам лично навстречу. Но это совсем не означает, что обоснованные пожелания не нужно присылать. Если вы опасаетесь, что пожелания теряются и не доходят до руководства отдела разработки, то напрасно — это не так.


        Немного оффтопика:

        >>> как и всё в этой упитой стране

        Как вы яхту назовёте, так она и поплывёт.


        Резюме:

        Руководство компании осознанно выбрало такую модель использования фреймворка в облачном хостинге, прекрасно понимая, что кое в чём связывает руки тем, кто хотят выполнять дополнительные доработки сайта, и что компания будет неизбежно что-то терять от ухода клиентов на другие хостинговые площадки. Поэтому единственное, что можно сделать в этой ситуации — это добавить нужных хелперов в стандартную "коробку" Shop-Script, чтобы как можно меньшему количеству пользователей приходилось уходить на другой хостинг именно из-за нехватки плагинов и хелперов. А узнавать о том, какие именно хелперы чаще всего нужны, мы можем только от вас, пользователей и наших партнёров-разработчиков. Тут выгода обоюдная: мы будем меньше терять клиентов, уходящих из облака, а вам будет удобнее разрабатывать темы дизайна и делать их всё более функциональными, а значит, продающимися.

        • +1

          >>> Не вводите значения этой характеристики для всего товара (на вкладке "Характеристики"). У артикулов они пусть останутся, но отображаться на странице товара уже не будут.

          Да никто их там и не вводит. Они автоматически проставляются при сохранении товара. И нужно потом ручками убирать их. Проходиться ручками по большому ассортименту - не вариант. Особенно если речь идет об импорте с поставщика. Проще скрыть их на странице товара.

          >>> Видимо, было принято решение так не делать.
          Далее будет много оффтопа о наболевшем. Да вот понимаете, в чем дело. Я ведь тоже вроде не дурак. Я не из тех, кто жалуется и винит Путина из-за повышения курса доллара и кризиса. Я понимаю, что на всё есть свои причины.
          Я не требую срочно ввести какой-то функционал, который мне нужен. Но давайте остановимся на конкретном примере с unset(). Что мешало(-ет)? Это откроет какую-то дыру? - нет. Это потребует большой работы и изменения в текущем функционале? - нет, это пару строк кода. И как ни искать, но причины этого НЕ делать нет. Однако это не сделано до сих пор. Да, есть такое понятие, как приоритет. Но на что он расставлен? Убиты сотни трудочасов сотрудников на построение графика на странице пред-редактирования товара. Рационально... Молодцы, порадовали 1% клиентов. Хотя можно было потратить в 32 раза меньше времени на расширение функционала корзины, о котором я писал 2.5 года назад, и порадовать этим в десятки раз больше клиентов. И привлечь новых, путем уменьшения "показателя отказов" среди клиентов, которых не устроили отсутствие содержимого корзины на всех страницах.
          Я еще понимаю отказ насильно заставить разработчиков плагинов делать классы и айдишники по маске. То есть чтобы они(мы) всплывающим окнам не просто класс .popup давали, а потом другие мучались с конфликтами и сломанными страницами, а сразу давали им .quickorder_popup(никаких претензий к разработчику quickorder'a. Его можно считать образцовым). Понять могу, т.к. сейчас кучу обновлений придется проверять. Но я об этом и говорил еще в те времена, когда в магазине было меньше десятка плагинов. Я бы ни капли не разочаровался в вашем подходе, если бы хоть 1 из "навангованных" мною проблем, на которые я яро просил обратить внимание, не переросли бы в эти самые проблемы, а остались лишь в моем больном воображении. Отсюда и разочарование и полное отсутствие желания писать подобные просьбы. Я не ТП тут виню. Я прекрасно понимаю, что ребята там делают лишь то, что им говорят. И делают это хорошо. У меня сегодня отвисла челюсть от того, что сотрудник ТП с 8-800 телефона не перенаправил меня куда-то там, а сам посмотрел код и сказал все возможные варианты решения моей проблемы. То есть у вас там не блондинки со скриптами разговорными сидят, а квалифицированные специалисты. Но вот человек, который отвечает за модель развития в целом, должен быть уволен на**й.

          Резюме:
          Кто отвечает за подобную политику? Как зовут этого человека? Почему он еще не уволен? Куда писать письмо с просьбой о его увольнении, ссылаясь на явные его ошибки, которые были очевидны еще на старте проекта?


          PS

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

  • 2

    Да.... Если у Вас сайт в облачном хостинге - программист Вам не нужен - он все равно ни чем Вам не поможет....

    Все понимают, что все в облаке работает на надежность и стабильность, но надо как-то Вам решать проблему с индивидуальным кодом.

    Разрешить хотя бы использовать свои хелперы и свои плагины.

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

    часто сталкиваюсь с просьбами пользователей допилить какую-то мелочь - а сайт в облаке. Уже 3 мои клиента ушли с облака только по причине "ни че низя".

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

Добавить ответ

Чтобы добавить комментарий, зарегистрируйтесь или войдите