Working with WordPress users

On WordPress there is a pyramid of user permissions, the highest user role is administrator, the lowest is visitor, who only has a profile.

In between are the roles of contributor, editor, editor-in-chief, which may or may not make various edits. For example, an editor cannot upload a file, while an editor-in-chief can. It is also possible to create an editorial board because edits made by an editor must be approved and released by the editor-in-chief. This means that the editor-in-chief is in control of the content of the site.

How to set user rights

But even the editor-in-chief cannot change the settings of the website. He only works with posts and pages, he has no access to the appearance settings or plugin configuration. But this can be changed. Individual user roles are made up of permissions – capabilities. These are individual permissions, there are dozens to hundreds of them, and by putting them together, the user role itself is formed. It is quite normal that many plugins create their own roles, for example WooCommerce, Rank Math SEO, Yoast and many others.

So you can create your own role. If you were programming the website yourself, then you would probably use your own access rights to various functions and build a role from them. Even if the site is already finished, you can still use this principle and build the role yourself. To do this, you need a user role editor and you also need to know what individual permissions are available to you. For example, Ninja forms doesn’t have its own role but it does have its own permissions. This applies to many other plugins as well.

This means that even the editor in-chief can’t access the results of the submitted forms, but because there is a permission that allows this, you can create your own role and assign it to a user. So a user can have the role of editor in-chief and perhaps the role of ninjaforms administrator.

Do you know that woocommerce has a role for the store administrator that allows to checkout orders , without the person in question being the site administrator? And do you know that seo pugins are similar?

Testing under another user

Sooner or later, when you manage a website, you will find out that something is not working for a certain user. Even if you have carefully set up and tested everything and everything works for your user, someone will undoubtedly report to you that it doesn’t work for them. It is therefore advisable to check the situation directly under that user. However, it will also be advisable not to change a given user’s password, sometimes it can break the trust of the person who uses it by wondering, Why is the administrator changing my password? Fortunately, in WordPress we have a better option, and that is to use the Identity Switch plugin. Simply put, you switch to another user for a moment, then you see everything through their eyes. The most famous plugins of this type are user switching or xyz.

Discarded User

Every collaboration will end at some point and you will also get a request to delete the user from the site. This cannot be taken literally or you need to think in advance whether you will actually delete the user. With him you would delete all his content, which is undesirable. We know many Urban Legends who gloatingly remind us that by deleting user number 1, more than one administrator has also deleted all the content of the site that this user created. This means especially the front page done in elementor, the contact page, and all other key content components, so be careful.

The user does not have to have any role in WordPress. So if you want to delete someone, try to remove all permissions or more precisely the role and he will not be able to log in. To be safe, also delete all his logged-in sessions in his profile and change his email address so he can’t generate a new password.

User application passwords

In addition to a password, each user has the option of using an application password for access. With it, you don’t log into the WordPress app at /wp-admin/, but you can send a query to the REST API, which will return the data. The password is set in each user’s profile.

The Wordfence plugin disables this option to improve security, so if you don’t see the password settings in your profile and you’re using WF, check your settings (Wordfence > Firewall > Brute force protection > Disable Application passwords).

How to use it? Imagine that you want to display the data submitted via your form (=responses, submissions), or get this data into an application and work with it.

A request of this type cannot be sent by simply entering an address (GET method) because you must add authorization headers and some requests are sent by POST. You can use applications like Postman for this, but you can also use a VS Code add-on like Postcode (there are more). If you want to use an information system, it will usually already know how to do this and send the request correctly (everything is usually done using cURL).

REST API entry points are used as base addresses. The base address is /wp-json/, when we want to get data from Ninja forms, there is ninja-forms-submissions, then submissions and finally form numbers. So the whole url looks like this:

http://xxxx.cz/wp-json/ninja-forms-submissions/submissions/get?type=data&form_ids=2

In the picture you can see how to send the request using the Postcode add-on in VS Code.

The Password field contains the application password you created earlier. If the user does not have permission to access Ninja forms data, see the previous text, then you will only get the response.

{"code": "rest_forbidden", "message": "You have not\u00e1te enough\u010dn\u00e9 opr\u00e1vn\u011bn\u00ed to perform\u00e9this action.", "data":{"status":403}}

I intentionally leave it escaped, but the message is „You do not have sufficient permissions to perform this action.“. That’s what WordPress says, it’s not a firewall. You’re too small user.

Ninja Forms has a bad solution, you have to set higher rights yourself using hook (this one for REST API, you still can’t see the data in the administration, there is another hook for that in the exmple):

add_filter( 'ninja_forms_api_allow_get_submissions', 'nf_define_permission_level', 10, 2 );

function nf_define_permission_level() {
  
  $allowed = \current_user_can("edit_posts"); // or other permisson
  
  return $allowed;
}

Don’t set the user as administrator! This then misses the point of using application passwords themselves.

After that, you should get a JSON response. First, you can see the form fields, and the submitted value inside. Converting it to other data and processing it is another chapter.

The purpose was to demonstrate the use of application passwords, so you can, of course, get various data from WooCommerce, SEO plugins and other components.