* 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
Eliminated efficiency.inc.php file - moved functionality to the functions.inc.php file and converted to a function. Called the function in the appropriate area in the recipe_mash.inc.php file.
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
Initial intention was to fix the IBU issue in Bug 3138339 (SourceForge)
plus some other IBU calc issues but one thing led to another and
numerous files needed to be updated. Code in many of the files for this
project is nearly impossible to read due to poor/no formatting. In most of
the updated files in this commit:
* Major re-formatting of code to increase readability.
* Fixes to logic errors; Conditional branches that will never execute
under any circumstance, for example.
* Implemented PHP best practices in code style. The standards listed on
the PEAR site are a good start:
http://pear.php.net/manual/en/standards.php
* Implemented arrays, hashes, constants and 'else' conditionals where
relevant. These features of the language seem to have been overlooked
in most of the files updated.
* All bitterness calculations now use the admin/lib/bitterness.lib.php
library. Cut-n-paste instances of the formulas have been removed from
all modules in the project now (unless I missed any).
* admin/includes/constants.inc.php has been added to the project to
contain constants. Many constants can probably be moved into this file
over time; However, those containing relative paths may prove to be
difficult so they might be better left out.
* Major changes to the method of collecting POST data and formatting it
for commits to the database in the admin/process.php module. The
functionality is the same but it's much easier to read and manage now.
Many of the sections in this file still need to be updated, however.
* Trying to add comment headers to each file as I think about it. A
short description of what the file does goes a long way in helping
to understand the flow.
Overall, there was a reduction of over 2,900 lines of code from these
files being committed. The break down on the larger ones:
recipe_calculator.php = 146
process.php = 2066
importFormVar = 139
calcFormVar = 143
calculations = 414
I hope I haven't stepped on any toes with this update but I believe the
changes make it easier for everyone to read and follow the code and,
therefore, easier to fix bugs, add features, etc.
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.
Added ability for admin to set the hopPelletFactor in the Preferences form.
Added sanity checking to the new field.
The bitterness library pulls the pelletFactor value from the preferences
table now.
Rearranged some of the code for readability and easier management.
Minor update to the interface.
Bitterness Calc
Significant rewrite to much of the code.
Modified interface to allow dynamic additions of hop entry fields.
Max number of hop entry fields is controlled by a constant at
the top of the file: $MAX_HOPS.
Moved all constants to the top.
Moved all JavaScript to bitterness.js since there's a lot more of
it now - the hop entry field stuff is all JS.
Modified the interface to make Garetz calculations optional.
Modifications to $pelletFactor. This is a constant at the top
right now but will soon be set in prefs.
Moved all IBU formulas into a separate library, bitterness.lib.php.
This will allow all IBU calculations to be handled in one file
instead of duplicating the code. The next step is to convert the
recipe/blog IBU code to start using it.
Updated all relevant files to link to the two calculators which
were modified/added.
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).
