I am running both Local (old one) and Local Lightning.
Local is set to Apache and PHP 7.3
Local Lightning is set at the default of Nginx and PHP 7.3
So, this is weird and sort of at whits end. I was using Local Lightning and was having problems with a date outputting on the front end. I felt for sure it was a theme issue and have spent a long time debugging. The author swears it outputs.
I was looking in Adminer for Local Lightning and saw these weird errors of “Incorrect DATETIME value:”.
I was like strange. So, I switched over to OLD Local with the same theme and data and sure enough the date prints out on the frontend. Same clean install of the theme on both installs. The date prints out on the live production website as well.
However, it doesn’t print for my Local Lightning install. Can anybody shed any lights on this?
@clay This is sort of driving me nuts. As I mentioned, I figured this was definitely theme related. However, this works on production and the old Flywheel, but not on Lightning. And they all basically share the same environment configuration.
Do you know of anything Database wise that might handle Datetime different between the Old Local and Local Lightning?
@clay I just created a completely new and fresh install with both 5.7 and 8.0 on Lightning. It doesn’t work at all.
On old Flywheel it works on 5.6 and on production, which is 5.7 it works.
Normally, I would think it is a theme issue, but the only place I can reproduce the problem is Local Lightning. So, I am just wondering (taking a flyer) if there is anything different with Lightning’s database that might cause this anomaly?
Interesting. It could be caused by a difference in the MySQL mode or MySQL config in general.
Is there any way you can provide a screenshot of the errors you’re seeing?
Additionally, is there any possibility you can provide an export of the Local site so we can dig in on our end? If so, feel free to e-mail me the export at clay@getflywheel.com.
Also, If I try to start a new project with the prefered PHP & Nginx settings BUT with MySQL 5.41 > Local goes into an infinite loop and never finishes the process.
If I import an existing site archive (which is what I did in my previous message) and select MySQL 5.41 as the db engine during the setup, the process goes fine.
I imported the sites into Local as well as looked an existing site and I do see the errors you mention within Adminer. From doing a little googling, it looks like that error is just MySQL complaining about that datatype formatting that the query is using:
If I were to guess, this has to do with some sort of changes to some sort of MySQL setting. This SO answer might point you to more info.
Since I’m seeing that adminer error on other, plain WordPress sites in Local, I don’t think that would be the issue, though it is possible that this theme that you are using isn’t compatible with these newer versions of MySQL.
Have you tried using that theme with a clean install of WordPress to verify that the theme works with newer versions of PHP and MySQL?
Thanks a lot for taking the time to answer @ben.turner
Regarding my 2 site archives, these are VERY standard default setups created by local on which I did absolutely nothing (no fancy settings, no custom themes). 100% default WordPress…
The one with mySQL 8.0.16 does have the issue, not the one with 5.7.28. This is the only difference between the 2 sites.
Notice how the site that is throwing errors is using the utf8_general_ci character set vs
the site that doesn’t throw errors, which uses latin1_swedish_ci.
Going back to the original site that you were having issues with – you mentioned that the theme wasn’t outputting dates correctly. In your troubleshooting, did you copy the theme to a new, plain site in Local and see if the dates weren’t being output within that plain site?
I’m not the original author of this thread so I can’t answer your question.
I don’t have access to my previous site files (the one I was testing when sending my original messages) I just want to describe step by step what I did before sending you the 2 site archives today.
start local
create a new site with the preferred settings > Nginx / PHP 7.3.5 / MySQL 8.0.16
test a quick request with admineer > I get the error/result shown in my video
export the site to > localapptest.zip
And …
start local
create a new site with the custom settings > Nginx / PHP 7.3.5 / MySQL 5.7.28
test a quick request with admineer > I get the right result.
export the site to > localapptest1.zip
That’s it, nothing else No fancy mySQL tweaks and so on. Not even a login on the WP admin.
I see, thanks for clarifying @earnoud and sorry to mix you and @JP2017 up!.
So just to verify that I’m understanding correctly, is the only issue that there are errors within Adminer – or are you seeing an issue related to time in some other place?
If it’s just within Adminer, then I think that might boil down to how Adminer is constructing its search query. If you click on the link next to the error, you can see the actual SQL that Adminer ran, and it’s not accounting for the fact that there are columns with a datetime datatype:
I would like to make it clear that it is more an aesthetic concern than a functional one as far as I am concerned today.
As this display is not “normal” or “expected”, it seemed important to me to point it out so that it can be taken into account in the context of a future fix.
