Tips wanted for upgrading ordinary 7.6 to RN76 v2.02.02 ??

New Member Joined: Apr 27, 2006 Posts: 10

I want to upgrade an existing vanilla 7.6 install, with over 1200 users, to raven's 7.6 (2006-04-20 v2.02.02)

At the moment the site only uses two mods (that I know of).

* Approve Membership Version 6.0
* Enhanced Downloads V2.1

And the forum is phpBB 2.0.16

The mysql tables have have had their "nuke_" $prefix changed to something anonymous like "an_example_".

Is there a howto on the normal conversion process or can anyone give me a some pointers?

My current thinking is this:

Download the phpBB upgrade pack from: [ Only registered users can see links on this board! Get registered or login! ]

and run the following files from the browser to upgrade the phpBB database tables.

upgrade16-17.php
upgrade17-18.php
upgrade18-19.php
upgrade19-20.php

But after that I'm all out to sea.

I made a backup of the live database and tried the RN76 files on it and it seemed to work but I'm sure that the NSN groups and sentinel is not working correctly; so I'd appreciate some pointers. Smile

For instance Approve Membership work with RS7.6?

Many thanks in advance.

PS) I'd be happy to type this up to help people follow the transition path.

Posted: Sat Apr 29, 2006 1:38 pm

I was going to wait on this until I had completely finished my process but since you asked ...

I am doing a similar conversion from a 7.6 system with Sentinel and a couple custom modules and Approve Membership to RN 2.02. Here's the notes I made for myself, with a mind to sharing them when I was done. As always, have a good dump before you start (errr .. I mean back up your database) and be prepared to revert if things go wrong. At the outset let me say that I decided to eliminate Approve Membership even though it's a great module and is well supported. The upgrade process is just too convoluted every time there is a Forum upgrade, which seems to be quite frequently.

Anyway, here's the notes I took:

Quote:

Log: upgrading to RN2.02.

