И к названию файла добавлять id заказа и складывать в отдельную папочку, доступную для админа (менеджера), например bill_25.pdf, плюс и перезаписываться не будут.
Как предложения автору- мне кажется что нужно создавать физический файл (флаг F), а уже потом отправлять его пользователю. Потому что часто так случается типа «я счет потерял, дайте мне его еще раз» — а взять то его и негде :)
Судя по флагу I он и не должен создаваться — файл сразу отдается в поток. Можно попробовать флаг S поставить тут в качестве эксперимента (вроде с ним makePDF лучше работал).
Плюс неплохо бы выставить заголовок ответа
header("Content-type:application/pdf");
перед печатью самого файла тут. А потом рассказать, что получилось :)
1. Плагин Commerce Options, в конфигурации — только шаблон страницы товара.
2. В меню магазин — появился еще один пункт — Атрибуты опций
3. Вкладка с атрибутами
4. Режим редактирования
5. На странице товара в админке появилась дополнительная вкладка
6. Режим редактирования
Заполнил один параметр (т.е. это уже и не параметр в привычном понимании)- все работает, здесь видно что цена пересчиталась (выше — цена из стандартного варианта)
Выводится сниппетом — пример по ссылке вначале поста.
Все красиво, но есть и ряд как вопросов:
1. Вообще поменялась концепция, что параметры должны быть в TV, а к этому все в MODx привязано, все компоненты.
Я когда только поставил, подумал что это будет похоже на eList (из состава eFilter), а оказалось что нет. И как к такому магазину прикручивать тот же eFilter пока не понятно — параметров же нет, по чем фильтровать((
2. Как-то много дублирующей писанины — сначала заполнил вкладки в меню (атрибуты), а потом почти то же самое, только с изменением цен — на странице товара. Может, я очередность заполнения не ту применил, или просто с непривычки…
3. На странице товара — если выбрал один атрибут, то его уже не изменить — другие становятся неактивными. И картинки не появились, зря загружал(( Но с картинками — это хорошо будет, типа цвет картинками задавать, или как у меня в примере сезоны.
4. В корзину летит товар с правильной ценой, но без выбранного атрибута (опции), но это я может что-то недопрописал.
Так я и не против, в том числе и пронспонсировать, и не только плагин, а и вообще весь Commerce.
Думаю, и другие присоединятся, если автор где-нибудь свои кошельки опубликует.
Касательно этого топика — просто разбираюсь сам, если попутно это каким — то образом популяризирует этот компонент, ну и хорошо))
Касательно этого плагина — заказчики порой сами не очень представляют, что должно быть в модуле (как и вообще в магазине), поэтому было бы интересно мнение более искушенных людей, свое скромное мнение я высказал.
Ну, а если в дальнейшем будет совсем туго — то и в лс постучусь))
Лучше всего будет взять и доделать, чего не хватает, или хотя бы проспонсировать разработку. Я сомневаюсь, что этот плагин появился от того, что Михаилу нечего было делать (:
Поставил этот плагин github.com/mnoskov/commerce-billpayment
Этот плагин добавляет способ оплаты по выставленному счету.
Т.е. в форме заказа в разделе Способ оплаты появляется пункт «Выставить счет». Если покупатель его выбирает, то после отправки формы автоматически скачивается файл bill.pdf с реквизитами для оплаты и списком товаров, с печатью, с фотографией директора и т.п.
Но файл у меня не создается. И соответственно при скачивании — ошибка.
Причины не нашел — ставил и новый пакет mpdf через модуль Composer, и брал уже готовый от этого компонента с ранее сделанного рабочего сайта — безрезультатно. Хотя плагин mpdf видит, ошибок в логах нет.
Сайт на локалке OpenServer.
Настройки плагина выглядят так
И по нему вопрос — нужно ли прописывать чанки, если нужно, то куда какой из тех что в папке? или если их не прописывать, то по умолчанию из указанной папки? Может из-за этого и файл pdf не создается? И где он вообще должен создаваться?
Стал с пол-оборота, никаких настроек вроде и нет. Админку перезагрузил — и вот они — два виджета на стартовой странице админки, все как на скриншоте по ссылке.
Все замечательно, спасибо.
Я, конечно, не маркетолог, но этого ИМХО, как было выше сказано «для промышленного применения» маловато будет. Это не критика (прав таких не имею), это пожелание если компонент будет развиваться — надо статистику не только по дням за текущий месяц (пусть и по сравнению с предыдущим), но и по месяцам, по годам.
И не только по заказам, но и по продажам (исполненным заказам).
И по другим — которые до исполнения не дошли, сколько и каких.
В натуральных выражениях и процентах.
Возможно вы и правы, я сайт верстал сам barbos.by/
Но там есть страница одного («товара») так сказать, и сердечко вроде совсем в воздухе висит. Я склонен думать что это JS. Вот если кто глянет, вообще хорошо будет ))
1. Добавились шаблоны чанков и во фронт, и в модуль, в том числе чанк пустой корзины, теперь if отпал за ненужностью.
2. В заказах добавилась возможность редактирования заказов, скриншоты ниже.
3. Добавилась очистка корзины.
4. В модуль Commerce добавились поля, по ним пока информации нет.
5. Капчу в форму заказа теперь можно добавлять.
Это то что бросилось в глаза, наверное и еще есть.
Кодировки пока остались в старом варианте((
По самому обновлению — вроде без замечаний, все перезаписалось, за исключением плагина Commerce — установилась новая версия, при этом старая версия плагина не отключилась, получилось 2.
Спасибо. Конечно, с foreach лучше, на это и akool намекал выше, как я понял. Но делать не стал по следующим причинам:
1. Рецидив SHK, понятно что от него надо избавлять и принимать новые подходы, но вольно или не вольно все-равно клонит к тому что привык((
2. Как я понял, многие «обвесы» здесь делаются вручную, может оно и лучше, пока рано судить. Но если какие-то вещи прописываются под конкретный проект, то зачем делать лишнее.
3. Как сказал автор, есть модуль по опциям, хоть и сырой. Но это он сегодня сырой. Но еще будет «завтра»))
Хотя, наверное, это было бы удобно, по образу и подобию как сделано у вас в eFilter — закинул в нужную категорию ТВ — и сниппет (плагин) его тут же добавил в список параметров на странице товара (как у вас tovarParams).
По _extDocLister — тут у меня пробел. Конечно, доки я читал, но когда не сталкиваешься одного «читал» мало. А столкнулся первый раз в примере, которым поделился kassio / И то он для DL, а как на странице я пока и не разобрался.
В любом случае для «промышленного» применения эти опции нужно как-то автоматизировать, т.к. могут быть товары с совершенно разными характеристиками. Потому надо:
1. предварительно собрать массив с именами и названиями опций (например из таблицы ТВ, если они идут оттуда)
2. проходить массив $data['options'] через foreach и заменять названия на нужные, попутно преобразуя массивы значений (если встретились).
Т.к. в функцию передает $eDL (наверно это объект $_extDocLister) — то там должны быть доступны и его методы setStore/getStore — т.е. массив опций может быть получен один раз и не надо будет постоянно туда что-то дописывать при появлении новых опций.
По кодировке тоже спасибо, учту на будущее. Но здесь выше уже очень даже справедливо советовали не лезть в исходный код. Там и без моих кривых рук есть кому поправить))
Скорее всего баги в верстке и стилях.
Посмотрите по стилям. Эти айфоны и айпеды многие современные стили просто не понимают, из-за этого блоки могут наезжать друг на друга — визуално это не видно, но один блок закрывает другой (на котором как раз ссылка) и кажется что ссылка не работает, а по факту — вы по ней и не кликаете, а кликаете совершенно по чему-то другому (блоку который наехал сверху).
Плюс может где-то какого стиля не хватать, типа relative + z-index «поиграться», в общем смотрите в сторону верстки и особенностей браузеров apple.
Из ранее выявленных, чего он не понимает — относительные размеры, min-, max-, flex только через -webkit и то не все. Ну и т.д. — хорошо бы найти список непонимания и как с этим бороться, может где и есть. Если кто найдет — киньте ссылку))
С недавних пор начал практиковать bootsrap-4 — это жесть, так и хочется повесить плагин с заставкой, как раньше практиковалось — обновите свой старый браузер, только с фразой — купите себе другой телефон.
Плюс неплохо бы выставить заголовок ответа
перед печатью самого файла тут. А потом рассказать, что получилось :)
github.com/mnoskov/commerce-options
ну, сразу и поставил.
На этот раз установился без проблем.
1. Плагин Commerce Options, в конфигурации — только шаблон страницы товара.
2. В меню магазин — появился еще один пункт — Атрибуты опций
3. Вкладка с атрибутами
4. Режим редактирования
5. На странице товара в админке появилась дополнительная вкладка
6. Режим редактирования
Заполнил один параметр (т.е. это уже и не параметр в привычном понимании)- все работает, здесь видно что цена пересчиталась (выше — цена из стандартного варианта)
Выводится сниппетом — пример по ссылке вначале поста.
Все красиво, но есть и ряд как вопросов:
1. Вообще поменялась концепция, что параметры должны быть в TV, а к этому все в MODx привязано, все компоненты.
Я когда только поставил, подумал что это будет похоже на eList (из состава eFilter), а оказалось что нет. И как к такому магазину прикручивать тот же eFilter пока не понятно — параметров же нет, по чем фильтровать((
2. Как-то много дублирующей писанины — сначала заполнил вкладки в меню (атрибуты), а потом почти то же самое, только с изменением цен — на странице товара. Может, я очередность заполнения не ту применил, или просто с непривычки…
3. На странице товара — если выбрал один атрибут, то его уже не изменить — другие становятся неактивными. И картинки не появились, зря загружал(( Но с картинками — это хорошо будет, типа цвет картинками задавать, или как у меня в примере сезоны.
4. В корзину летит товар с правильной ценой, но без выбранного атрибута (опции), но это я может что-то недопрописал.
Думаю, и другие присоединятся, если автор где-нибудь свои кошельки опубликует.
Касательно этого топика — просто разбираюсь сам, если попутно это каким — то образом популяризирует этот компонент, ну и хорошо))
Касательно этого плагина — заказчики порой сами не очень представляют, что должно быть в модуле (как и вообще в магазине), поэтому было бы интересно мнение более искушенных людей, свое скромное мнение я высказал.
Ну, а если в дальнейшем будет совсем туго — то и в лс постучусь))
github.com/mnoskov/commerce-billpayment
Этот плагин добавляет способ оплаты по выставленному счету.
Т.е. в форме заказа в разделе Способ оплаты появляется пункт «Выставить счет». Если покупатель его выбирает, то после отправки формы автоматически скачивается файл bill.pdf с реквизитами для оплаты и списком товаров, с печатью, с фотографией директора и т.п.
Но файл у меня не создается. И соответственно при скачивании — ошибка.
Причины не нашел — ставил и новый пакет mpdf через модуль Composer, и брал уже готовый от этого компонента с ранее сделанного рабочего сайта — безрезультатно. Хотя плагин mpdf видит, ошибок в логах нет.
Сайт на локалке OpenServer.
Настройки плагина выглядят так
И по нему вопрос — нужно ли прописывать чанки, если нужно, то куда какой из тех что в папке? или если их не прописывать, то по умолчанию из указанной папки? Может из-за этого и файл pdf не создается? И где он вообще должен создаваться?
github.com/mnoskov/commerce-dashboard
Стал с пол-оборота, никаких настроек вроде и нет. Админку перезагрузил — и вот они — два виджета на стартовой странице админки, все как на скриншоте по ссылке.
Все замечательно, спасибо.
Я, конечно, не маркетолог, но этого ИМХО, как было выше сказано «для промышленного применения» маловато будет. Это не критика (прав таких не имею), это пожелание если компонент будет развиваться — надо статистику не только по дням за текущий месяц (пусть и по сравнению с предыдущим), но и по месяцам, по годам.
И не только по заказам, но и по продажам (исполненным заказам).
И по другим — которые до исполнения не дошли, сколько и каких.
В натуральных выражениях и процентах.
Если убрать из сниппета Order
include_once MODX_BASE_PATH. 'assets/snippets/FormLister/__autoload.php';
и из вызова
то все работает ок (((
Корзина и форма заказа у меня на одной странице,
Cart page ID
Order page ID
в конфигурации плагина id этой страницы указал.
До обновления работало отлично, только корзина автоматически не очищалась после отправки заказа, но она и сейчас не очищается.
Или я какие-то изменения не разглядел и не внес.
Но там есть страница одного («товара») так сказать, и сердечко вроде совсем в воздухе висит. Я склонен думать что это JS. Вот если кто глянет, вообще хорошо будет ))
1. Добавились шаблоны чанков и во фронт, и в модуль, в том числе чанк пустой корзины, теперь if отпал за ненужностью.
2. В заказах добавилась возможность редактирования заказов, скриншоты ниже.
3. Добавилась очистка корзины.
4. В модуль Commerce добавились поля, по ним пока информации нет.
5. Капчу в форму заказа теперь можно добавлять.
Это то что бросилось в глаза, наверное и еще есть.
Кодировки пока остались в старом варианте((
По самому обновлению — вроде без замечаний, все перезаписалось, за исключением плагина Commerce — установилась новая версия, при этом старая версия плагина не отключилась, получилось 2.
скриншот 1
скриншот 2
Кстати, добавьте что есть еще instance=order и шаблоны в папке lang/russian-UTF8.
1. Рецидив SHK, понятно что от него надо избавлять и принимать новые подходы, но вольно или не вольно все-равно клонит к тому что привык((
2. Как я понял, многие «обвесы» здесь делаются вручную, может оно и лучше, пока рано судить. Но если какие-то вещи прописываются под конкретный проект, то зачем делать лишнее.
3. Как сказал автор, есть модуль по опциям, хоть и сырой. Но это он сегодня сырой. Но еще будет «завтра»))
Хотя, наверное, это было бы удобно, по образу и подобию как сделано у вас в eFilter — закинул в нужную категорию ТВ — и сниппет (плагин) его тут же добавил в список параметров на странице товара (как у вас tovarParams).
По _extDocLister — тут у меня пробел. Конечно, доки я читал, но когда не сталкиваешься одного «читал» мало. А столкнулся первый раз в примере, которым поделился kassio / И то он для DL, а как на странице я пока и не разобрался.
1. предварительно собрать массив с именами и названиями опций (например из таблицы ТВ, если они идут оттуда)
2. проходить массив $data['options'] через foreach и заменять названия на нужные, попутно преобразуя массивы значений (если встретились).
Т.е. каким-то таким путем
Т.к. в функцию передает $eDL (наверно это объект $_extDocLister) — то там должны быть доступны и его методы setStore/getStore — т.е. массив опций может быть получен один раз и не надо будет постоянно туда что-то дописывать при появлении новых опций.
По кодировке тоже спасибо, учту на будущее. Но здесь выше уже очень даже справедливо советовали не лезть в исходный код. Там и без моих кривых рук есть кому поправить))
Ну а чтобы получать «человеческую» кирилицу в json уже давно придумали флаг JSON_UNESCAPED_UNICODE :)
Посмотрите по стилям. Эти айфоны и айпеды многие современные стили просто не понимают, из-за этого блоки могут наезжать друг на друга — визуално это не видно, но один блок закрывает другой (на котором как раз ссылка) и кажется что ссылка не работает, а по факту — вы по ней и не кликаете, а кликаете совершенно по чему-то другому (блоку который наехал сверху).
Плюс может где-то какого стиля не хватать, типа relative + z-index «поиграться», в общем смотрите в сторону верстки и особенностей браузеров apple.
Из ранее выявленных, чего он не понимает — относительные размеры, min-, max-, flex только через -webkit и то не все. Ну и т.д. — хорошо бы найти список непонимания и как с этим бороться, может где и есть. Если кто найдет — киньте ссылку))
С недавних пор начал практиковать bootsrap-4 — это жесть, так и хочется повесить плагин с заставкой, как раньше практиковалось — обновите свой старый браузер, только с фразой — купите себе другой телефон.