Simple Machines Community Forum

Hi all.

I'm in the process of trying to update from SMF 1 to 2. I've got as far as running the update, but then ran cross a problem. The updater was returning a error, saying smf_log_errors was missing.

After searching around I found this, and uploaded it as a .sql into the database:

CREATE TABLE smf_log_errors (
  id_error mediumint(8) unsigned NOT NULL auto_increment,
  log_time int(10) unsigned NOT NULL default '0',
  id_member mediumint(8) unsigned NOT NULL default '0',
  ip char(16) NOT NULL default '                ',
  url text NOT NULL,
  message text NOT NULL,
  session char(32) NOT NULL default '                                ',
  error_type char(15) NOT NULL default 'general',
  file varchar(255) NOT NULL default '',
  line mediumint(8) unsigned NOT NULL default '0',
  PRIMARY KEY (id_error),
  KEY log_time (log_time),
  KEY id_member (id_member),
  KEY ip (ip(16))
) ENGINE=MyISAM;

Ran the updater again and got this message: Incorrect date value: '0000-00-00' for column 'eventDate' at row 1. I've searched around and found the problem is with the database not liking the value '0000-00-00' and it preferring 'null' or a random date. The problem is that I'm a real newbie when it comes to this stuff. Please could somebody give me some pointers on how to proceed.

Sorry if this is in the wrong section -- wasn't sure where to put it.

Did you change all the '0000-00-00'  values? Or need help with it?

Quote from: vbgamer45 on May 09, 2020, 08:24:51 AM
Did you change all the '0000-00-00'  values? Or need help with it?

Thanks for the reply, vbgamer45. I need a bit of help, please. I don't know where to edit it, or how.

Run this query on the database

UPDATE smf_calendar_holidays  SET eventDate = '0001-01-01' WHERE eventDate = '0000-00-00'


Thanks. Sorry to be so thick -- I don't think I'm doing this right. Here's a screen shot attached

Get rid of the whole line SELECT * FROM
Then try again

Did it (see attachment) but the SMF update is still sticking on the same fault:

Which 1.1 version are you updating from?

I think that this could be related to the sql mode which can be strict mode. If strict mode is not enabled, '0000-00-00' format is allowed without errors. If strict mode is enabled, '0000-00-00' is not allowed. Please see the below link.

https://dev.mysql.com/doc/refman/5.7/en/sql-mode.html#sql-mode-strict

For that format to be allowed without errors, the STRICT_TRANS_TABLES mode in mysql config needs to be disabled.

eventDate is a valid column name in 1.1, not in 2.0.  The table structure for _log_errors is different in 1.1 and 2.0, the code posted above is the 2.0 version, was it imported to the original 1.1 database?  Do you have an unaltered dump of the 1.1 database?

Quote from: doug_ips on May 10, 2020, 06:04:37 PM
I think that this could be related to the sql mode which can be strict mode. If strict mode is not enabled, '0000-00-00' format is allowed without errors. If strict mode is enabled, '0000-00-00' is not allowed. Please see the below link.

https://dev.mysql.com/doc/refman/5.7/en/sql-mode.html#sql-mode-strict

For that format to be allowed without errors, the STRICT_TRANS_TABLES mode in mysql config needs to be disabled.

Thanks for the reply. I think you're right. Unfortunately, I don't think I have access to change that on the server. I'll try asking the host. Cheers

Quote from: Sir Osis of Liver on May 10, 2020, 04:30:39 PM
Which 1.1 version are you updating from?

Thanks for the reply. I don't know exactly, I think it was 1.1.21 with TP.

QuoteeventDate is a valid column name in 1.1, not in 2.0.  The table structure for _log_errors is different in 1.1 and 2.0, the code posted above is the 2.0 version, was it imported to the original 1.1 database?

I just ran update.php and whatever that does led to where we are now. It looks like it creates a backup file of each part of the database before automatically deleting it at the end.

QuoteDo you have an unaltered dump of the 1.1 database?

Yes, I took a full backup of the database before I started the upgrade.

I've just had this reply from my host's tech support:

QuoteHello,

There isn't strict mode in effect on the server. Please note this is a shared hosting server where your account is hosted and for the same reason no custom changes can be done as it all user accounts. Please check following snippets and let us know if you need any further assistance.

+------------+
| @@sql_mode |
+------------+
| |
+------------+

