Vasyl Martyniuk
Forum Replies Created
-
@yg1958 thank you for the report. Indeed. It is possible when get_post function returns null if post does not exist. We are going to address this in the next AAM release.
@kcisme thank you for the explanation.
It is likely access that you are trying to configure requires actual Administrator role assigned to user. Unfortunately some plugin developers choose to use role-based access strategy instead of deferring to WordPress capabilities.
You would have to work with their plugin dev team to understand better what criteria user needs to meet in order to get access to desired functionality. As alternative – you can always check their source code to understand better what is going on.
Regards.
Can’t quite reproduce your issue and I’ve tried several different settings with WPS Hide Login. Maybe there is some incompatibility issue between both plugins that we can’t understand at the moment.
Try to go to AAM and on the “Settings” page disable “Login Redirect” service. This may help.
Otherwise, let us know what settings you have defined on the Settings -> WPS Hide Login page.
Forum: Plugins
In reply to: [Advanced Access Manager – Access Governance for WordPress] Not working…Hm, Backend Menu & Admin Toolbar are foundational services in AAM and so far you are the only one reporting that they are completely not working. Please send us exported AAM settings to support@aamplugin.com and we’ll check your setup.
Regards,
The “Plugin” resource was removed in AAM 7 after a thorough evaluation revealed significant inconsistencies in how WordPress core manages plugins across the Backend and the REST API. Specifically, while this resource allowed access control over the plugin list in the Backend, it proved ineffective for the REST API.
Additionally, we determined that the
/pluginsendpoint in WordPress core lacks the flexibility needed to support the same level of granular access control available on the Backend Plugins page.To avoid creating a false sense of security, we made the decision to remove this resource entirely in AAM v7.
Regards.
@tohevi thank you for the follow up. I’ve tested custom filter functionality over and over again and can’t reproduce an issue. My best guess is that you register
aam_jwt_claims_filterfilter likely after the token is issued. Here is what I’ve done to test it.#1. Created a custom plugin to test the filter:
<?php
/**
* Plugin Name: AAM Test Bug
* Description: Just a playground for any functionality that is related to AAM
* Version: 1.0.0
* Author: Vasyl Martyniuk <vasyl@vasyltech.com>
* Author URI: https://vasyltech.com
*
* -------
* LICENSE: This file is subject to the terms and conditions defined in
* file 'LICENSE', which is part of AAM Protected Media Files source package.
**/
if (defined('ABSPATH')) {
function cci_aam_extend_jwt_claims($claims) {
return array_merge($claims, [
'house' => 'house',
'apartment_id' => 'apartment_id',
'family_id' => 'family_id',
'customer_number' => 'custom_number',
]);
}
add_filter('aam_jwt_claims_filter', 'cci_aam_extend_jwt_claims');
}Issued a token with AAM UI and custom claims are in the token:
{
"jti": "a8fc8b70-8b46-476b-882d-ae3a29d9acfd",
"revocable": true,
"refreshable": false,
"house": "house",
"apartment_id": "apartment_id",
"family_id": "family_id",
"customer_number": "custom_number",
"iat": 1749427205,
"iss": "http://demo.local",
"exp": 1751068802,
"user_id": 1
}@treetex got it. Looking into the root cause and if we can replicate it – we’ll release a new update to the add-on.
@virtualdemon wondering if you have a custom capability
aam_show_admin_noticescreated. We’ve noticed that WooCommerce for no particular reasons rely on admin_notifications filters to render their UI (likely a bug on their end).Otherwise, I can’t quite replicate your issue.
@andisites thank you for the report. We were able to replicate the issue and looking into the root cause. It’ll be fixed in the next minor AAM release 7.0.3
@tohevi thank you for the report. Likely the issue is with:
if (!isset($claims['userId'])) { return $claims; }To standardize props, the
userIdnow isuser_id.Give a try and keep us posted.
@npalmigiano and @ceccah5 thank you for the issue. The root cause was identified and @npalmigiano your fix is a good attempt, but it’ll not work. The entire idea behind these couple lines of code is to differentiate between term metaboxes as WordPress core recycles the same callback function for all taxonomies (including custom)
The best fix for now is to disable the “Metaboxes” service on AAM “Settings” tab.
@bentalgad this issue was resolved in the past few releases. Keep me posted if anything.
@raoulunger got it. Identified the root cause. We are going to adjust AAM functionality in the next minor release 7.0.2 to work better with plugins that hook into WP core initialization early on.
Hm, interesting. Ok. I’m wondering if there is some sort of conflict. I see the trace goes through “updraftplus” plugin. I’ll try to install and replicate an issue.