Ты же сам ответил уже на свой вопрос))
Да и потом addData не привязан к miniShop2, он работает с любыми ресурсами.
24 марта 2017, 11:47
0
Ну через join скорее всего — да
24 марта 2017, 08:30
0
Да, параметр-ресурс.
24 марта 2017, 08:08
0
В своих таблицах.
23 марта 2017, 17:40
0
На модерации, будет позже.
22 марта 2017, 20:33
0
А так получается?
...
...
...
$modx->sendRedirect($modx->makeUrl(123, '', '', 'full')); // 123 - ID страницы, куда нужен редирект
exit;
13 марта 2017, 09:54
0
Добрый день!
Ну тогда некорректно поставлена задача:
Нужен только разработчик функционала, дизайн и верстка уже есть.
Если нужно будет, что-то, разработать уникальное, обращайтесь.
А на эту задачу, наверняка кто-то найдётся, благодаря нашим комментариям, и приступит к настройкам.
О! Узнал знакомый почерк)).
Рад, что всё получилось!
08 декабря 2016, 19:53
0
Работа с tv как-то в minishop2 не комильфо
В компоненте есть выбор, или использовать TV, или кастомную колонку в таблице miniShop2, если это для miniShop2.
По остальным вопросам ответил выше, спасибо за вопросы!
08 декабря 2016, 19:43
0
А это наследие от клиента, который заказывал этот компонент а потом переключил меня на другое.
Я ещё много вырезал, там и контроль остатков был, и оповещение менеджеру о статусе кол-ва «Ноль», и возможность разрешать подписку тем или иным (авторизован/не авторизован), и возможность выбора проверки адреса почты с подтверждением или через проверку записи DNS… (не помню, это я сам придумал или он заказывал, точно знаю — что ему нужен был реальный адрес почты — всё сразу пишется в рассылку (Sendex), любитель, умеренно, поспамить, просто))), ну и т.д.
Зачем обязательное имя и количество?
Имя нужно для обращения к человеку посредством обратной связи — это правильно, мне кажется.
Количество: оно не обязательно, можно вырезать из формы — будет один всегда. Замысел был такой: ведётся учёт всех ожидающих товар, с выводом в бекенд, где в первую очередь показываются самые востребованные — статистика, одним словом.
Если клиент введет, допустим 2, то если товар 1, то ему никогда не придет оповещение и даже этот 1 товар ему не продадите.
Так вот для этого и нужно кол-во предполагаемой покупки. Всё правильно, как мне кажется, — зашёл менеджер в таблицу ожидаемых товаров, накинул сверху n-ое кол-во и отдал в отдел поставок (ну или заказал/купил) — разослал уведомления потенциальным заказчикам.
Просто мы, наверное, разные вещи подразумеваем, — ведь товар может быть не только розничный, но и оптовый.
Да даже если и розничный, в штуках, ведь, не всё меряется, допустим в строительстве…
Так и каким в итоге способом происходит оповещение?
Пока ни каким, поэтому и alpha-тестирование.
У меня есть мысли по поводу оповещения, как со стороны заказчика, так и от себя.
Хотелось бы услышать разработчиков, работающих со своими клиентами — их мысли, чтобы этот компонент был максимально универсален.
05 декабря 2016, 23:37
+1
Изменить параметр &logoutResourceId, по умолчанию — текущий ресурс, в вызове сниппета ajaxLogin:
Да и потом addData не привязан к miniShop2, он работает с любыми ресурсами.
Ну тогда некорректно поставлена задача:
Если нужно будет, что-то, разработать уникальное, обращайтесь.
А на эту задачу, наверняка кто-то найдётся, благодаря нашим комментариям, и приступит к настройкам.
1. mSearch2
2. Импорт/Экспорт
3. Для ЯндексМаркета есть это msYmarket, для гугла можно настроить здесь
4. Если имеется ввиду sitemap, то в pdoTools есть сниппет pdoSitemap
5. miniShop2 это умеет делать.
6. Tickets
7. HybridAuth
8. easyComm — рейтинг, комментирование. Сравнение товаров Comparison
Не понимаю, что тут нужно ещё разработать?
А много вообще записей в БД?
Нужно детально всё обсудить.
Контакты в профиле.
Пришлите ТЗ на marat@marabar.ru
Рад, что всё получилось!
По остальным вопросам ответил выше, спасибо за вопросы!
Я ещё много вырезал, там и контроль остатков был, и оповещение менеджеру о статусе кол-ва «Ноль», и возможность разрешать подписку тем или иным (авторизован/не авторизован), и возможность выбора проверки адреса почты с подтверждением или через проверку записи DNS… (не помню, это я сам придумал или он заказывал, точно знаю — что ему нужен был реальный адрес почты — всё сразу пишется в рассылку (Sendex), любитель, умеренно, поспамить, просто))), ну и т.д.
Имя нужно для обращения к человеку посредством обратной связи — это правильно, мне кажется.
Количество: оно не обязательно, можно вырезать из формы — будет один всегда. Замысел был такой: ведётся учёт всех ожидающих товар, с выводом в бекенд, где в первую очередь показываются самые востребованные — статистика, одним словом.
Так вот для этого и нужно кол-во предполагаемой покупки. Всё правильно, как мне кажется, — зашёл менеджер в таблицу ожидаемых товаров, накинул сверху n-ое кол-во и отдал в отдел поставок (ну или заказал/купил) — разослал уведомления потенциальным заказчикам.
Просто мы, наверное, разные вещи подразумеваем, — ведь товар может быть не только розничный, но и оптовый.
Да даже если и розничный, в штуках, ведь, не всё меряется, допустим в строительстве…
Пока ни каким, поэтому и alpha-тестирование.
У меня есть мысли по поводу оповещения, как со стороны заказчика, так и от себя.
Хотелось бы услышать разработчиков, работающих со своими клиентами — их мысли, чтобы этот компонент был максимально универсален.
Должен сработать.