Jump to content

Upgrade from IP. 3.4.x to IPS4.0 (updated)


Recommended Posts

  • 1 year later...

Did anyone, that upgraded from 3.4.x to 4.4., have an issue with their custom emoticons (used in posts) not being upgraded correctly? By that I mean that half of our emoticons, which use to reside in the "public/style_emoticons/default/" folder got moved to the "uploads/emoticons/" folder, with the group name (default) used as the file prefix,  and their img src's corrected in the old posts, meanwhile the other half had it's URLs simply rewritten to the public folder (not the emoticons subfolder) and never moved, resulting in broken images in our forum posts?

Or to make the question simpler: does anyone know how to change the URLs of custom emojis (with corrections to existing posts)? It use to be a simple matter of executing a content rebuild, which isn't available any more.

Tried talking to the official support, but they keep insisting I give them access to our installation and I keep telling them I am doing test upgrades in a cloned virtual environment on my workstation and therefore can't give them access.

Edited by AdminDA
Link to comment
Share on other sites

From a local stand point try moving those image files still in your "public folder" and move them to your "uploads/emoticons/" then change those urls of the broken images to reflect to their new location.

As for the workstation localhost situation you are correct and they most likely thought this test site may be on a closed hosted site. This is what I thought until the word "workstation" caught my eye.

 

Link to comment
Share on other sites

  • 4 weeks later...

Hi all.. I did follow Woodsman instruction before upgrating from 3.4 to 4.3

Hi. I did upgrade my IPB 3.4 to IPB 4.3 yesterday in WAMP. I ran the IPS UTF8 Converter before and all table was converted successfully.

I did copy all IPB 4.3 files/folders to the root of IPB 3.4.

I had no choice to do this way because I can't log anymore to ACP on 3.4.. Got some errors

Warning: require_once(/home/xxx/public_html/forum.com/forum/admin/applications/core/modules_admin/login/manualResolver.php): failed to open stream: No such file or directory in /home/xxxx/public_html/forum.com/forum/admin/sources/base/core.php on line 1188

Fatal error: require_once(): Failed opening required '/home/xxx/public_html/forum.com/forum/admin/applications/core/modules_admin/login/manualResolver.php' (include_path='.:/opt/cpanel/ea-php56/root/usr/share/pear:/home/xxx/public_html/forum.com/forum/ips_kernel/') in /home/xxx/public_html/forum.com/forum/admin/sources/base/core.php on line 1188

So, what I did ..

  • Copied all files/folders to my laptop and ran WAMP
  • Added original database to WAMP
  • Change PHP version to 7.0.33
  • Ran IPS UTF8 Converter
  • Upload all files/folders from IPB 4.3 folders to WAMP
  • Now, when I try to log to my forum, I got this error

    An error occurred (500 Error)

    We're sorry, but a temporary technical error has occurred which means we cannot display this site right now.
    
    You can try again by clicking the button below, or try again later.

  • If I try to log to AdminCP, I got this error

         An error occurred (500 Error)

        We're sorry, but a temporary technical error has occurred which means we cannot display this site right now.

         Table 'xxx_forum221.x_utf_ibf_core_sys_conf_settings' doesn't exist

You can try again by clicking the button below, or try again later.
 
I'm lost... Did I miss something ?.. I'm not a guru in mysql or PHP..
Is someone can help me please ?
 
Thanks

forum.png

AdminCP 4.3.png

Link to comment
Share on other sites

@Woodsman, The only difference in config_global.php is

  • INFO['sql_tbl_prefix'] =    'ibf_';  changed to $INFO['sql_tbl_prefix'] = 'x_utf_ibf_';
  • Added in new config_global.php  $INFO['sql_charset'] = 'utf8';
  • Changed default Board URL to  $INFO['board_url'] = 'http://localhost/forumtest/index.php';

Thanks for your help

Link to comment
Share on other sites

  • 5 weeks later...

I've started yesterday, to follow Woodsman instructions, when i was trying to upgrade from 3.4.8 running in a Windows VM to 4.4.7 running in a Linux VM. I've tried to locate the database conversion utilities to run them beforehand, but i wasn't able to do so. As far as i can understand, the database conversion utils have now integrated to the main upgrade procedure.

While the upgrade process, was upgrading the database, it failed with the following message:

Data too long for column 'entry_content' at row 103
/var/www/autoexec.gr/system/Application/Application.php::1636
ALTER TABLE `blog_entries` CHANGE COLUMN `entry` `entry_content` TEXT CHARACTER SET utf8 COLLATE utf8_unicode_ci NULL

Have anyone seen anything like this?

Thank you in advance

axc-upgrade.png

Link to comment
Share on other sites

In the client area where you downloaded the 4.4.x install zip there are 2 options 1 with the converter and 1 without. Did you choose the download with the converter?
This one should have run you through the utf8 conversions 1st before the upgrade.
 

Edited by Woodsman
Link to comment
Share on other sites

Not exactly - the converters referenced in that download are for converting from other software, not for the UTF8 conversion. The UTF8 conversion utility is always included with the download.

The error would seem to indicating that your blog_entries.entry_content column is likely not UTF8 presently, and at least one row has enough data stored in the column that when converting it to UTF8, the data would exceed the amount that you can store. For instance, if you are using latin1 and the column is currently TEXT type, then converting from a single byte character set to a multibyte character set results in too much data being stored in the column. It's a fairly niche scenario to find yourself in.

You can likely work around this by changing the column type to allow more data (e.g. if the column is currently TEXT, change it to MEDIUMTEXT), and then continue the upgrade. Or you can submit a ticket if this occurs when attempting to upgrade your live site.

Link to comment
Share on other sites

Thank you Woodsman and Bfarber for your answers, much appreciated!

Based on the attached screenshots, i guess that the database is already in UTF8, the column 'entry' in the table 'blog_entries' is already MEDIUMTEXT and there is no need for any conversion.

This is my production site, that why i did submit a ticket but the answer i got is that Invision Power does not support IPS 3.4.8 anymore 😞

What else could i try ?

Thanks in advance,

Vaggelis Kappas 

 

 

axc-blog_entries.png

axc-UTF8-01.png

axc-UTF8-02.png

Link to comment
Share on other sites

If you look at that error message, it's trying to change entry to entry_content with a column type of "TEXT". I can see in the older upgrade routines why this is happening and will submit a fix.

In the mean time, you would need to edit applications/blog/setup/upg_40000/queries.json to change

    "17": {
        "method": "changeColumn",
        "params": [
            "blog_entries",
            "entry",
            {
                "name": "entry_content",
                "type": "TEXT",

to

    "17": {
        "method": "changeColumn",
        "params": [
            "blog_entries",
            "entry",
            {
                "name": "entry_content",
                "type": "MEDIUMTEXT",

 

Link to comment
Share on other sites

Actually, looking back - the Blog version prior to 4.0.0 used TEXT column type. It appears that you changed this to MEDIUMTEXT yourself, and the upgrade routine is naturally not aware of this and expects it to still be TEXT at this point (incidentally, we changed the column size to MEDIUMTEXT in a 4.x release later on).

To that end, you're going to need to customize your upgrade routine - it's not something we can account for, since the issue is based on a customization you previously implemented.

Link to comment
Share on other sites

@Woodsman,

Yes, i have downloaded the IPS 4.4.7 suite from the client server and i'm trying to upgrade and change server at the same time. My old server, with the IPS 3.4.8 suite was Windows Server while the new Server is Ubuntu 18.0.4.

@Bfarber, 

Thank you ! I did the changes you proposed at the queries.json and the upgrade completed successfully!

Now, i have to troubleshoot the missing user images .. but i think that i saw a post about that ...

 

Thank you again for your help and support !

 

AXC-Completed.png

Link to comment
Share on other sites

  • 6 months later...

No you need ACP access as an administrator in order to perform an upgrade.

You also need to provide your IPS client information as well to access the Client Area for an upgrade download if needed.

Edited by Woodsman
Link to comment
Share on other sites

1 hour ago, Woodsman said:

No you need ACP access as an administrator in order to perform an upgrade.

You also need to provide your IPS client information as well to access the Client Area for an upgrade download if needed.

Ok, apparently you can actually start the upgrade process manually without having access to the ACP. Database converted successfully.

But when it starts the last step of the upgrade it gives

Table 'uofcom_ipb.core_sys_module' doesn't exist
/home/uofcom/public_html/system/Application/Application.php::1636

It is correct that this table isn't in the database for some reason. Can this be created/bypassed?

Link to comment
Share on other sites

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...