Uncanny Automator recipes can be initiated by users that are signed in to WordPress, users that are not logged in, or incoming data. When users are logged in, Automator knows who they are and we can always depend on user data being available. These types of recipes are called “logged-in recipes”, and because activity is tied to a WordPress account, Automator can do things like having multiple triggers in a recipe and allowing it to run a certain number of times per user.
Many recipes, however, need to run for everyone on a site. These recipes run for anonymous users, users that are signed in, even situations where there is no associated user. From Automator versions 2.0 to 3.0, we called these “Anonymous Recipes”. Beginning in 3.1, with the introduction of userless recipes, we call them “Recipes for Everyone”.
Recipes may or may not need user data
When you create a new recipe for “Everyone”, you see a list of integrations and triggers that can run for anyone on the site, even if they’re not signed in. These may be different than triggers for “Logged-in” recipes, with more options generally be available to logged in users.
Creating a recipe for everyone is the same as for logged in user, but some actions may require user data. If they do, we’ll tell you. See the screenshot below for an example.
If you choose a recipe that needs user data, Automator will automatically show you a user selector to capture it. Please note that any recipes for everyone that can create users require the Pro version of Uncanny Automator.
Introducing the User Selector
The User Selector available in Recipes for Everyone is what connects the trigger to actions on a specific user. It provides two possible functions:
- Creating a new user
- Selecting an existing user
Once the user selector has created or selected a user, the recipe’s actions then are performed on that user.
The user selector opens up some powerful workflow possibilities, such as:
- Taking a regular form (using any supported form integration including [list with links]) and converting it into a form that register a new user, then performs any number of actions on that user such as enrolling them in a LearnDash course, adding them to a BuddyPress group, emailing them a coupon code, etc.
- Receiving data via a webhook from a service like Zapier, IFTTT, Integromat, or another site running Uncanny Automator that creates a new user or modifies an existing user.
Creating a new user
Select this option if you want completion of the recipe’s trigger to create a new user on which the recipe’s actions will be performed. You’ll see a form containing the standard WordPress profile fields:
Use the token selector to populate the fields with data from the recipe’s trigger.
If you don’t see any tokens, configure a trigger that will provide data for the new user, then come back to this field and select a token.
Note: If you don’t populate the Password field, a random password will be stored and the user will need to reset their password to access the site. Use the Send an email action and include the Reset Password Link token to make this process seamless and secure.
Once you’ve added data for the required fields and any desired optional fields, some triggers for everyone will give you the option of automatically logging the new user in. (Webhooks and other triggers that are not instantiated directly by the anonymous user on your site cannot log the user in.)
Then decide what should happen if the user already exists. The two options are:
- Select existing user – Perform the recipe’s actions on the existing user.
- Do nothing – The recipe terminates and no actions are performed.
Select existing user provides an additional field that allows you to prioritize which user should be selected if two different existing users are found, one that matches the specified email and a different user that matches the specified username. Typically, this is a very rare case.
Select an existing user
Select this option if you want completion of the recipe’s trigger to select an existing user on which the recipe’s actions will be performed. You’ll see a form that lets you choose which unique field should be used to select an existing user; username or email:
Use the token selector to populate the field with data from the recipe’s trigger. If you don’t see any tokens, configure a trigger that will provide data to select an existing user, then come back to this field and select a token:
Multisite Considerations
In a multisite environment, WordPress shares user information across network sites. This means that recipes for everyone cannot create a new user on one network site if that user already exists in the multisite network.
There is a workaround, but instead of creating users, it requires updating users and adding new usermeta. This workaround is recommended for developers only.
Suppose there are 2 sites in a network, and a user exists on Site A but needs to be set up and modified on Site B (both part of the same multisite network install). On Site A, an action would send webhook data about the user to Site B. On Site B, a recipe for everyone would include a trigger to receive webhook data from Site A. Then, in an action for that recipe, a key for “wp_2_capabilities” is needed (where “2” is the blog_id of Site B) with a value of a:1:{s:10:”subscriber”;b:1;}. This assumes a subscriber role and can be modified by a developer for the appropriate context of the user that’s added. Then a “wp_2_user_level” (where “2” is again the blog_id) value of 0 is needed as a second pair for the usermeta update. See below for more details:
Actions
Once a new user has been created or an existing user selected, the recipe executes the actions on the selected user, just like a Logged-in recipe. Learn more about Managing Actions.
With great power comes great responsibility
Recipes for everyone are very powerful and enable automation of user creation and modification by anyone, without authentication. Always think about who can access the trigger if the recipe is for everyone (if it’s tied to submission of a form) and how it could be potentially misused to create or modify users on your site. Questions to ask when setting up a recipe for everyone include:
- Should anyone be able to access this form, or should only some users be allowed to perform the actions of the recipe, including creation or modification of users?
- Should the form be indexable by search engines?
- Should the page containing the form show up in the results when a user uses the search field on your website?
If you’ve set up several forms that perform different actions, consider restricting access to the forms using your membership plugin or any other plugin that limits access to pages based on your desired criteria.