Put files in directory on local (windoze system)
Delete all language files except english
do search for lang*.* then sort result by file name puts all english files together, then delete rest and double check. Of course only do this if you are running an English only site.
Delete all themes except nukenews, fisubice, deepblue -- again depending on your preferences, I sure don't intend to support a bunch of themes.
Read and follow instructions in the TWO README files for experimental. Get this setup right on the local system.
Create another database on my host
Edit config.php file to point to that new database and its user
Upload everything (PHP etc) to a new directory on the host
Note: on my hosted system I had been running Nuke several directory layers down so my new one will be closer to the /root. I am creating a "rn" directory right "under" public_html so the paths will be less complicated.
Use phpmyadmin to create a structure listing of my current database
Use Raven's SQL installer
maxed out host with 4th IP country load, fortunately they are idiots and I can just go in and reset the user but anyone else using Ipowerweb or similar brain dead hosts will probably run into this (go into host manager, database set up, find the user you are using to connect to the database, edit it and just hit the update button and you'll be fine). Procedure might differ or not work on other hosts.
Go into phpmyadmin on host, select the RN database, select export. Select all tables and export both data and structure. Wonder why it took so long and notice that you've selected data. Go back and redo it with just the structure. Replace the file. Notice that it's alot quicker without the data (mostly IPcountry I bet).
Now run a comparison between the table structures of RN versus what I'll call 76 (my Nuke 76 database). Note: I use the compare utility that comes in UESTUDIO. There are other file comparison utilities of course.
Notes: the 76 has many fields that are identified as primary key and also as index. I suspect that's redundant and RN omits the index on them. So probably I can go into 76 and just delete the indexes preparatory to running the conversion.
Also auto increment values, especially in the Forum tables are different, lower in RN than in 76. Probably should just change them in 76 preparatory to conversion. Don't see any obvious way to change them, maybe SQL calculates them. Leave them alone, it won't harm anything.
note some changes in defaults for sentinel tables.
Note: I had to go thru the dump structure and compare process three times before I got everything straight. I would have the comparison files up on on window, and phpmyadmin up on the other and go back and forth, going down thru each table on my 76 system and adjusting its structure to match RN. The only danger I can see to this is if you were to add a field or delete one from a production system where there was SQL that, say inserted a list of values and now there is a different number of fields and the SQL would thus have an error. I didn't encounter this but be warned.
Now, make a list of:
1. Tables in RN that are not in 76. These can be left alone in the RN database
2. Tables in 76 that are not in RN. These can be dumped, structure and data and then loaded ito the RN database. Obviously at the actual conversion time the 76 database activity will have to be quiesced (the site shut down) but this will be after a couple of tests of the process.
3. Any "problematic" tables. For instance a lot of fields were added to the users table by the Approve Membership module. I'm ditching this so all those fields will have to go. Probably would be best to delete them before the dump rather than trying to edit the dump itself to remove them. Later: no ... what I did was dump the data and structure and load them into a users_test table on the RN database. There I deleted the extra fields to make the users_test table match the RN users table in structure. Then I dumped that table and restored it into the RN users table. This required a couple of global replaces on the dump file changing say "insert into users_test" to "insert into "users".
4. Matching tables (exist in both RN and 76). After adjusting the structure in 76 these can be dumped and loaded into the RN database. This should preserve the data.
----
At this point the basic preparations will be done. It probably makes sense to test the RN system on the host by going thru the steps in the Setup.php program. This will identify any glitches that would otherwise come back to haunt us.
Run setup ... looks okay. Delete installation folder thru FTP client. Okay. Click on the site and it's okay brings up Raven Nuke!
Go into admin.php, logging in with the user set up in the setup.php step. Okay.
Go into modules administration and turn on Forums.
Then go into Forums administration and set cookie domain. Thinking out loud that this could possibly conflict with my production domain during the process I set the domain followed by a /rn for the path where RN is installed. We'll see if this works properly. I've been pestering Raven to set the mysite.com to blank in the cookie domain setup but even blank wouldn't work properly here cause it might conflict with my production domain.
Puzzled how some of the "test code" I was writing got into the RN system. Will have to go retrace my steps.
nahh ... setting the domain with the following /rn doesn't work, the cookie still gets written to my site domain. Could try renaming the cookie but may just ignore it, it will eventually be okay in production.
Think about setting Sentinel http_auth on but defer that. It doesn't seem to work with my other admins who use MACs. I've been meaning to experiment with them because I suspect the MAC doesn't send the http_referer (spelled wrong in the spec) but I haven't proved that and will have to write something to dump the results out when I have them trying to get in. Just another something for the to do list.
Time for a break.
Oh, just working on my site and realized that anything else I've put in my production directories beyond the core PHP stuff will need to get copied over to the RN directory structure. Now I knew that my custom modules and other modules such as Weatherharvest and Gallery would need to be reinstalled if I go this route, but there are less obvious things like topics/images too. Hummm.

Tables that will be deleted
nuke_approve_config
nuke_approvedemailaddresses
nuke_approvedemaildomains
nuke_fields_config
nuke_pendingusers
nuke_stdemail
nuke_options1
nuke_options2
nuke_options3
nuke_options4
nuke_priorrenewals
nuke_renewals
nuke_months

Tables that are in 76 but not RN
nuke_complementary
nuke_household
nuke_location
nuke_members
nuke_rides
nuke_security_groups
nuke_transaction
tcal_app
tcal_backgrounds
tcal_boxes
tcal_calendars
tcal_categories
tcal_columns
tcal_events
tcal_mod_users
tcal_rsvp_full
tcal_rsvp_once
tcal_tasks
tcal_users

nuke_optimize_gain (this gets created on the fly later)

Tables that are in RN but not 76
nuke_nsngr_config
nuke_nsngr_groups
nuke_nsngr_users

Just leave these for later ... probably reinstall a weather program
nuke_weatherblock
nuke_weathercountries
nuke_weatherdefaults
nuke_weatherini
nuke_weathermarine
nuke_weatherstations
nuke_weathersummaries
nuke_weatherzones

After adjusting tables in 76 to match as much as possible those in RN (mostly deleting indexes that duplicate primary keys) rerun the dump of structure and the comparison. Make any adjustments you missed the first time.

For users tables dump users, users_temp from 76. Create and load them as users_nu1 and users_temp_nu1 in the RN database. Then edit the structure of the nu1 tables. Save and dump them. Then edit the dump and restore them as users and users_temp in RN.

Note: that if you copy nuke_config table and nuke_blocks table over from an old database the values of nuke_url and the admin file can be wrong. You may need to adjust these. I believe that setup.php in the installation directory sets these so overwriting them with the tables from an older system can overwrite these values. Will I should say.

Note: if you copy the nsnst_config table over from an old database the paths to htaccess and the version numbers will be wrong and must be updated.

The key elements are being able to setup a parallel database on your server and, as others have pointed out, getting the structures of your database to match. I'm at the point where I've loaded all the core data plus my custom modules into the test system and I'm inviting users to go in and look around and give me feedback. I've also loaded up Gallery 2 and converted the albums over from Gallery 1.5 and tested the results a bit. When I'm ready for the final cut over I will shut the production system down, dump the tables I intend to copy over (structures match so no problem) do the restore into the RN system and change the pointer in .htaccess to point to the new site. I'll probably do something to disable the old site too so people who don't come into my root won't get confused.

As always I'll appreciate any suggestions the others have.

Posted: Sun Apr 30, 2006 4:05 pm

Just two other anomalies I've noticed:

RN sets flood protection in Sentinel off in the SQL load. If you dump and restore your old nsnst_blockers table to the RN system you may set it on. I believe there is a problem with the Sentinel code with respect to floods in the latest version so you probably should just to into admin of Sentinel and set flood protection off after installation is complete.

If you reload your nuke_bbconfig table from your old system to your RN system you will inadvertently set the version field to whatever is in your old system. You can fix this thru going to PHPmyadmin and setting this field to: '.0.20' -- get the periods in the right places .. here's Raven's exact SQL from the load:

Code:

INSERT INTO `nuke_bbconfig` VALUES ('version', '.0.20');

and the code in the installation directory is just a treasure trove of information by the way Smile

Posted: Tue May 02, 2006 7:50 am

many thnaks for all of that, phew. I'm doing a dry run this afternoon and will let you know how I get on.

I'll try to made some ammendments as I go & if they seem worthwhile; I'll PM them back to you.
I'm sure other people will find a "Sidegrade Guide" useful Smile

Posted: Tue May 02, 2006 8:23 am

Feel free to post them here. Anything that is posted comes with an implicit caveat emptor and "do your backups first" anyway.

Posted: Wed May 24, 2006 8:30 am

Just to add a note re. a problem I just found with this conversion or I should say my approach ...

Today I noticed in logs that certain IP addresses that I thought I had banned were getting at least part way into the system. I looked at Sentinel and they were on its banned IP list. But then I looked at htaccess and they weren't in the deny from area and the deny from area was suspiciously short. Humm. Then I noticed that the only thing in the deny from area was the IP's that had been banned since the conversion. To make things worse I couldn't find a good backup of the old htaccess before the conversion (shame on me).

The hack to fix it was to print the banned list from Sentinel to the screen, capture it into an editor, use column mode to delete everything but the banned IP's (the country, reason etc were deleted) then do some global changes to stick "deny from" in front of the IP's, download the real htaccess from the server, wipe out the deny from area in it, and copy and paste the full edited list from Sentinel in. Then reupload the thing and pray. Obviously if you manually add things to htaccess in addition to what Sentinel puts there you'll have to preserve those too.

The solution I believe is to "merge" the htaccess files at conversion time so all the deny froms from the old one are carried forward. And of course have a good backup.