Jump to content

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


Recommended Posts

1 hour ago, Woodsman said:

Yes she gives a whole new meaning to the phrase "Shop Until You Drop!"

Love that haha, but bad during the holiday sales! :lol:

I also had one more question. The screenshot below is not of my forum, but another forum I browse that recently also upgraded to 4.1.4.1.

eW5OErI.png

The indented text is actually supposed to be a quote. When you rebuild the posts, this is supposed to be fixed and will actually show up in a quote box, correct? This particular board is very large with over 8 million posts, so I'm just assuming the background processes haven't finished running, but I could be wrong too. I hope the background processes do fix this.

Link to comment
Share on other sites

Check this in the default skin theme, and see if the quote and citation boxes are there...
It appears that this is being a 3rd party theme. Without the code snippet information needed in the post-content.css it will appear blank as it is now.

Also remember the themes have to be for version 4.1.x, 4.0.x and older themes will not work properly they are not compatible.

Link to comment
Share on other sites

The admin turned off the default skin, so I'm not sure. My test board is on the default skin at the moment and I'm having the same issue. I don't know why exactly. Before I upgraded, I switched my test board to the default 3.4.6 theme and followed all your steps. That's why I was thinking that maybe the rebuilding process would fix this.

Link to comment
Share on other sites

Speeding up the background tasks

Add 4 cronjobs to run every minute but prefix them with "sleep 0 && ", "sleep 15 && ", "sleep 30 && ", "sleep 45 && ".

This significantly increased the speed of the background tasks on our board.

Depending on your server setup you could increase or decrease the amount of cronjobs and associated sleep values (6 cronjobs => sleep 0, 10, 20, 30, 40, 50).

Link to comment
Share on other sites

Hello
I created a ticket to IPS about this issue, unfortunately I didn't receive an answer for 48 hours. :(
I upgraded 3.2 to 4.1. I have a character set collation problem. My forum uses Turkish character set.
3.2 DB has utf8 character set. I see "Özgür" in DB, but "Özgür" in forum - this was OK.
4.1 upgrade tool convert it to utf-8 again. I see "Özgür" in DB, but "Özgür" in forum - this is incorrect.
Also, members login name with Turkish character set can not login successfully cause of this issue.
If I post a new message with Turkish characters, I see my post with Turkish characters not utf8 in DB. I think this is a problem. Upside down :)

How can I find reason and fix this problem ? I think there is no need to convert tables, it must remain utf8.
Is there any parameter within IPB config files ? Or do I need to change mysql server client/server/connection collation character set values ?

Capture.JPG

Link to comment
Share on other sites

2 minutes ago, Selcuk Keles said:

Hello
I created a ticket to IPS about this issue, unfortunately I didn't receive an answer for 48 hours. :(
I upgraded 3.2 to 4.1. I have a character set collation problem. My forum uses Turkish character set.
3.2 DB has utf8 character set. I see "Özgür" in DB, but "Özgür" in forum - this was OK.
4.1 upgrade tool convert it to utf-8 again. I see "Özgür" in DB, but "Özgür" in forum - this is incorrect.
Also, members login name with Turkish character set can not login successfully cause of this issue.
If I post a new message with Turkish characters, I see my post with Turkish characters not utf8 in DB. I think this is a problem. Upside down :)

How can I find reason and fix this problem ? I think there is no need to convert tables, it must remain utf8.
Is there any parameter within IPB config files ? Or do I need to change mysql server client/server/connection collation character set values ?

Capture.JPG

Hi Selçuk,

Normally when collation of DB is set to UTF-8 and configuration of the forum has the charset="utf-8" setting you should see all characters in Turkish form both in forum and DB. That is what I see in mine at the moment. 

Link to comment
Share on other sites

1 hour ago, ABGenc said:

Hi Selçuk,

Normally when collation of DB is set to UTF-8 and configuration of the forum has the charset="utf-8" setting you should see all characters in Turkish form both in forum and DB. That is what I see in mine at the moment. 

Thank you.
Currently :
Server connection collation : utf8mb4_unicode_ci
Database collation : utf8_unicode_ci
All table's collation : utf8_unicode_ci

I added a line to conf_global.php "$INFO['sql_charset'] = 'utf8';" but nothing changed.

Link to comment
Share on other sites

8 minutes ago, Selcuk Keles said:

Thank you.
Currently :
Server connection collation : utf8mb4_unicode_ci
Database collation : utf8_unicode_ci
All table's collation : utf8_unicode_ci

I added a line to conf_global.php "$INFO['sql_charset'] = 'utf8';" but nothing changed.

The solution may not be that simple. with cong_global having sql_charset as utf8 can you do a test and post a message to board with Turkish characters and see how the records look like both in forum and db ? If all look ok  you may need to do something with db.

Link to comment
Share on other sites

8 minutes ago, ABGenc said:

The solution may not be that simple. with cong_global having sql_charset as utf8 can you do a test and post a message to board with Turkish characters and see how the records look like both in forum and db ? If all look ok  you may need to do something with db.

ith or without "ut8" line, new posts are Turkish charset in DB. But old posts are utf8 charset.

No conversion process between forum - db. Forum displays what it gets from db.

 

