An option to disable the 'Contact' link / Backup-Restore (Features)

by shian, Sunday, August 30, 2020, 13:54 (1329 days ago)

One feature that I personally would use is to disable the 'Contact' link at the bottom of the forum screen.

In my case I prefer to get email directly from the sender; The other reason is that the 'Contact' link is a "great" feature for spam mail, and this is annoying.

I guess that the option to disable the 'Contact' link should be in the 'Advanced options' of the forum. (In my case the email is displayed on the screen).


Another thing:

One of the best admin features of my little forum is the 'Backup'. I would love to use it instead of using the cpanel of the server. Yet, every time that I've tried to 'Restore' a database it failed with the message (or something similar):

Error!

MySQL error: Incorrect datetime value: '' for column `rapideup_mylittleforum-2.4.21`.`mlf2_temp_infos`.`time` at row 1

If the 'Backup' feature is not reliable, then it shouldn't be there, yet I guess that a lot of users would love to use this great feature. We all know that Backup is critical and we all need it. I would love to see it works, really.


Thank you for this great software.

Avatar

Error in the backup-restore-function

by Auge ⌂, Friday, September 04, 2020, 15:43 (1323 days ago) @ shian

Hello

One of the best admin features of my little forum is the 'Backup'. I would love to use it instead of using the cpanel of the server. Yet, every time that I've tried to 'Restore' a database it failed with the message (or something similar):

Error!

MySQL error: Incorrect datetime value: '' for column `rapideup_mylittleforum-2.4.21`.`mlf2_temp_infos`.`time` at row 1

Did you encounter further errors?

If the 'Backup' feature is not reliable, then it shouldn't be there, yet I guess that a lot of users would love to use this great feature. We all know that Backup is critical and we all need it. I would love to see it works, really.

With version 2.5 the backup function will get removed. It's because we get error reports every when and then – often months after the introduction of new datafields or tables – for this function like the one above. Not every admin run backups. Not every admin who run backups reimports the data. Because of that we have a fair chance to forget something in the backup function without taking notice of it (we as developers and forum operators) for a long time.

We came to the conclusion that it's much better to remove this function and to point the audience to tools like phpMyAdmin, the MySQL-Workbench or equivalents.

To be fair, it's necessary to remove known errors as long as we maintain the 2.4-branch. So, if you found and find further error messages like the one above, please tell us about it.

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Error in the backup-restore-function

by shian, Friday, September 04, 2020, 18:14 (1323 days ago) @ Auge

Error!

MySQL error: Incorrect datetime value: '' for column `rapideup_mylittleforum-2.4.21`.`mlf2_temp_infos`.`time` at row 1


Did you encounter further errors?

As far as I remember this was the only error, in PHP version 5.x as well as in PHP version 7.x - the same error after a clean install of the forum and the database.

With version 2.5 the backup function will get removed. ...

We came to the conclusion that it's much better to remove this function and to point the audience to tools like phpMyAdmin, the MySQL-Workbench or equivalents.

I see. I'll use other tools then. :crying:

To be fair, it's necessary to remove known errors as long as we maintain the 2.4-branch. So, if you found and find further error messages like the one above, please tell us about it.

I did not find more errors yet. Actually, this specific error never allowed me to restore my backups even once...

BTW, since I backup everything every 30 minutes (emotional disorder :cool: )... the Backup feature was the punch line in my decision to go for 'my little forum', which was the best choice. Honestly.

I'll live without this feature - 'my little forum' is still much better then other bloated forums.

I wonder if 'my little forum' could create a database file in the home directory... I don't know much about servers and PHP though.

Thank you.

Avatar

I think I found the reason for the backup error

by Auge ⌂, Monday, September 07, 2020, 12:15 (1321 days ago) @ shian

Hello

One of the best admin features of my little forum is the 'Backup'. I would love to use it instead of using the cpanel of the server. Yet, every time that I've tried to 'Restore' a database it failed with the message (or something similar):

