Thread Starter
slepi
(@slepi)
I found the problem: eshop-install.php:889-897 sql insert statements don’t insert the emailContent value, for which no default value is specified.
Is it enough just to insert the missing rows with correct id’s for the respective merchant gateway (e.g. #3 for PayPal, #5 for Cash…)?
We will look into this but I have to point out that we cannot replicate your issue.
Thread Starter
slepi
(@slepi)
bug revealed:
eshop-install.php, line 795:
create table eshop_emails (..., emailContent TEXT NOT NULL);
last column’s value must be specified at the time of insertion of new record.
Later on (lines 889-897), the insert into statements do not do this (only id, emailType and emailSubject are inserted) hence MySQL gives an error and does not insert relevant records into the table.
Definitely a bug. If you cannot replicate this you must have some other error(s) elsewhere, too.
Before marking resolved, however, I still need to know if manual insertion is an OK solution to do?
If it works for you, I’d suggest you go ahead and use it. I’ve flagged this up for a more in-depth investigation but, given our current workload, we have no idea when the new version of eShop will be released yet.
Can I ask what “flavour” of MySQL you are using? And whether you know how strict it is? I’ve come across similar issues in WordPress generally when the site is using Percona’s MySQL.
Thread Starter
slepi
(@slepi)
5.6.12 MySQL Community Server (GPL)
Regardless of the SQL “flavour”, I think this is intended SQL behaviour and the bug is on the eShop side.
I’ve just installed eShop in a fresh 3.6 copy of WordPress on my development server and didn’t have a single problem. I had all 11 email templates with only the first 2 active. You do realise that templates 3 – 11 are supposed to be blank, don’t you?
Thread Starter
slepi
(@slepi)
I had only 2 templates listed… This was the reason I started to investigate in the first place.
Try to execute the following 3 SQL commands in your DB:
create table bug (id int not null, emailContent text not null);
insert into bug (id, emailContent) values (1, 1);
insert into bug (id) values(2);
The last one MUST fail because there is no default value specified for the emailContent column!
I can only guess your database was not empty prior to eShop activation (I noticed that eShop de-activation does not drop tables). Have you tried it with a clean/new DB?
This was a clean WordPress install in a new database.
Thread Starter
slepi
(@slepi)
Well, it makes no sense unless your MySQL behaves differently than mine and silently assigns an empty string to a text column without default value… If so, it’s a YourSQL bug, but I seriously doubt it. Can you please execute the above three commands and report the result?
Mysterious.
I’m sorry but the key point here is that we cannot replicate your issue. And we cannot “fix” what we cannot replicate.
Thread Starter
slepi
(@slepi)
Well, Oracle documentation about the list of columns in the INSERT INTO command:
… If the list does not include all the columns in a table, each missing columns is set to NULL or to a default value specified in the CREATE TABLE statement.
The emailContent is specified to be a NOT NULL column therefore the above rule cannot be applied… Error.
?
Thread Starter
slepi
(@slepi)
Your key point is flawed.
Are you telling me that you cannot replicate the SQL error:
CREATE TABLE bug (id INT NOT NULL, emailContent TEXT NOT NULL);
INSERT INTO bug (id) VALUES(2);
(MySQL Workbench 6.0, build 6.0.6.11184 Community):
Error Code: 1364. Field ’emailContent’ doesn’t have a default value
This is the question!
Anyone else reading this?
The plugin – with all 11 email templates files – installs without any problems for us. We cannot fix what we cannot replicate. Additionally, you’re the only one (in the last 5 years, IIRC) who has this issue out of a potential user base of over 500k. Best guess – this is related to your specific install.
Thread Starter
slepi
(@slepi)
I’m the only one to report it and I did manage to replicate it on another machine… “Crash” testing is good, code inspection is better.
I found something: the CREATE TABLE command in eshop-install.php works for me, too, but is rejected(!) by MySQL when typed-in from the console:
‘CREATE TABLE eshop_emails (id INT NOT NULL AUTO_INCREMENT);’
MySQL:
‘ERROR 1075 (42000): Incorrect table definition; there can be only one auto column and it must be defined as a key’
This tells us that the SQL in php code is not fed directly to the MySQL, but is being processed by “X”… And you and I have active different implementations of this X with my X strictly following the SQL standard (in the case of INSERT INTO at least), and yours not. This is the only explanation.
So, “your” crash testing will never find “my” bug unless strict layer X is active… This is why code inspection is better than crash testing!
Again: your SQL code has syntax errors – it works (for you) only because you have some other piece of non-standard(!) software installed!
you have some other piece of non-standard(!) software installed!
So that would be us and all of eShop’s other 100K+ users*? Hmm… Or could the issue perhaps be at your end since you are the only person to have ever had this problem?
* And that’s a very conservative estimate for a plugin with over half a million downloads.