+-------------------+
| @@GLOBAL.sql_mode |
+-------------------+
| |
+-------------------+


Thank You!

Best Regards,
---------------------------------------------
Steve
Technical Support

Frankly, I don't have a clue what he means by checking those snippets.  ::)

That means strict mode is not in affect. So shouldn't be the cause of the 0000-00-00 error.
Lets just try to remove that table we can add it back later...
Run this mysql code

DROP TABLE smf_calendar_holidays;





Then run sql

CREATE TABLE smf_calendar_holidays (
  id_holiday smallint(5) unsigned NOT NULL auto_increment,
  event_date date NOT NULL default '0001-01-01',
  title varchar(255) NOT NULL default '',
  PRIMARY KEY (id_holiday),
  KEY event_date (event_date)
) ENGINE=MyISAM;


Thanks. Tried that. Now on the updater I'm geting:


Executing: "Updating holidays and calendar..." (5 of 19 - of this script)
Error: Unknown column 'eventDate' in 'where clause'

Ok lets try it again

DROP TABLE smf_calendar_holidays;

then run

CREATE TABLE smf_calendar_holidays (
  ID_HOLIDAY smallint(5) unsigned NOT NULL auto_increment,
  eventDate date NOT NULL default '0001-01-01',
  title varchar(30) NOT NULL default '',
  PRIMARY KEY (ID_HOLIDAY),
  KEY eventDate (eventDate)
) ENGINE=MyISAM;


Urgh :o

Executing upgrade script 1 of 3.
Executing: "Updating holidays and calendar..." (5 of 19 - of this script)
Error!
Incorrect date value: '0000-00-00' for column 'eventDate' at row 1

Very very strange.....Attach .sql file. for upgrade..

0000-00-00 stopped being a legal date in MySQL so,e versions ago, cf all the changes in 2.1 to make it 1004-01-01.

Do you have an idea why? Even after dropping that whole they would get the same error?

It's part of the new strict mode, see https://dev.mysql.com/doc/refman/8.0/en/sql-mode.html#sqlmode_no_zero_date

So the old default above   eventDate date NOT NULL default '0001-01-01',
Won't work? And needs to be changed?
I just checked 2.1 and uses the same default date.

The birthdate was changed in the members table to 1004-01-01, I assumed this had been changed too for similar reasons (but I stopped caring about the calendar a long time ago)

Ah, you are right. I was doing a quick search on .sql files the code I was looking at was 1.1 upgrade part.

Tried deleting again and running:

CREATE TABLE smf_calendar_holidays (
  ID_HOLIDAY smallint(5) unsigned NOT NULL auto_increment,
  eventDate date NOT NULL default '1004-01-01',
  title varchar(30) NOT NULL default '',
  PRIMARY KEY (ID_HOLIDAY),
  KEY eventDate (eventDate)
) ENGINE=MyISAM;

And that brings up this on the My Sql:

MySQL returned an empty result set (i.e. zero rows). (Query took 0.0020 seconds.)
CREATE TABLE smf_calendar_holidays ( ID_HOLIDAY smallint(5) unsigned NOT NULL auto_increment, eventDate date NOT NULL default '1004-01-01', title varchar(30) NOT NULL default '', PRIMARY KEY (ID_HOLIDAY), KEY eventDate (eventDate) ) ENGINE=MyISAM

and this on the update.php:

Executing database changes
Please be patient - this may take some time on large forums. The time elapsed increments from the server to show progress is being made!
Executing upgrade script 1 of 3.
Executing: "Updating holidays and calendar..." (5 of 19 - of this script)
Error!
Incorrect date value: '0000-00-00' for column 'eventDate' at row 1

Turning strict mode off resolves this issue.

You should leave the original logic, the only change needed is to disable strict mode.

Quote from: shawnb61 on May 11, 2020, 11:05:02 AM
Turning strict mode off resolves this issue.

You should leave the original logic, the only change needed is to disable strict mode.

Thanks for the reply, but the server admins say strict mode is not enabled

Ask them to turn off NO_ZERO_DATE mode.

Quote from: Arantor on May 11, 2020, 11:16:47 AM
Ask them to turn off NO_ZERO_DATE mode.

They tell me because it's a shared environment they're not prepared to mod the PHP

I would set it globally to '' at the server level.