Error!

MySQL error: Incorrect datetime value: '' for column `rapideup_mylittleforum-2.4.21`.`mlf2_temp_infos`.`time` at row 1

Please open the backup file and search for the INSERT-statements of the temp-info-table (should be named mlf2_temp_infos or similar). Are there entries with 'NULL' (with empty single quotes) as third value of a row?

INSERT INTO mlf2_temp_infos VALUES ('foo', 'bar', '');

If so, please change it to …

INSERT INTO mlf2_temp_infos VALUES ('foo', 'bar', NULL);

… (value NULL without single quotes) and try again to restore the backup.

The installation SQL-script in itself defines the column time to be NULL or an datetime value. That does obviously does not allow the column to be an empty string '' on your server even this seems to be no problem on some other servers.

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

I think I found the reason for the backup error

by shian, Tuesday, September 08, 2020, 08:25 (1320 days ago) @ Auge

Thank you.

This is the entry in my last backup of my little forum, using the 'Backup' feature:

#
# mlf2_temp_infos
#
TRUNCATE TABLE mlf2_temp_infos;
INSERT INTO mlf2_temp_infos VALUES ('last_changes', '1598868462', '2020-08-31 13:07:42');
 


And this is the entry in my last backup of my little forum, using the server's cpanel:

--
-- Table structure for table `mlf2_temp_infos`
--
 
