Recently Browsing 0 members
No registered users viewing this page.
SnipWire - Snipcart integration for ProcessWire
With SnipWire, you can quickly turn any ProcessWire site into a Snipcart online shop. The SnipWire plugin helps you to get your store up and running in no time. Detailed knowledge of the Snipcart system is not required.
SnipWire is free and open source licensed under Mozilla Public License 2.0! A lot of work and effort has gone into development. It would be nice if you could donate an amount to support further development:
Status update links (inside this thread) for SnipWire development
2020-07-03 -- SnipWire 0.8.7 (beta) released! Fixes some small bugs and adds an indicator for TEST mode 2020-04-06 -- SnipWire 0.8.6 (beta) released! Adds support for Snipcart subscriptions and also fixes some problems 2020-03-21 -- SnipWire 0.8.5 (beta) released! Improves SnipWires webhooks interface and provides some other fixes and additions 2020-03-03 -- SnipWire 0.8.4 (beta) released! Improves compatibility for Windows based Systems. 2020-03-01 -- SnipWire 0.8.3 (beta) released! The installation and uninstallation process has been heavily revised. 2020-02-08 -- SnipWire 0.8.2 (beta) released! Added a feature to change the cart and catalogue currency by GET, POST or SESSION param 2020-02-03 -- SnipWire 0.8.1 (beta) released! All custom classes moved into their own namespaces. 2020-02-01 -- SnipWire is now available via ProcessWire's module directory! 2020-01-30 -- SnipWire 0.8.0 (beta) first public release! (module just submitted to the PW modules directory) 2020-01-28 -- added Custom Order Fields feature (first SnipWire release version is near!) 2020-01-21 -- Snipcart v3 - when will the new cart system be implemented? 2020-01-19 -- integrated taxes provider finished (+ very flexible shipping taxes handling) 2020-01-14 -- new date range picker, discount editor, order notifiactions, order statuses, and more ... 2019-11-15 -- orders filter, order details, download + resend invoices, refunds 2019-10-18 -- list filters, REST API improvements, new docs platform, and more ... 2019-08-08 -- dashboard interface, currency selector, managing Orders, Customers and Products, Added a WireTabs, refinded caching behavior 2019-06-15 -- taxes provider, shop templates update, multiCURL implementation, and more ... 2019-06-02 -- FieldtypeSnipWireTaxSelector 2019-05-25 -- SnipWire will be free and open source Plugin Key Features
Fast and simple store setup Full integration of the Snipcart dashboard into the ProcessWire backend (no need to leave the ProcessWire admin area) Browse and manage orders, customers, discounts, abandoned carts, and more Multi currency support Custom order and cart fields Process refunds and send customer notifications from within the ProcessWire backend Process Abandoned Carts + sending messages to customers from within the ProcessWire backend Complete Snipcart webhooks integration (all events are hookable via ProcessWire hooks) Integrated taxes provider (which is more flexible then Snipcart own provider) Useful Links
SnipWire in PW modules directory SnipWire Docs (please note that the documentation is a work in progress) SnipWire @GitHub (feature requests and suggestions for improvement are welcome - I also accept pull requests) Snipcart Website
---- INITIAL POST FROM 2019-05-25 ----
I'm a newbie to Process wire. I'm trying to pass the form values to a different URL (i.e to sales force). We have a RestAPI to do a post method with URL Prams. when we tested the rest API it works with static values. So, i select the the option called submit to another URL in actions tab in my form.
So now the issue is how can i pass the field values dynamically to the REST API prams on form submit?
If their is any easy way to submit form details to sales force please advice.
Thanks in advance!!
I have a marketplace site built on PW which I'd like to tie to a subscription payment system for those selling. The user accounts currently use specific PW user accounts. I'm looking closely at PayWhirl to manage payments and subscriptions as it looks ideal for subscriptions. Their API seems to work well too from initial testing.
I wondered if anyone else in this super forum had used PayWhirl and had any advice or tips & tricks?
Hi, I have created a site profile that shows how to integrate ProcessWire 3.0 with Vue 2.0. See repository here.
How this site profile works
This ProcessWire site profile is loosely based on the REST API tutorial by @gebeer. Here are the most important steps to reproduce it:
Create an api template with default settings and just the title field assigned to it. Refer to @gebeer tutorial for further details
Create a pages and nav templates with just the title field, for both template tick “Allow URL Segments” in the “URLs” tab (see attachment)
Create a home template, this is going to be the single php file that will load your Vue SPA. Assign this template to the root of your website
Any other template you create should have the “Alternate Template Filename” field in the “Files” tab set as home (see attachment), in this way if a user enter the website from any url that is not the root, ProcessWire will always redirect to the home template, Vue router will handle the url and call the right data through the REST API
Under the root, create an api page and assign the api template to it (you can set “hidden” to this page so doesn't show up in the menu)
Under the api page, create the pages nav and pages (see attachment), and assign the templates nav and pages to them. Now you have the www.sitename.com/api/pages and www.sitename.com/api/nav urls that you can use to fetch the JSON data
PHP template setup
In the templates folder, create home.php file and leave it empty, the HTML will be generated by webpack
Now create pages.php and nav.php files. On these files is where we return the JSON data, based on the right url segment. Again, refer to @gebeer tutorial for further details on this matter. Note that I wrote a PageFields class that I use on these templates to fetch ProcessWire fields. The fields that are supported are text, textarea, repeater, img. Other fields may work but I haven't tested them. See the REST API setup for further details about how to use the PageFields class
REST API setup
You can decide what fields are included and what fields are excluded by passing a configuration array to the PageFields class. You can find here a list of the available configuration settings. See examples below.
Show only selected core fields: $pageFields = new PageFields($p, [ 'fld_core_included' => ['url', 'httpUrl', 'template'] ]);
Show no global fields, and only selected custom fields:
$pageFields = new PageFields($p, [ 'fld_core_included' => , 'fld_include_all' => false, 'fld_included' => ['title', 'gallery'], ]);
On a gallery image field, hide breakpoint listing and show only httpUrl field:
$pageFields = new PageFields($p, [ 'img_fld_overrides' => [ 'gallery' => [ 'fields' => ['httpUrl'], 'bp_list' => false ] ], ]);
The most important file of all Webpack setup is config/index.js. On line 33 you need to provide your domain name so that Webpack can proxy the ProcessWire REST API to the Webpack dev server. Without this you wouldn't be able to take advandage of the Webpack hot module replacement feature which allows you to reload a vue module without refreshing the page, it also allows you to keep the state of the app.
My REST API may have bugs, this is just an example of an integration with ProcessWire, I suggest you either build your own REST API or use the awesome GraphQL module by @Nurguly Ashyrov.
Replace REST API with the GraphQL module. This requires vue-apollo, the Apollo/GraphQL integration with Vue, and vue-supply for integration with Vuex.
I am running development server where I test and try the changes in fields and templates of ProcessWire. The php files are stored in git@bitbucket.
The part of managing changes and versions of php code itself via git is quite straightforward, as I presume we all know. However, I have not been able to come up with decent way of moving the changes in fields, templates, modules and settings from development to production other than repeating them, step-by-step, manually in production environment via the admin back-end.
Perhaps there is more sophisticated way of transferring these changes?