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)
Added a hack to work locally for me. May move to using composer to obtain / install vfsStream just didn't like the "vendor" directory, will look into using a custom directory so it can be hidden git ignored.
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.
In an effort to only maintain compatibility with the latest version of PHP (currently the 5.5 branch) I dropped the sanity checks if `json_encode` was available as it is always available in PHP 5.2+. Dropping this sanity check also allowed me to remove the wrapper function and the `JSON_AVAILABLE` constant. Ideally I'd like to move towards dropping the `Convert` class entirely but will need a way to convert an array to XML as the `RSS` class still leverages it. One thought is to move that code right into the `RSS` class as it never gets used elsewhere because XML is gross.
Includes AYAH v1.1.7, a static wrapper class and an update to our main include file to handle loading the official AYAH library from the vendors directory.
Instead of making the Module the keeper of validation, moved the actual sanity checks to another class. This makes it stupid easy to use one module's validation (some or all) to validate arbitrary values elsewhere in your system.
Primary key queries should not be cached because the record may not exist today but could exist in the future and because the INSERT logic in PICKLES doesn't do any invalidation of the cache.
If you tried to use the extended array syntax to query against the primary key (id) and passed it an integer instead of an array, an error was occurring. Thanks @geoffoliver !
Pass a Model an optional second or third parameter to force the Model to check the cache before running the query and stashing the results in the key for future queries.
Caching was limited to single row selects against the primary key. Expanded to include cache checking and storing when selecting multiple values against the primary key. Does not work on any other row due to the fact that some rows may have duplicate values and the mapping could get borked pretty quick.
Too much juggling to make sure the proper assets were loaded. Opened up a security issue that allowed some pages to be accessed even if data was missing, just a headache, best to move away from it and allow users to defining custom routing in inde.php. Perhaps down the road allowing a Route class that the user can define everything in.
If you're pulling data against a single column and returning a single column the UID will be cached out to a key that can easily be recalled the next time the same query is executed. On UPDATE and DELETE the corresponding keys are deleted.
