Sage is my new ‘Franks Red Hot Sauce’. I put that shit on everything.
One of the first things I do after cloning sage is create a new folder inside /lib named after my theme. I put all theme specific .php that is not template code in here. I understand that Sage is not meant for child theming and altering it’s code is welcome and encouraged.
Still, that goes against what we’ve been taught about modifying 3rd party libraries. So I really resist editing any sage files if I can. But sometimes I have to and can’t help but wonder why.
For instance, in /lib/titles.php where the is_home() title is determined, if I want it to say something other than ‘Latest Posts’ I can just change it there. But why not include a filter so I can change that value without touching Sage files? What’s the philosophy there?
It is a goal of ours to make Sage fully object-oriented at some point. This will allow you to extend Sage objects and manipulate them without having to touch Sage’s core code. WordPress hooks are not necessary to do this. We have started down this path with Sage 9.
There are a few reasons I didn’t go full OOP in my contributions to Sage 9. Part of it was the task of translating all of our utility functions into objects in a way that doesn’t come across as contrived. The other reason is that naming stuff is hard. 
3 Likes