My configuration on a MacBook Pro :
MacOS 12.7.1
DevKinsta 2.11.0
PHP 8.1
WordPress 6.4.1
Docker Desktop 4.26.0
During the installation of a saved WordPress site, I get the error “Something bad happened” at the MySQL step : hereafter is the devkinsta_nginx container log that I get from that tentative local DevKinsta installation, retrieving an existing WordPress site : would you give me any hint to solve this issue ?
Thank you in advance,
2023-12-07 11:27:37 /docker-entrypoint.sh: /docker-entrypoint.d/ is not empty, will attempt to perform configuration
2023-12-07 11:27:37 /docker-entrypoint.sh: Looking for shell scripts in /docker-entrypoint.d/
2023-12-07 11:27:37 /docker-entrypoint.sh: Launching /docker-entrypoint.d/10-listen-on-ipv6-by-default.sh
2023-12-07 11:27:37 10-listen-on-ipv6-by-default.sh: info: /etc/nginx/conf.d/default.conf is not a file or does not exist
2023-12-07 11:27:37 /docker-entrypoint.sh: Launching /docker-entrypoint.d/20-envsubst-on-templates.sh
2023-12-07 11:27:37 /docker-entrypoint.sh: Launching /docker-entrypoint.d/30-tune-worker-processes.sh
2023-12-07 11:27:37 /docker-entrypoint.sh: Configuration complete; ready for start up
2023-12-07 11:27:37 2023/12/07 10:27:37 [warn] 1#1: the “http2_max_field_size” directive is obsolete, use the “large_client_header_buffers” directive instead in /etc/nginx/nginx.conf:16
2023-12-07 11:27:37 nginx: [warn] the “http2_max_field_size” directive is obsolete, use the “large_client_header_buffers” directive instead in /etc/nginx/nginx.conf:16
2023-12-07 11:27:37 2023/12/07 10:27:37 [warn] 1#1: the “http2_max_header_size” directive is obsolete, use the “large_client_header_buffers” directive instead in /etc/nginx/nginx.conf:17
2023-12-07 11:27:37 nginx: [warn] the “http2_max_header_size” directive is obsolete, use the “large_client_header_buffers” directive instead in /etc/nginx/nginx.conf:17
2023-12-07 11:30:39 2023/12/07 10:30:39 [warn] 1#1: the “http2_max_field_size” directive is obsolete, use the “large_client_header_buffers” directive instead in /etc/nginx/nginx.conf:16
2023-12-07 11:30:39 2023/12/07 10:30:39 [warn] 1#1: the “http2_max_header_size” directive is obsolete, use the “large_client_header_buffers” directive instead in /etc/nginx/nginx.conf:17
2023-12-07 11:31:40 2023/12/07 10:31:40 [warn] 1#1: the “http2_max_field_size” directive is obsolete, use the “large_client_header_buffers” directive instead in /etc/nginx/nginx.conf:16
2023-12-07 11:31:40 2023/12/07 10:31:40 [warn] 1#1: the “http2_max_header_size” directive is obsolete, use the “large_client_header_buffers” directive instead in /etc/nginx/nginx.conf:17
To clarify, did you get that error “Something bad happened” at the MySQL step, when you tried to import your WordPress site from your MyKinsta account? cause I’m not quite sure understand when you said “during the installation of a saved WordPress site” (if you can please elaborate and clarify that? )
Since it’s been more than a week ago, could you please give it another try now ? and if you’re still experiencing the same error message, please kindly provide us with the following:
The screenshot showing that “Something bad happened” error in your DevKinsta
As I am using a local installation of my site for testing, so far with MAMP http://localhost:8888/wordpress/wp-admin/, I tried to perform a similar set-up with DevKinsta, and got this behaviour :
Thank you for sharing those screenshots and the main log. After reviewing the main log data I am seeing an error indicating that the wp-config.php file itself cannot be found during the site creation. This type of error indicates that the backup archive is either missing the wp-config.php file entirely, or the file is located in an incorrect directory. Below is a snippet from the log you shared showing this error:
[2023-12-16 00:47:11.758] [error] Error - DK0081: WP_PARSE_CONFIG: wp-config.php not found
I see from your screenshot however that the extracted archive appears to contain the file in the public directory.
Something that can be tried is to move the files/folders from within the public directory up into the PourKinsta directory itself that currently contains the SQL file. After moving the files/folders up into this directory, you may archive the folder yourself into a ZIP archive. You can then use this archive instead to attempt to create the site again.
You may find instructions on how to create a ZIP archive on your Mac at the link below:
Please do let us know if this helps resolve the issue, or if you continue to experience any difficulty with creating the site. We look forward to working with you to find a solution!
attaching the most recent main.log file of DevKinsta main.log (112.7 KB)
After a quick review of this log file, I thought that maybe I should avoid creating the DROP option when exporting the wordpress database from the existing WP site ?
Thank you for your reply, and providing the updated screenshots and main log. It does appear the command run to DROP the database occurs after the issue locating the wp-config.php file. So, I am unsure if that is contributing to this issue at all.
I am seeing some errors indicating there might be a problem communicating with the Docker service. Just to confirm, have you tried fully quitting both DevKinsta, and Docker desktop and then relaunching both? Also, just to confirm does the Docker engine state it is running from within the Docker desktop application?
We will continue to investigate into this issue internally and will update this thread once we have more information to share.
Thank you for sharing that updated screenshot and log. We are investigating this further internally and will update this thread once we have more details to share.
To get started, I suggest extracting again the .zip file in your local computer. Make sure that the file structure contains the “/public” folder that stores the WP files and the wordpress.sql file is at the root folder. As shown below:
Once done, you should run the command line (via “Terminal”) to set files/folders permission recursively, inside that extracted folder with something like:
find . -type d -exec chmod 755 {} ; && find . -type f -exec chmod 644 {} ;
This is necessary just in case if the wp-config.php has permission issue “after it’s extracted” and that DevKinsta couldn’t “read/see” it properly. You should also set the ownership of your files/folders with your correct local user account.
Once the permission issue has been fixed, create a new zip file again from it, and see if you can import it to your DevKinsta.
If the above recommendation doesn’t work. You may want to consider trying to import the backup manually as described in our documentation here:
We are not able to accept the files of your site, unfortunately. Also this is a local issue on your end so it is likely that we wouldn’t be able to replicate the exact same issue.
What I would advise is to import manually.
You can create a new DevKinsta Site, open a Site Path of the new empty DevKinsta site, delete the wp-content folder, and move the one from the backup you have to the DevKinsta new site.
Then, you would proceed and drop all tables from the database and manually import SQL file from your backup.
Thank you for your reply. I’m sorry to see that you are also having difficulty with creating a new empty site. I would like to review the current main.log file to see what error was logged. Could you please send me a direct message with the updated main.log file?
Also, to confirm is your DevKinsta and Docker Desktop installations up to date?
Thanks for your reply, and for sharing the updated main.log file! We have reviewed the log file and see it looks like there is a permission denied error occurring when attempting to make a connection to the database as root. This indicates something may have caused the root password used by DevKinsta to become out of sync with the database container.
The first thing we can try is to remove the DevKinsta related Docker containers, and recreate them. To do this you may first exit DevKinsta completely. This can be done by existing the DevKinsta window, and then locating the DevKinsta icon in the upper status bar, right click the icon, and then choose to quit DevKinsta.
Once DevKinsta has been completely exited this will shutdown the Docker containers. Next, open the Docker Desktop interface and select all of the DevKinsta containers and choose to delete them. This won’t affect the site files that exist on your system.
After the containers have been deleted you may relaunch DevKinsta. This will recreate the containers, and hopefully sync up the root database password.
Please let us know if performing these steps help resolve the issue, or if any problems persist.
After having deleted the DevKinsta related Docker containers, then relaunched DevKinsta, Il still get the same problem, as you can see in the attached main.log
Redacted main.log (Kinsta staff edit)
Thank you for sharing the updated main.log file, @jazzyguy! We are continuing to investigate into this issue and will provide an update as soon as we have more details to share.
We appreciate your patience while we further look into this.
Thank you for your patience in regards to this!
Could you please try these steps and let us know if it resolves the issue for you?
Edit config.json, and remove the line with the DB password - look for something like this:
“services”: {
“host”: “127.0.0.1”,
“mariadb”: {
“name”: “devkinsta_db”,
“user”: “root”,
“password”: “**********”, ← REMOVE THIS ENTIRE LINE
“containerId”: “devkinsta_db”,
“port”: “15100”
},
Stop DevKinsta if it is/was running.
Remove all the DevKinsta containers using Docker Desktop or CLI.
and welcome to Kinsta Community!
)