smf1.1 provided the capability to address this by adding
$mysql_set_mode = true;
to Settings.php.  That works, too. 

Quote from: PD3 on May 11, 2020, 11:48:06 AM
They tell me because it's a shared environment they're not prepared to mod the PHP

It's not a php setting, it's a mysql setting.

But then try the $mysql_set_mode suggestion from above.

I'd edit the update/upgrade script and remove the restriction from the mysql SESSION variable.

https://github.com/ShamblesX/SMF-Tools/blob/master/RemoveModeFromMysqlSession.php

RemoveModeFromMysqlSession ( 'NO_ZERO_DATE' );

or

RemoveModeFromMysqlSession ( 'STRICT_TRANS_TABLES' );

Quote from: Shambles on May 11, 2020, 12:16:03 PM
I'd edit the update/upgrade script and remove the restriction from the mysql SESSION variable.

https://github.com/ShamblesX/SMF-Tools/blob/master/RemoveModeFromMysqlSession.php

Code Select Expand

RemoveModeFromMysqlSession ( 'NO_ZERO_DATE' );

or

Code Select Expand

RemoveModeFromMysqlSession ( 'STRICT_TRANS_TABLES' );

Thanks for the reply. Where do I run that query, on the root_smf structure? I'm a real noob at this, sorry.

Quote from: shawnb61 on May 11, 2020, 11:50:58 AM

Quote from: PD3 on May 11, 2020, 11:48:06 AM
They tell me because it's a shared environment they're not prepared to mod the PHP

It's not a php setting, it's a mysql setting.

But then try the $mysql_set_mode suggestion from above.

Error
Static analysis:

4 errors were found during analysis.

Unexpected character. (near "$" at position 0)
Unexpected beginning of statement. (near "$" at position 0)
Unexpected beginning of statement. (near "mysql_set_mode" at position 1)
Unexpected beginning of statement. (near "true" at position 18)
SQL query:

$mysql_set_mode = true

MySQL said: Documentation

#1064 - You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '$mysql_set_mode = true' at line 1

Quote from: PD3 on May 11, 2020, 12:34:25 PM

Quote from: Shambles on May 11, 2020, 12:16:03 PM
I'd edit the update/upgrade script and remove the restriction from the mysql SESSION variable.

https://github.com/ShamblesX/SMF-Tools/blob/master/RemoveModeFromMysqlSession.php

Code Select Expand

RemoveModeFromMysqlSession ( 'NO_ZERO_DATE' );

or

Code Select Expand

RemoveModeFromMysqlSession ( 'STRICT_TRANS_TABLES' );

Thanks for the reply. Where do I run that query, on the root_smf structure? I'm a real noob at this, sorry.

It is not a query. It is an edit to the upgrade.php file.

Quote from: PD3 on May 11, 2020, 12:37:49 PM

Quote from: shawnb61 on May 11, 2020, 11:50:58 AM

Quote from: PD3 on May 11, 2020, 11:48:06 AM
They tell me because it's a shared environment they're not prepared to mod the PHP

It's not a php setting, it's a mysql setting.

But then try the $mysql_set_mode suggestion from above.

Error
Static analysis:

4 errors were found during analysis.

Unexpected character. (near "$" at position 0)
Unexpected beginning of statement. (near "$" at position 0)
Unexpected beginning of statement. (near "mysql_set_mode" at position 1)
Unexpected beginning of statement. (near "true" at position 18)
SQL query:

$mysql_set_mode = true

MySQL said: Documentation

#1064 - You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '$mysql_set_mode = true' at line 1

Did you enter the code posted by shawnb61 at your Settings.php file correctly?

Sorry, forgot the semicolon:
$mysql_set_mode = true;

::)

Quote from: doug_ips on May 11, 2020, 12:47:23 PM

Quote from: PD3 on May 11, 2020, 12:34:25 PM

Quote from: Shambles on May 11, 2020, 12:16:03 PM
I'd edit the update/upgrade script and remove the restriction from the mysql SESSION variable.

https://github.com/ShamblesX/SMF-Tools/blob/master/RemoveModeFromMysqlSession.php

Code Select Expand

RemoveModeFromMysqlSession ( 'NO_ZERO_DATE' );

or

Code Select Expand

RemoveModeFromMysqlSession ( 'STRICT_TRANS_TABLES' );

