* Removed check_mobile include which was crashing pages like the admin section (it was previously added to functions.inc.php)
* Fixed ABV display in lists
* Fixed bitterness calculations.
* Removed call-time pass-by-reference in BeerXML parser, since it is no longer supported by PHP
of color management. I moved all color functions into a color library
admin/lib/color.lib.php. I also consolidated a lot of code in various
modules. Three color formulas are available now: Morey, Moser and
Daniels and the user can set their default in preferences.
The lovibond fields have also been removed from each fermentable table and two new fields were added in its place: 'xxxLovibondLow' and 'xxxLovibondHigh' (see below). Only LovibondLow is a required field; If LovibondHigh isn't present, the LovibondLow value will be used as the high value. For example, if Low is 8.00 and High is 0.00 then the range will become 8.00-8.00 in all calculations and presentation of the Lovibond data.
I've also made type updates to most fields in each fermentable table to better reflect the data being stored. This should increase query efficiency, reduce db size and ensure sane data is added.
Obviously, a ton of files had to be updated to enable these changes to the db tables. I also created two new 2.3.3 files under sql/ for new installs or updates.
**Lovibond calculations are currently broken.** This is something I'm working on but I wanted to commit the code I have now since all the sugar_type and PPG changes are finished.
'malt' table
maltYield --> maltPPG
maltLovibond --> dropped
maltLovibondLow --> added
maltLovibondHigh --> added
'extract' table
extractYield --> extractPPG
extractLovibond --> dropped
extractLovibondLow --> added
extractLovibondHigh --> added
'adjuncts' table
adjunctYield --> adjunctPPG
adjunctLovibond --> dropped
adjunctLovibondLow --> added
adjunctLovibondHigh --> added
Defined constants in index.php for various paths (e.g., includes, sections, etc.). Will employ the use of these across the application - this commit begins the process.
The trunk folder is for all new features that are not yet ready for release. This folder will be for stabilizing work as it is built and creating new features.
The releases folder is used for release builds. The earliest available build is 2.3.x, and thus it will have the 2.3 folder. All maintenance and bug fixes go in this folder. No new features whatsoever are to be added in here, keeping those completely in the trunk. When the trunk is ready for the next version, it will have a new folder created for it (releases/2.4 for instance) to stabilizing for final release.
The tags folder is used for individual releases. When a release build is ready to go out for download, that release folder will be cloned into an appropriate tag folder. For example, the releases/2.3 folder will be cloned into tags/2.3.1 for that release, and after more work on bug fixes, it will be cloned to tags/2.3.2. Thus, these tag folders should never be modified for any reason. The tag exists purely as a snapshot of a certain point on the release path, and to modify a snapshot defeats the purpose. Any bug in a tagged release should be fixed in the appropriate release folder (such as releases/2.3 for a bug found in 2.3.1).
