Not being used and the logic is pretty damn hacky. I don't believe in JOINs so
I'm unsure if this support will be re-added in the future or if there will
simply be a backed in opinion that JOINs are the devil.
Never gets used, ended up being somewhat MySQL specific as PostgreSQL favors
letting the server handle it instead of hinting at it. Write better queries I
suppose?
Finished up all the low hanging fruit (working the classes I already started
that were just shy of 100% coverage). Just shy of 80% coverage at this point.
Also fixed a few minor bugs and reworked Browser class to not use the constant
UNIT_TESTING so I could get the class to 100% coverage. Adds a dependency of
testing_helpers which I believe is available on Travis CI by default. Up to 75%
coverage, w00t w00t!
Also found a bug in the Form class that would bork phone numbers with dashes in
them. Even though the Form class is going to go away eventually I wanted to fix
the issue.
The class didn't provide any value and promised that it would in the future.
Any sort of redundant connection logic should simply be contained in a class
that can be extended and not an API-centric common class. Trying to move away
from all common classes in favor of classes that can be reused in different
parts of the core as well as outside of it.
Travis is failing and barking about an undefined index "cache". Found the one place I'm referencing it without checking it first and added an isset(). Not failing locally so perhaps it's an issue with PHP 5.5.6 in comparison to 5.5.7 or some other nuance I'm not aware of.
Added a new 404 system which checks for templates/__shared/404.phtml (module-less bare in mind) and falls back to a generic Apache-ish Not found page with PICKLES shout out. Added some more assumptions (login page is always /login a/k/a the login.php module) also there's no way to customize which template is used for the 404. Removed some code that was no longer used in the Security class.
Very hacky, switched variables to public and added a catch in the __get method to assign to the right place for the variables that modules are using (instead of having to update all of the modules in the wild)
Just need to include `?pretty=true` to a request and the JSON returned will be formatted. As I was digging in there I think I may consolidate all of the Display logic into a single class and potentially bring back `.json` and `.xml` extensions to dictate what is returned. Would help a ton in scenarios where I have an endpoint that I want to server up a template on error or return JSON on success.
