Unsure if it'd be better off as a part of safety net, but it feels like the WP_HTTP_BLOCK_EXTERNAL constant may be beneficial as a blanket block for production code that reaches out to third-party servers (like sendgrid or the like) to negate some issues about api calls from staging sites. It's non-destructive, so it would be easier to add in when cloning through CLI here and remove when desired (or add allowlisted hosts to the related WP_ACCESSIBLE_HOSTS constant).
May be worth evaluating https://wordpress.org/plugins/http-requests-manager/ / https://veppa.com/http-requests-manager/ as a plugin to auto install when spinning up staging clones -- if more selective blocking is desired or worth enabling on production sites to isolate what external services it's dependent on.
Anyway, just stumbled on it and figured it may be of interest to y'all. cc: @ahegyes
Unsure if it'd be better off as a part of safety net, but it feels like the
WP_HTTP_BLOCK_EXTERNALconstant may be beneficial as a blanket block for production code that reaches out to third-party servers (like sendgrid or the like) to negate some issues about api calls from staging sites. It's non-destructive, so it would be easier to add in when cloning through CLI here and remove when desired (or add allowlisted hosts to the relatedWP_ACCESSIBLE_HOSTSconstant).May be worth evaluating https://wordpress.org/plugins/http-requests-manager/ / https://veppa.com/http-requests-manager/ as a plugin to auto install when spinning up staging clones -- if more selective blocking is desired or worth enabling on production sites to isolate what external services it's dependent on.
Anyway, just stumbled on it and figured it may be of interest to y'all. cc: @ahegyes