Announcement

Collapse
No announcement yet.

3.8.11 to 5.6.7 Upgrade Issues

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • 3.8.11 to 5.6.7 Upgrade Issues

    Hello!

    Trying to upgrade from 3.8.11 to 5.6.7 and got this error:

    ----------------------------------
    400a1 Step #102
    Fatal Error Occurred

    Undefined constant "ATTACH_AS_FILES_NEW" on /var/www/vhosts/forum.com/htdocs/core/install/includes/class_upgrade_400a1.php : 2105

    Script: 400a1
    Step: 102
    ----------------------------------

    3.8.11 is good prepared to upgrade - without any products and plugins, all attachments moved to the database.
    Environment - PHP 8.1, Mysql 8.0.28 (Percona), NginX 1.21.6
    Tried to upgrade to 5.6.7 and to 5.6.8 RC1, the same result..

  • #2
    Please place the attached file in the core/install/includes directory on your server and run the upgrade script again.
    Attached Files
    Translations provided by Google.

    Wayne Luke
    The Rabid Badger - a vBulletin Cloud demonstration site.
    vBulletin 5 API

    Comment


    • #3
      Thank you!
      The problem has gone from "Fatal" to "Warning":
      • Upgrading to 4.0.0 Alpha 1
      • [400a1] Step 102 - Updating attachment table
      • Warning: Undefined array key "attachtype" in .../install/includes/class_upgrade_400a1.php on line 2105
      • Warning: Undefined array key "attachtype" in .../install/includes/class_upgrade_400a1.php on line 2105
      • [this line is repeated over a hundred times]
      Is everything okay or can we fix this warning?

      Another Fatal error:
      Click image for larger version

