Question:
Hello, So I come from a background as a full stack / backend developer who has built several websites and backend systems for our business, and has handled all infrastructure for several years. I’m not a designer, so we have very functional websites that don’t look very good. We’ve hired a designer who has convinced us to use wix , Which while he created some websites that look wonderful, The backend functionality from existing plugins was embarrassing to say the least.
But that’s what I do for a living, Wix seems to allow for code and extensions, Why not make an extension that blows everything else out of the water?
And to be fair, I’m Extremely impressed with Wix’s velo and tooling.
But while everything in the Wix Blocks seems to indicate that the thing should work as expected, There seems to be SERIOUS limitations on what a Blocks extension can actually do when installed on a live site, to the point here I’m questioning whether it’s even possible to make an app that does anything more powerful than displaying a timer in wix. Several times now I think I’ve thought up a solution to one of my problems (caused by these limiations), Only to find even more limitations, all of which seems to be caused by Block Extension Functionality just … Not Working , On the live site.
If I’m just an idiot and there’s some dumb easy fix to these issues, I’d like to know.
If these are real limitations and I’ve wasted 5 weeks of 2 developers time, I’d also like to know.
To clarify, There’s 2 environments – Wix Studio (Site) , and Wix Blocks (Extension), And 3 cases : Site Code running on site , Extension code running on Blocks Editor, and Extension code running on Site. When you look at these 3 cases for things I’m trying to do, It’s highly inconsistent :
API Endpoints - This is the one thing that works on the live site because there’s a separate url endpoint for the SITE endpoint and the EXTENSION endpoint on the site. But there’s no “Site” endpoint on the blocks environment, so There’s no way to test this in the blocks editor.
Web Modules - Site modules work on the live site, and blocks modules work in the blocks editor, but the blocks modules DO NOT work on the live site. I took a working extension in the editor, that didn’t work on the live site, and had to change it to an api endpoint that no longer worked in the editor, but did work on the live site.
Wix Pay Backend StartPayment function - Site Code works on site, Blocks code does nothing in editor, Blocks code does NOT work on the live site (via api endpoint, cannot hit web module because web module does not work)
Widget Public Functions - Blocks code works in editor, does NOT work in live site. For some context, My idea was to just create a PUBLIC FUNCTION on the widget (which is a horrible design fragmentation of functionality) that, I thought would work exactly like in the Blocks editor when you inport a widget, it has an #id that you can call and have access to the public functions in the widget, Have the Site code backend call the wix-pay-backend function, and have the site frontend put a button with an onclick connectButton() function . Something like
$w('Site-frontend-button').onclick((e)=>{ $w('widget').connectButton(); })
that will run the appropraite code. But for reasons I cannot quite comprehend from a technical perspective, There is NO #ID on a widget on the wix studio site frontend. So unlike a widget object in the wix blocks editor, on the wix studio site, a widget is not an “object” and you can’t interact with the widget at all programmatically. But other objects in the wix studio frontend on the same page are objects that can be interacted with? And you can interact with a widget object in exactly this way on the Blocks editor? It’s just a devistating limitation that severs the last ideas I have for this being even possible within this environment. I’m genuinely hoping I’m wrong abou this, But this is the point I’ve had SEVERAL times in the past now where I compeltely give up on trying with a technology because It’s just not possible to do what I need to do (or not worth the effort to figure it out) and look elsewhere.
Product:
Blocks, Studio
What are you trying to achieve:
Press a “Pay Now” button to pay for the thing my extension is providing.
To clarify further : Site Owners wants to offer thing X on their website. Site Owner Installs our GCM Extension. Site Owner inputs X’s Information on the CGM Section of the Site’s backend, and the GCM Extension does various ongoing processes based on that informaiton (X also offered elsewhere, so information on X needs to be continuously synced). On the Site, Potential customers can navigate to the list of X’s, and choose the ones they want. They can see up-to-date information on the X, provided by the ongoing processes in the backend of our CGM app running on the Site. CGM provides the pages that shows the list of X’s and the indivdual X, and the payment flow for X (Offered by site owner) to potential customers, as well as ways to interact with X after payment. Payments go to Site Owner and fulfillment of services for X are the responsibility of the Site Owner. (Specific details withheld due to agreements with my company)
Ideally, This would be self-contained within our GCM Extension, A one-click extension (plus enter some information on the backend) to allow site owners to easily offer X. We have an immediate need to use this ourselves, but we would like to launch on the Wix App Marketplace.
I’ve resolved all issues and have the extension working up to the payment, which if I can have a payment process correctly and confirm X on the backend, The MVP of the app is complete and we can launch it immediately to our website for real testing. We have customers waiting to use this, and we’re already a week behind becuase I can’t for hte life of me figure out how to “Start a payment”.
What have you already tried:
Everything I can think of.
Additional information:
I’ve been extremely impressed with the wix environment, the dsign tools, velo code, sites and extension caabilities, But the limitations are stacking up to the point (I guess at least for an extension system) where it’s almost becoming a non-starter for any future projects. Are these limitations the reason why we had such a poor experience with the original app we tried to use?
I guess thinking about it we may be able to implement this within just a site itself without trying to package it into an extension, which we might try if we cannot get any progress on this, but that effectively destroys the entire design of the system and limits it to just our sites (which will be duplicated and then need to be maintained separately).
