Invision Community 4: SEO, prepare for v5 and dormant account notifications By Matt Monday at 02:04 PM
Woodsman Posted December 5, 2015 Author Posted December 5, 2015 Glad it worked out for you... I'll have my secretary send your secretary the bill in the morning....
heartbreakers Posted December 6, 2015 Posted December 6, 2015 If only I could afford a secretary, haha!
Woodsman Posted December 6, 2015 Author Posted December 6, 2015 Which reminds me.... I don't have one either.... Just a wife who likes to spend what I don't have yet....
Woodsman Posted December 6, 2015 Author Posted December 6, 2015 Yes she gives a whole new meaning to the phrase "Shop Until You Drop!"
heartbreakers Posted December 6, 2015 Posted December 6, 2015 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! 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. 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.
Woodsman Posted December 6, 2015 Author Posted December 6, 2015 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.
heartbreakers Posted December 6, 2015 Posted December 6, 2015 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.
Woodsman Posted December 7, 2015 Author Posted December 7, 2015 Are you showing background tasks going on when you first enter the ACP? If so give it a little time or run them manually to see if the issue still persists.
heartbreakers Posted December 7, 2015 Posted December 7, 2015 Yeah, my background tasks for rebuilding posts are still around 7-8% right now, so hopefully that fixes the problem.
Afrodude Posted December 9, 2015 Posted December 9, 2015 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).
Selcuk Keles Posted December 10, 2015 Posted December 10, 2015 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 ?
ABGenc Posted December 10, 2015 Posted December 10, 2015 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 ? 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. Selcuk Keles 1
Selcuk Keles Posted December 10, 2015 Posted December 10, 2015 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.
ABGenc Posted December 10, 2015 Posted December 10, 2015 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. Selcuk Keles 1
Selcuk Keles Posted December 10, 2015 Posted December 10, 2015 (edited) 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 December 10, 2015 by Selcuk Keles
ABGenc Posted December 10, 2015 Posted December 10, 2015 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.. Selcuk Keles 1
Selcuk Keles Posted December 10, 2015 Posted December 10, 2015 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.
Nathan Explosion Posted December 14, 2015 Posted December 14, 2015 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. media 1
Selcuk Keles Posted December 17, 2015 Posted December 17, 2015 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. ABGenc 1
ABGenc Posted December 17, 2015 Posted December 17, 2015 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.
SaltyBart Posted December 23, 2015 Posted December 23, 2015 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
Woodsman Posted December 23, 2015 Author Posted December 23, 2015 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.
SaltyBart Posted December 23, 2015 Posted December 23, 2015 Hi Al, Thanks for your reply, then i can go on. Kind regards, Richard
Valtasar Posted December 28, 2015 Posted December 28, 2015 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!
Recommended Posts