Whoops! Thanks for the welcomes, guys! It'd be easier for me to fix this, if I could duplicate it myself, but I've not been able to yet.
1. Many of the files in the zip do not have a closing php tag.
None of my PHP files have closing tags, unless strictly required. And there is absolutely nothing wrong with this, it's actually safer and a better practice.
Zend Framework: PHP File Formatting - "For files that contain only PHP code, the closing tag ("?>") is never permitted. It is not required by PHP, and omitting it? prevents the accidental injection of trailing white space into the response.".
2. The file, cad_db_install.php has an error...I think in the following:// Our variables & values.
$final_array = array(
'lab360_childboard_dropdown' => 1,
'lab360_childboard_limit' => '0'
);Notice that line 23 has no single quotes around the 1 and line 24 has quotes around the 0. Both should be the same I would think...
No, let me explain...quoting an attribute (whether single-quotes or double-quotes) makes that value a STRING. Unquoted values are assumed to be integers. For instance... $variable = 1; is an integer. $variable = '1'; is a string. Even though they'll output identically, they are different TYPES of data.
Here's a little bit of reasoning as to why in this case, specifically, one is cast as a string, and one as an integer. These fields are added to {db_prefix}settings, which are all thrown into the $modSettings array, the settings table has two columns, variable and value. Both of which are expecting strings, so even if you send an integer, it'll be cast to the database as a string.
However, assigning the INTEGER 0 to a variable can also be seen as 'null' or would return !empty as false (empty) because 0 is another way of saying nothing. But the variable HAS to enter the database as 0, and since it's going to be a string anyways, it's cast as a string in the definition of the variable in the array so it's cast, otherwise it'll be considered empty, and not be set in the database properly. Quoting the 0 makes the zero a string, and as long as the string has a character, it's not considered empty. Empty only checks for 0 being an integer, so it HAS to be a string in this scenario to get the proper value sent to the database.
Since 1 is not empty, it's fine to stay an integer, it'll be cast later, but it's still okay to be an integer ahead of the value being cast to the database. Although it could be cast as a string, it simply doesn't matter as it doesn't affect the outcome.
3. cad_db_uninstall.php does not remove the tables from the db. I think, but could be wrong, that there is a missing underscore in this line:DELETE FROM {db_prefix}settingsI'm thinking it should be: DELETE FROM {db_prefix}_settings.
To make this clear, there are no tables added by my modification, nor are there even
columns added, simply
just rows are added. Have you tried uninstalling? It should indeed remove the rows. I didn't encounter any issues and the syntax is most definitely accurate, although it could indeed be minimized by using IN(); rather than utilizing a foreach(); loop, but again, that's not a problem, just a possibility to increase the performance - which would not even be noticed.
Let me explain this to you. What is {db_prefix}? It's simply a "keyword" or a "shortcut" that will be replaced with the ACTUAL database prefix upon the query being executed. How? using a str_replace();.
Here's how SMF does it specifically:
global $smcFunc, $db_prefix;
$tableName = str_replace('{db_prefix}', $db_prefix, $tableName);What is this doing? Well, it's globalizing the actual database prefix, so it can be used ($db_prefix is the variable). The variable is defined in Settings.php.
Assuming you don't customize the prefix, it's "
smf_" so {db_prefix} = $db_prefix = "smf_". So when you take that further, {db_prefix}settings would be smf_settings or yourprefix__settings or yourprefix_settings, or whatever your prefix is. The underscore is PART of the prefix. The default prefix, once again, is smf_, meaning {db_prefix}_settings would normally output smf__settings, which is incorrect.
So all of the issues in question are inaccurate, and not actual issues, more misunderstanding PHP syntax, data types, and SMF procedures.
Which is fine, I completely understand, and I'm sorry if this comes across as rude or insulting, neither of which are my intentions of this post. I simply wanted to help you understand why they are NOT issues, otherwise I wouldn't have spent 20 minutes writing this in the first place.
Also, if there are any steps to replicate the issues you guys are experiencing, I'd be extremely grateful if you could pass them on so I could replicate and fix the existing issues.
Thank you for your time and interest in helping!
Best Regards,
Matthew "Labradoodle-360" Kerle
SMF Customizer
