I've been trying to use the [wpv-login-form] shortcode and it simply redirects to a 404 error. It doesn't matter what I put in the redirect parameters, it always results in a 404. I've determined this is due to my using the SiteGround Optimiser security plugin to change to default login URL away from /wp-login.php to something else, let's say it's /example. Disabling the security plugin resolves this issue, but I need a work around as changing the default login URL has become a basic WordPress security measure these days.
I've had a look at the shortcode's code located in toolset-blocks/embedded/inc/wpv-shortcodes.php and I've tried changing the wp-login.php call on line 751:
And this redirects the successful and failed login attempts to the default wp-login.php page, with the login token information in the URL, but it doesn't progress past that point or successfully do anything.
I'm trying to set up something similar on my local test site so that I can work through what's happening in the scenario you describe.
But I'm not getting on very well with the Siteground security plugin, to be honest.
If I set a custom login URL in its settings (I use "hidden"), then if I visit siteurl.com/hidden I do indeed see a login page, but I note that the URL has changed to siteurl.com/wp-login.php?sgs-token=hidden, so it still seems to be using the normal WordPress wp-login.php template.
Indeed, if I just enter siteurl.com/wp-login.php I'm presented with the normal login page. The plugin doesn't appear to be "protecting" the standard login URL in anyway, it just redirects a custom login URL to the standard URL and adds a URL parameter.
This, by the way, is without Toolset plugins active, this is just me familiarising myself with what happens with the security plugin.
Honestly, I've never looked into how it works if I'm being honest. 95% of my sites are hosted on SiteGround, so it's a natural choice and generally does a good job with the other functions it provides.
This particular site isn't on SiteGrounds servers, but I just used a standard plugin setup as a base to start with and encountered this. While I could easily use a different plugin for this functionality on this site, this could be a big problem on many of my other ones in the future, so if there's anything we could do then that would be great.
I've just done some testing and you're right, if you use the custom login URL it does simply redirect to the usual wp-login.php and add the sgs-token URL parameter. Also if you try going to wp-login.php it will load, but if you try logging in then you get this error message:
<quoteblock>ERROR: You are trying to login with an administrative account. Please, use the Custom Login URL instead.</quoteblock>
So it is blocking things to a degree, but I agree that it should be locking out the wp-login.php altogether. It's an odd functionality choice.
All of the plugins other features are very useful if you host with SiteGround and I know it has a fairly large install base, so I feel like this does warrant digging into a little. If you have any questions I can get their support on a chat later on and pose them to them directly and see if we can get any answers from SiteGround if that will help at all.
I tried some more with the plugin, but updating the settings was giving me invalid format errors when trying to enter simple alternate slugs for the login page, and there is no documentation about what is valid and what is not.
Thanks Nigel. I've been talking to SiteGround support and the issue is currently with their developers. So if we can leave the ticket open for a little while I'll update and close it when I get a resolution from them one way or the other.
No reply from SiteGround yet, but I've just had a thought and it's worked. This isn't a solution at the moment as it requires changing the shortcode code, but it's further information.
As we've identified, when the SG plugin uses the login.php, it adds the sgs-token URL parameter. So if you change the line I was tinkering with before, line 751 in the wpv-shortcodes.php file at the time of writing, and add your full URL parameter, then it just works.
Where example is whatever your alternative login URL is, then it just works perfectly. Is there anyway to hook into this and override it with a filter?
Again, I'll post any follow up from SiteGround and share this information with them.
I've had the cleanup bot chasing me about this thread, but I just want an answer to that last question please:
Is there anyway to hook into the $action_url variable setup and override it with a filter? I don't want to change the base plugin code obviously, and now I've solved why it's doing it, I'd like to know if there's any viable workaround before changing my setup to another plugin.
If you want to persist with the SG solution, the function site_url calls the function get_site_url, and if you check the documentation for that, you will see that the source code which assembles the URL passes the result through a filter ('site_url') before returning the result, so that would be a means of intervening without modifying the Toolset plugin code.
Apologies if I wasn't clear, but I meant hook into the Toolset function that is generating the variable, not the way the site URL is set through the site_url filter as I can't see a way of hooking into this specific instance given that it's inside the Toolset function.
If not then no problem, I can use an alternative solution, but a hook to the function code so that this could be modified would be great, so does this exist?
The topic ‘[Closed] [wpv-login-form] Not Compatible with Custom Login URL's – 404 Error’ is closed to new replies.
