budasy

Hi @eskapism, I wrote my question when I was comparing several logging plugins and hadn’t spent much time with Simple History.

During the last few days I’ve been testing Simple History on my dev box and I found your examples file. It only took me a few hours to copy a few lines to my code and modify it to suit meet my needs.

I’m so glad I took the time to test Simple History, great work.

I have found a solution to my problem. I suspect that the most prominent solutions found by my web searching were suitable for /wp/v1/. We are now at /wp/v2/ so those answers are out-of-date.

The advice to use register_meta to declare that a particular meta option can be accessed by REST API is still correct.

It can easily be added by placing a short code block in your theme functions.php file. Registering your custom field using register_meta instructs your custom meta property to be included in the output when a call is made to a REST endpoint.

This is what I have included in my theme functions.php file.

add_action( 'rest_api_init', function () {   
		register_meta( 'user', 'wpcf-uuid', array( 
		'single' => true, 
		'type' => 'string', 
		'default' => true, 
		'show_in_rest' => true, 
		'supports' => [
                    'title',
                    'custom-fields',
                    'revisions'
                ]
		) );
}); 

For my needs, to fill custom fields when adding a new user, the important component that I needed was to add an action to be triggered on rest_insert_user. That can be achieved with this code, which I found at Stack Exchange – WordPress. Thanks to Guilherme Sampaio. Guilherme Sampaio

The function simply walks through the meta array and passes the values to update_user_meta.

function remote_user_update($user, $request, $create)
{
    if ($request['meta']) {
        $user_id = $user->ID;
        foreach ($request['meta'] as $key => $value) {
            update_user_meta( $user_id, $key, $value );
        }
    }
}
add_action( 'rest_insert_user', 'remote_user_update', 12, 3 );

This is solution may be the “first and worst.” If you have a different way of solving this problem, please respond here so that there can be a small repo of working solutions for other people working with Custom Fields and the JSON REST API.

• This reply was modified 3 years, 9 months ago by budasy.

Hi @bcworkz, thanks for looking at this issue.

WordPress v5.6 has brought “Application Passwords” into core, so we can use basic authentication without needing a plugin. The UI is accessible on a users profile page.

I’ve tried with register_meta() and with register_rest_field(). Currently I have both in place. This allows me to see the data when I use the GET endpoint but it doesn’t seem to help me when I use the PUT endpoint. Right now my functions.php contains this code:

/*
 * Allow custom field wpcf-uuid to be accessible to REST-API
 */
register_meta( 'user', 'wpcf-uuid', array( 'single' => true, 'type' => 'string', 'default' => true, 'show_in_rest' => true, ) );

add_action('rest_api_init', function() {
    register_rest_field( 'user', 'wpcf-uuid', [
        'get_callback'    => 'get_user_uuid',
        'update_callback' => 'update_user_uuid',
        'schema'          => [
                                'type'        => 'string',
                                'description' => 'The UUID passed in by FileMaker',
                                'context'     => [ 'view', 'edit' ],
                             ],
    ]);
});

function get_user_uuid( $user, $field_name, $request ) { 
    return get_user_meta( $user[ 'id' ], $field_name, true );
}

function update_user_uuid( $user, $meta_value ) { 
    update_user_meta( $user[ 'id' ], 'wpcf-uuid', $meta_value );
} 

I’m trying to create a user with a cURL call that looks like this:

$ curl --user 'user:password' -X POST "https://my.domain.com/wp-json/wp/v2/users" \
     -H "Content-Type: application/json" \
     -d "{\"email\":\"[email protected]\",\"first_name\":\"tea3\",\"last_name\":\"thaaba\",\"meta\":{\"wpcf-uuid\":\"got-it\"},\"name\":\"tea3 thaaba\",\"nickname\":\"teatha\",\"password\":\"A5B8128F-7\",\"slug\":\"tea3tha\",\"username\":\"tea3tha\"}"

I’m using a call to GET /wp/user/<id> to test visibility of the custom field.

I included register_meta() in my functions.php file and that didn’t help, the custom fields weren’t returned. Should I have done more than simply paste in a call to register_meta()?

However, the method outlined on StackExchange did return the custom fields. https://wordpress.stackexchange.com/questions/338134/updating-custom-wordpress-user-meta-field-via-rest-api

add_action('rest_api_init', function() {
    register_rest_field( 'user', 'uuid', [
        'get_callback'    => 'get_user_uuid',
        'update_callback' => 'update_user_uuid',
        'schema'          => [
                                'type'        => 'string',
                                'description' => 'The UUID passed in by FileMaker',
                                'context'     => [ 'view', 'edit' ],
                             ],
    ]);
});

function get_user_uuid( $user, $field_name, $request ) { 
    return get_user_meta( $user[ 'id' ], $field_name, true );
}

function update_user_uuid( $user, $meta_value ) { 
    update_user_meta( $user[ 'id' ], 'wpcf-uuid', $meta_value );
}

I’ll check to see if it is possible to pass data into the UUID field when creating users. It’s working for accessing data that is currently there.

OK, it seems like I’m getting the meta formatted correctly.

     -H "Content-Type: application/json" \
     -d "{\"email\":\"[email protected]\",\"username\":\"Masu\",\"meta\":{\"wpcf-uuid\":\"E54AF95C-CC35-462C-A058-561D6CE3C108\"},...

I’ll follow up the links to register_meta(),

thanks

I’m here because I have been seeing this warning too. It is very distressing to have a false alert of this kind on such an important process.

I don’t want to see false alarms from my security code. I don’t want to have to check the file update times to see if the rules have been applied. AND, if the verification test is that simple, why isn’t your plugin able to do it?

Ever heard the story of the boy that cried wolf? Are the other alerts from Wordfence reliable? Which ones should i trust?

@reneesoffice you’ve made me very happy!

Everything worked. I was prompted to sign in and then walk through the steps to configure the account. At the end I was returned to the correct domain.

thank you

The WP dashboard is at wp-admin.

I’ve posted the information from the production site using your form.

The staging site is https://staging.adelphi.co.nz and it is a default installation.

thanks

that’s great news. I’ll have a look at it.

thank you. I’ll update the plugin

Great. looking forward to the update

I’ve forked the code and installed the beta. Unfortunately this problem remains.

I don’t think I described the problem carefully enough. The [group][/group] shortcodes embedded in the HTML are being saved. I know that the code editor was removing them in some cases but I haven’t noticed that happening in the last few releases. In my usage with current versions the [group][/group] shortcodes are not being removed from the HTML code when saving the form.

The problem I have been describing above occurs when creating and saving conditional fields rule sets using the input form on the conditional fields tab. I raised the issue here because the input form works without error when the smart grid-layout plugin isn’t active.

I did notice that the conditional fields rule sets are saved when rule set is in text mode. The rule sets are not saved when rule set input form is active.

I rolled back to 4.4.2 and found that the rule sets are saved when in text mode there too.

So, for this issue, the simple work-around is switch the conditional fields rule set view to text mode when saving/updating.

I’ll post to Conditional Fields as well, as the best solution may be a change to that code.

I applied the principles of Marie Kondo. I asked myself – does this plugin bring me joy? No. It does not bring me joy.

Just like spam, it interferes with my work. It intrudes on my working space with unwanted advertising. I have to scroll past the enormous billboard that the plugin inserts on the page. If I click the billboard closed it opens again the next time I open the dashboard. That is not working well for me.