pkarjala

Chiming in that we are seeing the same deprecation notices in PHP 8.3:

Deprecated: Creation of dynamic property Media_Deduper::$compat_manager is deprecated in /var/www/html/wp-content/plugins/media-deduper/inc/class-media-deduper.php on line 69

Deprecated: Creation of dynamic property Media_Deduper::$async_test is deprecated in /var/www/html/wp-content/plugins/media-deduper/inc/class-media-deduper.php on line 76

Deprecated: Creation of dynamic property Media_Deduper::$indexer is deprecated in /var/www/html/wp-content/plugins/media-deduper/inc/class-media-deduper.php on line 80

Deprecated: Creation of dynamic property Media_Deduper::$capability is deprecated in /var/www/html/wp-content/plugins/media-deduper/inc/class-media-deduper.php on line 86

Deprecated: Creation of dynamic property Media_Deduper::$hook is deprecated in /var/www/html/wp-content/plugins/media-deduper/inc/class-media-deduper.php on line 725

Any updates or information on a future release would be appreciated.

Thank you, will do!

Hi @aaloise in order to keep discussion to one support thread, I’m going to keep my responses on your first opened support issue on GitHub at https://github.com/uhm-coe/authorizer/issues/158

Thanks!

Hi, can you please provide links to Themeco’s X theme and the Cornerstone plugin? We can take a look and see what we can find from there.

Hi Terry,

Mike has the gist of it. You will need some way to automatically assign roles based on the LDAP attributes, and then set up a specific role that only has the necessary permissions for your faculty members.

More on the WordPress roles can be found at https://www.ads-software.com/documentation/article/roles-and-capabilities/

FYI I did finish a look through the Authorizer codebase and there is not a hook currently for getting this type of information.

Authorizer will by default synchronize the incoming user’s CAS email address with their account info in WordPress. You can test this on a fresh WordPress install configured with Authorizer.

This is assuming that you have configured your CAS settings in Authorizer on the External Service tab in the CAS attribute containing email address field, and the CAS users linked by username option is NOT checked.

So if you have a user that has logged in via Authorizer, their email address should be present in the WordPress user that is created or already present. You can then pull this email address directly from the currently logged in WordPress user through the WP_User object.

This post may be useful for getting CAS attributes such as email address directly from Authorizer: https://www.ads-software.com/support/topic/cas-login-filter/

I’m also taking a look through the codebase to verify if we have any hooks for this purpose, though my recollection is that we do not at this time, so it would require some custom changes to the Authorizer plugin.

Authorizer is specifically geared towards allowing third party authentication options for a WordPress user account; in the end it is a layer for logging into WordPress user accounts. If we allow logins to WordPress through the external authentication provided via Authorizer but then there is no user associated with the login after Authorizer verifies the credentials, it creates issues with regards to permissions and access levels because WordPress needs a user account to manage anything beyond a non-logged-in user.

In the workflow you’ve described, what is the purpose of having Authorizer managing WordPress logins? Do your users need to actually use any service in WordPress, or are you just using Authorizer to verify they should have access to specific content within WordPress (the link page you’ve mentioned)? If you can describe your use case in more detail, it would help us to guide you in the right direction or see if there is a hook in Authorizer that may suit your purposes.

It does look that way. We’re going to continue refactoring and I’ll check back in if we discover anything that’s an exception to this.

OK, following the logic flow, user editing is handled in edit_user (see https://developer.www.ads-software.com/reference/functions/edit_user/).

In edit_user are two functions that appear to get called whenever a user is updated or created: wp_update_user (https://developer.www.ads-software.com/reference/functions/wp_update_user/) and wp_insert_user (https://developer.www.ads-software.com/reference/functions/wp_insert_user/). The former actually calls and passes data to the latter, so we’ll focus there.

wp_insert_user will update roles by calling set_role on the user object (see https://github.com/WordPress/wordpress-develop/blob/master/src/wp-includes/user.php#L2144). This will presumably only get called if everything else with the user has not thrown an error, based on where it is in the insert user call.

set_role (https://developer.www.ads-software.com/reference/classes/wp_user/set_role/) has a hook in it called set_user_role (see https://developer.www.ads-software.com/reference/hooks/set_user_role/). This appears to be only called if there are no issues with the set_role and happens only if the user’s role actually was properly set.

Based on this, it’s looking like it’s safe for us to remove references to user_profile_update_errors, which is called early on in edit_user and before either wp_update_user and wp_insert_user, which means it would not really be indicative of whether the user’s role has actually been set at that point since all of the subsequent logic to actually set the user’s role had not yet been called. Instead we should use the set_user_role hook to verify that a role has been changed successfully, and run our code based off of that.

I hope that helps explain our refactoring work!

Sounds good; I’m already part way down the rabbit hole on this one and getting a good handle on the workflow. We’re trying to hunt down a weird bug related to roles, and in the process trying to reduce complexity. If we can reduce the hooks when role changes occur to just one place it will make troubleshooting issues easier down the road.

I’ll update with findings once I have more info.

The plugin is https://www.ads-software.com/support/plugin/authorizer/, I am one of the developers on it.

Great, thank you for the update!

Hi, following up if you still need assistance with this issue. Thanks!

Hi, we have not received any additional response to this support thread, so we are marking it as resolved. If you still need additional assistance with this issue, please reply to this thread, or open a new support thread and reference this one.