Uncanny Owl

Hi @memeworx ,

It sounds like you’re using both the login redirect and not enrolled redirect modules. The Not Enrolled Redirect settings for courses would apply when users aren’t enrolled in a course and try to access that course, but wouldn’t affect login behaviour. As for the login redirect, there is no way to distinguish between LearnDash students and other users. If you want to separate behaviour by role, there are other plugins that can do this, but our module only has a generic login redirect. And in some cases, any Woo redirect behaviours might be overriding ours, in which case a code snippet to change behaviour.

Hi @devdigith ,

I’m afraid that recent releases don’t officially support a version of LearnDash that old. Some modules may work, but if you do run into any issues we unfortunately wouldn’t be able to support them.

If you do purchase and need an older version of our plugin that is compatible with what you’re using, reach out via our Help Desk and we can provide older copies.

Thanks

Hi @asiegle , I wanted to confirm that we have replied to the ticket you raised via our Help Desk. Since it’s being handled there, and since this relates to our Pro version, we’ll go ahead and close this duplicate.

Thanks

Sorry @cte2087 , just because LearnDash has its own login system, are you definitely using ours? Can you confirm the exact shortcode you mention you’re using?

Since you mention using an SMTP plugin with Mailgun, is it showing that the Toolkit generated 4 emails?

Do you have a Staging environment where you could temporarily deactivate everything, even LearnDash, so only the Toolkit plugin is active? And then could you retest to see if a single email is sent? If we can confirm that it’s working that way, perhaps you could reactivate plugins gradually to try to assess when more emails start going out. And, like in the other ticket, it would help to see the system report so we can see if something else might be involved.

Thanks

Hi @cte2087 ,

Were you able to try disabling modules within the Toolkit plugin alone to try to trace it to a single module? That would help us isolate what might be happening. So to confirm, disable Toolkit Pro, disable all modules, check again. If that works, enable a module you were using, test again, then repeat to see where it fails. It would also still help a lot to see the system report from LearnDash LMS > Settings > Support. It would help to see what other plugins might be involved and their versions.

Since you are using Pro, you can also send that to our Help Desk via your account on our site.

Sorry, what are you using to send out new user emails? The Toolkit doesn’t support this type of functionality natively, as it’s not involved with user creation.

You mention using both our free version and Pro, and to confirm, your test case then was that there was no change when deactivating Pro, but there was when deactivating the free Toolkit plugin? If so, were you able to trace it to a specific module, like which one being active affected the URLs? This would help us trace it, but it would help to understand what’s creating the user and what’s sending these emails out. A system report from LearnDash LMS > Settings > Support would also help us see what else is on the site that might be involved. We haven’t had any similar reports, so it sounds like it’s tied to something else that’s in use in the environment.

Thanks

Hi @cte2087 ,

The Toolkit itself would not fire more than one email. To confirm, when you mention “LearnDash password reset function”, you do mean our Front End Login module specifically, so you are using some type of [uo_login] shortcode? Is the page excluded from all types of caching?

For the emails themselves, are you using your host to send them or a transactional email service? You mention that everything is deactivated, but does that include LearnDash then, any plugin to support email delivery and a default theme?

I wonder too if you use an email logging plugin to track what’s handed off to WordPress for email delivery. It would help to confirm that all emails go out from the same time from our plugin.

Only 1 of 4 working makes sense, since later requests would invalidate previous links.

If it’s not our module initiate the password reset email, can you confirm exactly what is doing it and if you have our Front End Login module enabled?

Thanks

Hi Parm, it seems as though the WPS Hide Login plugin simply moves the login form /wp-login.php to a URL of your choosing. You still need to get users there somehow. Unfortunately, our login/logout links module isn’t compatible with WPS Hide Login because it doesn’t know what page you’ve set as your login page in the WPS Hide Login settings. However, even if it could detect the URL, it would simply output a direct link to the page, which would be the same as using a static link.

