Another Geek post, with no pictures.
I seriously overhauled the user class, to abstract the database fields into the object.
What was there before was a mixture of an array ( $user ) and an object ( $userob ).
For a newbie developer, this wasn't very obvious to deal with.
Regardless, the other thing that has always been lacking is abstraction.
There were certain hard coded ways Rick did things and you had to know how the DB was setup.
Now, you don't....
Before you had to do something like:
if ($user['USER_MEMBERSHIP_LEVEL'] == 'Administrator') doSomething();
All well and good for those in the know, but it really made it so there were only 2 or 3 peeps who 'got it'. And if i showed you how a Mod or globalMod was determined, it is even more obscure with a preg_match..
Now, the code is simply:
if ($me->isAdmin) doSomething();
or
if ($me->isMod) doSomething();
or
if ($me->isAnyMod) ... etc etc..
You don't care what the DB value is, because the user class shields you from the DB layer..
This is just one example of about 30 or more things that were changed to make it easier for both the developer ( modder, plugin maker ) as well as efficient code execution
Additionally, all fields in the DB that should have had a default value for the user profile in particular, now DO!
I don't know how many times i see stupid code where we have to wonder if a database value is set and take the configuration value if it isn't, when it would have been much simpler to have a default.
Like posts per topic or topics per page for example...
DB field lengths are also cut down to proper size. If it is a simple yes/no value, then i use 0, 1, with it abstracted. This makes DB record fetching much more efficient overall.
It also fixes BUGS!!! the email user when getting a PM always gets hosed in 7.5.6 and below, because the admin code uses Yes/No for the value and the script side uses On and anything NOT On... egads... now it is simply $me->notifyPM, and the coder has no clue and doesn't care what the value is ( yes, it is 0, 1 now )
Many more changes to the underlying engine have been made.
Like lower case table names, for example. This allows going to/from linux/windows servers a no brainer.
( note: why you would go TO a windows server for ubbthreads is beyond me however

. stay in unix, if you have a choice!! )
All in all, a TON of time was spent just cleaning up junk...
the scripts directory in 7.5.6 had 129 files.
the scripts directory in 7.6 has 98 and will be less when i'm done.
Same for the templates/default directory ( approximate same ratio )
Oh and surprise: there are even comments in the headers to say what the hell the file does and the filenames have been renamed to kinda be more logical...
example 'addaddress.inc.php' -- take a guess what it did.. yup.. no semantic meaning...
now it is included along with other files into one file called:
...
mywatches.inc.php
...
kinda more meaning there...
bla bla bla...
essentially, all this abstraction allows us to make proper DB changes that are needed to move forward without overhauling the code each time. The code stays the same and just the ONE FILE ( class.user.php ) changes to re-abstract the new DB to all the scripts...
what i did for the user class has also been done for the html, mysql, bbcode and mysql classes.
oh, and speaking of bbcode.. there was NO reason to include that file every time in ubbthreads, when the html class was the only one that used it. now, it is only loaded when needed. That is one HUGE class that isn't lugged around anymore.
Same goes for the mailer class...
use it when you need it..
too much more rambling to go here, but suffice to say, the code is much more streamlined, readable, commented AND SECURE!. ( all variables are sanitized.. they weren't before... yes, there are still obscure issues with 7.5.6 security and have been since 7.0 )
bottom line.. a LOT has been done and i can see the light at end of tunnel to beta...
hang in there... i have a couple more picture based posts to follow in the coming week
