As a recap, our directory structure should look like:
...po (directory)
...README.txt
...mw_sanitizer.inc
...mw_parser.inc
...liquid_wikipage.module
...liquid_filters.module
...liquid.mysql
...liquid.module
...liquid.install
...liquid.info
...LICENSE.TXT
Now, go into Administer -> Modules (Under site building for those of you used to the old structure), and if everything has been setup properly, we see an option to install the wiki (you should see something like the following):
As a recap, our directory structure should look like:
...po (directory)
...README.txt
...mw_sanitizer.inc
...mw_parser.inc
...liquid_wikipage.module
...liquid_filters.module
...liquid.mysql
...liquid.module
...liquid.install
...liquid.info
...LICENSE.TXT
Now, go into Administer -> Modules (Under site building for those of you used to the old structure), and if everything has been setup properly, we see an option to install the wiki (you should see something like the following):
Go ahead and active it, hitting submit. If you don't see any errors at the top in a pink block, or on the next page load - we have success!
Now it's time to dive right in and make some changes to liquid.module.
/*
* Implementation of hook_settings.
*/
function liquid_settings() {
This hook, hook settings, had been depreciated in favour of handling the code directly from the menu system. In 4.7, hook_setting allowed a module to create values that are stored in the variable table. Now, all we have to do is create a function that contains the form we want to save values for, and add an associated hook to the menu.
Let's rename it to liquid_admin_settings like so:
function liquid_admin_settings() {
and we add the following to our menu table so it looks like this:
function liquid_menu($may_cache) {
$items = array();
if ($may_cache) {
// the default wiki page and empty page
$items[] = array('path' => 'wiki',
'title' => 'Wiki',
'callback' => 'liquid_page',
'access' => true,
'type' => MENU_CALLBACK);
} else {
$items[] = array(
'path' => 'admin/settings/liquid', 'title' => t('Liquid Wiki Project'),
'callback' => 'drupal_get_form',
'callback arguments' => array('liquid_admin_settings'),
'access' => user_access('administer site configuration'),
'type' => MENU_NORMAL_ITEM,
'description' => t('Change settings for the liquid module.'));
....
Now.. try to load up /admin/settings/liquid
Do you get a blank page, or an error? We've stumbled upon our first bug, and it lies in this section of the form in liquid_admin_settings:
$form[PREF_LIQUID_DEFAULT_TYPE] = array('#type' => 'select', '#default_value' => variable_get(PREF_LIQUID_DEFAULT_TYPE, PREF_LIQUID_DEFAULT_TYPE_DEFAULT),
'#title' => t('Default content type'),
'#description' => t('This is the content type that will be created when'.
'somebody tries to change a nonexisting wiki page.'),
'#options' => node_get_types()
);
The problem is with the call to node_get_types(). In 4.7, this function was a call to _node_names("list"), which returned all of the possible node types. In 5.0, the function returns a much richer set of data - a collection of objects containing the node type data. Unfortunately, this breaks the form builder, which just wants an array of strings. Luckily, there's an easy fix:
Change:
'#options' => node_get_types()
to
'#options' => array_keys(node_get_types())
Whew! Our first real bug in the conversion process.
Now, after doing a quick scan of function calls, another problem presented itself. On lines 648 and 709, a function entered as 'module_exist' is called. Oops! This appears to be a typo. Let's change that to module_exists so that everything will be peachy.
Next article we will dive into finding (and hopefully solving) other bugs with the upgrade process.
]]>