wordpress widgets: refactoring, part 3

WordPress Widgets Refactoring, Part Arguably, the problem with Boilerplate is that everything is encapsulated within single class.   In terms of updating WordPress Widget Boilerplate, we've come long way in terms of refactoring how it's organized...   Thus far, we've looked at how WordPress Widget API provides example of object-oriented programming, how we can use this API to determine object-oriented programming in other areas of WordPress, installed of the code, in terms of modern programming standards, and began re-organizing the code base so that it fits with more modern practices...   I recommend doing so because it's going to take little while to bring this up to date.   Arguably, the problem with Boilerplate is that everything is encapsulated within single class..   Other problems that exist just from looking at the code include adding actions and filters in the constructor, having methods doing more than one thing, not having classes responsible for implementing things like registering dependencies, and so on...   In this post, we're going to start the process of creating abstractions that we'll implement to break up the god-class-like nature of Boilerplate as it stands..   Abstract classes, on the other hand, can have some functionality implemented in the abstract class while leaving the domain-specific code such as loading stylesheets and JavaScript to the appropriate method..   This will become apparent, if it has not already, the further we get into this series.   In the meantime and as per usual do not forget to check out the branch to see where we stand with the code..   Read more