21stcn

I have no opinion about whether a refresh token should be provided for client credentials. I am no expert and I did not claim to be nor did I write an oauth2 plugin. You did, and in your documentation you specify that an example response returns a refresh token. This is the page: https://wp-oauth.com/docs/general/grant-types/client-credentials/

If it is changed since, here is a screenshot.

A successful response will contain the following.

{
  "access_token": "apvwxkbcxrnm9o92wmp4yjlbmoajeycfbn4ws6nx",
  "expires_in": 9087654,
  "token_type": "Bearer",
  "scope": "basic",
  "refresh_token": "z8wpp3pshgled4d81b4z8dmlc6ftwdscpgktyh7u"
}

I was only working to your documentation which I transcribed into documentation for the app develops. Refresh token for client credentials is not a feature request from me, I don’t know or care about the IETF draft, I was working with what you specified was a mandatory response for your plugin in the official docs.

While you are overhauling your site and support system, could you also make a note to make sure your documentation is accurate. Thanks.

Ok, I just found this documentation page Using a Bearer Token with WP REST API , https://wp-oauth.com/docs/how-to/using-a-bearer-token-with-wp-rest-api/

Changing the header from ‘Bearer: {token}’ as specified in the other documentation page, to ‘Authorization: Bearer {token}’, as specified in this page I am able to get it working.

Perhaps the other page should be updated or I maybe just misunderstand the headers syntax? https://wp-oauth.com/docs/general/wp-rest-api-authentication/

• This reply was modified 5 years, 7 months ago by 21stcn.

but you rated 5 stars ??

Bottom line. While the Gutenberg interface has a lot of merit, has potential to address some issues where WordPress is lacking, potential to add some really intuitive and new functionality to WP, the single minded zeal of focusing on this one central content creation experience, to the determent of a lot of other use cases, ignoring them in fact, is its weakness.

This is the absolute truth of this situation and why Gutenburg should not be included in core. WordPress is many things to many people, and many developers/managers have shaped and adapted it to create the CMS and web people use. WordPress is, by a long way, not only for independent bloggers writing blog posts, even if it once was. None of my clients should be formatting the content except for applying tags like h1 and blockquote. Any other styling is what I wrote style.css for.

The sites myself and many others have built using WordPress are not nice little ‘my holiday’ blogs by someone who should have complete control and stylistic freedom. They are bespoke sites shaped around what WordPress has always been, and facilitate the inclusion of varied content types on the frontend, according to my, the web developer’s specifications. Make it optional.

• This reply was modified 6 years, 3 months ago by 21stcn.
• This reply was modified 6 years, 3 months ago by 21stcn.

https://github.com/woocommerce/woocommerce/issues/20374

It seems that updating the ‘visible’ property of a single variation via the API toggles the ‘enabled’ checkbox, so it has the same functionality. It sets purchasable to false (indirectly).

For example, if you toggle the ‘visible’ property of a single variation to false using the rest api, $woocommerce->put(‘products/22/variations/733’, $data);, it will result in ‘purchasable’ being set to false, and uncheck the ‘Enable’ checkbox.

However, if the parent product is not also set to invisible, the variation visibility will remain true, even though purchasable is set to false. So this seems the best way to do it, even though it is kind of counter intuitive.

This works:

