Hi Kstarcher,
Thank you for your input, it is much appreciated. It seems that many of our users are altering the plugins code base, which when the plugin gets updated, is reverted.
We haven’t altered any of the styles within the plugin since we re-launched the plugin. We have added a few additional helper classes, but haven’t removed anything or altered any of the style files. Feel free to take a look at the latest commit to the repository. The one major thing to note is that only 3 of our files were altered in the last release, and none of them were .css files.
When making any alterations to any plugin, you should be making style changes to the theme itself, and not the plugin. Ideally, you should have a child theme setup, so your changes aren’t erased there either.
Sadly, the way inexperienced users alter the plugin code base causes many issues that they are unaware of, which they then pass off as an issue with the plugin itself.
Hopefully, you now have a better understanding moving forward so you can avoid re-doing all of your work each time a plugin or a theme gets updated, and in-turn avoid leaving other developers negative reviews.
Thanks again for taking the time to provide us with some input and leaving a review, even if it wasn’t a positive one.
Evan
Plugin Contributor
Tracy Levesque
(@liljimmi)
🏳️🌈 YIKES, Inc. Co-Owner
Hello kstarcher
I’m really sorry you experienced these issues and I’m not sure why the widget styling would have changed from a 6.x to 6.x upgrade. We didn’t change any of the class names.
The plugin was created in 2012 and contained a lot of legacy code. In order to make the plugin sustainable, and one we can continue to build features for in the future, a complete rewrite was necessary.
Literally 100s of hours went into the rewrite and we tried to make migrating to the new version as painless as possible, but unfortunately dropping depreciated functions and old code forced some users to have to take some extra steps during the process.
I apologize for the problems you experienced.
If you ever use the plugin again we are always here to provide free support for our free plugin.
Thank you!
-Tracy
Evan, I know better than to make changes to a plugin directly. I’m working from the Bones starter theme and building up, so there’s no child theme code to be overwritten either.
It looks like the issue was due to the widget losing its previous ID and so my associated styles were lost. It’s a recoverable issue, but my point is that having to do it already twice means I simply don’t feel I can trust that there aren’t going to be sudden changes again in the future. My client is maintaining the site, and if I’m going to be called in every few months to fix the same thing over and over again, it’s not worth it.
This is the first time I’ve been angry enough to leave a negative review for a plugin. I know sometimes there are good reasons to rewrite a codebase, but if it’s such a dramatic rewrite that people are going to lose their work multiple times, it should have been branched off into a new plugin entirely.
Best of luck in the future.
Again, I’m not sure why your ID’s/class names are changing.
The only thing I can think is that you/your client removed the widget that you had previously styled and added it elsewhere – which would of course alter the ID of the parent contianer based on the widget area/location (eg: yikes_easy_mc_widget-2).
For your future reference, you can easily style the forms globally so that regardless of what form you display in your widget areas, they all appear the same (even after plugin udpates).
.widget-area .yikes-easy-mc-form {
/* styles */
}
Which would style all forms displayed in any widget area the same way. This means if you remove it at some point, and re-add it (Even if in another location) it will appear as it once did.
Even though you’ve since left a negative review and moved on to a different plugin, I felt it would be beneficial to anyone else doing something similar to post the resolution here.
Thanks again!
Evan