DROP TABLE IF EXISTS `mlf2_temp_infos`;
/*!40101 SET @saved_cs_client     = @@character_set_client */;
/*!40101 SET character_set_client = utf8 */;
CREATE TABLE `mlf2_temp_infos` (
  `name` VARCHAR(50) NOT NULL,
  `value` VARCHAR(255) NOT NULL,
  `time` TIMESTAMP NULL DEFAULT NULL,
  PRIMARY KEY (`name`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
/*!40101 SET character_set_client = @saved_cs_client */;
 
--
-- Dumping data for table `mlf2_temp_infos`
--
 
LOCK TABLES `mlf2_temp_infos` WRITE;
/*!40000 ALTER TABLE `mlf2_temp_infos` DISABLE KEYS */;
INSERT INTO `mlf2_temp_infos` (`name`, `value`, `time`) VALUES ('last_changes','1598868462','2020-08-31 10:07:42');
/*!40000 ALTER TABLE `mlf2_temp_infos` ENABLE KEYS */;
UNLOCK TABLES;
 


It looks OK. So I tried to restore again using my little forum 'Restore', and I got a new error! :-D :

Error!

    MySQL error: Column count doesn't match value count at row 1


it's getting interesting... BTW - The 'Restore' simply erased all entries in my Forum! :-|

Thank you, shian.

Avatar

I think I found the reason for the backup error

by Auge ⌂, Tuesday, September 08, 2020, 09:57 (1320 days ago) @ shian

Hello

This is getting confuse.

This is the entry in my last backup of my little forum, using the 'Backup' feature:

#
# mlf2_temp_infos
#
TRUNCATE TABLE mlf2_temp_infos;
INSERT INTO mlf2_temp_infos VALUES ('last_changes', '1598868462', '2020-08-31 13:07:42');

Ok, there is only this one entry ('last_changes', '1598868462', '2020-08-31 13:07:42') in the table mlf2_temp_infos? No entry for the version number? No entry for the latest version check?

And this is the entry in my last backup of my little forum, using the server's cpanel:

--
-- Table structure for table `mlf2_temp_infos`
--
 
DROP TABLE IF EXISTS `mlf2_temp_infos`;
/*!40101 SET @saved_cs_client     = @@character_set_client */;
/*!40101 SET character_set_client = utf8 */;

Delete an possibly existing table of the name mlf2_temp_infos.

 
CREATE TABLE `mlf2_temp_infos` (
`name` VARCHAR(50) NOT NULL,
`value` VARCHAR(255) NOT NULL,
`time` TIMESTAMP NULL DEFAULT NULL,
PRIMARY KEY (`name`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
/*!40101 SET character_set_client = @saved_cs_client */;

That's the same create statement than the one from the installation script.

 
LOCK TABLES `mlf2_temp_infos` WRITE;
/*!40000 ALTER TABLE `mlf2_temp_infos` DISABLE KEYS */;
INSERT INTO `mlf2_temp_infos` (`name`, `value`, `time`) VALUES ('last_changes','1598868462','2020-08-31 10:07:42');
/*!40000 ALTER TABLE `mlf2_temp_infos` ENABLE KEYS */;
UNLOCK TABLES;

Ok, the one dataset from above ('last_changes','1598868462','2020-08-31 10:07:42', the ony difference is the time (zone)) seems to be really the only entry in the table. So far so good (but disturbing).

It looks OK. So I tried to restore again using my little forum 'Restore', and I got a new error! :-D :

Error!

MySQL error: Column count doesn't match value count at row 1

Oh, that is definitely another statement. Because the forum entries are gone I guess it's the statement for the table mlf2_entries. The statement for the table mlf2_temp_infos implicitely specifies three columns (with not naming them, there are only three columns in the table (`name`, `value`, `time`)) and provides data for three columns ('last_changes', '1598868462', '2020-08-31 13:07:42').

it's getting interesting... BTW - The 'Restore' simply erased all entries in my Forum! :-|

:-( I hope, you have a working backup and did the tests in a non productive copy of your real forum. I will definitely dig into it.

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

I think I found the reason for the backup error

by shian, Tuesday, September 08, 2020, 14:02 (1320 days ago) @ Auge

This is the entry in my last backup of my little forum, using the 'Backup' feature:

#
# mlf2_temp_infos
#
TRUNCATE TABLE mlf2_temp_infos;
INSERT INTO mlf2_temp_infos VALUES ('last_changes', '1598868462', '2020-08-31 13:07:42');


Ok, there is only this one entry ('last_changes', '1598868462', '2020-08-31 13:07:42') in the table mlf2_temp_infos? No entry for the version number? No entry for the latest version check?

No. That's all there is, one entry.

It looks OK. So I tried to restore again using my little forum 'Restore', and I got a new error! :-D :

Error!

MySQL error: Column count doesn't match value count at row 1


Oh, that is definitely another statement. Because the forum entries are gone I guess it's the satement for the table mlf2_entries. The statement for the table mlf2_temp_infos implicitely specifies three columns (with not naming them, there are only three columns in the table (`name`, `value`, `time`)) and provides data for three columns ('last_changes', '1598868462', '2020-08-31 13:07:42').

it's getting interesting... BTW - The 'Restore' simply erased all entries in my Forum! :-|


:-( I hope, you have a working backup and did the tests in a non productive copy of your real forum. I will definitely dig into it.

Tschö, Auge

Thank you. I backup everything, always. Yet I did the tests in a productive copy... anyone who knows me cannot be too surprised... :-)

Avatar

Now I know that I found the reason for the backup error

by Auge ⌂, Tuesday, September 22, 2020, 21:24 (1305 days ago) @ shian

Hello

… I tried to restore again using my little forum 'Restore', and I got a new error![/i] :-D :

Error!

MySQL error: Column count doesn't match value count at row 1

This is definitely the entries table (as I assumed). There was the column email_notification up to the version 2.4.13. With the new structure to store subscriptions, introduced with 2.4.14 the column got removed but it still existed in the backup script. It is there only in the INSERT-statements for the restore that does not contain a column list. Default behaviour of MySQL in this case is to try to distribute the given data to all of the columns but the number of provided data columns in the INSERT-statement does not fit with the real number of table columns (valid for version installed before 2.4.14 and updated to version 2.4.14 or higher).

Additionally I found the column email_notification in the installation script. If the forum was installed with a newer version than 2.4.13 the column was created but never used. If one created a backup and restored it, the number of columns in the statements and in the table matched. With a version that was installed before 2.4.14 and where the update script removed the column with the update to 2.4.14 the number of columns does not match in case of restoring a backup.

I reworked the whole backup script.

- The statement strings that will be created by the script will from now on contain a field/column list in every statement. With that one can compare the number of table columns with the number of data fields if one can read SQL-code.
- I added backup functions for subscriptions and for tags.
- I corrected the statement for the entries and removed the column email_notification in the end.
- I put a bit of work into the determination of the file sizes of the backup files after seeing file sizes of 0.000MB for files with under 1 Kilobyte of data.

I will release a new version (2.4.22) within the next two days (until thursday evening (CEST)).

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Now I know that I found the reason for the backup error

by shian, Wednesday, September 23, 2020, 17:48 (1304 days ago) @ Auge

This is definitely the entries table (as I assumed). There was the column email_notification up to the version 2.4.13. With the new structure to store subscriptions, introduced with 2.4.14 the column got removed but it still existed in the backup script. It is there only in the INSERT-statements for the restore that does not contain a column list. Default behaviour of MySQL in this case is to try to distribute the given data to all of the columns but the number of provided data columns in the INSERT-statement does not fit with the real number of table columns (valid for version installed before 2.4.14 and updated to version 2.4.14 or higher).

Additionally I found the column email_notification in the installation script. If the forum was installed with a newer version than 2.4.13 the column was created but never used. If one created a backup and restored it, the number of columns in the statements and in the table matched. With a version that was installed before 2.4.14 and where the update script removed the column with the update to 2.4.14 the number of columns does not match in case of restoring a backup.


Thank you very much for this professional work!

In my case I've installed my little forum version 2.4.21 (I did not upgrade from older version), so maybe in my case the problem is different?

Thank you, shian

Avatar

Now I know that I found the reason for the backup error

by Auge ⌂, Wednesday, September 23, 2020, 19:28 (1304 days ago) @ shian

Hello

In my case I've installed my little forum version 2.4.21 (I did not upgrade from older version), so maybe in my case the problem is different?

I can not think of another cause. This is because I checked every single query and every single concatenated query string for the backup restore process in the backup function angainst the table structure in the install.sql and against the real database of my own testing forum (initially installed as version 2.4.6).

The column mlf2_entries.email_notification was in fact the only column that I found to be able to cause such an error. Maybe your error will remain after an update to 2.4.22 but the error that I found will be gone and I would keep searching for the cause of your error (but then I would need additionally informations about your installation and data).

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Now I know that I found the reason for the backup error

by shian, Thursday, September 24, 2020, 08:23 (1304 days ago) @ Auge

The column mlf2_entries.email_notification was in fact the only column that I found to be able to cause such an error. Maybe your error will remain after an update to 2.4.22 but the error that I found will be gone and I would keep searching for the cause of your error (but then I would need additionally informations about your installation and data).

You're right.
Maybe this is a server issue? over security?
I've created the SQL database while I installed my little forum (mylittleforum-2.4.21.tar.gz), and enabled all types of access to the database by the user (myself).

I can send you the last backups using my little forum's admin, and using the server's cpanel, so you can analyze them, if you want. Just let me know how.

The server I'm using has all software and hardware new and updated.

Lately I've switched to PHP version 7.4 from version 7.2, yet I didn't see any problem related to it. The 'Restore' problem was exist in all PHP versions that I've used (5.4, 7.2, 7.4). (hopefully I don't make mistake with the version numbers...).

The only thing that I've manually changed in the installation is the default theme, i.e. the files 'main.tpl' and 'style.min.css' in the directory 'forum/themes/default/' - but this was done carefully not to mess with the beautiful default theme.

Thank you, shian.

RSS Feed of thread