1

Hi I’m new to Kinsta & DevKinsta and i’m currently facing an issue with using the software.

When I pull a site from our Kinsta service, and try to launch it within DevKinsta, I am greeted with the error:

This page isn’t working

sitename.local is currently unable to handle this request.

HTTP ERROR 500

I’ve looked through the forums, and the only similar issue I could find is from 2021, but related to missed .PHP files, which doesn’t apply here, as the PHP files are present.

I’ve looked at the log files, but nothing immediately jumps out at at me, so if someone could please take a look, that’d be great!

Thanks

2

Hello there! I hope you are well! This is Jovana from the Kinsta Team. :blush:

Can you please provide us with the details from the main.log file or with the actual file, so we can investigate further?
You can check how to view it here

Please let me know if you have any questions.

Thank you!
Jovana, Kinsta Team

3

Sure, I’ve attached the main.log file for you.

4

Hey @Joe,
can you please also send the site error logs? Those are stored inside the DevKinsta/logs folder

6

Please see attached.

promworld_error.log (538 Bytes)

8

Thank you for sharing the file Joe.
Can you please open Docker, move into the Containers tab, select devkinsta_nginx, then click on the Terminal tab, execute the following command and provide us with the output?

nginx -t

Regards,
Alessandro

9

Hi Alessandro,

Sure, the output is as follows

/ # nginx -t
2024/04/19 11:35:51 [warn] 169#169: the "http2_max_field_size" directive is obsolete, use the "large_client_header_buffers" directive instead in /etc/nginx/nginx.conf:16
nginx: [warn] the "http2_max_field_size" directive is obsolete, use the "large_client_header_buffers" directive instead in /etc/nginx/nginx.conf:16
2024/04/19 11:35:51 [warn] 169#169: the "http2_max_header_size" directive is obsolete, use the "large_client_header_buffers" directive instead in /etc/nginx/nginx.conf:17
nginx: [warn] the "http2_max_header_size" directive is obsolete, use the "large_client_header_buffers" directive instead in /etc/nginx/nginx.conf:17
2024/04/19 11:35:51 [warn] 169#169: the "listen ... http2" directive is deprecated, use the "http2" directive instead in /etc/nginx/sites/promworld.conf:7
nginx: [warn] the "listen ... http2" directive is deprecated, use the "http2" directive instead in /etc/nginx/sites/promworld.conf:7
2024/04/19 11:35:51 [warn] 169#169: the "listen ... http2" directive is deprecated, use the "http2" directive instead in /etc/nginx/sites/promworld.conf:8
nginx: [warn] the "listen ... http2" directive is deprecated, use the "http2" directive instead in /etc/nginx/sites/promworld.conf:8
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
/ #

Hopefully that is correct and what you need,
Thanks

11

Hi @Joe!

Thanks for your reply! It does appear that the NGINX configuration is checking out ok. We have reviewed the error log you shared further, and we do see it looks like a PHP fatal error is indeed occurring. It appears that PHP is having difficulty with opening the malcare-waf.php at the path specified in the error log.

I would recommend checking the wp-config.php file and see if this file is being referenced anywhere to be included. If it is, please try adding // in front of the line to comment it out. Then, try visiting the local site again to see if it can load.

Please let us know if this has helped or if you need any further assistance. We’re standing by and happy to help!

Best regards

12

Hi, thanks for taking the time to look at the log files for me.

I’d noted the fatal error in the logs myself and spent some time looking into it. The Malcare plugin was a plugin brought over from our existing hosting, however, i have since removed it from the Kinsta install completely. In any case, I’ve checked the wp-config file on the devKinsta local site, and there’s no mention of malcare in it, and further to that, the site works perfectly fine up on Kinsta itself, so the issue seems specific to the devKinsta install.

Joe

13

Hey @Joe :wave:
Can you please check if in your .user.ini file you have set an auto_prepend_file value with the path of that no longer existing file?

Regards,
Alessandro

15

Thanks, yep there was an auto prepend line in the user.ini file, which once removed, allows the local site to work.

I’ve done some Googling, and it appears that other site cloning tools deal with this kind of issue by renaming the user.ini file to user.ini.bak during the cloning process, perhaps this is something that could be implemented on DevKinsta too?

Thanks
Joe

16

Hello @Joe

Yes, we can submit a feature request for our devs to review and consider, however, as feature requests go, we can’t promise if and when that will be implemented.

But I’ll submit it nonetheless.

Thanks for writing back!

Kind regards

17

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.