Have you ever had to exclude an element from a collection so you could run a plugin method with two different sets of arguments? Have you ever had to modify someone else's (or maybe your own) plugin for a specific use case and felt dirty for doing so? When dealing with plugins, do you frequently think to yourself there's got to be a better way to develop plugins? You're not alone. Shane Riley, the front-end development lead at Hashrocket, is tired of modifying plugins to suit a particular need and fearing the modified plugin will be overwritten by future Shane when he realizes there is a new version out. To that end, he set out to change the way he, and hopefully others, develop plugins to eliminate this worry and hassle and returned with a solution that's not only super-extensible at the plugin level, it's also completely customizable at the element level once the plugin has been initialized. Intended for those who have experience writing and/or modifying plugins, Shane will walk through the process he now uses in his own plugin development to ensure that if the plugin doesn't exactly suit your use case, you can make it easily and without having to change the core code of the plugin.