• Resolved ext237

    (@ext237)


    You keep changing the plugin PHP class names, file structure, HTML and CSS class names. Every time you do an update, my custom CSS, JS and plugins have to be rewritten. It’s ridiculous how unstable your codebase has become.

    Because of the limitations of customization in your product, CSS and JS are the only way to format a website to look nice. But every time you update your plugin, you change CSS class names and HTML structure, often for seemingly no reason or benefit.

    Your latest update changed critical file names and PHP class names, causing my custom plugins to crash. Even commercial plugins that rely on stability in your code crashed such as Ecwid Useful Tools, Ecwid Product Advisor, and Ecwid Widget Avalanche.

    Please provide an update that replaces backward-compatible functionality that was removed in the latest version, so that Ecwid Useful Tools, Ecwid Product Advisor, and Ecwid Widget Avalanche plugins can start working again.

    And stop screwing with the HTML/CSS.

    Joe

Viewing 7 replies - 1 through 7 (of 7 total)
  • Plugin Support ecwid_team

    (@ecwid_team)

    Hi Joe!

    Thanks for reaching out to us. We’re really sorry you’re experiencing issues with the plugin. I see that you’ve left a plugin review message here as well: https://www.ads-software.com/support/topic/extremely-unstable-development-process-updates-break-websites/#post-11640138

    We need more details from you to investigate this, please check out our reply in that post. Thanks, we’re looking forward to hearing from you.

    Thread Starter ext237

    (@ext237)

    Might I suggest that Ecwid Plugin be given a couple of updates to satisfy those like @ext237 and myself, who are used to really customizing a lot of customer sites?

    • An admin panel area with custom CSS references for various parts of the Ecwid presentation. This panel could list the various display items by their common descriptive names, then translate those programmatically to whatever class or ID your developers currently use. That would permit customization of the back-end features with far less interruption to front-end customizations.
    • An admin panel area for custom JS, with documented examples of which pieces and parts are acceptable for customization within your framework. Quform provides documentation with sample code snippets, AND a full API reference for similar customizations.
    • Add several action and/or filter hooks to various portions of the output and/or workflow. This would permit customizations at safe and documented points controlled by your developers. Such a filter would allow me to add custom options to various controls (like the Date Picker), without having to pick through your classes with jQuery (or similar framework). Provided with sufficient hooks, we custom developers would have very little need to perform undocumented modifications. Instead, we would follow a model very similar to WooCommerce and their hundreds of third party plugins, and plugins to plugins, and themes.

    Understanding that these suggestions are not overnight remedies, and would require a full regression test prior to deployment; I think they would go a long way toward improving the extensibility and reputation of your plugin. This would make it easier for customizers to promote your plugin, and by extension, all of your services.

    Just a suggestion…

    Thread Starter ext237

    (@ext237)

    @mvbaxter there is no like button here, so I’ll reply with thank you.

    I’m not a fan of adding custom CSS into a form field in an admin screen. It’s yet another thing that WP has retrieved from the database and echo into the HTML when a page is rendered. And in-line CSS is rarely the best scenario. Same for JS, having JS in an admin panel form field doesn’t really give you control over when the code is emitted.

    However, taking your suggestion one step further, if we had the ability to give specific objects custom CSS class names in the admin panel, that would be helpful.

    But, your 3rd suggestion offers a significant amount of flexibility. Also, if each section of the Ecwid interface was part of a themeable file that could be overridden in the theme directory, we could build our own interfaces completely.

    I use a calendaring plugin on some sites that provide that customization option.

    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,

    Thread Starter ext237

    (@ext237)

    Interesting, I hadn’t considered The SaaS javascript aspect of page rendering, and how that would affect the ability to hook, filter and theme. With that in mind, it remains important that DOM structure not significantly change so we can use CSS and/or JavaScript to affect customizations.

    The website I previously provided, HoustonPhotowalks.com uses some customizations, however another website, https://calidoguitars.com/ makes heavy use of customizations. I will compile a list of the customizations for you and reply back.

    Thanks for the response and willingness to work with designers/developers of custom sites.

    Interesting, I hadn’t considered The SaaS javascript aspect of page rendering, and how that would affect the ability to hook, filter and theme. With that in mind, it remains important that DOM structure not significantly change so we can use CSS and/or JavaScript to affect customizations.

    Agree. Thousands of Ecwid stores are using CSS to customize look and feel. So, we try to keep the CSS classes and DOM structure unchanged. When changes are inevitable, we make them as feature toggles available for a seller to enable in their control panel. For example, the houstonphotowalks.com uses an outdated Ecwid storefront layout, we completely revamped the storefront 2 years ago. You (or a store owner) can consider enabling it in the store setting — that’ll make it look better. But it’s all right if you don’t want to — this particular feature is under feature toggle so you will be able to continue using the old storefront there.

    The website I previously provided, HoustonPhotowalks.com uses some customizations, however another website, https://calidoguitars.com/ makes heavy use of customizations. I will compile a list of the customizations for you and reply back.

    That would be awesome! Thank you!

    Thanks for the response and willingness to work with designers/developers of custom sites.

    You are welcome. That’s in our best interest. There is a lot to improve for us in this area. So, your honest feedback and discussions like this is of a great help.

    • This reply was modified 5 years, 3 months ago by makfruit.
Viewing 7 replies - 1 through 7 (of 7 total)
  • The topic ‘This plugin is completely unstable’ is closed to new replies.