Apologies for the very long delay here.

Our dev team says you should remove the custom text added to the Resume button settings page and then add the following filter to the functions.php file of your child theme:

function custom_learndash_resume_link_text( $resume_link_text ) {
    // Check the current language
    $current_language = defined('ICL_LANGUAGE_CODE') ? ICL_LANGUAGE_CODE : 'en';
    // Set text based on the language
    if ( $current_language == 'es' ) {
        return 'Reanudar Curso'; // Spanish text
    } else {
        return 'Resume Course'; // English text (default)
    }
}
add_filter( 'learndash_resume_link_text', 'custom_learndash_resume_link_text' );

Replace the text “Resume Course” above with the text you had been using in the module settings and replace “Reanudar Curso” with your Spanish text.

Hopefully that helps.

We did some additional testing on our end and it while we weren’t able to reproduce the issue you’re seeing with 404 errors, we did see an issue with a redirect loop occurring with the “Log In” link while the WPS hide login plugin was active.

It’s important to use a special link when users are logging out because that link has to be dynamically generated. However, the “Log In” link is a static link to the login page (as defined in the Front End Login module settings). Could you try using a static link to the login page instead of the Log In/Log Out shortcode/menu link to see if that works? You could then hide the Log In link if users are logged in, and hide the Log Out link if users are logged out, using the Menu Item Visiblity module. That would behave the same way the Log In/Log Out link works.

Hi @parms ,

Thanks for making us aware of the issue and the context.

I wonder if we could get more details, as we’re having trouble reproducing the problem on our site. Can you confirm what you mean by “I’m using Uncanny Owl’s log-in module to redirect users to the log-in page”, so how are you using one of our tools to take anonymous visitors to a login page? Otherwise, in the Front End Login module settings, have you set the login page map to match what you’re using in WPS Hide Login?

Thanks

Hi @ispacecrusader ,

Apologies for the late reply here. I ran this by our team, and they wanted to confirm that WPML cannot normally translate strings for the native site language. Can you confirm if the issue is related to the site native language or for a different language?

Please note too that this module allows you to define the text for the native language in the module settings under Uncanny Toolkit > Modules, like this: https://cln.sh/Y5HJr7Pc. Have you tried changing the text there?

Hi @ksielski ,

Our team had another look here and tried reproducing this with the latest versions of our Toolkit plugin and WP2FA. Everything is working fine for us, which makes it harder to trace.

If you have a Staging site available, our team’s recommendation is that you clone out there, confirm you can reproduce it, then disable everything EXCEPT our Toolkit plugin and WP2FA. Does it still happen in that situation? If not, can you try reactivating plugins and retesting as you go to see if it’s a conflict with something else?

The error you saw related to the login nonce is pretty generic, but would you be linked to the user not being found or trying to update user meta while logging in but experiencing a caching or database issue. Is there caching enabled, and if so, can you try disabling it temporarily to test with it off?

Thanks

Hi @denicew ,

Just a note that this came in under the Toolkit plugin, so we’ll tentatively mark this as closed.

Having said that, it’s really important that you get the details of the error on your site. You should see the specific details of the error in your site error log, which your host can help you find if you’re not sure where it’s located. Once we have those details we’ll be able to provide better feedback. You can submit the ticket under the Automator plugin here or on our website.

It wouldn’t be related to your PHP version though (7.0 through 8.3 are fine and widely tested), but perhaps another plugin is causing an issue, so once you have the error details, it would also help if you could include a system report (feel free to remove site URLs) from Automator > Status when you follow up.

Hi @lorilself ,

Yes, LearnDash made major changes to course navigation in 4.11.0. While there isn’t much detail in their release notes, you’ll find a lot of discussion in their Facebook group, both before and after the release.

In some cases, the progression changes they made do render some of our modules that affect navigation less applicable. In a future release we may deprecate those, but for now, users of versions from before LearnDash 4.11 may still find them useful.