Gadgetto

I just tried to implement custom namespaces for all of my SnipWire "extra" classes (service, helpers, installer, ...) but it seems to be a huge modification = a lot of work!

As SnipWire uses a lot of helper classes with common names like "Webhooks", "Taxes", "Functions", Countries", ... there is a big chance it will crash in some environments. I really don't know how to handle this currently. Implementing custom namespaces means editing nearly hundred files.

Do you think its a good idea to use custom namespaces which lie within the ProcessWire namespace:

ProcessWire\SnipWire\Helpers
ProcessWire\SnipWire\Services
...

Besides, I have little experience with namespaces in PHP ...

UPDATE 2020-02-01

SnipWire is now available via ProcessWire's module directory!

https://modules.processwire.com/modules/snip-wire/

Hi @d'Hinnisdaël,

I just installed your module (via "Add Module From URL") but immediately get an exception after hitting download:

Compile error
Cannot declare class ProcessWire\Dashboard, because the name is already in use

I also found the culprit: It's a PHP trait within my module which has the same name as your module class. I'm using PHP traits to split large process modules into smaller parts. Didn't know that traits are treated like class files in namespace.

Do you have an idea how we could solve this with the least effort?

Its also a general question because my module has a lot of helper classes which will collide with other modules sooner or later ...

All my module files are in namespace "ProcessWire". Is it good to use a separate namespace for my module?

<?php namespace ProcessWire;

