Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by Gadgetto

  1. Regarding "custom order fields": It seems you have some experience integrating Snipcart into PW. I'm following your suggestion by preinstalling a "snipcart-order" template and a "snipcart-order" page under Admin / Setup / SnipWire. The goal is, that an admin could add PW fields to this page which should later be mapped (or "translated") to the required Snipcart markup. But how should a PW field look like to get the required values from? Here is a sample Snipcart custom order field markup (taken from @Noborus sample) which should be generated from a PW field: data-cart-custom1-name="By checking this box, I have read and agree to the <a href=\'https://www.processwire.com\' class=\'js-real-link\' target=\'_blank\'>Terms &amp; Conditions</a>" data-cart-custom1-options="true|false" data-cart-custom1-required="true" One idea is, that I simply add a Textarea field where an admin could enter the config string from above. SnipWire will then render this to the <script> tag. BTW, in this case we wouldn't even need a template/page/field. I could simply add a Textarea to module config where these strings could be stored. What do you think?
  2. A single order template with a single order page should be enough (for handling custom order fields). Or do you mean creating a page for each order?
  3. Sorry, I didn’t mean this as the final html markup. I meant the naming convention for PW fields. I edited my post above.
  4. Good question! 🙂 Its probably the best way to have a separate "order" template. But then wouldn't I also need a separate "Order" page?
  5. Taking this example from Snipcart docs ... data-item-custom1-name="Print label" data-item-custom1-required="true" data-item-custom2-name="Size" data-item-custom2-options="Small|Medium|Large" data-item-custom2-value="Medium" data-item-custom3-name="Gift" data-item-custom3-options="true|false" ... this could be translated to this naming convention: snipcart-item-c-{fieldname}-{param} (The "c" is to avoid naming collisions with existing snipcart-item fields) snipcart-item-c-printlabel snipcart-item-c-size snipcart-item-c-gift The n° option could be detected/added automatically by the field order within a template. But would this be flexible enough? If we'd use this convention: snipcart-item-c1-{fieldname}-{param} snipcart-item-c2-{fieldname}-{param} snipcart-item-c3-{fieldname}-{param} We would block the reusability of fields in multiple templates.
  6. Custom product fields I think the best way to implement this is to let SnipWire auto-detect fields in product templates which names start with snipcart-item-custom{index} and if found add their output to markup. The admin simply needs to create those PW fields and add them to the desired product template. Custom order fields Implementing custom order fields will be a little bit more complex as we don't have a specific "order" template where we could attach a field. Processing a Snipcart order also won't trigger any PW page actions so where should we define a custom order field? Any idea?
  7. Custom product and order fields are in the works! I am just not sure yet how to make this feature configurable via module config.
  8. This is the answer I got in their Slack developer channel:
  9. UPDATE 2020-01-19 This is a follow-up to my last post! The question was asked when v3 of the cart system will be implemented in SnipWire. The following features are still missing in Snipcart v3: Digital goods Google Analytics integration Inventory management Deferred payments Multi-currency Recurring subscriptions with Stripe Authorize.net support Some of the listed features are required by SnipWire as they are essential and would require a lot of code rewrites to exclude them. So SnipWire will be changed to use v3 of the cart system when the following features are available in Snipcart: Inventory management Deferred payments Multi-currency
  10. Compared with v2, Snipcart v3 is still not feature complete. Some parts are missing as far as I know. At the moment I don’t know exactly what’s still missing but as soon as v3 is complete, I’ll definitely implement this - or even make it configurable to switch between versions.
  11. Done! 🙂 - donation button in GitHub repo, forum signature and initial SnipWire forum post. (I hope this is not against forum rules?)
  12. UPDATE 2020-01-19 I finally finished the integrated taxes provider - SnipWire now also handles shipping taxes correctly - and in a very flexible way which should cover pretty much all tax calculation methods/requirements worldwide! The integrated SnipWire taxes provider is now even more flexible than Snipcart own integrated provider! A store merchant can choose between the following shipping taxes calculation methods: No shipping taxes Apply a fixed tax rate: A fixed shipping tax rate from taxes configuration is used. Apply predominant tax rate: The shipping costs are allocated entirely to the economic good with the highest tax rate. So the highest tax rate from cart is used to calculate shipping taxes. Proportionally split and apply tax rates: The shipping service is divided as a secondary service and shares proportionally the fate of the respective main service. Part of the shipping service is thus subject to the normal tax rate, part to the reduced tax rate. If you find any other constellations which cannot be covered by the present options, please drop me a line and I'll add it.
  13. I have pushed a small fix regarding the new "multiple product templates" feature. Please redownload at GitHub.
  14. I just implemented your feature request! 🙂 Multiple product-templates are now allowed! Just get latest version on GitHub!
  15. The problem is, taxes handling needs to be bomb proof, otherwise the store merchant could get problems with the taxes authorities. Taxes is one of the last things which needs to be finished before the first release. I'm in contact with the Snipcart guys and I think this should be solved in short time.
  16. UPDATE 2020-01-14 What's new - what has been added - what has changed: I had to completely remove the DateRangePicker.js library because of quirks on mobile devices and accessibility problems. The dashboard date range picker has been completely rebuilt with default ProcessWire fields - and I think it looks great + its now fully working on mobile devices + its more accessible! The orders detail panel is now also capable of changing order statuses and adding order comments (including customer notifications, tracking number and tracking url) Finalized the discount editor: create, edit, delete, archive, unarchive Snipcart discounts A lot of internal fixes and enhancements One of the greatest features of the current version is the dashboard performance. I was able to increase the REST API execution speed by the factor of 2 - 2.5 times What's next: I'm still struggling with taxes handling. Especially the handling of shipping taxes is a complex thing and drives me crazy... DONE! Finishing the remaining detail panels Implementing Subscriptions Implementing Digital Products (probably not in the first release) Implementing a more flexible product template handling (probably not in the first release) DONE! And of course - release! Here are some fresh screens:
  17. Not in the first release. But multiple product templates are definitely planned.
  18. To also give it a visual representation you can additionally add: $f->addClass('ui-state-disabled');
  19. I know Jens, but I'd like to use same references as PW uses. An PW is not yet on ECMAScript 6.
  20. Sorry, for sure I meant SnipWire (I edited my post)! I don't see a reason why this shouldn't work. It probably would be the best, if you install and use the latest versions of SnipWire module and only use custom code where SnipWire isn't ready yet or is missing features you'd like to use. As I don't have a documentation available yet, please don't hesitate to ask your questions here and I'll try to help. If you find any problems/bugs or if you have suggestions for improvement while using SnipWire, it would be great if you could post back here or post an issue at GitHub so I could fix it.
  21. I have a PW panel with a button element inside. When this button is clicked, the panel should close and the button action (href is triggered via JavaScript) should be executed in the main window (from where the panel was opened). In the current state, when the button is clicked, the action is processed within the panel, which is not what I want. Here is the button code: /** @var InputfieldSubmit $btn */ $btn = $modules->get('InputfieldButton'); $btn->attr('name', 'delete_discount'); $btn->href = $this->snipWireRootUrl . 'discounts/?id=' . $item['id'] . '&action=delete_discount'; $btn->aclass = 'DeleteDiscountButton'; $btn->text = $this->_('Delete discount'); $btn->icon = 'trash'; $deleteButton = $btn->render(); Here is the JS part which is triggered when button is clicked: $('.DeleteDiscountButton').on('click', function(e) { e.preventDefault(); var a_href = $(this).attr('href'); ProcessWire.confirm( discountActionStrings.confirm_delete_discount, function() { // dialogue OK click window.location.href = a_href; } ); }); Any hints on how this could be done?
  22. I'm glad you like SnipWire! 🙂 Important: SnipWire is not yet ready for production environments! Subscriptions are on my backlog and will be definitely in the first release!
  • Create New...