Users running a non-download version of Vanilla (pulled from github), on branch release/2019.016 or master from the last 2 weeks should upgrade to release/2019.017 or latest master for security reasons. Downloaded official open sources releases are not affected.

migrate from v2.2 Windows to v2.8.3 Linux

I was constrained on my previous Windows hosting provider to an archaic version of PHP that kept me locked into very old versions of Vanilla (currently 2.2). I am now moving to a new Linux hosting vendor, and have access to PHP 7.1, so plan to move to v2.8.3. Is there an accepted set of best practices/guide available for how best to migrate my forum to my new host?

Thanks in advance...

Comments

  • I should followup by saying I'm aware of the steps outlined here https://docs.vanillaforums.com/developer/installation/self-hosting/#upgrading , but that I'm also wondering about database migration, as well as whether I will run into any trouble considering that I'm moving from a Windows host to a Linux one....

  • K17K17 Unkorneglosk - Français / French Paris, France ✭✭✭
    edited May 20

    If the MySQL server has the requirements, you shouldnt have any problem to transfer. No matter thé operating system.

  • R_JR_J Cheerleader & Troubleshooter Munich Moderator

    I would advise to install vanilla from scratch on your Linux machine, copy the database (mysqldump would be helpful), point the db settings of your new installation to the imported dB, copy the /uploads folder to your fresh install and after that most of the work should be finished


    You will have to tweak some other settings which are in your old config.php but not in the new one. If you have a nice file diff irks, you can quickly find them. But you can also walk through the dashboard and set them one by one


    K17
  • Thanks to you both - I was thinking along the lines of R_J's suggestion, to install fresh, but didn't know how successful I'd be with just copying the database, etc... I will give it a shot - appreciate the help!!

  • OK, so that didn't really work. I exported the MySQL database, then imported into new database on new server. Installed fresh Vanilla 2.8.3, and specified new database on first page that appears. When I see Vanilla forum homepage, I don't see any of my old categories or messages. I tried mysite.com/utility/update , which was successful, but no change on the homepage, just the stock initial Vanilla page without any of my existing content.

    Suggestions?

  • I also tried K17's approach; after having deleted the entire /forum directory, and deleting the database from my last attempt (so starting from scratch basically), and then again importing old database from original server onto new server database, and just replicated entire forum directory from old server onto new - when I navigate to mysite.com/forum, I get "Class Gdn not found."

  • ShadowdareShadowdare Moderator
    edited May 21

    In your original Windows MySQL database, are your tables cased like "GDN_Discussion" or "gdn_discussion"? If I recall correctly, MySQL on Windows stores table names in lowercase by default, but Linux preserves the case that applications specify by default; therefore, on Linux, the table names are case-sensitive and, if your Windows export has lowercase names, Vanilla won't see them as they're essentially different tables. If this is the issue, then you may have to manually change the table names to their correct casing.

    Also, for the "Class Gdn not found" error, you probably have to clear Vanilla's cache files.

    Add Pages to Vanilla with the Basic Pages app

  • meshugymeshugy Musician/Hacker ✭✭

    @dnigrin I'm currently trying to do the same thing, update from 2.2.1 to 2.8.3, except both are Linux. I was successful in performing what @R_J suggested (i.e. fresh install of 2.8 and the updated the config file to point to my 2.2 MYSQL database.) The new 2.8 forum will display all the posts and categories, but I'm unable to fully update it as I get error every time I run the updater. See more here: https://open.vanillaforums.com/discussion/37298/upgrade-from-2-2-1-to-2-8-3-504#latest

  • Thanks for the feedback to you both.

    @Shadowdare , you're spot on with respect to the case; all of my tables are lower case. So I guess I have the arduous task of renaming them all - I'll give it a shot. And also, after clearing the cache directory, I now no longer get "Class Gdn not found", and instead I get "Something has gone wrong." I'll try renaming the tables and see if that fixes things. To be clear, this is using the 2.2 version, and not the 2.8.3 version.


    @meshugy , thanks - I'm thinking that you got further than I did because of the MySQL table name case issue above. I'm first going to just get the original 2.2 version running, and then upgrade from there. If that doesn't work, I'll go back to trying what @R_J suggested, starting with a clean 2.8.3 install, and pointing to my (case corrected tablenames) database.

  • OK, have made good progress.

    I first tried using my moved 2.2 version (with cache cleared), and using the database with table names corrected for case. I then got the "something went wrong" screen or similar, and nothing I did seemed to fix it.


    I then tried using that same case-corrected database with a fresh 2.8.3 install, and *that* worked, so I am now seeing all my categories and messages.


    Things aren't quite right though, as I'm noting that the existing users do not have the correct roles assigned to them - in fact, they don't have *any* role assigned to them. Will have to do comparison with how things were set up on the old site...


    Thanks again for all the help thus far!

  • Also - I ran mysite.com/forum/utility/structure , and see this:


    alter table `GDN_UserAuthenticationNonce`

    -- [Existing: `Timestamp` timestamp not null default current_timestamp, New: `Timestamp` timestamp not null]

    change `Timestamp` `Timestamp` timestamp not null;


    alter table `GDN_UserAuthenticationToken`

    -- [Existing: `Timestamp` timestamp not null default current_timestamp, New: `Timestamp` timestamp not null]

    change `Timestamp` `Timestamp` timestamp not null;


    update `GDN_User` `User`

    set `Permissions` = ''

    where `Permissions` <> '';


    insert `GDN_UserMeta` 

    (`UserID`, `Name`, `Value`) 

    values ('0', 'stubcontent.record.locale', 'en');



    I tell it Run Structure and Data Scripts, it is successful, and then I Rescan, but each time I get the exact same set of messages. I've tried doing the process 3 or 4 times, but each time after Rescan I get the same list of things that are not right...

  • R_JR_J Cheerleader & Troubleshooter Munich Moderator

    Don't mind about those messages: they will not disappear no matter what you do but that's okay.

    Take a look at your GDN_UserRole table: that's where user roles are stord. You can look up role IDs in GDN_Role. By looking at both tables you will be able to make out which roles your users are assigned to and which RoleIDs you would like to have. If needed give some examples and we can provide you with an SQL to change all role ids


  • Thanks @R_J - I've only got two rows in my GDN_UserRole table, which doesn't really make sense as I've got thousands of users:

    Those two (Administrator) Users are ones I created just this morning. I can now see what the problem is though - when looking at my original database table names, I've got gdn_userrole , which I had renamed to GDN_Userrole. That table must have been overwritten by a fresh GDN_UserRole. So I guess I've got to start all over, with renaming of my database tables such that EachWordIsCapitalized... Painful, but I think I'm getting closer.

    Again, thanks for all the help!

  • Yup, that fixed it! Thanks everyone, I think I'm off to the races now. Few small things to clean up, but basically all looking good. 😊

  • R_JR_J Cheerleader & Troubleshooter Munich Moderator
    Do you have PHPMyAdmin or anything like that? Use this sql:
    RENAME TABLE gdn_accesstoken TO GDN_AccessToken;
    RENAME TABLE gdn_activity TO GDN_Activity;
    RENAME TABLE gdn_activitycomment TO GDN_ActivityComment;
    RENAME TABLE gdn_activitytype TO GDN_ActivityType;
    RENAME TABLE gdn_analyticslocal TO GDN_AnalyticsLocal;
    RENAME TABLE gdn_attachment TO GDN_Attachment;
    RENAME TABLE gdn_ban TO GDN_Ban;
    RENAME TABLE gdn_category TO GDN_Category;
    RENAME TABLE gdn_comment TO GDN_Comment;
    RENAME TABLE gdn_contentdraft TO GDN_contentDraft;
    RENAME TABLE gdn_conversation TO GDN_Conversation;
    RENAME TABLE gdn_conversationmessage TO GDN_ConversationMessage;
    RENAME TABLE gdn_discussion TO GDN_Discussion;
    RENAME TABLE gdn_draft TO GDN_Draft;
    RENAME TABLE gdn_invitation TO GDN_Invitation;
    RENAME TABLE gdn_log TO GDN_Log;
    RENAME TABLE gdn_media TO GDN_Media;
    RENAME TABLE gdn_message TO GDN_Message;
    RENAME TABLE gdn_permission TO GDN_Permission;
    RENAME TABLE gdn_pocket TO GDN_Pocket;
    RENAME TABLE gdn_reaction TO GDN_reaction;
    RENAME TABLE gdn_reactionowner TO GDN_reactionOwner;
    RENAME TABLE gdn_regarding TO GDN_Regarding;
    RENAME TABLE gdn_role TO GDN_Role;
    RENAME TABLE gdn_session TO GDN_Session;
    RENAME TABLE gdn_spammer TO GDN_Spammer;
    RENAME TABLE gdn_tag TO GDN_Tag;
    RENAME TABLE gdn_tagdiscussion TO GDN_TagDiscussion;
    RENAME TABLE gdn_user TO GDN_User;
    RENAME TABLE gdn_userauthentication TO GDN_UserAuthentication;
    RENAME TABLE gdn_userauthenticationnonce TO GDN_UserAuthenticationNonce;
    RENAME TABLE gdn_userauthenticationprovider TO GDN_UserAuthenticationProvider;
    RENAME TABLE gdn_userauthenticationtoken TO GDN_UserAuthenticationToken;
    RENAME TABLE gdn_usercategory TO GDN_UserCategory;
    RENAME TABLE gdn_usercomment TO GDN_UserComment;
    RENAME TABLE gdn_userconversation TO GDN_UserConversation;
    RENAME TABLE gdn_userdiscussion TO GDN_UserDiscussion;
    RENAME TABLE gdn_userip TO GDN_UserIP;
    RENAME TABLE gdn_usermerge TO GDN_UserMerge;
    RENAME TABLE gdn_usermergeitem TO GDN_UserMergeItem;
    RENAME TABLE gdn_usermeta TO GDN_UserMeta;
    RENAME TABLE gdn_userpoints TO GDN_UserPoints;
    RENAME TABLE gdn_userrole TO GDN_UserRole;
    
    

    It should cover all tables


    K17
  • Thanks for that - a little late for me, but I'm sure will be helpful for others if they have ever have the same need!

Sign In or Register to comment.