Name:	vbulletin.png
Views:	41
Size:	18.7 KB
ID:	4470457

      How can I fix this?

      Comment


      • #4
        Turn display warnings off in your php.ini file. These should not be enabled on production machines.

        As for the fatal error, it looks like you were kicked off of MySQL for some reason. Does your hosting provider have resource limits like number of queries per hour? This is a common method to limit "unlimited hosting plans." I would suggest trying again.
        Translations provided by Google.

        Wayne Luke
        The Rabid Badger - a vBulletin Cloud demonstration site.
        vBulletin 5 API

        Comment


        • #5
          Originally posted by Wayne Luke View Post
          As for the fatal error, it looks like you were kicked off of MySQL for some reason. Does your hosting provider have resource limits like number of queries per hour? This is a common method to limit "unlimited hosting plans." I would suggest trying again.
          This fatal error on 500а1-152 is gone on 5.6.8 release. Checked twice on 5.6.7 and 5.6.8. Looks like it was a bug.

          Other errors:
          1. almost all vb3-links are redirected correctly but /blog.php?b=* (like /blog.php?b=1794) are not redirected. Clicking on this link opens a page with the message:
          Code:
          Invalid Page URL. If this is an error and the page should exist, please contact the system administrator and tell them how you got this message.
          And the error from the webserver-log:
          Code:
          Warning: Undefined array key "file" in /var/www/vhosts/forum.com/htdocs/includes/vb5/template.php(404) : eval()'d code on line 4
          Warning: Undefined array key "trace" in /var/www/vhosts/forum.com/htdocs/includes/vb5/template.php(404) : eval()'d code on line 22, request: "GET /blog.php?b=1794 HTTP/1.1"
          2. The 'Find Updated Phrases' section got an error:
          Code:
          Warning: Undefined array key 11 in .../admincp/phrase.php on line 399
          This appears with default clear English selected without any updated phrases.

          3. Files missing on 5.6.8 (they are present on 5.6.7):
          core/install/includes/class_upgrade_567.php
          class_upgrade_567a1.php
          class_upgrade_567a2.php
          class_upgrade_567b1.php
          class_upgrade_567rc1.php
          Is that how it should be?

          Comment


          • #6
            4. My vB3-database and all tables are initially utf8/utf8_general_ci encoded. When migrating a vb3 database from mysql 5.7 to 8.0, a new database was created with default charset = utf8mb4 and collation = utf8mb4_0900_ai_ci;
            I use a non-English language on the forum. There is a service file utf8convert.phar in the \do_not_upload\dbtools folder, is it possible to convert tables from utf8 to utf8mb4 using the command:
            Code:
            php utf8convert.phar --connectionCharset=utf8 --charset=utf8mb4 --collateCI=utf8mb4_0900_ai_ci --wipeSearch=1
            or for tables that have utf8/utf8_general_ci, it's better to do it with the command:
            Code:
            php utf8tablefix.phar
            ?

            On a test configuration, I tried to run the command:
            Code:
            php utf8convert.phar --connectionCharset=utf8 --charset=utf8mb4 --collateCI=utf8mb4_0900_ai_ci --wipeSearch=1
            and got the result:
            Code:
            conversion complete. No errors found during conversion.
            So everything is ok?


            5. Some tables:
            Code:
            blog_aaggregate_temp_1580409300
            blog_attachment
            blog_attachmentviews
            blog_tag
            blog_tagentry
            blog_tagsearch
            ipaddress
            legacy event
            postindex
            tachyforumcounter
            tachyforumpost
            tachythreadcounter
            tachythreadpost
            are not converted from utf8 to utf8mb4 by the script utf8convert.phar. How to deal with them? Maybe they are not listed in utf8convert.phar and these tables should be added to this script?
            Or are they old unnecessary tables from vB3 and can be deleted?
            As I noticed, they are also not converted to InnoDB by the myisamfix.phar script (php myisamfix.phar -dofix command)
            Last edited by Neil; Thu 19 May '22, 8:35am.

            Comment


            • #7
              1. There is a bug where blogs don't redirect. Since it is marked as minor and there are no customer votes on the issue, it will be overshadowed by more important issues. https://tracker.vbulletin.com/vbulle...sues/VBV-10499

              2. Warnings happen. They can be ignored. The code is updated to remove them as time allows. They won't affect the operation of the software with current versions of PHP.

              3. Upgrade steps that only increase the release version and do not actually make changes to the database are deleted from the download package with the next release. https://tracker.vbulletin.com/vbulle...sues/VBV-21107

              4. You should use utf8convert.phar. It is tuned to deal with multibyte non-latin characters.

              5. None of these are vBulletin 5 tables and therefore converting them is a waste of server resources. The
              blog_aaggregate_temp_1580409300 would have been created by a bug in an old vBulletin 3 version… Something in the 3.6 series if I remember correctly. The tapatalk tables are from a third-party addon and they must provide the script to convert their tables, or simply uninstall then reinstall tapatalk to recreate them with the proper collation. The other tables are obsolete.
              Translations provided by Google.

              Wayne Luke
              The Rabid Badger - a vBulletin Cloud demonstration site.
              vBulletin 5 API

              Comment


              • #8
                Originally posted by Wayne Luke View Post
                1. There is a bug where blogs don't redirect. Since it is marked as minor and there are no customer votes on the issue, it will be overshadowed by more important issues. https://tracker.vbulletin.com/vbulle...sues/VBV-10499
                How many votes are needed to make this issue as important? This is quite important to me as it can prevent search engines from indexing blog posts by old urls. I just voted there..

                Originally posted by Wayne Luke View Post
                5. None of these are vBulletin 5 tables and therefore converting them is a waste of server resources. The
                blog_aaggregate_temp_1580409300 would have been created by a bug in an old vBulletin 3 version… Something in the 3.6 series if I remember correctly. The tapatalk tables are from a third-party addon and they must provide the script to convert their tables, or simply uninstall then reinstall tapatalk to recreate them with the proper collation. The other tables are obsolete.
                What is tapatalk? I never had this addon on vB3 )
                Do you mean that tables
                Code:
                tachyforumcounter
                tachyforumpost
                tachythreadcounter
                tachythreadpost
                are from some vB3 add-on? If I will not reinstall any addon from vB3 history, can I just remove these tables?

                Can I remove old vBBlog tables without any consequences?
                Code:
                blog_attachment
                blog_attachmentviews
                blog_tag
                blog_tagentry
                blog_tagsearch
                What about ipaddress and postindex tables? Can I also remove them without any repercussions?

                I see that the legacyevent table is just renamed the old event table and a new vb5 event table is created. If I didn't use Calendar in vB3, can I remove the legacyevent table?

                Comment


                • #9
                  Sorry… Yes, Tachy not Tapatalk.

                  You can remove all those tables.
                  Translations provided by Google.

                  Wayne Luke
                  The Rabid Badger - a vBulletin Cloud demonstration site.
                  vBulletin 5 API

                  Comment


                  • #10
                    When upgrading, the main errors in the logs on the [error] level are:
                    Code:
                    Undefined variable $customFields in /core/vb/vb.phar/library/user.php on line 623
                    Undefined array key "infractionlevel*" in /core/install/includes/class_upgrade_501a2.php on line 1315
                    Undefined array key "emailnotification" in /core/vb/vb.phar/library/content/privatemessage.php on line 518
                    Undefined array key "attachtype" in /core/install/includes/class_upgrade_400a1.php on line 2105
                    Undefined array key "categoryid" in /core/install/legacy/400a1/vb/datamanager/attachmentfiledata.php on line 217
                    Undefined array key "contentid" in /core/install/legacy/400a1/vb/datamanager/attachmentfiledata.php on line 156
                    Undefined array key "postcount" in /core/install/includes/class_upgrade_ajax.php on line 293
                    Can they be avoided by well preparing the database/forum configuration for the upgrade? I mean, it might be a good idea to carefully prepare vB3 for an upgrade - not only remove products and plugins, but do other work as well, like uploading tools.php and restore Master English, Fix Unique Indexes (at the Repair / Optimize Tables section), etc.

                    And an assumption - maybe for an ideal upgrade from 3.8.11 to 5.6.8 we need a stepped combination of php + mysql. For example, first we upgrade from vB3.8.11 to vb4.2.5 and use php5.6+mysql5.7, then to vbulletin 5.6.8 with php8.1+mysql5.7, then we make a re-dump of the database to mysql8?

                    Comment


                    • #11
                      These are warnings and can be ignored. If it bothers you, clear your error log after upgrading.

                      Going through the upgrade steps you are suggesting will most likely do nothing to diminish them. At least depending on where they are happening. It has nothing to do with the version of MySQL but more the format of the database over the years.

                      Edit for a little explanation.

                      When vBulletin 3 was written back in 2002-2004, PHP was described as a loosely typed scripting language. This means that when you used variables within your scripts and arrays, they did not need to be previously created or assigned a type (i.e. int, string, etc…). If PHP encountered a variable, it would assume you meant it and would just assign it memory space. When you put a value into the variable, it would take its best guest estimate at what kind of variable it was. So if you meant a string of numbers like 8005551212 was a phone number then PHP could look at it and say, "No it is an integer." You would have to compensate.

                      Starting in the PHP 5.X series, this started to change. The PHP Language started getting more serious about variable and method declarations for several reasons including performance, memory use, and security. Security is probably the most important on. With each subsequent version, it has these declarations have gotten more strict. Since some of the vBulletin code is 20 years old, mainly in the AdminCP and Install step scripts, they can run afoul of these changes.

                      There are three stages of warning that the developers look at when resolving things like this.

                      Notice: The least severe and least likely to get fixed immediately. Probably have 3-5 years to fix these issues.
                      Warning: Next level of severity. These are a little more important but should probably be fixed in the next 2-3 years.
                      Deprecated: The highest level of severity and should be fixed as soon as possible.

                      Like any programming project, vBulletin builds technical debt over time. Coding standards change, functions and methods get renamed, new methods of implementing features are developed, etc… Neither customers or developers are particularly thrilled when only bugs are fixed and new features are not added. Unless of course if the specific bug is affecting a specific customer and then it becomes the most important thing to work on.

                      So these messages have all occurred in vBulletin for many years. However, to keep your logs clean they were artificially suppressed in the vBulletin code. The software would alter how you configured your server to write your error logs for the convenience of hiding these messages. Today, it does not. This suppression was removed in 5.6.5 and 5.6.6. Suppressing these messages also makes them harder to locate and resolve. Which can be a big issues when Deprecated messages become Fatal Errors in 8.2 or later. The developers are working on removing issues that cause these messages in the default code.

                      However, you may still receive them if you customize vBulletin. Now or in the past.
                      Last edited by Wayne Luke; Fri 20 May '22, 9:14am.
                      Translations provided by Google.

                      Wayne Luke
                      The Rabid Badger - a vBulletin Cloud demonstration site.
                      vBulletin 5 API

                      Comment


                      • #12
                        Thanks for the detailed answer!
                        If I configure the PHP log file to write only [error] level errors, then there are no errors during the upgrade.

                        Other questions:
                        1. I get an error at the very beginning of the installation, when I click on Options, although the version of the Chrome browser is the latest, Javascript is enabled/allowed 100% and no additional blocking plugins are installed. How to avoid this error? I checked vB 4.2.5 installation on php5.6+mysql5.7 system and didn't get this error.. Looks like a bug on vB5.x

                        Click image for larger version

