joho68

You’re welcome. I’ll be here if you have further questions.

Hello Rebecca, and thank you for reaching out.

I don’t believe the question is stupid. But to be clear, the Cloudbridge Mattermost plugin does not enable embedded Mattermost functionality on your WordPress site.

The plugin interacts and interfaces with Mattermost in two ways:

1. To get notifications in Mattermost when something happens on WordPress sites
2. To allow logins to WordPress to be authenticated by Mattermost

I hope this clarifies things.

The errors have indeed been corrected in 1.0.1, and now 1.1.0 is out.

The error is triggered here:

	if ( ! isset( $allowed_options[ $option_page ] ) ) {
		wp_die(
			sprintf(
				/* translators: %s: The options page name. */
				__( '<strong>Error</strong>: Options page %s not found in the allowed options list.' ),
				'<code>' . esc_html( $option_page ) . '</code>'
			)
		);
	}

in wp-admin/options.php

Yes, I know. And that’s what I’ve done. I just think that this is such a fundamental part of WordPress back-end (so to speak) that it’d make sense to have AJAX_DEBUG as a known define that can be enabled/disabled from wp-config.

Anyway, thanks for all the replies ??

Thanks for the reply.

I’m not entirely sure I agree. One of the first things admin-ajax.php does is to call the admin_init action. After that, it does is_user_logged_in() and, if true, does wp_ajax_${action}, if false, it calls wp_ajax_nopriv_${action}.

My error was a stupid mistake, but nevertheless, it’d be nice if there was special debugging in admin-ajax.php that we could enable, with logging to the PHP standard logfile (as defined elsewhere).

Thanks for the response. Well, I needed to have a way to handle possible errors during the ping process (when run by WordPress), but I’ll figure out another way to do what I wanted to do.

I was just surprised not to find a hook/filter for this ??

Fair enough. I’ll carry on using this method until I find a better way ?? Thanks.

Thanks for responding. But since WP knows when it’s a REST request and when it’s not, it would seem reasonable to expect that some of this is accessible rather early, no? I mean, it has to know about at least namespaces when checking a request, right?

What I’m doing now, in my class, is something like:

if ( $this->my_rest_server == null ) {
    $this->my_rest_server = rest_get_server();
}

and it seems to work like I want/need it to, but I’m not sure it’s the “correct” way of doing it the “WordPress way” ??

• This reply was modified 3 years, 8 months ago by joho68.
• This reply was modified 3 years, 8 months ago by joho68.

Hmm … it seems like if I don’t sent total items, or any of the data used by the pagination, it’s not output (the clear break). I can check in a few hours to see if that is what’s happening.

I found one situation where it wouldn’t be set, so that may very well have been the issue.

Thanks for getting back to me.

For what it’s worth, I think it’d be nice with some sort of reference for available CSS and/or JS functionality already present in Admin. I think it would make for a much better UX and I think it would save a lot of people a lot of time.

They may even (possibly) be able to focus more on fixing bad behavior if they didn’t have to spend time finding out which CSS/JS (library or self-made) they should use for their specific plugin ??

Thanks for responding. I’m aware of these potential issues, but AFAIK, nothing has changed in the plugins involved, and certainly nothing in my own plugin. But I “solved” this by issuing an exit-call in my REST handler (which does the output) as opposed to returning a value. So that’ll have to do for now.

(Another option would, of course, have been to simply have a .php file outside of WordPress’ REST framework.)

Thank you. Turns out that, in this particular case, using a gettext-filter was the best/least complex way of accomplishing what I needed.

OK. So this is weird, and I don’t know why, but if I set the priority to 99999, it works. I guess that means my function is called when everything is set-up, and that it was being called too soon previously.

Once again, thanks for the replies.

So I’ve validated that my filter function is being called if I use a priority of 19 or lower, but it doesn’t seem to matter what I return, the login still proceeds (provided the given credentials are correct of course).

Looking at the code here: https://developer.www.ads-software.com/reference/functions/wp_authenticate/, I cannot for the life of me figure out why my function returning an instance of WP_Error does not prevent the login.