trait Dashboard {
    /**
     * The SnipWire Dashboard page.
     *
     * @return page markup
     *
     */
    public function ___execute() {
        $modules = $this->wire('modules');
        $user = $this->wire('user');
        $config = $this->wire('config');
        $input = $this->wire('input');
        $sniprest = $this->wire('sniprest');

5 hours ago, porl said:

Does this module handle subscriptions?

Not yet, but I'm working on it.

3 minutes ago, adrian said:

Ryan will review. In the meantime, you can access and edit it at: https://modules.processwire.com/modules/snip-wire/

OK, thank you!

I just submitted my first module to the PW modules directory. The module is a full featured e-commerce module but I couldn't find a corresponding category there.

May I suggest that a responsible person add a new category "e-commerce" (or something similar)?

I just submitted "SnipWire" to the ProcessWire modules directory. ?
What happens now? Is it in review state and how can I access/edit the module entry?

Sorry, I couldn't find any infos regarding this.

UPDATE 2020-01-30

SnipWire 0.8.0 (beta) first public release!

It is done! After almost 1 year of hard work and a lot of help from the usual suspects I just released the first public version!
Please note that this is still a beta so please test, test, test before you use this plugin in a real project.

The module can be loaded via PW modules directory (just submitted - in review I think) or directly via GitHub.

More infos will be added soon ...

UPDATE 2020-01-28

I just added the Snipcart "Custom Order Fields" feature!

Thank's @Noboru & @d'Hinnisdaël & @szabesz for your help and hints!

Custom order fields can be added/configured by editing a hidden config page under Admin > Setup > SnipWire > Custom Cart Fields.
The corresponding template/page/field resources are preinstalled by SnipWire installer. If you update to the new module versions, those resources will be added too!

The config page has a single textarea field where you can add the configuration strings for your custom cart fields:
(multi language support is also available)

... can also be edited and enabled/disabled from within SnipWire module config.

The config from the screenshot above leads to the custom step "Order Info" in checkout process:

The Snipcart docs for Custom Order Fields (v 2.0) can be read here:
https://docs.snipcart.com/v2/configuration/custom-fields

Next step is to implement custom product fields! When this is done, I'll release the first official version. SnipWire will then be added to the ProcessWire module directory (as far as @ryan accepts it).

1 hour ago, d'Hinnisdaël said:

This might just be enough, but will this work reliably with multi-language setups?

The way I've done it in the past is by creating a repeater matrix field that has a string, an integer and a bool type for creating and editing options. But you'd have to create a field on installation and the matrix module isn't free, so I guess that's out of the question?

Yep, multi-language will require to use PW fields (at least to keep things simple). So I’ll stay with installing a cart template and a cart page where admins could add their custom cart fields. In the first version, I’ll solve this with a textarea field where the custom field config can be stored as is.

21 hours ago, szabesz said:

Yes I do. I thought there is "custom data" related to each order but if not, then that is a different story.

Ah, ok! Snipcart custom order fields are global and valid/used for each order/cart.

On 1/24/2020 at 9:43 AM, d'Hinnisdaël said:

That's what I've done in the past: create an order template with fields that I map to custom options. Also good to have the consent text editable by site editors.

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?

8 hours ago, szabesz said:

Each pw order page could store the data of the related extra order fields. Order pages could be saved under Admin (page id 2) > Snipcart Orders > [order#n] similar to the way PW saves repeaters "hidden" under the Admin page.

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?

7 hours ago, d'Hinnisdaël said:

Are you sure that's the final markup? Whenever I had to use custom fields, the attribute names were kept as custom1, custom2, etc. So the example from the Snipcart docs are copy-paste and not meant to be changed to the fieldnames you have. It's of course possible that both work and Snipcart will detect the fields either way. Just checking

Sorry, I didn’t mean this as the final html markup. I meant the naming convention for PW fields.

I edited my post above.

1 hour ago, szabesz said:

What do you mean by saying "start with"? Is the example above a prefix or the complete fieldname?

Why not? ? 

Good question! ? Its probably the best way to have a separate "order" template. But then wouldn't I also need a separate "Order" page?

1 hour ago, szabesz said:

What do you mean by saying "start with"? Is the example above a prefix or the complete fieldname?

Yep it should be a prefix. Sorry for my bad English ...

8 hours ago, d'Hinnisdaël said:

I think there will be cases where custom fields will differ by product template, so the order might not be guaranteed and it's probably better to name them after their content (custom_field_size instead of custom_field_1). But how do you determine the option n° for Snipcart — if you move around the field in the template, should it keep its ID to keep order records consistent, or does that not matter as long as it's named properly?

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.

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?

8 hours ago, Noboru said:

Hi @Gadgetto, 
I need additional consent to the general business terms. For API version 2 this is documented here: https://docs.snipcart.com/v2/configuration/custom-fields

It works like this in a test in MarkupSnipWire:

 $jsResources[] = 
              '<script src="' . $this->snipwireConfig->snipcart_js_path . '"'
            . (!empty($this->snipwireConfig->snipcart_js_integrity) ? ' integrity="' . $this->snipwireConfig->snipcart_js_integrity . '"' : '')
            . ' data-api-key="' . $snipcartAPIKey . '"'
            . ' 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"'
            . ' id="snipcart"'
            . '></script>';

Could such a custom field be accessible via the configuration? Or is there a better way?

Custom product and order fields are in the works! I am just not sure yet how to make this feature configurable via module config.

On 1/21/2020 at 10:57 PM, d'Hinnisdaël said:

Sounds reasonable. They kind of jumped the gun for marketing reasons there; not a fan of how it was rolled out. How does a production shop even work without analytics and inventory management?

You don't happen to be in contact with them regarding ETAs on those features? I found it hard to get reliable answers even though wish I could switch my sites to their Vue cart layouts and ditch jQuery once and for all ?

This is the answer I got in their Slack developer channel:

Quote

We should be shipping the latest inventory management quirks (in-cart auto-updates of max. available quantities) by the end of this sprint:
Release v3.0.8 - end of 3/2/2020 → 14/2/2020 sprint
Multi-currency isn't strictly planned short term. We should be tackling it somewhere in March. Same thing goes for deferred payments.

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

3 hours ago, jacmaes said:

Hi @Gadgetto Thanks for your effort with this module and making it available to the PW community! I'm installing it right now to give it a try. I've noticed that the module configuration still refers to Snipcart v.2 when version 3 has been out for a few weeks now and looks stable enough. Among other things, the jQuery dependency is gone so I guess you could remove that option, and update the links to the Snipcart JS and CSS files.

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.

10 hours ago, szabesz said:

I think if you make it absolutely clear that the Donate button is for supporting the development of your Mozilla Public License 2.0 licensed module, then it is ok.

Done!

6 hours ago, d'Hinnisdaël said:

Please make it very obvious how to donate or contribute to the project in whatever way is helpful ?

Done! ? - donation button in GitHub repo, forum signature and initial SnipWire forum post. (I hope this is not against forum rules?)

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:

1. No shipping taxes
2. Apply a fixed tax rate:
   A fixed shipping tax rate from taxes configuration is used.
3. 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.
4. 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.