They keep changing the plugin PHP class names, file structure, HTML and CSS class names. Every time they release an update, my custom plugins, CSS, JS, etc have to be rewritten/repaired. It takes hours to debug the random and often/usually unnecessary changes to fix the site again.
In the latest update, they significantly changed the PHP filename structure and class names … this made all plugins that relied on Ecwid’s stability to stop working, resulting in a white-screen-of-death.
Ecwid Useful Tools, Ecwid Product Advisor, and Ecwid Widget Avalanche are affected one way or another.
1-star until their development team stabalizes their workflow and stops causing disruptive outages with each update.
Thank you for your feedback. We’re extremely sorry you’re experiencing issues because of the plugin update.
Can you please provide us with some additional details so we investigate this? Please provide the following details:
— Screenshots of the pages where you receive the errors.
— The steps you take to troubleshoot the issues on your end when making repairs to other plugins.
— A link to your website with your Ecwid store.
Any other details you can provide us with will help. Thank you!
Please send us a message at firstname.lastname@example.org. Our developers will look into this and check how the issues can be fixed. Thank you in advance, we’ll be looking forward to your email.
I have already gotten my site back up. But do a code diff between your last two plugin updates and you will see the filename and code changes that are breaking dependent custom plugins that rely on your code stability, and review your code changes for the past year to see all the HTML and CSS changes that are impacting people’s themes.
I also provided you 3 plugins that are not custom, freely available on the wordpresss plugin website. This will allow you to test your repairs on real-world situations and resolve issues that are negatively affecting your users.
Ecwid’s plugin is the only plugin on any of my client sites that requires me to refactor my CSS every time you update the plugin.
Our developers will take a look at the global Ecwid plugin changes as well as analyze how the changes affect the third-party plugins you’ve mentioned. It would also be really helpful if you could allow our developers to take a look at one of your own custom plugins, so that they could see what it’s based on. This will help us understand how you use the Ecwid plugin with your custom ones and what improvements can be made on our side to the Ecwid plugin’s structure.
If you run into any issues in the future, we would really appreciate if you could provide us with the details from the previous post – screenshots of the errors, your troubleshooting workflow, your website address. Please feel free to send them at email@example.com. Thank you!
Ecwid has the official API documentation for developers: https://developers.ecwid.com/api-documentation
Thousands of developers and partners use it for their purposes. We constantly maintain its backward compatibility to make sure nothing breaks down.
Ecwid itself is constantly growing, which includes changes in the plugin, core service and the API as well (keeping the backward compatibility of the API in mind, of course).
We add new features and fix bugs, thus things change all the time. It’s inevitable, otherwise, there would be no progress in Ecwid development at all.
If third-party solutions such as plugins or other modifications are based on some part of Ecwid that is not a public API (HTML structure, internal plugin code and methods in it, file names, etc.), they may be broken one day as we always improve and change Ecwid. So it’s up to a developer to decide whether to use some undocumented features or not.
If we’re talking about “Product Advisor for Ecwid”, it was using exactly these undocumented elements mentioned above. It’s broken now, right. But well, that plugin was last updated 5 years ago and after that, we contacted the developers on the issue. However, they still haven’t fixed that, which looks like a reason to consider to stop using that plugin.
Of course, we know that someone may have their own custom solutions and plugins that work with Ecwid in an undocumented way. Since there’s no way to track all such use cases, we’d love to get some feedback from you on what you’re achieving with these modifications exactly. What do you change in Ecwid? Which methods do you use?
We will try to take it into consideration and probably create an appropriate API or recommend the existing one. Of course, if you start using the official API methods mentioned above, things won’t be getting broken all the time.
Waiting to hear from you, feel free to send the details at firstname.lastname@example.org.
Ecwid Useful Tools, Ecwid Product Advisor, and Ecwid Widget Avalanche were all affected.
Yes, changes are inevitable. Drastically rewriting code without considering deployment impact is irresponsible.
I maintain 14 client sites, 3 personal sites, and deploy at least 2 new sites per month for other companies I contract for. The ecwid plugin is the only update that requires me to refactor custom css and rewrite jquery selectors.
If this plugin rewrite was completely unavoidable, an advanced email would have been appropriate. As long as ecwid refuses to maintain backward compatibility with the code that is emitted, I will have to stick with my preference not to recommend this product.
You are absolutely right it’s annoying to fix custom solutions and we understand your intention not to recommend our plugin. We are really sorry you need to make changes in the custom solutions after some of our plugin’s updates. This is really frustrating.
The thing is it’s difficult for us to guarantee that custom solutions developed outside our public API will always work properly. That’s due to the fact that we can’t possibly know the workflow of these custom solutions and what elements they are based on, for example, on what particular CSS selectors or features of the HTML structure.
We understand that you’re an experienced developer who supports a large number of sites. Hopefully, you understand that custom solutions based on an open-source code like our plugin may be broken from any change made to it. After all, we do not know where exactly in the code something gets changed with a custom solution.
Then again, this does not apply to the public API as we fully support backward compatibility of the API and we commit to support it further. Therefore, we would like to offer using the official public API in the future. Custom solutions based on it will not be broken after the plugin’s updates.
We totally understand that some changes in the Ecwid plugin may affect third-party solutions that are not related to the API, and we are really sorry about this.
You’re right that it would be great to inform developers about the exact parts we plan to change in the next update in advance. Therefore, all changes made in the plugin are currently described in the changelog. You can view its details to get an idea about the exact changes we make in the new version and what elements in your code may be affected by this update.
Hopefully, we can come to a solution allowing us to work together further. It would be great if you told us more about your custom solutions, describe what elements they are based on, what they do. We may think about the way we can change our API so that it fits your custom solutions and keep you in mind when updating the plugin.
I already provided the requested information in my support email when our Ecwid sites all crashed. Those sites have been repaired and back online after removing the functionality from the 3rd party custom plugins, but here is a current example of issues I outlined.
Note the “drop shadow” included on the blog list on this page: http://houstonphotowalks.com/blog/
This interface element is used for consistency throughout the website.
A 3rd party calendar plugin “panels”, same drop shadow: http://houstonphotowalks.com/
A custom plugin to display advertisements, same drop shadow: http://houstonphotowalks.com/member-perks/
A 3rd party plugin to display “FAQ” items, also same drop shadow: http://houstonphotowalks.com/faq/
The above 3 plugins provide regular updates without changing class names or modifying the most basic structure of the HTML layout. This allows us to provide customizations that are stable and attractive.
The situation is different with the Ecwid store plugin:
Each category should have a white background with a drop shadow like the rest of the site. But because of the constant, arbitrary and unneeded class name and HTML structure changes every-single-time you update the plugin, the CSS has to be repeatedly edited.
As you can see, it looks like I need to go in and edit it. Again. Woocommerce sites don’t require me to budget time for rewriting basic css customizations when they provide updates and security patches.
So why does Ecwid?
- The topic ‘Extremely unstable development process, updates break websites’ is closed to new replies.