Edited by Selcuk Keles
Link to comment
Share on other sites

2 minutes ago, Selcuk Keles said:

ith or without "ut8" line, new posts are Turkish charset in DB. But old posts are utf8 charset.

No conversion process between forum - db. Forum displays what you get from db.

 

The behaviour with new posts is what it has to be. 

I am afraid ( and I hope I am wrong ) you will need to convert the old posts to look normal. That was what I had to do long ago when I was using SMF .. I hope support has a better solution for this..

Link to comment
Share on other sites

1 minute ago, ABGenc said:

The behaviour with new posts is what it has to be. 

I am afraid ( and I hope I am wrong ) you will need to convert the old posts to look normal. That was what I had to do long ago when I was using SMF .. I hope support has a better solution for this..

Yes but this is a workaround solution. All settings are utf8 but content is Turkish. :) I am looking for best solution.
Thank you.
 

c1.JPG

c2.JPG

Link to comment
Share on other sites

Something that may help those who are planning upgrades now that PHP 7 is available....

For the last couple of weeks, I've been doing a test upgrade/rebuild every few days in preparation for doing an upgrade next week. My forum has ~3 million posts and the rebuild process was taking approximately 2 days (just over 2 days) to complete via CRON, running on PHP 5.6.x

When PHP 7 was released, I put it in place on my server - left the PHP version at 5.6.x for my test site, went through the upgrade and then changed to PHP 7.0.0 when the upgrade had completed. I then put my CRON in place and left it to it. Checked just 24 hours later and it was close to finished. Since then I've performed 2 further test upgrades, one with 5.6.x entirely and the other putting PHP 7 in place after the completed upgrade but before running the rebuild tasks - and the results have been great with the switch to PHP 7.0.0 for that rebuild portion. Now looking at a down time of just 2-3 days instead of a previously planned 4-5 days.

Link to comment
Share on other sites

On ‎10‎.‎12‎.‎2015 at 2:07 PM, ABGenc said:

The behaviour with new posts is what it has to be. 

I am afraid ( and I hope I am wrong ) you will need to convert the old posts to look normal. That was what I had to do long ago when I was using SMF .. I hope support has a better solution for this..

IPB support fixed the issue :

MySql server "Server connection collation" was "utf8mb4_unicode_ci"
They changed my DB and table collations to "utf8mb4_unicode_ci"

All of characters are Turkish in tables now, and forum displays as is.

Thank you.
 

Link to comment
Share on other sites

5 hours ago, Selcuk Keles said:

IPB support fixed the issue :

MySql server "Server connection collation" was "utf8mb4_unicode_ci"
They changed my DB and table collations to "utf8mb4_unicode_ci"

All of characters are Turkish in tables now, and forum displays as is.

Thank you.
 

Glad it is fixed. :) 

Link to comment
Share on other sites

Hello,

I just upgraded our forum from 3.4.8 to 4.1.5.2.

I did run the convert tool with succes, and then runned the GetReadyforips tool and everything whas green, so good to go.

Removed all the old hooks, skin, language pack etc.. 

Then i uploaded everything and performed the upgrade, got 1 issue,

''Table 'nld_farmers_nl.nld_farmerscore_view_updates' doesn't exist 
/customers/7/0/5/nld-farmers.nl/httpd.www/applications/core/setup/upg_101019/queries.json - query #2
TRUNCATE `nld_farmerscore_view_updates`''

I hit the try again button same error come up. Then i hit the continue button en upgraded whas finished. Now i checked my forum and everything looks fine. All the Members, topics, downloads and gallery looks fine and everything is there.

Now i would like to now if this error (issue) is okay or if there is gone something wrong and i need to do everything over.. 

I hope you understand (my english is not the best) and someone can reply.

Kind regards, Richard

Link to comment
Share on other sites

From time to time I have seen this error "_view_updates" while performing a 3.4.x upgrade to current versions
From what I have seen and experienced it is nothing to worry about. It is a database table that the upgrader did not find in version 3.4.x then added for 4.1.x.

Link to comment
Share on other sites

I have just completed the database conversion and faced some problems with the converter( IPS UTF8 Database Converter 1.1.19 ) that I want to report:

a) We had made in the past a backup copy of  ibf_message_topics table to  ibf_message_topics_old in our database. All our tables were already in utf8 so there was no need to convert their content, just the collation (e.g. from utf8_general_ci to utf8_unicode_ci). But, for some reason. the converter did not convert this table to utf8. When I renamed ibf_message_topics_old to ibf_old_message_topics, it worked!

b) we had a problem with a custom table which had a default value of  "€" (Euro sign). This caused the script to exit with an error, since the "definition" column in table "convert_session_tables" that the converter creates was null! Tracing the code showed that the problem was due to the "json_encode" statement which returned an error "Malformed UTF-8 characters, possibly incorrectly encoded", when converting the field with default value the Euro sign. I checked the length of the field in my database and it is 3, so my content(and default value) is Euro in utf8. Since I couldn't find any other way to solve this problem, I had to temporarily change the default value (e.g. to NULL), do the conversion and then restore the default value back to the "Euro" sign.

 

Otherwise, the converter 1.19 works very well!

Link to comment
Share on other sites

  • Recently Browsing   0 members

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