jasnon

@dadmin31 thanks for the advice. I was able to follow this and maintain a connection long enough to finish the job (took around 24 hours). But after the job had finished it simply took me back to the main Ultimate Member dashboard page and I’m still seeing the message to upgrade.

I’m not sure what happened exactly after the job finished as it completed overnight. I think I need to reach out to support on this unfortunately.

@andrewshu I’ve changed the status back to ‘Not Resolved’ per missveronicatv’s comments above.

Please can you provide an update on a solution for this?

@dadmin31 were you able to resolve this somehow? I’m running into the same issue with around the same amount of users

Thank you for continuing to push this forward @missveronicatv

@andrewshu – I’m still experiencing the issue and would greatly appreciate if the issue could be fixed as outlined by @missveronicatv

I was going to create a new topic but figured I’d just piggyback on this instead in case the issues were related.

After updating to the latest version of the plugin (v20.13) I’m now receiving the following php warnings in my error log:?

[20-Aug-2023 01:44:31 UTC] PHP Warning: Attempt to read property “taxonomy” on null in /wp-content/plugins/wordpress-seo/src/helpers/current-page-helper.php on line 488 
[20-Aug-2023 01:44:31 UTC] PHP Warning: Attempt to read property “term_id” on null in /wp-content/plugins/wordpress-seo/src/presentations/indexable-term-archive-presentation.php on line 99 
[20-Aug-2023 01:44:31 UTC] PHP Warning: Attempt to read property “taxonomy” on null in /wp-content/plugins/wordpress-seo/src/presentations/indexable-term-archive-presentation.php on line 99 
[20-Aug-2023 01:44:31 UTC] PHP Warning: Undefined property: WP_Error::$taxonomy in /wp-content/plugins/wordpress-seo/src/presentations/indexable-term-archive-presentation.php on line 155 
[20-Aug-2023 01:44:31 UTC] PHP Warning: Undefined property: WP_Error::$taxonomy in /wp-content/plugins/wordpress-seo/src/presentations/indexable-term-archive-presentation.php on line 180 
[20-Aug-2023 01:44:31 UTC] PHP Warning: Undefined property: WP_Error::$taxonomy in /wp-content/plugins/wordpress-seo/src/presentations/indexable-term-archive-presentation.php on line 186 
[20-Aug-2023 01:44:31 UTC] PHP Warning: Undefined property: WP_Error::$taxonomy in /wp-content/plugins/wordpress-seo/src/presentations/indexable-term-archive-presentation.php on line 214

Thank you!

@missveronicatv @andrewshu adding reCAPTCHA to my registration form looks like it did the trick! I’m no longer seeing those Undefined index: user_id errors show up in my log. Feel free to close the ticket, and thanks again for all the support!

@maybellyne excluding the post type ‘post’ would exclude all posts though wouldn’t it? how could I only exclude posts under a specific category?

@maybellyne thanks for the reply. Is there a way to exclude all posts under a specific category (or multiple categories) using the methods shown in the article here?

https://developer.yoast.com/features/xml-sitemaps/api/#excluding-content-types

@missveronicatv thanks will do. I’ll install now and monitor to see if that helps.

@missveronicatv @andrewshu some additional information on the issue as I’ve seen more occurrences over the weekend:

Some (not all) registrations trigger the php notice 5 times.

• 3 times on the registration page (form mode = register)
• And 2 times on the login page (form mode = register)

These 5 notices all occur for the same user id within a matter of seconds.

Looking at my users database, the new registrations that trigger the notice appear to possibly be bot signups as the username is just a log string of characters and numbers. Is it possible that bot signups who automatically fill registration fields to sign up may be the culprit for triggering these error notices? And if so, is there a fix for that?

@missveronicatv I think I may have finally been able to re-create the issue. Steps that were taken:

1. Open a browser tab on the registration page (don’t fill any fields out)
2. Open a second browser tab on the login page
3. Log into an existing account
4. Go back to the first tab and attempt to register a new account
5. After submitting the form you’re taken back to the registration page with the message “You’re already registered”
6. The following is also appended to the end of the URL: ?err=invalid_nonce&um-hash=5ec446
7. And the following notice is added to the log: PHP Notice: Undefined index: user_id in /wp-content/plugins/ultimate-member/includes/core/um-actions-form.php on line 433

Hi @maybellyne thanks for the reply. 99% of the posts on my site are created by users via a Gravity Form. These posts are membership pages which is why I don’t want them included in my post sitemap or indexed by search engines.

As the site admin however, I do create a few posts for educational purposes (marketing landing pages, etc.) and these are the only posts I would like included in the sitemap and indexed by search engines.

This is why by default I have the global setting of posts toggled to OFF so the 99% don’t get indexed, and then I change the advanced settings of each individual post I create as admin to ON so those do get indexed. They don’t however show up in my site map and that’s the problem I’m trying to solve.

Hope that helps explains things better.

@missveronicatv thanks for the additional code snippet, this actually revealed some interesting information. The PHP notice appears to always trigger on my ‘Default Registration’ form ID when the form mode is set to ‘register’ and the number of fields is ‘5’ (which explains why the notice fires 5 times whenever it shows up in my log).

What’s interesting though is that I also added the page URL to that code snippet so I could confirm which page the issue was occurring on (as I have registration forms on two different pages). Surprisingly what I found was that the notice is triggering on both my UM Register page AND my UM Login page. I don’t understand how that would be possible though as I don’t have my registration form anywhere on my login page.

Thanks for the continued support on this, I feel like we’re getting closer to the root of the issue.

Hi @missveronicatv the ability for users to edit their own profiles has been disabled this entire time from the User Roles -> Subscriber -> General Permissions settings. Currently, the only place for user’s to edit their information is from the Account Settings page.

The challenge with this issue right now is I haven’t been able to re-create it myself at all, so I can’t pinpoint what’s causing it. I just see it being logged in my error logs when users visit the site at some point. But even then, I haven’t been able to pinpoint the exact page / UM functionality that’s causing them to trigger this.

From the stack trace were you able to tell which UM form/function specifically is causing this?