Bad gateway (Error code 502)

Hi, First thank you for this amazing plugin. On a recent update I have started noticing that in 2 of my websites I get an “Bad gateway (Error code 502)” when trying to open the Media Library page (Media > Library) (/wp-admin/upload.php). When I deactivate the “Phoenix Media Rename” plugin, the Media Library works normally as expected. I tried to check the logs (have both define( 'WP_DEBUG', true ); and define( 'WP_DEBUG_LOG', true ); activated in my wp-config.php file) but I don’t see anything that could help me investigating this issue. Kind regards Hi @lostguybrazil , since version 3.12 Phoenix Media Rename uses cookie, maybe this can create some compatibility issue with other plugins, can you tell me which plugins you are using, so that I can try to replicate your configuration on my development server? Thank you for reporting C. Thank you for your quick response! I currently have 4 websites running the latest version of “Phoenix Media Rename” (v3.12.6). On 2 of these websites, I am encountering the issue described in the original post (OP). Here are the plugins installed on one of the problematic websites: AAA Option Optimizer – 1.2.1 Admin and Site Enhancements (ASE) – 7.5.1 Advanced Database Cleaner PRO – 3.2.10 Brazilian Market on WooCommerce – 4.0.2 Cloudflare – 4.12.8 Complianz | GDPR/CCPA Cookie Consent – 7.1.4 Connect Polylang for Elementor – 2.4.5 CTX Feed – 6.5.31 Easy Auto SKU Generator for WooCommerce – 1.2.0 Edit Custom Fields – 0.1.10 Elementor – 3.25.4 Embed Google Fonts – 3.1.1 Google Analytics for WooCommerce – 2.1.7 Matomo Analytics – Ethical Stats. Powerful Insights. – 5.1.5 Melhor Envio – 2.15.9 Mercado Pago – 7.8.2 PhastPress – 3.6 Polylang – 3.6.5 Polylang for WooCommerce – 2.1 Polylang Slug – 0.2.3 Query Monitor – 3.16.4 Redis Object Cache – 2.5.4 Secure Custom Fields – 6.3.10.2 Site Kit by Google – 1.139.0 Smash Balloon Instagram Feed – 6.6.0 WC Variations Radio Buttons – 2.1.0 WooCommerce – 9.3.3 Wordfence Security – 8.0.0 WP-Optimize – Clean, Compress, Cache – 3.7.0 WPCode Lite – 2.2.3 WP Consent API – 1.0.7 WP Console – 2.4.1 WP Crontrol – 1.17.0 XML Sitemap Generator for Google – 4.1.21 And here are the plugins found on one of the problematic websites that are not present on the non-problematic website: Brazilian Market on WooCommerce – 4.0.2 CTX Feed – 6.5.31 Easy Auto SKU Generator for WooCommerce – 1.2.0 Edit Custom Fields – 0.1.10 Google Analytics for WooCommerce – 2.1.7 Melhor Envio – 2.15.9 Mercado Pago – 7.8.2 Polylang for WooCommerce – 2.1 Secure Custom Fields – 6.3.10.2 Smash Balloon Instagram Feed – 6.6.0 WC Variations Radio Buttons – 2.1.0 WooCommerce – 9.3.3 I have already tried deactivating these plugins, but the issue persists: CTX Feed – 6.5.31 Easy Auto SKU Generator for WooCommerce – 1.2.0 Edit Custom Fields – 0.1.10 Google Analytics for WooCommerce – 2.1.7 Polylang for WooCommerce – 2.1 Secure Custom Fields – 6.3.10.2 Smash Balloon Instagram Feed – 6.6.0 WC Variations Radio Buttons – 2.1.0 Additionally, I have attempted the following steps: – Clearing the browser cache. – Reducing the “Number of items per page” settings in the Media Library to 10 before enabling the “Phoenix Media Rename” plugin. It may be worth noting that both websites experiencing the issue have over 100 media files, while the websites where the plugin works as expected have a low number of media uploads. This could be only a coincidence. Thanks again! Hi @lostguybrazil , I’ll try to replicate your configuration on my server, I hope to find the issue soon. I tested Phoenix Media Rename on a site with more than 4000 images and 100 file per page in media library and everything works, so the number of images shouldn’t cause any problems. Thank you for your help addressing this issue C. I’m trying the plugins you listed, but at the moment everything is working, can you check the server log and tell me which line of Phoenix Media Rename is reported there as the one that caused the crash? You can find the error log in the administration panel of your hosting. C. This reply was modified 1 year, 6 months ago by crossi72 . This also happened to my site right after upgrading a few plugins a few hours ago. Everything works fine after deactivating this plugin. It doesn’t occur on the staging site where I haven’t made the upgrades. No error log is recorded on the hosting side. This reply was modified 1 year, 6 months ago by wonderwooman . Hi @crossi72 , thank you for checking the plugins and replicating my setup. For the WordPress Debug file, I don’t see anything related to this issue. For the server log file, I have noticed that this entry is added to the log every time I try to open the the Media Library page (Media > Library) (/wp-admin/upload.php) (the number *314044 changes slightly on every entry): “nginx error: 1588306#0: *314044 upstream sent too big header while reading response header from upstream”. Maybe it helps! Kind regards Hi @lostguybrazil , that message is quite useful: the new version on Phoenix Media Rename uses cookies instead of database to store temporary data and I think that some hosting doesn’t supports all that data. I’ll dig into this and let you know as soon as I will find a fix. Thank you for you help C. Hi @crossi72 , Thank you for the quick response! I wanted to provide a bit more information: three of the websites mentioned are hosted on a VPS Debian server. Out of these, two websites are experiencing the issue, while one is not. This leads me to believe that the problem might not be related to hosting limitations, as one of the sites is functioning correctly. Thanks again for your help! Hi @lostguybrazil , I’m working on a new version that doesn’t use cookie, if I have the error correctly this would resolve your issue. I hope to complete development and tests in a couple of days, I will let you know as soon as I will release it. C. Hi @crossi72 , many thanks for the update and for the great support! Kind regards Same problem here, after the latest update /wp-admin/upload.php stopped loading. Hi all, I just released version 3.12.7 that optimizes cookies management, can you tell me if the problem persists on your servers? If the problem persists I will revert to database use, it is less efficient, but it has never created problems. Thank you all for your patience! C. A bit slow, but it works now. Hi @sosfactory , thank you for your feedback, I’m still working on a version that doesn’t use cookies, but it is harder than I was thinking -.-‘ I hope to release soon the version I’m working on (based only on javascript). C. Thanks for the quick solution! Yes, for me it’s also working now. Great to hear that it’s working for you now! If you need any further assistance, feel free to reach out. C.