Forum Replies Created

Viewing 15 replies - 1 through 15 (of 93 total)
  • Thread Starter smgdarien

    (@smgdarien)

    I understand it’s an expected display of how Pay Later works, however the fundamental of Woo is having complement control. Not offering store owners flexibility on this displaying or opting for their own custom version is quite disappointing

    The official Afterpay plugin themselves offer extensive display options, so suggesting this counts as a custom development is beyond frustrating. As a developer, in my opinion it’s a lazy implementation that isn’t following WooCommerce’s best practices.

    As an enterprise store processing high volumes I know reaching out to my dedicated channel would result in a proper solution. However I always try the standard support avenue to continue advocating for my small stores. Seeing this as a response to what any median developer would know is an essential feature isn’t acceptable

    As relayed in my other support topic which wasn’t resolved and given the same “this requires custom development” I would suggest opting for Shopify if you require these features. While the benefit of Woo is to have complete control, it seems WooPayments is heading towards limited developer accessibility as well.

    Thread Starter smgdarien

    (@smgdarien)

    Oh this is disappointing! Most third parties offer this feature but as a high volume store we are moving towards first party plugins only

    Shopify Markets would be a great to take inspiration from, as this feature is included and quite easy to implement

    As a developer I tried sourcing a filter myself from the plugin which wasn’t possible. Forking a payments plugin isn’t a viable option whether I did it myself or via Codeable.

    For now I’d suggest anyone looking to have greater control over the price to opt for Shopify

    Thread Starter smgdarien

    (@smgdarien)

    “4 interest-free payments of A$12.25 with Afterpay” now appears under my cart totals. Deactivating WooPayments removes this. WooPayments doesn’t have any options to hide this promotional message.

    Adding CSS to remove it isn’t practical or the best approach for performance.

    smgdarien

    (@smgdarien)

    This would be so good!

    Thread Starter smgdarien

    (@smgdarien)

    It didn’t work. I am adding a shortcode to the single product page

    It overloads the site and crashes it with thousands of admin-ajax.php requests

    Thread Starter smgdarien

    (@smgdarien)

    Thank you!

    Thread Starter smgdarien

    (@smgdarien)

    Ah that’s quite disappointing! Hopefully this can be fixed soon

    Thread Starter smgdarien

    (@smgdarien)

    Just a follow up, the .json file requires “server_network_requests” to be added alongside “client_network_requests” to the permissions parameter

    I’m having the same issue, no add to cart events. Pixel Manager Pro JS error Uncaught SyntaxError: Invalid or unexpected token

    Thread Starter smgdarien

    (@smgdarien)

    Over 500 people had to report their frustrations with Gift Cards not syncing over eight years before it became the only new feature unrelated to payments introduced to this plugin, based on what I’ve seen in the changelog over the past few years.

    Importing 10,000 products from Square when only 1,000 active products are in use (9,000 archived in Square) is a huge bug. Adding 9,000 unused products to the database tables does not follow WooCommerce’s best practices for database optimization.

    Even with the best hosting, submitting bulk actions to unpublish 9,000 products isn’t viable. Creating 1,000 products manually is unnecessary double handling.

    Prompting users to submit a feature request is a last-ditch effort when band-aid fixes aren’t a viable workaround for the customer. Take a look at the feature requests yourself; the only one implemented over the span of eight years was Gift Cards. By the time that was introduced, I’m sure 99% of the customer base had abandoned this plugin and Woo. I now have to pay Codeable to build a custom plugin purely because the “official” plugin lacks essential features. I use “official” lightly, as Square themselves even acknowledge how poorly developed this integration is and don’t take any accountability for its lack of functionality. I’d go so far as to say that not syncing additional images would mark this plugin as broken.

    Thread Starter smgdarien

    (@smgdarien)

    Over 500 people had to report their frustrations with Gift Cards not syncing over eight years before it became the only new feature unrelated to payments introduced to this plugin, based on what I’ve seen in the changelog over the past few years.

    Prompting users to submit a feature request is a last-ditch effort when band-aid fixes aren’t a viable workaround for the customer. Take a look at the feature requests yourself; the only one implemented over the span of eight years was Gift Cards. By the time that was introduced, I’m sure 99% of the customer base had abandoned this plugin and Woo. I now have to pay Codeable to build a custom plugin purely because the “official” plugin lacks essential features. I use “official” lightly, as Square themselves even acknowledge how poorly developed this integration is and don’t take any accountability for its lack of functionality. I’d go so far as to say that not syncing additional images would mark this plugin as broken.

    Thread Starter smgdarien

    (@smgdarien)

    I can see multiple requests for this feature since 2016 acculumating to over 100+ upvotes. 8 years and it still hasn’t been added. This is extremly slack on WooCommerce’s part

    Adding another feature request to that graveyard of a list is pointless

    Thread Starter smgdarien

    (@smgdarien)

    Square has the option to archive products, these products should not be imported at all by this plugin.

    Altering 10,000 product statuses from published to private isn’t viable

    Thread Starter smgdarien

    (@smgdarien)

    Adding an option in both APIs to specify which products WooCommerce imports (and which it doesn’t) is easily achievable.

    Requiring all store owners to manage their products exclusively through WooCommerce is not a viable solution.

    If a store has over 10,000 products in Square but only 1,000 are needed on WooCommerce, this creates a significant amount of unnecessary postmeta bloat and extra work for the client. Importing all 10,000 products and then changing the status of 9,000 products to draft or private could potentially break the store. A possible workaround would involve batch updates, for example, updating 100 products in bulk per session. However, this process would be extremely time-consuming, even with a great host. I personally host WooCommerce stores on an optimized stack with dedicated VPSs and a separate database. Even in this scenario, managing such a high volume of batch updates isn’t fast.

    Furthermore, the proposed workarounds contradict WooCommerce’s best practices for maintaining a healthy and optimized store. Keeping 9,000 redundant products, complete with excessive metadata, especially in filtering tables, due to the plugin’s lack of essential segregation features is inadequate.

    The responses so far have not been practical and are merely temporary fixes for what, in my opinion, are essential tools for effectively handling both online and in-person POS experiences. If the Square for WooCommerce integration is this limited and there are no plans to update it to address these issues, it essentially encourages all store owners to switch to Shopify. It’s unreasonable to ask a retailer to adjust their entire data flow simply because of this plugin’s limitations or lack of development.

    I’ve considered another workaround when these temporary solutions prove infeasible, which is to create a feature request. After reviewing hundreds of feature requests, some with hundreds of upvotes over six years, it’s apparent that this plugin has been neglected with no attempts to improve it further. The only significant update was the addition of gift cards, a feature initially requested eight years ago. If I’m expected to wait eight years for a simple option to specify which products should be imported from Square to WooCommerce, you can understand why a developer with extensive experience in WordPress and WooCommerce, like myself, is frustrated and would rather switch to Shopify.

    Thread Starter smgdarien

    (@smgdarien)

    This would require each store to purchase an additional license for Square’s Retail Plus plan, which isn’t a feasible option since Retail Plus is priced per location.

    Additionally, setting up a separate location would necessitate maintaining two stock bases, despite all 14 products being sold at a single location. This arrangement would render inventory synchronization completely redundant.

    I’m sure you understand how crucial this tool is, and why the proposed workaround is not viable. Having a sales channel toggle to easily enable or disable products across WooCommerce and Square is essential.

    The “Import All” feature is suitable for very small stores with minimal product counts. However, the ability to select specific products to sync (and create) from Square to WooCommerce is critical. I would expect many store owners to find this useful.

    For comparison, Shopify allows sales channels to be easily enabled or disabled per product.

    From an API perspective, I see no limitation on either side that would prevent achieving this. It could even be handled purely within the WooCommerce plugin through the Square settings, syncing only products from specified categories.

    For example, if I have a product called ‘Maxi Dress’ categorized under ‘Dresses’ and ‘Online’ in Square, Square for WooCommerce should only flag products with the ‘Online’ category to be uploaded to WooCommerce. Note that ideally, the category should be ‘Dresses’—this is just an example, and the setup could be organized differently. However, using WooCommerce, Square, or this plugin as an excuse for why this isn’t possible is not acceptable. This capability is entirely feasible and, frankly, should have been implemented from the start.

Viewing 15 replies - 1 through 15 (of 93 total)