The updates didn’t add any new features, but they did add an important change to the code contained in each one. The full story on that is technical and likely to be quite boring (I’ll expand on this for those interested later in the post). The important bit is that I highly recommend those using Builder and/or any of the above-mentioned plugins upgrade their sites to these new versions.
Updating is important as some of the new features that will be released soon (such as the Builder Blocks that we discussed during yesterday’s iThemes.tv show) will only work properly if all of these updates are present on your system. In other words, if you update Builder to 2.4.15 but have an older version of Tabber Widget on your site, these new features will have a chance of not working properly. Again, please make sure that you upgrade Builder, Builder Style Manager, Builder SEO, and Tabber Widget.
I’m very sorry for this inconvenience. Please leave a comment if you have any questions or concerns.
For those that want to know the technical details, I am more than happy to share them. 🙂
The Builder, Builder Style Manager, Builder SEO Plugin, and Tabber Widget projects all have a shared set of code found in each project’s lib/classes directory. The lib/classes code library provides a robust set of functions and classes that makes development quicker and more reliable. For example, this library contain classes and functions that generate forms, process form data, provide versioned storage systems complete with upgrade abilities, handle files and images, offers a parent class that allows for rapid creation of new editors, etc. This central set of libraries started development with the Builder project and has grown to contain a wealth of valuable code that can be used for numerous projects (as none of the code is Builder-specific). Thus, this library has found its way into other projects.
For a couple of months, I’ve known of a serious problem with this code spreading to other projects: the fact that there is now a possibility of multiple versions of the code being present on the same system. This can be easily caused when more than one project that uses the library is present and only one of the projects is updated after a new library release. Since only one set of the code libraries can load, it was impossible to ensure that only the most current version of the libraries loaded. If the old set of libraries loaded, it could very easily cause the updated project code to fail.
These new releases contain a new set of the lib/classes code (version 1.2.0) which addresses this issue. Now, instead of a first come, first loaded process of deciding which library version loads, each project’s library registers itself. When all the plugins and the theme have loaded and registered their respective versions of the library code, a process runs that identifies the most current version of the library and loads only that one.
If you are interested in how this works, check out the load.php and init.php files in lib/classes of one of the updated projects. The init.php file is what is loaded when the current version is identified. Inside the init.php file, a function is defined that all the projects use to load that version’s file when needed.