Problem adding new modules

Posted: Thu Apr 19, 2007 6:00 pm

When we developed RN2.10 we limited the "recognition" of new modules to the modules administration screen within the general administration screen. Previously the system checked for new modules every time the home page was loaded and the consensus was that this was just way too much overhead and unnecessary duplication of functionality.

Right now it looks like a "patch" for this will be included in the rn2.10.01 patch release.

The symptoms for this would be that you've added a new module to the /modules directory and it's not being recognized. If you are experiencing this and need a solution before the patch release please post back here. If you have added modules to rn2.10.00 and they are being recognized properly please also post here so I can investigate further.

Posted: Fri Apr 20, 2007 7:27 am

Sorry I realized later that in this forum only moderators can post. Just PM me if you have any input. What I am looking for is situations where the modules were not on your system BEFORE Ravennuke 2.10 was installed and you added them later and they were or were not recognized. If they WERE recognized and added to the modules table then I have to look at the code again before we do a patch release.

registered · Posted: Fri Apr 20, 2007 7:32 am

Well, I moved it for now into a forum that folks can post to. Figured it would be good to see the response trail. Wink

Posted: Fri Apr 20, 2007 3:42 pm

Thanks M. I didn't think of the simple option ... moving the post. I have one PM response that the individual added modules after 2.10 but I have written for clarification. The real issue is whether modules can get added to the modules table with the current code. It doesn't look to me like they can but I've been wrong before.

The more I think about this the more I think we are missing the point here. Ravennuke requires Groups does it not? And an essential step of running the installation of Ravennuke is to add the groups and to modify the modules table to have the "groups" field. Is this supposed to be optional ... I don't think so.

What we probably should do is test the modules table for the correct set of fields and give some kind of error message telling people who don't have the groups field to go back and run rn_nsngroups.sql (or the step in installSQL.php that runs it). We should also stop using that geeky "VALUES" SQL update statement and instead explicitly identify which fields we are updating. It's bad enough trying to count them with 9 fields and when you get to the users table it's almost impossible. But I ramble.

Posted: Sat Apr 21, 2007 7:01 am

Quote:

But I ramble.

Quote:

Is this supposed to be optional ... I don't think so.

Absolutely correct. It is NOT optional.

Quote:

give some kind of error message

I don't disagree.

Worker Joined: Feb 18, 2006 Posts: 155 Location: Virginia

I installed Nuke Treasury after RN 2.10 and had no problems with it being recognized.

registered · Posted: Sat Apr 21, 2007 12:15 pm

I have also installed modules on RN2.10 and have not seen this. When does this happen?

Posted: Sat Apr 21, 2007 2:52 pm

My research indicates that whenever you move a new module into the modules directory (that was not there before) modules.php is supposed to recognize it and add it to the modules table. But the SQL for adding it tries to insert a null into the mod_group field which is defined as an integer and therefore generates an error. (The code is out in Mantis Gremmie). I put in a check for mysql error and was seeing this happen.

The key point is that the modules were NOT in the /modules directory before and therefore also were not in the modules table. I want to further refine my solution, I am just having the devils time finding time to work on it expeditiously. I think that what we should do is check for the existence of the mod group field and just "die" the application with a message to the admin to go back to their installation and run the nsngroups sql properly. But I believe we also need to add a 0 rather than a null to that field. I have the zero being added in what's in the SVN now.

The code in question is around line 83 of the current /admin/modules/modules.php.

Involved Joined: Apr 22, 2006 Posts: 356

Ok, here goes. I have two sites. Site one, I did a fresh install of files, but wound up having to use my old db, just ran the upgrade file on. I had to do this because I was having an issue with the stats and that was the only thing that solved it. Anyhow, I think the only thing I added to it was Gremmie's calendar. Worked fine.

The second site was pretty vanilla and I did the upgrade as well. I have added an Address list module, Gallery 2 module (embedded). That is it so far. They were added ok.

I can't really remember, it seems as if there was something I had to activate in the modules section before it showed up in the modules section of admin. Not for positive though. I am going to be adding some other things and will pay more attention for this conversation. Wink

Posted: Sat Apr 21, 2007 7:20 pm

kevinkapYes, thats correct. You have to visit the module admin area for the installed modules list to be updated. As fkelly mentioned in an earlier post, the 'list' update was previously done in three seperate area's which was a bit of an overkill and waste of resources.
The only problems anyone should be seeing is the 'Group' column in the modules admin screen being blank when a new module is installed. A quick work around is to click 'edit' then save for that module which will update the column.

Posted: Sun Apr 22, 2007 8:45 am

Okay, we gotta get systematic about this. This is not a matter of opinion but a matter of what's factually correct. So:

Step 1. Look at /admin/modules/modules.php

In the current RN distribution (not in the SVN for those who have access but in what was distributed with 2.10) you have the following code in the function modules:

Code:

   if ($groupsLoaded) $db->sql_query('INSERT INTO '.$prefix.'_modules VALUES (NULL, \''.$modlist[$i].'\', \''.str_replace('_', ' ', $modlist[$i]).'\', 0, 0, \'\', \'\', 1, 0)');


        else $db->sql_query('INSERT INTO '.$prefix.'_modules VALUES (NULL, \''.$modlist[$i].'\', \''.str_replace('_', ' ', $modlist[$i]).'\', 0, 0, \'\', 1, 0)');