$woocommerce->put('products/22/variations/23, $data);

$data = [
    'visible' => false
];

Resulting in these properties for the variation:

if parent visible: 'visible' = true; 'purchasable' = false;
if parent not visible/draft: 'visible' = false; 'purchasable' = false

Note however, just for the record, this same behavior does not occur when batching:

$woocommerce->post('products/22/variations/batch', $data);

Batch changing variation visibility does not change variation purchasable property nor toggle enable checkbox.

• This reply was modified 6 years, 5 months ago by 21stcn.
• This reply was modified 6 years, 5 months ago by 21stcn.
• This reply was modified 6 years, 5 months ago by 21stcn.

Thanks for your reply and pointing me in the direction of the list of properties in the documentation that can be changed using the rest api. I see now that purchasable is ‘read-only’ which would have saved me some time.

I wonder if simply setting the variation post itself as a draft is the way to handle this programmatically, using wp_update_post()? In testing, setting the variation post to draft:

1. Removes it from the user’s cart
2. Removes it from the product page

The problem with this method is that, after setting the variation as draft, the variation does not have ‘Enable’ unchecked in the dashboard when editing the parent product, it simply disappears. So unless you’re handling everything programmatically, this is potentially dangerous.

Ok guess I’ll open a github issue as there should be a way to toggle the purchasable property using the rest api.

Thanks for the reply.

I haven’t tried the beta but simply adding this to my stylesheet fixes the problem, so I’m sure it will work:

.lazyload { display:block; }

I guess it is because the lazyaspectratio script makes its calculations based on the computed height of the element, only if the element takes up space as a block element.

Thanks for your help

Same here. Reverting to previous version of the plugin.

tobiasfriman is right, the subscribe checkbox only shows if the person commenting is not logged in. This is because it is hooked in using

comment_form_default_fields

which is for the ‘logged out’ form.

It seems like an arbitrary distinction to make, only showing the checkbox to logged out users, especially on blogs where users MUST be logged in to comment in the first place. To show checkbox for logged in users until the plugin is updated (add to functions.php):

       //if replying to self dont send email

        if($email == $comment->comment_author_email){
            return false;
        }

This puts the checkbox above the comment textarea. To move it below, I used flex-box order css. Maybe there is a better hook to use to move it below?

• This reply was modified 7 years, 7 months ago by 21stcn.

Thanks for the reply and the detailed explanation.

The use-case is pretty standard I would have thought: you want some user types to receive points in certain instances, some not to. I am working on a blog which has content creators/managers (Editors and Authors) who publish about two posts a day, and then consumers (Subscribers and Contributors) who comment and interact with the blog. If a Subscriber OR a Contributor comments, they get points — the freedom to make this type of basic assignment seems implicit in the plugin.

I am using Wordpoints to reward the consumers for visiting the blog and commenting (and eventually buying though WC etc.) but don’t want to dish out the same points to the content creators, who I want to give points of the same type, but not for the same things. I suppose I could just let the system give points to the creators and not display them and then create a new points type for creators (even though some points should overlap between types), but it seems like the wrong way to go about it.

If you have the situation where you need to create duplicate reactions for each user type, it seems to undermine the effectiveness of the plugin, especially in multi/site setups with lots of roles. For a single reaction, such as posting a comment, you might have 4 entries to cover your roles, multiplied by any other comment related action, such as replying to a comment. The points type screen would become a mess and updating point quantities/descriptions becomes an administrative headache because the values are all the same, just the user roles are different.

But I am just diving into the plugin and will make it work one way or another. I just wanted to check that I wasn’t missing something obvious here. I would think having the ability to have an OR operator for user roles would be quite a popular request going forward (the ACF conditional logic system is a pretty good one for reference). Assign point for visiting the site.. to who? Subscribers and Contributors. Done.

All that said, the plugin is fantastic and I really appreciate its quality and the work you’ve put in. If things go according to plan, I’ll be purchasing at least the WooCommerce module (which reminds me, page of the modules is currently inaccessible: https://wordpoints.org/modules/page/2/ ). So thanks again for the plugin and your assistance.

I understand.

Thanks very much for your help!

Are you, as Super Admin having to login at sub-sites after being logged in already?

Yes, I am having having to sign into sub sites.

My setup is interesting though.

My primary site is on a subdomain:

main.website.com

My sub sites are:

site2.main.website.com
site3.main.website.com

BUT I am using multisite’s native domain mapping function, by changing Site Address (URL) under the info tab when editing the sub site, to:

site2.website.com

So I think that domain mapping is interfering with the single sign-on.

Bump. Note that deactivating ACF Image Crop Add-on removes the warnings and notices.

ACF Pro Version 5.5.9
Image crop add-on Version 1.4.10
Wordpress 4.7.2

Notice: Undefined index: url in /…/wp-content/plugins/advanced-custom-fields-pro/api/api-helpers.php on line 3851

Warning: Cannot modify header information – headers already sent by (output started at /…/wp-content/plugins/advanced-custom-fields-pro/api/api-helpers.php:3851) in /…/wp-includes/pluggable.php on line 1179

• This reply was modified 7 years, 9 months ago by 21stcn.
• This reply was modified 7 years, 9 months ago by 21stcn.

Thanks for your reply. The update fixed the php notices

However, when I go

1. Appearance -> Widgets and add the widget
2. Enter a place into the Find Place
3. Click Search Place

Nothing happens. No google maps autocomplete, no javascript error, nothing.

Just to remind you I am on multisite, in case this might be part of the problem.

I am on localhost so I can’t create a user for you and I’ve found another plugin so I am moving on and can’t troubleshoot this with you. I am changing my review to 4 stars to give you the benefit of the doubt, and so that my review doesn’t give you a bad average before you get more reviews.

If I return to this plugin in the future I will re-evaluate. Good luck.

Hi Michael,

I now have version 0.5 but am having the same problem with the same form.

I’ve just changed the css and message for the first error to resemble a success message. Only issue is if there is a real error, and the fields dont reset on submit. But still, your plugin is incredible and has saved me a lot of time already.