Thanks for the reply. Where do I run that query, on the root_smf structure? I'm a real noob at this, sorry.

It is not a query. It is an edit to the upgrade.php file.

Thanks. So if I edit the update file, can I then run it again without damaging anything, even though it's already half way through updating?

Quote

Quote from: PD3 on May 11, 2020, 12:37:49 PM

Quote from: shawnb61 on May 11, 2020, 11:50:58 AM

Quote from: PD3 on May 11, 2020, 11:48:06 AM
They tell me because it's a shared environment they're not prepared to mod the PHP

It's not a php setting, it's a mysql setting.

But then try the $mysql_set_mode suggestion from above.

Error
Static analysis:

4 errors were found during analysis.

Unexpected character. (near "$" at position 0)
Unexpected beginning of statement. (near "$" at position 0)
Unexpected beginning of statement. (near "mysql_set_mode" at position 1)
Unexpected beginning of statement. (near "true" at position 18)
SQL query:

$mysql_set_mode = true

MySQL said: Documentation

#1064 - You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '$mysql_set_mode = true' at line 1

Did you enter the code posted by shawnb61 at your Settings.php file correctly?

I think so. See attachment. I put the script in the window and then press the 'go' button highlighted.

Quote from: PD3 on May 11, 2020, 02:59:13 PM
I think so. See attachment. I put the script in the window and then press the 'go' button highlighted.

You must add it to your Settings.php file and not run it as a query. Said file can be found in the root of your forum folder, the one that contains the db info.

Quote from: doug_ips on May 11, 2020, 04:11:49 PM

Quote from: PD3 on May 11, 2020, 02:59:13 PM
I think so. See attachment. I put the script in the window and then press the 'go' button highlighted.

You must add it to your Settings.php file and not run it as a query. Said file can be found in the root of your forum folder, the one that contains the db info.

Thanks -- noob mistake, I know  ::)

Quote from: PD3 on May 11, 2020, 06:16:31 PM

Quote from: doug_ips on May 11, 2020, 04:11:49 PM

Quote from: PD3 on May 11, 2020, 02:59:13 PM
I think so. See attachment. I put the script in the window and then press the 'go' button highlighted.

You must add it to your Settings.php file and not run it as a query. Said file can be found in the root of your forum folder, the one that contains the db info.

Thanks -- noob mistake, I know  ::)

Do not worry about it. :)

Thanks Doug

I edited settings.php (see attachment) and there's no change when I run upgrade.php -- have I done it right?

Should I go on an edit upgrade.php as suggested earlier in the thread?

Appreciate all the help, guys. Thanks  :)

Everything in green is a comment, meaning the inserted line is being ignored.

The comment before it is not closed properly, which explains that.  Remove the space between the "*" and the "/".   

"*/" closes a comment, "*  /" does not.

Thanks. Changed it, but still the same result on upgrade.php  :-\

Is it still green?

No, it's changed colour now -- see attached

Quote from: Shambles on May 11, 2020, 12:16:03 PM
I'd edit the update/upgrade script and remove the restriction from the mysql SESSION variable.

https://github.com/ShamblesX/SMF-Tools/blob/master/RemoveModeFromMysqlSession.php

Code Select Expand

RemoveModeFromMysqlSession ( 'NO_ZERO_DATE' );

or

Code Select Expand

RemoveModeFromMysqlSession ( 'STRICT_TRANS_TABLES' );

I tried this just now (see attachment) and it made no difference to the update when I ran it again. It's still hanging on the zero date issue as before. Have I inserted the code in a place where it will have the desired effect, or should I put it somewhere else?

STRICT_TRANS_TABLES isn't the problem here, you need to remove NO_ZERO_DATE.

Quote from: Arantor on May 13, 2020, 04:10:10 AM
STRICT_TRANS_TABLES isn't the problem here, you need to remove NO_ZERO_DATE.

Thanks, put that in too (see attachment) and it hasn't made any difference to the update when I ran it again. It's still hanging on the event date on the calendar.

Strange, though -- last time I ran the update it got to 19% overall progress and 10.3% step progress, but now I've made the adjustment to the upgrade.php file it's hanging at 18 and 10% respectively. Am I definitely putting the code into the correct place on the file?

Right -- put the whole script from github in at the top of the upgrade.php page, ran the upgrade again, and it's still hanging in the same place as last time.