These values HAVE to correspond to the table definition, so what is that? Well looking in rn32_core_pl32.sql from the distribution (doctored up into something I can read) we find:

Code:

 


1. `mid` int(10) NOT NULL auto_increment, 


2. `title` varchar(255) NOT NULL default ''


3. `custom_title` varchar(255) NOT NULL default '' 


4. `active` int(1) NOT NULL default '0', 


5. `view` int(1) NOT NULL default '0', 


6. `inmenu` tinyint(1) NOT NULL default '1', 


7. `mod_group` int(10) default '0', 


8. `admins` varchar(255) NOT NULL default '',

That's 8 fields. But in rn_nsngroups.sql we add the following:

Code:

ALTER TABLE $prefix.`_modules` ADD `groups` TEXT NOT NULL AFTER `view`;

So, please bear with me as this will be a valuable reference, we wind up with for the groups table:

Code:

 


1. `mid` int(10) NOT NULL auto_increment, 


2. `title` varchar(255) NOT NULL default ''


3. `custom_title` varchar(255) NOT NULL default '' 


4. `active` int(1) NOT NULL default '0', 


5. `view` int(1) NOT NULL default '0', 


6.   `groups` TEXT NOT NUL


7. `inmenu` tinyint(1) NOT NULL default '1', 


8. `mod_group` int(10) default '0', 


9. `admins` varchar(255) NOT NULL default '',

Now look at that SQL I quoted. In the situation where isGroupsLoaded is true we are trying to add:

Code:

('INSERT INTO '.$prefix.'_modules VALUES (NULL, \''.$modlist[$i].'\', \''.str_replace('_', ' ', $modlist[$i]).'\', 0, 0, \'\', \'\', 1, 0)'); 


which translates into:


1.  a null for the field mid -- an int field 


2.  a string for the field title : a varchar field


3.  a string for the field custom title: a varchar field


4.  a zero for the field active : an int field


5.  a zero for the field view : an int field


6.  a \'\'  for the field groups :  a text field


7.  a \'\' for the field inmenu : a tinyint


8.  a 1 for the field mod_group : a int field


9  a 0 for the field admins : a varchar field

So guess what. After a hour of messing around deleting and re-adding my test donothing module I'm convinced that the old code works. I swear that last week I saw a SQL error on this but I'm not seeing it now. I doctored up the modules.php (the one in the /admin/modules directory) with something like this:

Code:

        if ($groupsLoaded) {


      $result =


         $db->sql_query('INSERT INTO '.$prefix.'_modules VALUES (NULL, \''.$modlist[$i].'\', \''.str_replace('_', ' ', $modlist[$i]).'\', 0, 0, \'\', \'\', 1, 0)');


             if( !$result) {


                   $error = $db->sql_error();


                  $msg = $error['code'] . ' ' .  $error['message'];


                    $msg .= "<br /> for the following sql:  ".$sql."";


                   die($msg);


                   }


          if ($result) {


              echo 'sql succeeded <br>'; }


      }


        else  {


           $db->sql_query('INSERT INTO '.$prefix.'_modules VALUES (NULL, \''.$modlist[$i].'\', \''.str_replace('_', ' ', $modlist[$i]).'\', 0, 0, \'\', 1, 0)');


    }


   }

And I'm getting the "sql succeeded" echoed. So probably the user experience of not having problems adding modules is valid and we don't NEED a patch for this. Still it might be better to actually add a zero in the inmenu field as my patch currently does. And maybe for the next major release (not patch) we should just validate whether the groups field exists and do a die with some kind of message telling people to go back and run nsngroups.sql. But that's not needed now.

Well time to do something useful with the day. Sometimes the facts come back to bite those who feed them, this is not how I expected this post to turn out.

Posted: Sun Apr 22, 2007 11:11 am

Actually ... this has been driving me crazy since I posted it. I know I saw the problem last week ... the SQL error, yet others aren't seeing it. Even my own tests this morning don't show it. WHY?

Mystery revealed I think. A couple of weeks ago I destroyed MYSQL 4 on my home computer and wound up installing MYSQL 5. The tests where I found the problem thus took place on my localhost where I'm running MYSQL 5. I know MYSQL 5 can be stricter on certain things than 4 was, though I'm by no means a SQL guru. The tests I ran this morning were on my test server on one of Raven's servers and were running MYSQL 4,

So, I just reran my tests from this morning on my local host using that donothing module I mentioned. Voila! Sanity returns (of sorts). I get the following:

Code:

1366 Incorrect integer value: '' for column 'inmenu' at row 1

The SQL variable I was trying to echo in the code I posted this morning won't work because we don't capture the SQL to a variable before executing it, but rest assured it is the SQL that adds the record to the modules table.

Now I know that we don't "officially" support MYSQL 5 but at the same time we are surely moving in this direction and a patch that is "stricter" and loads a zero rather than a \'\' to an integer field is, at the very least, not going to do any harm and will be of definite benefit trying to run RN2.10 under MYSQL 5.

Phew.

Posted: Mon Apr 23, 2007 5:35 am

I am all for it. The change is minimal and is still valid regardless of the mySQL version. I was going to give you that input regardless of this latest post. Since its already been committed and tested, lets run with it. I'm ALL for mySQL 5.x and PHP 5.x! Wink