I've been waiting and waiting, and now the time has come.
My forum is running SMF 1.1 RC3 (I know, I know...). I'm now ready to make the move to SMF 2.0 RC5, but have a few questions about the best order to do things in...
First, and most important, is there any reason to upgrade from 1.1 RC3 to 1.1.13 first (as an interim step to ensure things go smoothly), and then upgrade to SMF 2.0 RC5? Or is it just as safe to simply upgrade directly from 1.2 RC3 to 2.0 RC5?
Regarding mods and themes....if it makes any difference, my forum is currently running the TinyPortal mod, version 0.9.5 (no other mods). Once I switch to SMF 2.0 RC5, I probably will not install TinyPortal, but might do that later. I'm also running a custom theme that I don't expect to be compatible with 2.0. So before I do the upgrade to SMF 2.0 RC5, I will probably just uninstall TinyPortal and switch temporarily to the default SMF theme. After the upgrade to 2.0 has been completed, I will worry about themes then.
And yes, I have been backing up my forum regularly, and will do so immediately before attempting the upgrade. :)
So....do I need to go through the smaller upgrade to 1.1.13 to be safe, or just go all the way to 2.0 RC5 in one jump? Any other things to watch out for?
Thanks in advance for the help.
you can just upload the large upgrade pack and it will upgrade you from any version of smf to that version.
as you suggested your old theme will not work on 2.0 and would need to be updated.
Upgrading SMF (http://docs.simplemachines.org/index.php?board=3.0;sort=subject)
Thanks - I'd rather just do it once, but mostly I want it to go smoothly and keep everything intact (all messages, the forum structure, accounts, permissions, etc.). I am assuming that all of these things should be preserved.
I'm reading through the linked documentation above right now. If I have any dumb questions, I'll be back here to ask them.
I'll do one last backup before starting, then will take a deep breath and keep my fingers crossed.
Many thanks again for the help.
you are welcome, for the mean time i will mark this solved, if you have further questions you can mark it unsolved.
DON'T FORGET TO BACKUP THE DATABASE, TOO!!!
Thanks - and yes, I did back up the database. :)
So I've run into a couple of wrinkles, probably minor(?)....
1. Before upgrading, I attempted to Uninstall the TinyPortal mod. I got messages that "installing" would be unsuccessful, but since I was trying to get rid of TinyPortal, I figured that would be OK. So I told it to go ahead and uninstall. That appeared to have failed, and now when attempting to access the forum, I get the following error:
Fatal error: Call to undefined.
function: tportal_sidebar() in
/home/(my database user name)/public_html/Sources/Load.php(1726)
: eval()'d code on line 217
I'm not that worried about this, since I assume that once the upgrade is complete, this mod will probably be blown away or at least disabled - correct? Should I fix this issue before proceding?
2. I have realized that I may have a potentially larger issue with the location/naming convention used for my forum. This may or may not be a problem, but I figure this may be the right to find out if it is...
Way back when I first created this forum, I (apparently) unzipped the installation package (which was SMF 1.1 RC2, the latest version at the time) on my local computer, and all the files were in a folder named "smf_1-1-rc2_install". Then I uploaded that folder via FTP to a folder named "forum" on my website. So the path to the legacy forum files has been:
mydomain/public_html/forum/smf_1-1-rc2_install/(all the individual files & subfolders)
I would like to correct this, and have the new forum live in the following location:
mydomain/public_html/forum/(all the individual files & subfolders)
What's the best way to accomplish this? Would it be best to simply upload the upgrade files (loose) into the existing folder where the legacy files currently are (mydomain/public_html/forum/smf_1-1-rc2_install/) just to accomplish the upgrade, and then (after the upgrade is complete, assuming it's successful), then figure out how to "move" things up in the directory hierarchy?
I'm not sure how large/complex a task it is to "move" things and make sure all the pointers are lined up correctly. Although it would be a little odd to have the SMF2.0 stuff sitting in a folder named "smf_1-1-rc2_install", that's OK for the time being (my users won't see that - only me and all the spam bots). I'm guessing that the Upgrade package is designed to be run when all the old files have been overwritten by newer files, and it'll only work correctly when both old and new files are (or were) in the same source directory (that is, there's no provision to "upgrade" an older version into a new location) - correct?
Suggestions welcomed.
Thanks again (and I've changed the status of this back to Normal from Solved).
you can move the files and run What is repair_settings.php? (http://docs.simplemachines.org/index.php?topic=663.0) to fix your paths to direct them back to where they should be.
Sorry, not trying to be intentionally dense here, just want to clarify things.
Are you saying that I should...
A: Upload the (unzipped) upgrade package to the same directory where my legacy forum is (overwriting the older files), complete the upgrade, and then (later, after everything has been finished) then move and fix things using the repair_settings.php file?
or
B: Upload the (unzipped) upgrade package to the directory where where I want the forum to be after it's upgraded (which is not the same location as my legacy forum), run the repair_settings.php file in the new location, and then complete the upgrade?
or
C: Upload the (unzipped) upgrade package to the directory where where I want the forum to be after it's upgraded (which is not the same location as my legacy forum), then perform the upgrade, and then run the repair_settings.php file to get things to point correctly to the new location?
or
D: none of the above?
I think you mean A (and hope you do, since otherwise I'm not exactly sure how to go about this). Correct?
Thanks again!
yes option A will work to do what you want.
Great, thanks - I'm FTPing the files now.
I guess I shouldn't worry about that error I was getting after I tried to uninstall the TinyPortal mod? After the upgrade is complete, it probably won't be looking for that - right?
I will report back after the files upload and I run the upgrade.php file.
Thanks again.
all your files will be overwritten, minus a few important files, with the upgrade, so any prior errors or issues related to the files will be gone.
Question about CHMODing the new files:
In my FTP application ("CyberDcuk, a Mac OS FTP client), there's an "Info" dialog where I can access Unix Permissions (and edit the value), there's a button labeled "Apply changes recursively" - there doesn't appear to be a simple "apply". But when I make the change to 777 (the value was 755) and close the dialog, it does seem to accept the value (it's sticky).
Suggestions on whether I should click "Apply changes recursively"?
Files have been uploaded, and all the necessary items have been CHMOD'ed to 777.
When I attempt to run the upgrade.php file, I get the following message:
The server encountered an internal error or misconfiguration and was unable to complete your request.
Please contact the server administrator, webmaster@[my_domain_name].com and inform them of the time the error occurred, and anything you might have done that may have caused the error.
More information about this error may be available in the server error log.
Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request.
Apache/1.3.42 Server at www.[my_domain_name].com Port 80
I'm attempting to access and run the file by entering the path/name in my browser and hitting Return. Same thing happens if I select the file in my FTP client and choose the command to "Open in browser." My browser is Safari 5.0.4 (6533.20.27), MacOS 10.6.7. I have other computers available (running Win XP and Win Vista) with those other browser available if it makes a difference.
I am confident that I am hitting the correct file (assuming that's upgrade.php); I can select another file in the same directory and access it successfully (e.g. news_readme.html opens successfully in a browser).
Ideas?
Just to clarify and update...
I realized that I had been attempting to upgrade the forum files in the wrong directory (d'oh!). I guess when I originally installed SMF, I dumped one installation in a sub-directory (just the files, with no database associated), and when that didn't work, I uploaded a second set of the files into the root (public_html) directory of my website. That worked, and has been working fine for a long time. Today, when I attempted to upgrade from SMF 1.1 RC3 to 2.0 RC5, I was aiming at the wrong directory. Stoopid user.
OK, I have fixed that tonight. I uploaded all the files from the SMF 2.0 RC5 large upgrade package to the root directory (where my functioning forum has been working just fine until today), I CHMOD'ed the required files (and double-checked them). Then I attempted to run upgrade.php by opening it in a web browser. When I do so, I'm getting this error:
Internal Server Error
The server encountered an internal error or misconfiguration and was unable to complete your request.
Please contact the server administrator, webmaster@[my_domain].com and inform them of the time the error occurred, and anything you might have done that may have caused the error.
More information about this error may be available in the server error log.
Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request.
Apache/1.3.42 Server at www.[my_domain].com Port 80
So I'm still stuck. At least now I'm stuck with the correct directory.
Any suggestions for how to fix this and make it work again?
Thanks again for the help.
CHMOD the files to 755, it can be possible that your server does not accept 777.
Quote from: Yoshi2889 on May 09, 2011, 05:15:33 AM
CHMOD the files to 755, it can be possible that your server does not accept 777.
Son of a gun...
that did it! THANK YOU.OK, off to watch it churn.
Many thanks again.
Quote from: nwflyboy on May 09, 2011, 05:27:57 AM
Quote from: Yoshi2889 on May 09, 2011, 05:15:33 AM
CHMOD the files to 755, it can be possible that your server does not accept 777.
Son of a gun...that did it! THANK YOU.
OK, off to watch it churn.
Many thanks again.
No problem, upgrading should be dead simple if you follow the steps :)
Well, it seemed to be going OK there for a bit.
But it now seems to have stalled here:
(http://i719.photobucket.com/albums/ww196/pacificnorthwestflying/notsofast.jpg)
I did select the option to make a backup, so I'm prepared for it to sit and grind for a while, but I would assume that the progress indicators would continue to update, and it's been stuck like this (15% overall, 2% step, elapsed time 7 mins 7 seconds), and although the Continue button changes states on rollover, I've clicked it several times and nothing seems to happen.
I assume that I should see some change to the progress indicators, even if it's busy with a large backup (when I manually backup my database files, it's about 56 MB). It's been stuck with these numbers for at least 5 minutes. I'll give it another 15 minutes just to be sure, but I'm wondering if something else has gone amiss now.
Thanks again.
EDIT: Forget this, it seems to log the board IDs and topic/post numbers.
Try to repair the table from within phpMyAdmin or any other database manager your host may have.
Quote from: Yoshi2889 on May 09, 2011, 05:54:19 AM
Try to repair the table from within phpMyAdmin or any other database manager your host may have.
My host seems to have multiple tools available, including phpMyAdmin (and MySQL Databases, MySQL Databases Wizard, and others) - but I have no clue how to use any of these.
My forum is fairly large and has a complex structure. I do have backups of everything that I made before I messed with anything today.
How worried should I be?
In Phpmyadmin this should be simple. Click on the DB name on the left hand side, find the table _log_boards in the listed tables,
check the checkbox - and way down after the list, you will see a dropdown including "Repair". Select "repair".
Be sure not to select Truncate or Drop though, some versions of phpmyadmin may not ask for confirmation!
While you are at it, perform this at all tables (Select All link) to avoid any future problems :)
Hmm. OK, so in phpMyAdmin, I've selected the forum database on the left pane. The Structure tab is active by default, and it lists a lot of tables (94). Half of them have the prefix "backup_". I note that the item "smf_log_boards" is listed as "in use" (it's the only one that doesn't show details for Records, Type, Collation, Size and Overhead). This is the item that's listed in the error message in my screenshot above.
OK, so if I scroll down to the bottom of the display, I can click the "Check All" function, and every item is checked. There's a dropdown (centered under the bottom of the list) that includes "Repair Table".
I should select that? (gulp...) Is this a fairly low-risk activity?
Anything else I should watch out for? What should I expect to see happen if it goes well? Assuming it does, should I then click the "Continue" button in the SMF Upgrade Utility in the web browser that's still open, or do I need to re-initiate the upgrade.php file?
Thanks again!
repairing a table that is not broken will not cause a problem so repairing all should not cause issues.
i would start the upgrade process over once you repair the tables. if the table is still "in use" after the repair, verify that your forum is in maintenance mode, if it is not put it in maintenance mode and try again.
The forum is definitely in maintenance mode.
OK, I did the above - was not sure if anything happened, since there was no confirmation dialog or "Do It" button. After about 10 seconds, the screen refreshed, with the happy message "Your SQL query has been executed successfully".
Looking down through the new display, for the item "smf_log_boards" I see two consecutive entries:
repair Error Incorrect key file for table 'smf_log_boards'; try...
repair error Corrupt
I do see the entry for backup_smf_boards repair status OK
Is that something worth pursuing?
If the query ran succesfully, try rerunning the upgrade.php now - it should pick up from where it left off the last time. :)
Well, I tried running the upgrade.php file again, and hit the same problem with the same item. I did tell it to continue from where it had stopped previously. Starting from the beginning, the results are the same.
Two questions....
1. The "backup" version of this table ("backup_smf_log_boards") is listed as OK. It shows as having 18,154 records with a size of 405.6 KB, so there's something in there. Is there a simple way to delete the contents of the "smf_log_boards" table and replace it with the "backup_smf_log_boards" table?
2. What exactly does this table keep track of? Maybe I don't care about it too much.
Thanks again.
You should be able to export the backup_smf_log_boards table, and then Truncate the original smf_log_boards table, and import the data to it.
But, before going that way, I'd try to repair the table once more, and making sure to note every message it might give.
Repaired all the tables again, the results are the same:
everything shows repair - status - OK, except for these two entries:
(forumDBname).smf_log_boards repair Error Incorrect key file for table 'smf_log_boards'; try...
(forumDBname).smf_log_boards repair error Corrupt
:-\
Any suggestions are welcome (although I have no experience with tweaking databases, so I will probably need some detailed hand-holding - sorry).
I'm pretty tired - it's after 0400 in the morning here and I've been fighting with this for most of the day. I need to get some sleep now. I will check back in a few hours and try to pick up the pieces then.
Many thanks again for the help.
I'm sadly no DB guru myself either, but while you sleep - it may be someone with a better understanding of that side comes along ;)
Try to remove that table and renaming the backup table to that table.
Quote from: Yoshi2889 on May 09, 2011, 07:34:18 AM
Try to remove that table and renaming the backup table to that table.
Doing this has the small risk of losing the only copy of that table you still have in the DB - So better would be to make a new copy of it first.
Quote from: Aleksi "Lex" Kilpinen on May 09, 2011, 07:35:24 AM
Quote from: Yoshi2889 on May 09, 2011, 07:34:18 AM
Try to remove that table and renaming the backup table to that table.
Doing this has the small risk of losing the only copy of that table you still have in the DB - So better would be to make a new copy of it first.
Eeh, yeah. Make a backup of the backup :P
and i dont off hand see a way to "rename" a table in phpmyadmin without a query. the user having this problem would need a detailed query to do this task. anyone know how to do that? or it is as simple as backup the table drop the old and upload the backup to the new table?
I'd go about doing it like I said earlier.
Export the contents of the backup, Truncate the original, import the exported backup data to the original table. :)
Quote from: Illori on May 09, 2011, 07:37:08 AM
and i dont off hand see a way to "rename" a table in phpmyadmin without a query. the user having this problem would need a detailed query to do this task. anyone know how to do that? or it is as simple as backup the table drop the old and upload the backup to the new table?
eeh, yeah I do.
The selected text says "Rename table to". And the table that is opened is not from SMF.
the version of phpmyadmin that i am looking at does not seem to have that feature and i am unsure where you are to find that since your screenshot is not in english.
Quote from: Illori on May 09, 2011, 07:42:51 AM
the version of phpmyadmin that i am looking at does not seem to have that feature and i am unsure where you are to find that since your screenshot is not in english.
At the Operations tab when you open a table.
I am using the latest RC.
ok, that is available in my version 3.3.9 as well, but the above idea to leave the backup in place might be the best idea.
Quote from: Illori on May 09, 2011, 07:47:31 AM
ok, that is available in my version 3.3.9 as well, but the above idea to leave the backup in place might be the best idea.
But then you can copy the "new" table as a backup table :P
Good morning and hello again. I've got a few hours sleep and am ready to try this again. First of all, many thanks again for your assistance, it's much appreciated.
I will probably need some more specific, step-by-step instructions to accomplish what you are suggesting. But first...
There are three of you helping (thanks again - I am glad to have all your input). Am I correct in understanding that the consensus seems to be to follow the suggestion made by Yoshi2889 (summary follows)?
If so, I think I understand that (at least the idea, I will want to clarify the exact steps in a later post). Please correct me if any of the following is not correct - I believe the suggestion is to accomplish the following:
A. Remove the bad table from the database.
B. Make a copy of the backup table in the database.
C. Rename the new copy of the backup table with the name of the original (bad) table.
This would effectively move the contents of the backup table into the database in place of the original (bad) table (and would preserve the same data in a backup table in case it's needed later).
Earlier in the thread, I believe Aleksi "Lex" Kilpinen had suggested a more complex-sounding sequence, "Export the contents of the backup, Truncate the original, import the exported backup data to the original table." If I follow the steps above (A, B, C), does that mean it's not necessary to export, truncate the original, and import back the data? Just want to be sure.
My apologies in advance if I seem overly simplistic on this stuff. I have no experience with databases, and just want to be sure I understand all the steps completely before proceeding. I am guessing that some of you may not be native English speakers (although your English is excellent), so I just want to minimize any misunderstanding or misinterpretation I might make. I appreciate that this conversation is conveniently in my native language (if it were it German of Finnish, it would be a very short, one-sided conversation ;D).
Many thanks again - more questions on the specific steps to accomplish this will follow shortly (assuming that I understand the above correctly).
That's correct, and if you follow A B and C you will not need to import, export and truncate.
Great, thanks. A couple follow up questions...
Looking over the user interface for phpMyAdmin, I have one question about what specific command/function to use to remove the bad table...
A. Remove the bad table from the database:
1. On the Structure tab, select the checkbox for the "bad" table (in this case, "smf_log_boards")
2. Then...in the "Action" column...which of the following is correct?
2A: click the "Empty" icon (looks like a trash can)
- or -
2B" click the "Drop" icon (looks like a red X)?
- or -
2C: at the bottom of the browser window listing all the tables, on the popup labelled "With selected:", choose "Drop"?
I notice that the "Empty" icon appears dimmed (may be disabled) - the item is listed as "in use"
(http://i719.photobucket.com/albums/ww196/pacificnorthwestflying/remove_table_screenshot.gif)
Then, I'm not completely sure about the backup-then-rename operations; can B and C be done in a single step?
B. Make a copy of the backup table in the database + C. Rename the new copy of the backup table with the name of the original (bad) table.
1. In the left pane, click on the name of the "good" table (in this case, "backup_smf_log_boards") to select it
2. Click the Operations tab
3. In the "Copy table to (database.table)" group, enter the name for the new table (in this case, the name entered should be "smf_log_boards")
4. Be sure that the "Structure and data" radio button is selected
5. Do not select any of the following checkboxes: Add DROP TABLE, Add AUTO_INCREMENT value, Switch to copied table
6. Click the "Go" button in the lower right corner of the "Copy table to (database.table)" group.
(http://i719.photobucket.com/albums/ww196/pacificnorthwestflying/copy_table_to_screenshot.gif)
Is that all correct?
Thanks again!
1. Hit the big X on the "broken" table.
2. Enter the name of the just-deleted table.
That should do it :)
and indeed, that did it. Whew! :o
OK, the upgrade churned for a while, and seems to have completed. I'm now looking at the "Upgrade Complete" screen:
(http://i719.photobucket.com/albums/ww196/pacificnorthwestflying/successdialog.gif)
Two final (I hope) questions....
1. The happy text reads That wasn't so hard, was it? Now you are ready to use your installation of SMF. Hope you like it!
I hope so, too. ;) But when I click that link to go to my forum, it's still in maintenance mode. How can I flip the switch to take it out of maintenance mode and get it back to normal mode?
2. There's an option to Delete this upgrade.php and its data files now. I figure I might want to see the forum is functional first before doing this, no? Or is there no benefit to hanging on to it now? I do understand that it may be a security risk so I'll certainly get rid of it. If I don't chose this option now, is there a list of all the items I should delete to clean up manually?
Many thanks again....Of course, I won't sleep much until I see it's functional...I have my fingers crossed and am holding my breath until I see the forum functioning...
you only need to remove upgrade.php the other files are safe to keep in place. admin -> server settings -> uncheck enable maintenance mode and save the page.
Good teamwork, guys'n'gals!!
Okiedokie, I've removed the upgrade.php file - done.
However, the forum is still in maintenance mode. When I go there in my browser, I just get the plain text message that I entered when I put it in maintenance mode - I can't get to any of the forum interface, so I can't access admin -> server settings.
How do I get there?
Thanks again everyone!
open your settings.php file with a text editor there is a line in there about maintenance mode and how to disable it.
Quote from: nwflyboy on May 09, 2011, 04:43:25 PM
Okiedokie, I've removed the upgrade.php file - done.
However, the forum is still in maintenance mode. When I go there in my browser, I just get the plain text message that I entered when I put it in maintenance mode - I can't get to any of the forum interface, so I can't access admin -> server settings.
How do I get there?
Thanks again everyone!
Open up Settings.php (no not Options.php :P), search for this:
$maintenance = 2;and change the "2" to "0".
OK, got it out of maintenance mode...but....
It's broken. It appears to still have some leftover items from before the upgrade, and one (probably both) of these are preventing me from accessing the admin section, so I can't make it work. Specifically....
1. It's attempting to use an old custom theme ("Amber") that I know is not compatible with SMF 2.0. This is the same custom theme that it was using before the upgrade.
2. It's also attempting to load a mod ("TinyPortal") that I don't need, and which I attempted to uninstall yesterday right before beginning the upgrade. The details are (more or less) the same as I posted in the 6th post in this thread. To save you all from scrolling, here's the specific error message:
Fatal error: Call to undefined.
function: tportal_sidebar() in
/home/(my database user name)/public_html/Sources/Load.php(2162)
: eval()'d code on line 217
So....I assume I need to go in and manually change two things somewhere:
1. Switch the theme to one of the (SMF 2.0) default themes.
2. Remove or ignore the TinyPortal mod (which did not uninstall successfully). I'm guessing this is probably the more critical one - maybe if this is disabled I'll be able to get to the admin section?
Can someone provide guidance on how to accomplish this?
Thanks again!
upload this What is repair_settings.php? (http://docs.simplemachines.org/index.php?topic=663.0) and ONLY use the part about resetting your theme to default and see if that helps.
I uploaded and ran repair_settings.php. Under "Paths & URLs" (the last section), it indicates that it is correctly pointing to the default theme: the values for all Theme-related items do match the recommended values.
I don't see any way there to manage Mods.
Not sure if it's related to this issue, but there is one item in repair_settings.php that's flagged as wrong:
Queryless URLs: [] Off (recommended)
Value not found! [] On
I'm going to remove the repair_settings.php now just to guard against a bad guy gaining control (OK, I'm paranoid). I can re-upload it when needed.
Thanks.
did you apply the change anyway for the theme part with repair_settings.php? this should make the above error message go away. for queryless urls i would go with the default off value.
Quote from: Illori on May 09, 2011, 05:31:13 PM
did you apply the change anyway for the theme part with repair_settings.php? this should make the above error message go away. for queryless urls i would go with the default off value.
I went back and did both (set the queryless URLs setting to Off, and clicked the recommended values for each of the Theme-related settings, then clicked the Save Setting button). Results appear to be the same.
Thanks.
can you try adding index.php?theme=1 to your url and see if that helps? if not then i would suggest uploading all files but upgrade.php to your server again and see if that helps.
Quote from: Illori on May 09, 2011, 05:44:50 PM
can you try adding index.php?theme=1 to your url and see if that helps? if not then i would suggest uploading all files but upgrade.php to your server again and see if that helps.
Yes - that works: adding the suffix index.php?theme=1 makes it all appear functional. A quick check of the message base and it looks like everything is there - whew!
Now, accessing Admin > Themes and Layout > Manage and Install, in Themes and Layout, I do see that the Overall forum default is listed as SMF Default Theme - Core. The value for "Reset everyone to: is currently set to "No change".
Should I go ahead and make changes there (i.e. re-select the "Default Theme - Core" for both "Overall Forum Default" and "Reset everyone to"? I have found that one theme can get "stuck" and changing both settings here was the only way to force it to behave.
I note that the old Amber theme is still available to select - I'll want to remove that soon, I assume. After that, I guess I'll try to wipe out any last bits of the TinyPortal mod....yes?
you can go ahead and reset to default theme for everyone. yes removing that theme should clean out the last of tinyportal as it was being called from that theme, it seems.
And all seems well - within seconds, I've already got a dozen forum users posting. They were really chomping at the bit after more than 24 hours offline. It's nice to know the forum is missed. ;D
I will wait a while to investigate some of the corners of the forum to be sure it's all working well before I have a drink to celebrate, but so far everything looks good. What a relief!
I want to extend a huge, sincere thanks to all the folks here who helped me resolve this little crisis, especially Illori, Yoshi2889, and Aleksi "Lex" Kilpinen. You were great (and I know it's not always easy to provide this kind of support).
I have a very active forum with a lot of very passionate users who rely on me, and ultimately we rely on you. Many, many thanks again for all your help!
If I find anything that needs further work, I will post later (for now, I need a rest). But for now, I'm marking this one "Solved." Great work everyone, and thanks again. | (http://i719.photobucket.com/albums/ww196/pacificnorthwestflying/itsOKIhaveabackup.jpg) |
Glad your forum works fine!
There should be no to minor problems. Post anything weird in the Bug Reports board, if you are unsure that it is a bug just post in 2.x Support :)
Or, 'course, this topic :P
Glad to hear you got there in the end - You already had many small problems arising there, that we usually do not see - so be sure to let us know if you notice any further oddities possible caused by the upgrade. :)