Any other ideas to try?

Thanks  :-\

The code sample you provided above is from the 2.1 upgrader, not the 2.0 upgrader...  All the input I've given above is applicable for 2.0, not 2.1...

I strongly suggest a 2.0 upgrade, not a 2.1 upgrade.  Get the 2.0.17 upgrade from here:
https://download.simplemachines.org/

And set the $mysql_set_mode as instructed above.

Thanks Shawn. I've tried editing the new upgrade.php a few times and I'm obviously not doing it right, because each time it leads to an error page when I run it. Please could you or somebody tell me where to add the code. I have tried inserting it in several different places around where the db is set going (see attachment), am I in the right place?

No changes needed to the upgrader files.

Please just use the files from the .zip you downloaded.

Add the $mysql_set_mode entry to settings.php.  I believe that one line insertion to settings.php is the only change needed.

If you get another error, let's see that.

Did that -- $mysql_set_mode = true; was already in settings.php, so left it there. Ran the updater and it froze again. With the new updater there aren't any error reports, it just freezes and after a while brings up this error message:

Quote
!!Error!
Server has not responded for 30 seconds. It may be worth waiting a little longer or otherwise please click here to try this step again

I restart it after a while and it does the same again. So far the longest I've left it is an hour. Should I leave it longer?

Screen shot attached.

Thanks

Please restart. 

This time, on the "Upgrade Options" screen, check the box for "Output extra debugging information".  That will get us more info to work from here.

I did what you said and it didn't output anything else. See screen shot attached. I scrolled down as far as it would go and it was just blank

To confirm what you did before -

You unzipped the contents of smf_2-0-17_upgrade.zip, and placed *all* of the contents of those files on top of your forum's previous files, correct?

Other than that one line in Settings.php, *nothing* has been altered, correct?

Quote from: shawnb61 on May 14, 2020, 12:00:19 PM
To confirm what you did before -

You unzipped the contents of smf_2-0-17_upgrade.zip, and placed *all* of the contents of those files on top of your forum's previous files, correct?

Other than that one line in Settings.php, *nothing* has been altered, correct?

Yes, see screenshot attached. Folders marked 'new' I'm guessing are old, due to the date on them

I have a nasty feeling this is all going to come down to me doing something stupidly wrong...

