Jump to content

Gadgetto

Members
 View Profile  See their activity

  • Posts

    394

  • Joined

  • Last visited

  • Days Won

    12

 Content Type 

Everything posted by Gadgetto

  1. 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 ...
  2. Gadgetto
    UPDATE 2020-02-01 SnipWire is now available via ProcessWire's module directory! https://modules.processwire.com/modules/snip-wire/
  3. Gadgetto
    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');
  4. Gadgetto
    Not yet, but I'm working on it.
  5. Gadgetto
    OK, thank you!
  6. Gadgetto
    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)?
  7. Gadgetto
    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.
  8. Gadgetto
    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 ...
  9. Gadgetto
    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).
  10. Gadgetto
    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.
  11. Gadgetto
    Ah, ok! Snipcart custom order fields are global and valid/used for each order/cart.
  12. Gadgetto
    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?
  13. Gadgetto
    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?
  14. Gadgetto
    Sorry, I didn’t mean this as the final html markup. I meant the naming convention for PW fields. I edited my post above.
  15. Gadgetto
    Good question! ? Its probably the best way to have a separate "order" template. But then wouldn't I also need a separate "Order" page?
  16. Gadgetto
    Yep it should be a prefix. Sorry for my bad English ...
  17. Gadgetto
    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.
  18. Gadgetto
    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?
  19. Gadgetto
    Custom product and order fields are in the works! I am just not sure yet how to make this feature configurable via module config.
  20. Gadgetto
    This is the answer I got in their Slack developer channel:
  21. Gadgetto
    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
  22. Gadgetto
    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.
  23. Gadgetto
    Done!
  24. Gadgetto
    Done! ? - donation button in GitHub repo, forum signature and initial SnipWire forum post. (I hope this is not against forum rules?)
  25. Gadgetto
    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.
×
×
  • Create New...