502 error on enabling plugin. Disabling removes this issue about seomatic HOT 24 CLOSED

I've never heard this before, no. I have a hard time understanding how it could actually happen as well. I'd need more info/data to look into it.

from seomatic.

So I'm still having a hard time understanding how the FieldType could result in a 502 error. I'm using SEOmatic FieldTypes on a similar dev setup running Nginx without incident.

Have you tried pushing to staging or another environment to see if the issue exists there?

from seomatic.

Hi

I can confirm the same problem happened on the staging server - I am going
to investigate further this morning.

On Thursday, 3 March 2016, khalwat [email protected] wrote:

So I'm still having a hard time understanding how the FieldType could
result in a 502 error. I'm using SEOmatic FieldTypes on a similar dev setup
running Nginx without incident.

Have you tried pushing to staging or another environment to see if the
issue exists there?

—
Reply to this email directly or view it on GitHub
#33 (comment)
.

from seomatic.

OK I completely uninstalled the plugin, thus removing any reference to it in the DB, then re downloaded it and installed a fresh copy. After initialising the plugin again in Craft, and clicking on the Get Started button on the welcome screen, I save the default data then I load my page that has the hook in the head and it breaks with a 502 bad gateway again. Again, disabling fixes this.
Craft.log shows no signs of any errors and nothing new in seomatic.log - perhaps its something with my nginx setup, but the remote site does the same

from seomatic.

If you're able, perhaps I can look into this on the staging server? If you don't mind giving me access, I'd like to see what's going on here. It's all very strange.

from seomatic.

Given the nature of the error, it makes it all the stranger:

http://pcsupport.about.com/od/findbyerrormessage/a/502error.htm

I realize that you've narrowed this down to happening only when SEOmatic is installed, which certainly points to it being the culprit. But I haven't the foggiest how SEOmatic could cause a bad gateway error.

from seomatic.

Can you check your nginx/php-fpm logs? This really seems like a server configuration issue. Maybe see if you have mod_security or Suhosin installed?

something is acting as a proxy here, I think. I highly suspect some kind of server configuration issue.

from seomatic.

Hi

Here is the contents of the nginx log file for the site, on the remote server.

2016/03/03 17:40:26 [error] 19126#0: *6 FastCGI sent in stderr: "PHP message: PHP Deprecated: Automatically populating $HTTP_RAW_POST_DATA is deprecated and will be removed in a future version. To avoid this warning set 'always_populate_raw_post_data' to '-1' in php.ini and use the php://input stream instead. in Unknown on line 0" while reading response header from upstream, client: 151.228.145.38, server: youi.design, request: "POST /index.php?p=admin/actions/tasks/getRunningTaskInfo HTTP/1.1", upstream: "fastcgi://unix:/var/run/php5-fpm.sock:", host: "youi.design", referrer: "https://youi.design/admin/settings"

from seomatic.

I agree, this seems like it is a server issue, even though disabling the plugin stops the error.

from seomatic.

Shall I create a user and ssh key so that you can have a look?

from seomatic.

It seems like it isn't your problem!

from seomatic.

That error message probably isn't relevant. But I think you should have your server guys take a look at the setup. I'm not abdicating all responsibility, but my instinct tells me this is a server misconfiguration issue. It's strange to me that it would happen both on dev and stating, though.

from seomatic.

It is my server setup, I'm running a forge setup on DO. It is strange that it is happening on both, yes.

from seomatic.

Locally it is a laravel homestead vagrant box

from seomatic.

If you set always_populate_raw_post_data to -1 in php.ini does the error go away?

from seomatic.

Unfortunately not.

from seomatic.

Did you restart Nginx and fpm?

 sudo nginx -s reload
 sudo service php-fpm restart

from seomatic.

Yes I did that. Thanks - I am continuing to try to debug this

from seomatic.

Let's talk on Slack a bit.

from seomatic.

This ended up being due to {title} and similar parsed fields used in the various fields in SEOmatic... which used to work, but now apparently result in an infinite loop that ultimately crashes the php thread.

This is fixed in develop and I'll roll it into a release soon.

https://github.com/nystudio107/seomatic/tree/develop

from seomatic.

Thanks Andrew.

On 4 March 2016 at 01:15, khalwat [email protected] wrote:

Closed #33 #33.

—
Reply to this email directly or view it on GitHub
#33 (comment).

from seomatic.

I've been getting a similar problem with the plugin. On my deployed server it shows 502 on the front-end but the back-end still works. When I disable our friend SEOmatic the error goes away.

Heres the error in the nginx logs:

2021/02/15 15:24:42 [error] 799#799: *105 upstream sent too big header while reading response header from upstream, client: 99.46.148.171, server: my.domain.com, request: "GET / HTTP/2.0", upstream: "fastcgi://unix:/var/run/php/php7.4-fpm.sock:", host: "my.domain.com"

from seomatic.

@clarknelson this is the old Craft 2 version of the plugin, which is deprecated now

from seomatic.

oh I didn't notice, I hope you don't mind if I open a new issue in the Craft 3 plugin

from seomatic.