Who knows?  (Even if so, we've all been there! ;))

But maybe it's time to take a step back further to understand how we got here.

Was your 1.1 forum working properly?  What happened leading up to the upgrade?  Did your host upgrade mysql?  php?  Did you change hosts? 

I don't think 1.1 would run under strict mode (not without the 1.1 mysql_set_mode tweak), so I'm wondering if/how you were running prior to the upgrade attempt... 

Quote from: shawnb61 on May 14, 2020, 12:56:51 PM
Who knows?  (Even if so, we've all been there! ;))

But maybe it's time to take a step back further to understand how we got here.

Was your 1.1 forum working properly?  What happened leading up to the upgrade?  Did your host upgrade mysql?  php?  Did you change hosts? 

I don't think 1.1 would run under strict mode (not without the 1.1 mysql_set_mode tweak), so I'm wondering if/how you were running prior to the upgrade attempt...

The (TinyPortal SMF) forum is almost dormant, but we still have a few of the old regulars come around from time to time, post a bit of news about their life and swap comments with others, but replies can be weeks apart. I haven't updated anything for a long time and there haven't been any errors. It was all running fine. We are still hosted in the same place and as far as I know nothing has changed. The only thing I can think of is that the hosts have updated php on the server.

Sorry, I'm slow on the uptake...  Did you upgrade to get current?  Or due to the apparent upgrade by your host?

I think in an ideal world, we'd start over.  If feasible, restore to where you were.  Make sure 1.1 is running fine.  Then unzip the 2.0.17 upgrade, do the mysql set mode thing.  And try again.

If the mysql set mode thing doesn't work, we'll try another way to disable strict mode.

Quote from: shawnb61 on May 14, 2020, 09:37:30 PM
Sorry, I'm slow on the uptake...  Did you upgrade to get current?  Or due to the apparent upgrade by your host?

I updated because when I went to go on the forum I got a white screen and a 500 error. It had crashed on its own, for no apparent reason.

Quote
I think in an ideal world, we'd start over.  If feasible, restore to where you were.  Make sure 1.1 is running fine.  Then unzip the 2.0.17 upgrade, do the mysql set mode thing.  And try again.

Sadly not possible.

Quote
If the mysql set mode thing doesn't work, we'll try another way to disable strict mode.

Thanks -- the annoying part is that nobody even uses the calendar, and that's the bit that's causing it to hang.

Do not you have a backup of your database from before the upgrade?

If you do not, smf makes its own backup of the db before upgrading. It prefixes the backuped tables with backup_smf if I recall it correctly. You can revert back to 1.1 easy.

Quote from: doug_ips on May 15, 2020, 05:23:15 AM
Do not you have a backup of your database from before the upgrade?

If you do not, smf makes its own backup of the db before upgrading. It prefixes the backuped tables with backup_smf if I recall it correctly. You can revert back to 1.1 easy.

Yes, I took a backup before starting. Are you saying I should restore from the backup, even though it wasn't working before?

Quote from: PD3 on May 15, 2020, 06:46:06 AM

Quote from: doug_ips on May 15, 2020, 05:23:15 AM
Do not you have a backup of your database from before the upgrade?

If you do not, smf makes its own backup of the db before upgrading. It prefixes the backuped tables with backup_smf if I recall it correctly. You can revert back to 1.1 easy.

Yes, I took a backup before starting. Are you saying I should restore from the backup, even though it wasn't working before?

Yes, as per shawnb61 advice. I think it is worth a shot.

OK, thanks -- I'll give it a try. Once I've restored it, do I just run the update.php again, or edit anything else first?

I believe the only thing to change would be to insert the mysql_set_mode line in settings.php.

The reason I am suggesting starting over is that I think we kinda mangled 2.0 & 2.1 & 1.1 updates.  E.g., your settings.php file now looks like a 2.1 file, not a 1.1 file. 

It may not change anything, other than rule out partial updates as a cause should we encounter more issues.  Ideally, you start all upgrades from a fully working forum. 

Restored to previous version and ran the update again. It made no difference. At this stage I'm worried I'm not going to get my forum back.

Quote from: PD3 on May 18, 2020, 11:29:30 AM
Restored to previous version and ran the update again. It made no difference. At this stage I'm worried I'm not going to get my forum back.

You do not have to worry about that as long as you have the db backup.

Can you get it back up & running in v1.1?

Hi Shawn, no I can't get it running at all. I sent a support ticket to my host yesterday, asking them to change the php version back, as I was under the impression them updating php caused the issue. This is the response I received:

QuotePlease note your forum didn't break because of the PHP update as it doesn't affect any of the user data. That issue was fixed by simply changing PHP version. Our server support Multiple PHP versions so you can use different versions of PHP. You can manage it in cPanel > MultiPHP Manager option. Changing PHP version back to older one made your site state as it is as before. It was explained in ticket WCD-911-63084 in my post sent on 09 March 2020 06:09 AM.

Problem is incompatibility issue as your forum was too old and looks like never updated. For now I have changed PHP back to 5.6.

Let me know if you need any further assistance.


Thank You!

I tried running upgrade.php again this morning, and it stuck on 14%, as it did before, and didn't output any error messages, though I did tick the box asking it to do so.

As noted above, the "strict" issues are not due to a php version change.   

They would be caused by a mysql version change.

Did they change mysql also? 

Even then, we can normally get past strict mode issues, even on newer versions of php & mysql.  I am now more concerned with the state of the backup itself. 

Are we certain that the backup is from before the issues started (the backup is of a working forum)?   

The backup I'm trying to use was taken when the forum was down, but the Cpanel takes backups automatically, so according to the techs at the hosting company, it might be possible to restore the whole site. He says this:

QuoteI am sorry to see this problem you have with your forums at the moment. I see that forums was actually broken after you tried to update it (JSC-920-48795). Unfortunately we cannot debug code related problems as it's more likely a developer side work. We can have a look into this but unfortunately cannot guarantee if it will be fixed. I believe you have set a maintenance page currently. Please disable it and provide steps to replicate the problem on our side so we can investigate properly.

Alternatively we can help you with restoring site and we can see if that helps. You can also try restoring data from your side by using "Restore Manager" option provided in cPanel main interface. With restore manager you cannot just restore specific data like files, database but full account can be also restored. Please confirm if you want us restoring it and what data you need to restore.


Thank You!

What would you recommend doing?

One other question:

Quote from: shawnb61 on May 20, 2020, 11:34:13 AM
Did they change mysql also? 

I've asked the question, just waiting for the reply from them now.

If I have to disable the maintenance page, how do I do that? I tried running upgrade.php with the option unticked, hoping that would do the trick, but it didn't. I don't mind losing a couple of month's worth of posts if the Cpanel restore is the only option at this point.

They have answered to say their backup only goes back 7 days and they have not updated MySQL.

Sorry there is a lot back and forth trying to figure this out. I can also try to convert on my side if that is an option you want to go.

Quote from: PD3 on May 22, 2020, 12:49:14 PM
They have answered to say their backup only goes back 7 days and they have not updated MySQL.

Before the upgrader runs, it makes a backup of your tables and prefixes them with backup_ I think. Are such tables in your db?

Quote from: vbgamer45 on May 22, 2020, 02:06:17 PM
Sorry there is a lot back and forth trying to figure this out. I can also try to convert on my side if that is an option you want to go.

Thanks for the offer. I'm open to any suggestions at this point.

Quote from: doug_ips on May 22, 2020, 02:29:22 PM

Quote from: PD3 on May 22, 2020, 12:49:14 PM
They have answered to say their backup only goes back 7 days and they have not updated MySQL.

Before the upgrader runs, it makes a backup of your tables and prefixes them with backup_ I think. Are such tables in your db?

Yes, they're all there with the prefix.

*Bump

Quote from: PD3 on June 01, 2020, 04:52:09 AM
*Bump

Did you revert your forum back to your previous version?

Quote from: doug_ips on June 01, 2020, 05:39:24 AM

Quote from: PD3 on June 01, 2020, 04:52:09 AM
*Bump

Did you revert your forum back to your previous version?

I'm not able to revert it back to the previous version. I've tried everything.

Quote from: PD3 on June 02, 2020, 05:31:56 AM

Quote from: doug_ips on June 01, 2020, 05:39:24 AM

Quote from: PD3 on June 01, 2020, 04:52:09 AM
*Bump

Did you revert your forum back to your previous version?

I'm not able to revert it back to the previous version. I've tried everything.

I can take a look at this for you if you want.

Quote from: doug_ips on June 02, 2020, 06:28:23 AM

Quote from: PD3 on June 02, 2020, 05:31:56 AM

Quote from: doug_ips on June 01, 2020, 05:39:24 AM

Quote from: PD3 on June 01, 2020, 04:52:09 AM
*Bump

Did you revert your forum back to your previous version?

I'm not able to revert it back to the previous version. I've tried everything.

I can take a look at this for you if you want.

Thanks Doug. Should I PM you login details?

Quote from: PD3 on June 03, 2020, 04:31:53 AM

Quote from: doug_ips on June 02, 2020, 06:28:23 AM

Quote from: PD3 on June 02, 2020, 05:31:56 AM

Quote from: doug_ips on June 01, 2020, 05:39:24 AM

Quote from: PD3 on June 01, 2020, 04:52:09 AM
*Bump

Did you revert your forum back to your previous version?

I'm not able to revert it back to the previous version. I've tried everything.

I can take a look at this for you if you want.

Thanks Doug. Should I PM you login details?

Yes.

All the errors have been fixed and the forum has been successfully upgraded to 2.0.17.

A very hearty thank you, doug_ips.  VERY helpful.

Any lessons to share?

Good work, doug.

Thanks guys. I am glad to have been of help.

Nothing to share btw Shawn. At least nothing new that was not already covered in this topic.

Just wanted to say thanks again for all the help, and in particular to Doug for sorting it out for me. Apparently it was a server problem, and not something I had done wrong, which is a relief to find out. I don't feel quite so stupid  ;D

Quote from: Hakan KUTLUTÜRK on February 12, 2021, 09:23:39 AM

Can you help me? I have the same problem and I could not overcome it.

please start your own topic (in english) with the exact problems that you are having
and what you are trying to do to get these errors

if you need help in your native language, then please search in the Language Specific Support (https://www.simplemachines.org/community/index.php?board=12.0) for your native language and you can post in there
given your other posts I'm going to say Turkish (https://www.simplemachines.org/community/index.php?board=76.0)
all other places, posts must be in english, thank you.