joshjcobb
Forum Replies Created
-
Hi there, we are experiencing a similar issue on a multi-site network (subfolder setup i.e. website.com.au/site1, website.com.au/site2).
When trying to access wp-admin of any website (after logging into the main network site), we are redirected to website.com.au/sitename/404.
After reverting your plugin back to 2.4.2, from 2.5.0, the issue is resolved. It appears 2.5.0 is causing this issue.
Forum: Plugins
In reply to: [WPS Hide Login] WP Loopbacks not working with WPS Hide Login enabledThank you. That’s good news you were able to replicate the issue and we look forward to the update.
What led us to this issue was our usage of WP Offload Media. When manually offloading media, the processes were stalling. So we started testing loopback issues.
Not only did WPS Hide Login prevent the loopback test from showing, it also prevented manual processes for WP Offload from completing succesfully. When disabling WPS Hide Login, WP Offload Media manual processes for offloading media worked fine. Not sure if anyone has reported this to you, but there does appear to be a conflict.
Forum: Plugins
In reply to: [WPS Hide Login] WP Loopbacks not working with WPS Hide Login enabledWhen WPS Hide Login is enabled, the Loopback test doesn’t show up at all in the Site Health test screen. So it’s like the test can’t run a when the plug-in is enabled. When the plug-in is disabled, the test runs fine and displays “Your site can perform loopback requests”.
So it’s like the test won’t run at all when WPS Hide Login is enabled.
When WPS Hide Login is enabled, background processes are failing on other plugins. When disabled, those same processes work as expected.
We’ve tested on two different servers, Apache vs Litespeed, php7.4 vs php8.*… same result.
Forum: Plugins
In reply to: [WPS Hide Login] WP Loopbacks not working with WPS Hide Login enabledHi, we don’t have any plugins managing our requests. And /wp-admin*, /wp-login.php* and /secretslug* are set to “bypass cache”.
No it doesn’t 🙁
The image URL’s are changed when the images are uploaded to the Media Library (to something like https://d36jvkr575z5d6.cloudfront.net/wp-content/uploads/2017/07/13085900/image8.jpg).
The changed URL has no impact on front-end display or when we use an RSS campaign in MailChimp.
But Mailpoet tries to link to the old URL (https://examplewebsite.com.au/wp-content/uploads/2017/07/13085900/image8.jpg) which no longer exists when WP S3 Offload moved the image to AWS S3.
We’re testing Mailpoet on this particular site with the view of rolling out across hundreds of websites. Hoping you guys can help solve this challenge so we don’t have to consider other software.
[ No bumping please. ]
- This reply was modified 8 years, 6 months ago by joshjcobb.
