Hi,
Matt from Ecwid here.
Good discussion, @mvbaxter and @ext237. Everything makes perfect sense. In fact, we added your suggestions to our roadmap to implement this in some form in the plugin in the future.
I’ll also add a couple comments and ask your for some additional feedback below.
As you might know, Ecwid is a SaaS solution. All of the code and data is stored on our cloud servers, the content is rendered and delivered to user browsers in Javascript. The Ecwid’s WordPress plugin is only a tip of the iceberg, it is basically a piece of code that adds the Ecwid JS snippet to the site pages, the rest is handled by the cloud part. There are some additional functionality in the plugin, e.g. SEO and some compatibility codes. But those are nothing compared to the Ecwid core code stored with us.
This approach alone gives us a lot of unique features: automatic backups of every store on any site platform — we can restore any Ecwid shop if something happens to the site or hosting; highload management — regardless of the hosting, we handle store traffic and quickly scale up if needed; bank level security of online payments; automatic updates a few times a day — all of the security patches, bug fixes and new features are released to all users centrally.
But there are downsides, which you pointed out: when it comes to customization, Ecwid differs from WooCommerce and other WordPress plugins. Instead of providing open database access, hooks, filters and templates like other plugins, we are providing a REST API, a Client-side JS API, different kinds of webhooks and other ‘cloud-solution-style’ APIs. Part of the reason, of course, is that we need to make sure Ecwid can be customized on various platforms, not just on selfhosted ones like WordPress. Another part is complexity of mixing selfhosted/cloud approaches to API. For example, since the output is generated on our servers (not on a WordPress site), it’s tricky to design filters/hooks properly.
The existing APIs do allow third party developers to extend Ecwid functionality or adapt it to websites better. But as you mentioned, that’s the matter of convenience. The WordPress developers community got used to the WordPress APIs. That’s not easy to switch patterns, especially if you customize several plugins and a theme at the same time and make them work together. No doubt, customizing frontend templates is much more convenient in WordPress “style”.
But that’s still possible to create a useful API for our selfhosted part (WP plugin). And the feedback you provide is of a great help.
Now, as this is apparently a big project, we’d like to understand where to start. So, can you provide a few examples of what exactly you wanted to customize in an Ecwid store recently? For example, changing the colors/fonts of the product description, or building a custom form on the cart page, or binding a custom logic to the “add to cart” event, or embedding product information into another WordPress page etc. The API design suggestion you made are great — we just need to make sure the API we’ll create will help you achieve what you want exactly. When we start working on it, we’d better start with some quick and useful part that would bring value as soon as possible.
Thank you,