Please upgrade here. These earlier versions are no longer being updated and have security issues.
HackerOne users: Testing against this community violates our program's Terms of Service and will result in your bounty being denied.

Fresh install of 2.6.3; how to integrate 2.1.11 database?

Hi, we have installed the latest Vanilla 2.6.3 on a brand new server with the latest MySQL and the latest PHP. It is up and running in a basic form. What we want to do is bring over our database from an old server that was getting infected, the database is 2.1.11. Can anyone help with instructions on what to do to accomplish this?

Thanks

Comments

  • R_JR_J Ex-Fanboy Munich Admin

    It should be quite easy:

    1. Make a backup of the old database
    2. Import that old database into the new server. This step is not Vanilla related. Use your preferred MySQL tool to do so.
    3. Change the database information in /conf/config.php to point to the imported db
    4. Visit yourforum/utility/update several times
    5. Visit yourforum/utility/structure. Scan your database and confirm the changes. When you scan it repeatedly, there will be some tasks which will always appear. Just ignore them
  • Thanks for this info. I tried it, but there does not appear to be a /utility/update path. Is there some other trick?

  • R_JR_J Ex-Fanboy Munich Admin

    Then try /index.php?p=/utility/update

    There is no path /utility/update. Vanilla uses a file called index.php which is used as a so called front controller. Every request to your page is routed through this controller and Vanilla will find the required files in the background. So there doesn't need to be a file called "/utility/update"

  • I see, thanks. As you can tell I am new to php (but have lots of asp.net/c#/iis). I did make some progress with your help.

  • When I use the MySQL database that was installed by default, when completing the Vanilla configuration, everything works fine. But when I point \conf\config.php to the database that we really want to use (the one from production from a different server, from a prior version of Vanilla/MySQL), and I run the command "http:///index.php?p=/utility/update", I get this error

    Permission Problem

    You don't have permission to do that.

    Trace

    0 C:\inetpub\wwwroot\Vanilla\applications\dashboard\controllers\class.utilitycontroller.php(276): permissionException()

    1 C:\inetpub\wwwroot\Vanilla\library\core\class.dispatcher.php(845): UtilityController->update()

    2 C:\inetpub\wwwroot\Vanilla\library\core\class.dispatcher.php(274): Gdn_Dispatcher->dispatchController(Object(Gdn_Request), Array)

    3 C:\inetpub\wwwroot\Vanilla\index.php(29): Gdn_Dispatcher->dispatch()

    4

    If I browse to the root of the website (http:///index.php) I am met with this error:
    Fatal Error in PHP.gdn_ErrorHandler();
    Unknown column 't.FullName' in 'field list'
    The error occurred on or near: C:\inetpub\wwwroot\Vanilla\library\database\class.database.php

    Obviously the older database is not in sync with the new codebase and needs to be updated, presumably by the technique you have outlined for me, but as stated I get the permissions error listed above.

    I have researched and cannot find a clear answer to this problem. Any ideas?
    Thanks

  • The strange "http:///" renderings above apparently happened because I was using left and right arrow characters to surround "mystitehere".

  • R_JR_J Ex-Fanboy Munich Admin

    Do you have the login credentials for the admin user of the old forum?

    Try first yourforum.com/index.php?p=/utility/structure and you should see a login box (hopefully)

  • Yes, I do get the logon prompt. I enter the admin credentials and

    (I have repeated this procedure 3 times to be sure...):

    1) with PHP's my.ini STRICT mode set as follows (default)
    sql-mode="STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION"
    I get
    "
    Fatal Error in Gdn_Database.Connection();

    An error occurred while attempting to connect to the database
    SQLSTATE[HY000] [1045] Access denied for user 'hiddenusernamehere'@'localhost' (using password: YES)
    The error occurred on or near: C:\inetpub\wwwroot\Vanilla\library\database\class.database.php
    "

    2) with PHP's my.ini STRICT mode set as follows (off)
    sql-mode=""

    I get
    "
    Permission Problem
    You don't have permission to do that.
    "

  • I wonder if you're having an issue similar to what I had. The passwords/usernames were all mixed up. You could try what I did:

    1. drop GDN_Permission and GDN_Role using phpmyadmin, from the old db
    2. grab GDN_Permission and GDN_Role from the fresh 2.6 install, and import them into the old db

    Here's one of the threads for more detail:

    https://open.vanillaforums.com/discussion/36346/upgrading-from-version-2-0-18-1#latest

  • Thanks, I looked into that possibility, but it seemed as though I would be losing important data from the old (production) DB.

    I actually got this working, as follows:

    I ran the index.php?p=/utility/update/ and got an error page that said "Unknown column ‘t.FullName’ in ‘field list’". This had happened to me several other times today, and I would immediately try something else. This time, I went to the MySQL Workbench to look at the schema for the table that it was complaining about, which was “GDN_Tag”. I was expecting to ~not~ see the column “FullName", but lo and behold it ~was~ there. So I went back to my webpage, and it said “Update Complete”!

    From there I was able run the utility/structure command and then to log in as admin.

    So apparently, even though I was presented with the error page about the schmea for the GDN_Tag table not having that column, the update was actually running in the background and did its thing.

  • I should add; prior to doing what I described above, I was getting various access denied / permission problems. I am on Windows Server 2016 with IIS 10 and PHP 7.2.10. I reviewed my notes and found that because we were trying to lock security down as much as possible I had set fastcgi.impersonate = 0 (app pool identity). The Vanilla forum website was running under its own app pool identity, of which I had previously granted permission to MySQL and the Vanilla website . It didn't occur to me that PHP/fastcgi was running under the DefaultAppPool. So I added DefaultAppPool with modify rights to MySQL and Vanilla (still not sure if both are needed, need to test). Then I got past the permissions problems, and was able to run the index.php?p=/utility/update/ scenario described above.

  • R_JR_J Ex-Fanboy Munich Admin

    @CJReese: it's good to have someone with Windows Server and IIS knowledge on board! From time to time people drop by and ask questions on that hardware constellation and by now there was nobody available to answer questions. Next time, I'll mention your name =)

  • Thank you.

Sign In or Register to comment.