Name:	1.jpg
Views:	9
Size:	48.9 KB
ID:	4470738 Click image for larger version

Name:	3.jpg
Views:	9
Size:	46.2 KB
ID:	4470739


                        2. After the upgrade from vb3 (or clean vb5-installation) is completed we have a button to "Go to AdminCP" with url forum.com/admincp, but this path is incorrect and follow to the 404-page as it should be forum.com/admincp/ (with a trailing slash). Is that a bug?

                        Click image for larger version

Name:	4.jpg
Views:	9
Size:	34.5 KB
ID:	4470740

                        Comment


                        • #13
                          3. I have PHP 8.1 and nginx web-server, but the latest vB5 nginx-config file is only for PHP 7 (do_not_upload/nginx_php7.vhost). Please add nginx-config for PHP 8.1

                          4. If nginx server is installed, do we need .htaccess files:
                          \htaccess.txt
                          \fonts\.htaccess
                          \images\.htaccess
                          \js\.htaccess
                          \core\cache\.htaccess
                          \core\clientscript\.htaccess
                          \core\cpstyles\.htaccess
                          \core\images\.htaccess
                          core\store_sitemap\.htaccess
                          ?

                          If these .htaccess are needed, then what is the content of these files for nginx?

                          Comment


                          • #14
                            1. I don't even know what the options does here. However, it does seem to be a bug with the current version. Probably referencing a Javascript call that doesn't exist anymore.

                            2. The trailing slash shouldn't be required. This would be a server issue. Though you should make sure there is no /admincp/ directory above the /core/.

                            3. The example should work for PHP 7 and higher. You will need to convert this to your specific installation of NGINX. It is assumed that users that choose to use NGINX are more advanced and able to configure the software. We provide this as a courtesy but are unable to provide direct support for NGINX at this time.

                            4. You don't need them but the file hash checker will complain that they are missing. 98% of our customers use Apache with the remainder divided between NGINX and IIS. Even this site and vBulletin Cloud uses Apache (specifically mod_php). We provide the .htaccess files to allow the majority of our customers and easy way prevent access where it isn't needed on their servers.
                            Translations provided by Google.

                            Wayne Luke
                            The Rabid Badger - a vBulletin Cloud demonstration site.
                            vBulletin 5 API

                            Comment

                            widgetinstance 262 (Related Topics) skipped due to lack of content & hide_module_if_empty option.
                            Working...
                            X