Run rnya.php from root message

Posted: Tue Jun 02, 2009 8:12 am

Got an error message on one of my client' domains to the effect that I MUST run rnya.php from root to update tables. Great, where is rnya.php ??

Cheers

Posted: Tue Jun 02, 2009 8:26 am

Thought it may be a good idea to post the error and so on when clicking on Edit Users:

Code:

ERROR: YOU NEED TO UPDATE YOU DATA BASE TABLE NOW!!


Run rnya.php from the root of your phpnuke installation, update the database tables, and delete the file afterwards!


The version of the module is 4.4.2 and the version of your data base table is Array['version']


 


    [RN Your Account 2.30.01]

I did see some other posts on this subject but the site is running 2.30.01 so what is there to upgrade?

registered · Site Admin Joined: Jun 04, 2004 Posts: 6437

That was a carryover from an early alpha version of RNYA. I thought we took that out...

Was this site running CNBYA or an earlier version of Nuke / RavenNuke?

Check to see if all the user tables have been created and have the correct structure.

Posted: Tue Jun 02, 2009 6:43 pm

Perplexing is that error just appeared out of nowhere yesterday without updating anything and no mods to anything - fingers have been out of the pie. To answer your question, yes, updated from two previous versions to present but a good while back. Optimizing the DB didn't do anything. Doesn't seem to affect anything.

Cheers

registered · Posted: Tue Jun 02, 2009 9:10 pm

This may have nothing to do with it, but I was testing a security fix on a local rn site with xampp. When I "hacked" the site, it deleted the user database information especially the user config tables and it displayed that same message. When I reloaded the database it went away. May have nothing to do with your situation but thought I'd mention it.

Posted: Tue Jun 02, 2009 9:26 pm

The user db is ok as far as I can tell. The members list and logins with no user complaints is testimony I guess ..

Cheers

Posted: Wed Jun 03, 2009 5:03 am

What about the temp tables? Are users able to register? Is the user config table there? The only logic that displays that message compares a version number stored in a file with one stored in the database.

Posted: Wed Jun 03, 2009 6:25 am

I have "admin approval" selected and yes, users can register once approved, tested ok. Tables you mention are all there. Dunno what happened, it WAS working without the error message and it still works even WITH the message.

Cheers

Posted: Wed Jun 03, 2009 6:35 am

Then it's just a difference between the version number in the file and the one in the database. Easy enough to resolve - just update the version in the users config table to match the one in the file (modules/Your_Account/includes/functions.php - search for $new_version, and update the "version" record in the users_config to match it)

Posted: Wed Jun 03, 2009 7:02 am

Perhaps it might be interesting to see how this happens. The index.php program in the /admin directory does this:

Code:

  if (!isset($ya_config)) $ya_config = ya_get_configs();

The function ya_get_configs is contained in functions.php in the include directory of Your_Account. It simply does this (some commented code removed)

Code:

$configresult = $db->sql_query('SELECT config_name, config_value FROM ' . $user_prefix . '_users_config');


   while (list($config_name, $config_value) = $db->sql_fetchrow($configresult)) {


      $config[$config_name] = $config_value;


   }


   return $config;

So, you can see that it is reading the _users_config table and retrieving the config_value field (other stuff too but that's what's relevant here).

At this point the variable $ya_config should contain one element where $ya_config['version'] equals 2.3.01.

Now in the function amain (also in functions.php) this test is done:

Code:

$yaversion = $ya_config['version'];


   $newversion = '2.30.01';


   if ($yaversion != $newversion) {

and an error message (the one you quoted) is generated if $yaversion is not equal to 2.3.01. Now, aside from the fact that we've hardcoded a version number, meaning that we need to change the code for each version release and that there is an unnecessary variable assignment ($ya_config['version'] could just be compared to the literal 2.3.01 ... aside from those nits ... I would guess that if you did a phpmyadmin on your users_config table and looked in the version field, you are not finding 2.3.01 as the value.

Either that or there is some screw up in how the programs are loaded through FTP but really, most likely there is a discrepancy in your users_config table.

Posted: Wed Jun 03, 2009 7:04 am

That was it but it was ya_version, not new_version ... nonetheless I found the problem. In the config table it was 2.30.0 and in the file it was 2.3.0 ... corrected now and no error.

Cheers

Posted: Wed Jun 03, 2009 7:14 am

Our posts crossed in the airways ...

However, in the table it was 2.30.01 and in "functions.php" it was 2.3.0

Cheers

Posted: Wed Jun 03, 2009 8:19 am

This is what is in my functions.php

Quote:

if (!($ya_config['version'] == '2.3.0'))

$newversion nowhere to be found.

Posted: Wed Jun 03, 2009 8:21 am

The functions.php that I am looking at has 2.3.01 (as quoted in the previous post). If you have something different than that then your functions.php file is not from the 2.3.01 distribution.

Posted: Wed Jun 03, 2009 8:43 am

The file in my distro is the same as yours but on the server it isn't. I did a normal upgrade, dunno why that file wasn't over-written with the new one.

Cheers

Posted: Wed Jun 03, 2009 10:35 am

I would suggest comparing all files against the latest download you had to make sure everything matches the SQL update (which appears to have been completed without issue).

Posted: Wed Jun 03, 2009 10:41 am

Did a compare after the upgrade, must have missed that one as there were many. Will just have to upload the latest file and make sure the table version matches again.

Cheers

Posted: Sat Jun 13, 2009 9:48 pm

If I may interject...

I had been looking through all these posts about this problem, as I was experiencing it as well. Settings wouldn't save for Users, when I accessed the Users Manager I have the error without a version at the end, databse version was correct, etc, etc....

When I got to this particular post, as I was reading the "head scratching" and possible solutions, I decided to take what I have read all day, and try something....

So I blasted my database, re-uploaded the files, and did a fresh install. Only this time I gave the same prefix for both "nuke" and "users".

BAM:!: It worked! Then looking back I noticed something I was overlooking before...

When I originally created the prefixes, I used "nuke" for the main data tables and "RN231" for the user tables. However, I noticed that there were three tables that had the "nuke" prefix instead of the "RN231" that were user tables. Confused

This is what sparked my idea to try and change both prefixes to "RN231". The install scripts for the database may need a bit of a tweak to correctly name the prefixes for the right tables.

Now I am pretty new to PHP, and I am running RavenNuke on an IIS 7 Windows Server with php/MySQL 5.0, so maybe that could be where the scripts are going wrong? Not sure.... Just a thought....

Sven2157

Posted: Sat Jun 13, 2009 10:07 pm

The problem was solved by making sure the version in the php file matched the version in the table.

Cheers

Posted: Sun Jun 14, 2009 8:12 am

There was/is a problem in the installer that used $prefix instead of $user_prefix for one of the user tables. I can't remember which one exactly, but we are aware of it.