Stephen S

Anyone??

Well, I figured out a workaround which should be good for my purposes. I changed my function to look like this:

function mytheme_only_allow_logged_in_rest_access( $access ) {
if (!strpos($_SERVER['REQUEST_URI'], "jwt-auth/v1/token")) {
	if( ! is_user_logged_in() || ! current_user_can( 'edit_posts' ) ) {
		return new WP_Error( 'rest_cannot_access', __( 'Only authenticated users can access the REST API.', 'disable-json-api' ), array( 'status' => rest_authorization_required_code() ) );
	} }
	return $access;
}
add_filter( 'rest_authentication_errors', 'mytheme_only_allow_logged_in_rest_access' );

Hope this helps someone else…

• This reply was modified 8 years ago by Stephen S.

oh one other thing: It is against spec to have more than one id of the same name on a page, so I modified the code to use class (a.agreement) instead. I think it would be good to change the plugin to do so in the next version as well.

I will, I think you have done an overall great job with this. I think it might be helpful in the next version to include a pref for setting whether this opens in the current or new window, and would solve this particular problem. Thanks

• This reply was modified 8 years ago by Stephen S. Reason: resolve

Well, I figured out a solution to this problem by modifying the code in agreement.js, line 22. I changed this:

window.open(href,'_blank');

To this:

window.location = href;

• This reply was modified 8 years ago by Stephen S.

Ok, I found the problem. I have a new user whose username contains a period, which is allowed by WordPress. This plugin was using that username to set the session name, but a period is NOT an allowed character in a session name. So I changed that code to replace a period with “DOT”

$session_id = 'CDW'.str_replace('.','DOT',$current_user->user_login);

and now bingo, no errors. Hope this helps someone else.

For anyone else that needs an answer, here is what I came up with.

I could only get a response by sending data as “raw” (instead of form or x-www-form-urlencoded)

fixed in latest update, thanks!

that works, thanks for updating so quickly!!

Ok, I will add these to feature requests.

From what I can understand from what you are saying, this should already be supported.
To troubleshoot further, I will need to know:

1. What are the EXACT entries you have made in an admin pointer?
2. What is the EXACT expected behavior for that pointer?
3. What is the EXACT result?

IF you can provide the above, I can take a look. But what you have said in your latest comment is too vague for me to troubleshoot in any meaningful way, sorry. A clear example of what you have tried would help me help you. Thanks.

Can you give me a very specific example?

Unless I am misunderstanding what you mean, they are already supported. (well, pages and posts anyway…not sure what you mean by “any” things)

Thanks for the kind words, glad you find my plugin useful.

Unfortunately, I can’t know what every third party has done to implement their own help tabs, whether or not they have used WP’s built in way, etc. Also, I have no way of testing what other plugins do (paid ones anyway), so I go by how my help tabs integrate with existing WP help tabs. Which is to say they integrate by adding tabs on pages that already have them, mixing the existing (WP anyway) tabs with the ones we are adding in my plugin. Also (as noted on the description page) there can be only one help sidebar per page, and it will be the most recent one (so will override whatever WP one is there, assuming it is newer).

So as far as I can tell (within my testing of how the help tabs integrate with the default WP ones), it is working as it should. If you can show me a clear example where it isn’t (and where a third party is correctly using WP APIs for their help tabs) I would be happy to take a look.