NewCodeByte

Hi @iainpurdie

If the manual link didn’t solve it, it confirms that your hosting environment is strictly blocking the WordPress Cron system (loopback requests).

I have experienced this on hosting providers (like InfinityFree) where aggressive security settings block both internal loopbacks and external automated requests. In these cases, even setting up an external cron service usually fails because the server rejects non-browser connections.

I strongly suggest contacting your hosting provider directly. Ask them if there are restrictions on WP Cron or loopback connections and if they can whitelist it.

This is definitely a server configuration issue, not a bug in the WP Statistics plugin.

Greetings

Hello @sc0ttkclark ,

That’s amazing news! Thank you so much for taking this feedback on board and deciding to implement it as a core feature.

I’m genuinely impressed by your responsiveness and commitment to improving Pods. Knowing this will be included in the next release is the best possible outcome.

We’ll look forward to the November release!

Best regards,

Hello Paul,

Thank you so much for your previous reply and for providing the filter code. It was the key to diagnosing the root cause of the problem.

We have implemented the pods_field_args filter exactly as suggested. To verify its execution, we added some console.log debugging to see what was happening for different users.

Our tests have produced a conclusive result:

1. When logged in as an Administrator:
   • Our debugging confirms that current_user_can(‘manage_options’) returns true.
   • The filter correctly sets $args[‘readonly’] = false;.
   • The field is fully editable in the browser, which is the correct behavior.
2. When logged in as a non-admin User (Subscriber role):
   • We first used the User Role Editor plugin to confirm that this user role does not have the manage_options capability. The user’s permissions are correct and minimal.
   • Despite this, our initial debug showed that current_user_can(‘manage_options’) was unexpectedly returning true for this user, indicating a deeper permissions conflict on our site.
   • To bypass this conflict, we modified your code to check the user’s role directly with in_array(‘administrator’, $user->roles).
   • This new test worked perfectly. Our console.log now definitively shows that for a non-admin user, the filter correctly identifies the role and sets $args[‘readonly’] = true;. The instruction to make the field read-only is being sent correctly from the server.

This leads us to the core issue:

Even though we have proven that the readonly: true argument is being correctly passed to the field’s arguments for non-admin users, the multi-select relationship field in the browser remains fully interactive. The user can still search, add, and remove items.

This confirms that the PHP logic is sound, but the JavaScript component (Select2) used to render this specific field type does not seem to respect or implement the readonly state.

Our Question:

Given that the readonly argument is being ignored by the field’s front-end, are there any alternative, non-CSS solutions to achieve this?

For example:

• Is there a different argument we should be using instead of ‘readonly’ for this specific field type?
• Is there a built-in Pods JavaScript event or hook that we can use to programmatically disable or destroy the Select2 instance for non-admin users after it initializes?

We are trying to avoid using CSS to hide the controls, as we prefer a more robust and integrated solution.

Thank you again for your expert help. We feel we are very close to a solution.