Conversion of PHP-Nuke addons to CPG-Nuke ⇒ Frequently Asked Questions ⇒ CPG Dragonfly™ CMS
$Version_Num vs. CPG_NUKE
As of CPG-Nuke 9.x, $Version_Num has become deprecated. Why? PHP-Nuke 8.x is around the corner and using $Version_Num to compare versions could cause a problem with CPG-Nuke 8.x. To eliminate the potential for this, a new constant has been created - CPG_NUKE, which stores the version of your CPG-Nuke.
If your modules use $Version_Num, please replace it with CPG_NUKE.
Can I still use PHP-Nuke themes, modules and blocks?
In most cases you can, but you won't be able to use CPG-Nuke's collapsable blocks unless you modify the theme.
Open up themes/cpgnuke/theme.php to familiarize yourself with how everything works and what needs to be changed for compatibility with CPG-Nuke.
Also, due to the differences in our SQL abstraction layer, modules, blocks and themes need to be changed to use the correct abstraction layer ($db vs. $dbi).
Direct access protection
We have created a better, more secure way of protecting files from being directly accessed by a user.
The same concept applies for files in admin files:
Freeing the memory associated with MySQL result sets
When working with several result sets in a single script, the memory associated with these result sets can become congested. By using the simple function below, we can free all memory associated with the given result set:
Let's take this bit of code in context:
Please take note that all memory is automatically freed at the end of a PHP script.
Including the appropriate files
In PHP-Nuke, each module made a direct inclusion to mainfile.php, something like:
NEVER, EVER directly include mainfile.php OR config.php, anywhere
Don't include footer.php it is loaded automaticly.
Find and remove something like:
Limiting access to administrator modules
In PHP-Nuke, extra code was wasted for determining if the given administrator had permission to access the requested admin module. A typical example looks something like:
We have replaced such code in CPG-Nuke with:
Read more on function can_admin() here
Obtaining information about the current user
In PHP-Nuke, if you wanted to obtain information about the given user, you would have to decode the cookie yourself, a process that is messy and insecure. A typical example looks something like:
NEVER attempt to decode the cookie yourself in CPG-Nuke!
Please take note that the $user and $admin variables are no longer used, thus they should not be used as arguments in the functions.
Follow this model for fetching information about a user:
Only fetch the needed data in a query
PHP-Nuke queries often selected all data from a selected table, only to perform a simple action such as counting the number of rows. Take this for example:
It is storing all data from cms_referer in the memory, a useless operation that takes up space. We can save memory by rewriting the code as:
Reduce code by using list()
A lot of code can be reduced by using PHP's list() function instead of assigning variables to the result set of an SQL query one by one.
Take this bit of code for example:
We can easily reduce this code by rewriting it as:
Read more on function list() here
Retrieving data from cms_config_custom
In PHP-Nuke and CPG-Nuke versions prior to 8.2, the table cms_config was used for storing configuration data. As part of our continuing efforts to simplify the use of CPG-Nuke, we have created a new table, cms_config_custom, which is a lot more flexible.
Retrieving data from this table is a piece of cake! As opposed to using an SQL query each time you want to grab a piece of information from the configuration table, you can use the array $MAIN_CFG. Let's say that you wanted to retrieve the value of sitename:
That may look a bit confusing, so let's break it down...
The first dimension of the array, in this case ['global'] is the cfg_name column in cms_config_custom.
The second dimension, in this case ['sitename'] is the cfg_field column in cms_config_custom.
Putting the array together will result in the retrieval of the cfg_value column in cms_config_custom.
Sending mail through CPG-Nuke
PHP-Nuke used PHP's mail() function for sending mail. The trouble with this is that it has limited usage and does not support SMTP.
In CPG-Nuke, we've developed a new function for this task, send_mail(). This new function can handle mail through SMTP or PHP, features support for non-html messages, and is a lot more powerful than the standard mail() function.
Let's compare PHP-Nuke and CPG-Nuke's handling of mail...
Read more on function send_mail() here
Using the right amount of quotes
PHP-Nuke's code was sloppy, one example being excessive quoting. Let's take this bit of code:
There is simply no need for that many quotes when you only wish to echo one constant. Rewrite it as:
register_globals... to use them or not to use them?
PHP-Nuke overrode PHP's default setting for register_globals (OFF by default, as of PHP 4.2.0). Misuse of register_globals can compromise the security of a script, and in turn the entire server. It's safe to say that PHP-Nuke misused register_globals.
Take this bit of code for example:
With register_globals on, $id could be set anywhere - a GET, POST, or even COOKIE request.
However, with register_globals off, $id cannot be set through any of these requests. In this case, a NULL value will be assigned to $id.
In order to allow $id to be set through a GET request, for example, we would change the above code to:
For a POST request:
Or to allow both GET and POST requests:
(intval returns 0 if not a numeric as opposed to int() which returns null)
register_globals have been turned off as of CPG-Nuke 9.x.
Read more on register_globals here
sql_fetch_array() vs. $db->sql_fetchrow()
sql_fetch_row() vs. $db->sql_fetchrow()
sql_num_rows() vs. $db->sql_numrows()
sql_query() vs. $db->sql_query()