WP-CLI is a very useful set of command line commands which helps one manage the WordPress installation. Most of the “tutorials” found all over the place are simply copied and pasted WP-CLI documentation entries, giving you simply the explanation on how to use it.
We at WP-doin are going to give you the examples on a typical and common WordPress development situations where this tool is going to show it’s true potential.
We assume that you’re familiar with the command line commands and you understand them:
Say there’s a custom site created with a number of new user roles and corresponding custom privileges. By default it’s quite hard to manage roles / and the users. Obviously you could go ahead and install a plugin which facilitates user role management.
However it’s not so easy to list all of the user with the corresponding roles, right? Again you could install the plugin that hooks into the users screen and prints the associated role. Continuously following the same rule. In a nutshell it’s not always a good idea to install a number of plugins for these tasks. They will simply overload the installation with enormous amount of code. Which most of the time is not even neccessary. This might impact site load times and negatively affect its performance. Moreover it’s quite frustrating having to install the same plugin for each of our WordPress installations? Why would we even need that if we can simply move between the installations from within the command line?
Why is it handy? Instead of clicking several (hundred) times we’re s
We believe it’s much faster and easier to preview the users instead of logging onto the site, doing several clicks, installing a few plugins to simple get the result.
If you’re a busy developer you’re probably installing several sites a month or even a week, don’t you?. The common pattern goes as follows:
In our opinion this is a horrible PITA! Especially due to the fact of the enormous number of clicks.
What could we do to simplify the whole process?
Assuming that we’re using git, our process will be much simpler:
Why is the process much simpler? Because everything can be done from the command line (with some exceptions depending on your staging server setup). There’s no reason to wait for the browser to load the WordPress, there’s no reason to click through the dashboard and load all of the plugins. And finally there’s no reason to alt-tab between the command line tool for subversion and the browser. Everything can be simply done from within one place.
Say we’re using XAMPP and our sites lie somewhere within on the D:\xammp\htodcs directory.
Let’s go ahead and fire the command line.
The following couple of lines moved us to our XAMPP development directory, (lines #1 to #5). Cloned the git repository. Downloaded the latest WordPress installation / created the wp-config.php file with some test data and installed it locally. For the purpose of this tutorial we assumed the database has already been created.
Now assuming you have moved the theme and plugin files to the wp-content corresponding directories, we can enable all of them at once with a simple two liner.
And voila our local installation is up and running and we’ve saved a lot of back and forth clicks.
It’s only a tip of the iceberg and a really basic introduction to WP-CLI. In our humble opinion WP-CLI power lies in the reduced amount of alt-tabbing and back and forth clicking between the command line tool, WordPress install and the database management tool.
We at WP-doin are using custom bash scripts and VVV setup to facilitate site creation. If you’re into the scripting you can preview a sample bash script combined with the WP-CLI, which both creates a database and downloads latest WordPress install.
Welcome to the third and last part of the Gravity Forms Front End Login / Register / Edit account series.
Unlike previously the form we’re going to create will be slightly different. First we need to output some data on the form, which will use Gravity Forms dynamic population. This will be bound to the currently logged in user for which we’ll load the data.
Let’s go ahead and create it. We need the following fields:
This form will let us change the associated email address, the password (for which we’ll need to provide a valid current password – safety precaution) and change our First Name.
With all the fields filled we need to validate them before submitting the form. In our case this only applies to the old password, since all other fields need not be validate.
It’s worth nothing the comments added to the functions. We’re using a simple trick here – we’re assigning field validation to a specific form field and then comparing it’s value with a different form – which has a specific CSS class assigned to it!
Now, we need to make sure, that the fields actually list the data provided by the user. Since we’re accessing a predefined values, there are already functions for doing so. Let’s make usage of the global variable $current_user.
Welcome to the second part of the Gravity Forms Front End Login / Register / Edit account series.
In our previous tutorial we have created a simple Gravity based login form. In this tutorial we’ll cover the user registration form.
Similarly to the previous form let’s go ahead and create a form with two simple fields:
Following the pattern, we’ll need to setup two hooks:
This hook fires before the form has been submitted, but after the values have been validated.
Let’s see the code we’ve used for that part:
This hook will do the following:
Now, we can already register a new user, however the validation rules will not show up if we won’t create them! This means that the form can be submitted even if the specified data would conflict with the existing entries.
The following code will assure us that the form is validated properly:
The above hook is triggered separately for each of the form fields – this is why we need to rely on CSS class names, which we had created before.
This finishes the second part of our tutorial. The user registration is disabled for our site, hence we won’t be posting a working form this time!
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.