What I love most about the WordPress ecosystem is that anyone can be a publisher, anyone can own their content and anyone has the power to manage their site. It's a powerful democratic tool that I believe harkens back to the revolutionaries of the United States.
We’re all familiar with the oft-used axion that with great power comes great responsibility. That could be no truer than when it comes to owning a self-hosted website.
Yet the expectation is that those who contribute code to the WordPress ecosystem are the ones responsible for the success of the sites where that code is used. In my experience supporting a WordPress plugin, the single source of all frustration with those who use the plugin comes from an assumption that if the plugin does not work, it is because the plugin author wrote bad code.
That cannot be further from the truth in most cases. Instead, broken functionality is often the result of components whose code conflicts with one another. While it is certainly possible that one or both of those components (or themes, or plugins, or whatever) contains bad code, it’s just as plausible that both are written rather well and the conflict comes from two valid but differing uses of the same WordPress hook.
In some ways, the general assumption should be turned on its head: we should expect the great possibility that code written independent of one another will not fit together and then be pleasantly surprised when they do.
I wrote the following post on CSS-Tricks to help explain that tension in the specific case when styles conflict between two components. No one like dealing with these conflicts but WordPress does give website owners a handful of ways to overcome them with the help of good ol’ CSS.Direct Link