Login redirects to unknown page

Maybe check your permalink settings in WordPress? Just go to the main Settings > Permalinks page, and save again (don’t have to make any changes) to make sure the permalink structure is properly saved/refreshed.

Otherwise, the “Login To Signup” link should have a redirect parameter on the end of it to tell WordPress the page to go back to after you login. Hover over the login link on that page and look at your browser’s status bar to make sure that parameter is set and the redirect matches the current page you are on. If your browser doesn’t show the status bar with the link, you may have to use the inspect element feature of your browser on that link to see what the redirect parameter at the end of the URL is. Is the post ID for the page you were on 300? From your URL, it looks like permalinks are set to use post ID with the “p” parameter.

I have tested it here just now with all 3 browsers I have (Firefox, Edge, Chrome) and they all work fine and take me back to the correct page after I login.

Hi – thanks for coming back to me so quickly.

I tried the permalinks but didn’t make any difference… (we’re using website/post-name for into) however I think I’ve spotted ‘something’ – whether it’s helpful or not remains to be seen!!

We’re displaying the volunteer sign-up forms on separate Tabs which have been created using the plugin “Tabs Responsive”. We’ve got 3 separate pages each with a “Tab” group on it. We add the Tabs to a page by using a shortcode that has an ID – in this instance, they are ID 300, 326, and 329. Using your suggestion of looking at the browser for the redirect parameter on each of the pages that has this redirect challenge, it looks like it’s trying to redirect to website.co.uk/?p=300, or p=326 or p=329… which I suspect is too much of a coincidence to not be somehow linked to the ID’s of the Tabs!?

Do you happen to know where the redirect_to is picked up from in the “Login to signup” links? I’m wondering if the “Tabs Responsive’ plugin is somehow inserting something on to the page that’s impacting that?

I’ve done a quick check – the Tabs aren’t in an iFrame or any other such wizardry – simply created as Divs with CSS styling as far as can see.

Have you come across anything similar previously by any chance?

OR… (sorry, epiphany moment… maybe!?) is there a setting I can use to set the redirect for each form by any chance?

Thanks

To display the login links, with the correct redirect parameter, my plugin uses two WordPress function, one as the parameter for the other:
wp_login_url( get_permalink() )

The wp_login_url function returns the URL to the login page (which can be altered by other plugins for custom login pages, etc.). The parameter you pass to the function is the permalink/url of the page you want WordPress to redirect to after logging in. For that, I use the get_permalink WordPress function. If you do not pass any parameters to the get_permalink function, it returns the link to the current post/page.

So, from what you have explained, my best guess is that the Tabs plugin you are using is creating custom posts for each tab, and then embedding those onto the main post/page where you have their shortcode. My shortcode for the signup sheets would be inside the content of that tab, so the get_permalink function is going to get the post link for that specific tab. But, the plugin most likely has it setup so that you can’t display a tab directly as a post/page. So, that’s why it’s not working for you.

I just did a search for the tabs responsive plugin, and saw a quick video of how to use it… only took me a few seconds of watching to see that as soon as they activated the plugin, there was a new custom post type menu for tabs, and when they created a new tab, you can tell that it was definitely setup as a custom post type from the layout.

This is not something I can fix with my plugin. This is an issue with how they are setting up tabs in that tabs responsive plugin. There are better/simpler ways to do tabs with simple jQuery/javascript where all the content is actually already on the page/post itself (not separate posts that are embedded into the main page/post), and just hidden until you click on the associated tab, and then it’s revealed by javascript/jQuery. I’m sure they have their reasons for making it a custom post type, and it’s probably just fine for typical uses, but it can definitely mess up any other plugin where you put a shortcode inside the tab and the plugin needs to get the page/post ID for any reason (such as getting the permalink).

So, you either need to get my shortcode outside of those tabs if you want the login redirect to work properly, OR you need to write some custom code to tap into a filter hook of the WordPress get_permalink function so that you can alter the URL that it returns.

Best/easiest solution would be to just rethink how you want to display the signup sheets, and NOT use that tabs plugin for them. Or, find some more simple Accordion or Tabs plugin for that page that does NOT use custom post types.

Thank you! Really appreciate you doing this investigation!

The custom code is perhaps a little beyond my ability so I think a bit of a redesign might be in order to remove those tabs!

Thanks again for your help and support with this.

Hi – just a quick update – while I look for an alternative to the Tabs I’ve done a very ‘quick and dirty’ fix and hardcoded a simple if (getPermalink() == p=300){ $redirect = "correct url"}. As we only have 3 pages, I’ve done an if then else for each of the 3 pages (a switch statement might have been easier in hindsight).

I’ve applied it into class-pta_sus_public circa line 1060. It works but obviously has no scalability/resilience and potentially gives a support nightmare if we change the tabs anytime soon… and of course the next time we upgrade the plugin it’ll no doubt get overridden, but thought I’d share in case it’s of use to anyone else who falls foul of the same “Tabs Responsive” challenge.

I’m off now to find a suitable Tabs replacement!

• This reply was modified 3 years, 7 months ago by imakers.
• This reply was modified 3 years, 7 months ago by imakers.
• This reply was modified 3 years, 7 months ago by imakers.
• This reply was modified 3 years, 7 months ago by imakers.
• This reply was modified 3 years, 7 months ago by imakers.

Thanks for the update.

Just FYI, the better way to do that without modifying the code in my plugin, would be to use the filter hook WordPress has on the get_permalink function, as I mentioned previously.

You would just put a simple code snippet in your child theme’s functions.php file, and then you won’t lose it when the plugin gets updated, or even if your theme gets updated (always use a child theme for custom code snippets and custom CSS, so your parent theme can be updated).

See the function reference here:
https://developer.www.ads-software.com/reference/functions/get_permalink/
Actually, though, looking through that code, for custom post types, the get_permalink function will call the get_post_permalink function instead, which you can see here:
https://developer.www.ads-software.com/reference/functions/get_post_permalink/
Expand the source code for that second function, and you can see the final filter hook on the very last line where it returns the permalink, and it also passes several other variables to help you figure out if you need to modify the permalink value or simply return the permalink without modification.
If you’re not familiar with the whole action/filter hook system of WordPress, here’s a good starting tutorial I found with a quick search:
https://kinsta.com/blog/wordpress-hooks/

This code is not tested, and you would need to supply the correct $post->ID values for the tabs whose links you want to replace, and fill out the switch statements. But, it should look something like this:

add_filter('post_type_link','ssp_maybe_modify_post_type_link', 10, 4);
function ssp_maybe_modify_post_type_link($post_link, $post, $leavename, $sample) {
    if(in_array($post->ID, array(300,301,302,303))) {
        switch ($post->ID) {
            case 300:
                $post_link = "https://yourdomain/parameter";
                break;
        }
    }
    return $post_link;
}

Wow! This is amazing – thank you very much! Far above and beyond!

I’ll give this a go during today!