If we’re still using SFTP for transfers to some hosts, it’s likely you may be too. But you may have also heard of rsync. Let’s all sync up and go on this journey together.

FTP: It works

Combined, WebDevStudios (WDS) and Maintainn have several customers which use a wide variety of hosts. SFTP works on all hosts, so it’s easy to go with that. But having used rsync for deploys on projects over 15 years ago, I understand the benefits. Eventually, the time came to see if we can adopt using it for future clients and projects.

WDS likes WPEngine. Why not use their git push functionality? As much as I like WPEngine’s git push (it’s fantastic!), we need something that is adaptable across all of our clients.

Does my host have rsync? How does it work?

If your host supports SSH, it supports rsync.

WPEngine added SSH support in 2018, so it was just a matter of time before we switched to rsync deploys for all of our hosts. Here’s how it works:

1. rsync establishes a connection to the remote host (usually via SSH) and runs another rsync receiver process at the destination.
2. The sender and receiver processes compare what files have changed.
3. What has changed gets updated on the remote host.

Only transferring what has changed makes rsync deploys an order of magnitude faster than traditional SFTP deploys where everything is uploaded. rsync also has the ability to compress files during transfer, making it even more efficient.

Configuration

We use a continuous integration service called Buddy for our deploys. It’s awesome because the interface is super easy to use and set up, but you can use rsync with anything from Jenkins to just running the shell command on your computer to upload files. rsync requires the following arguments, but it supports many options and can grow to be quite complex:

rsync [options] src dest

We typically run rsync as:

rsync -avz --delete /path/to/local/directory/ user@host:/path/to/remote/folder/

Before getting into the options, it’s worth noting that rsync is picky about the trailing slash on the source folder. If you omit it from the src folder in the above example, rsync will make a folder called directory inside /path/to/remote/folder/. That might not be what you want. I just always add trailing slashes to both the source and destination folder paths.

The options we’re using are:

• -a Archive mode (a good combination of options to start with if you’re not an rsync master)
• -v Verbose (shows files as they’re being transferred)
• -z Zip (compress files during transfer)
• --delete Delete (delete extraneous files at the destination)

Deleting files on the destination is where you’ll want to exercise caution. It’s a necessary evil for us because if a plugin or theme file gets renamed, we want the old file to go away. To control what gets deleted and what doesn’t, we’ll use an exclude list.

Excludes

Excludes control both what will get transferred from the source, as well as what shouldn’t be messed with at the destination. When you use it in concert with --delete, you’re making sure you don’t nuke something on the server that you want to keep.

There are probably some assets that you don’t need to transfer to your host. Skipping your .git folder with your project’s revision history database will save a bunch of time. You also probably don’t want to upload any node_modules folders, but you do want to upload the vendor folders.

You for sure don’t want rsync to delete your uploads folder; that would be bad. Add an --exclude option for each thing you want to exclude. Your rsync command will start looking like:

rsync -avz --delete 
  --exclude=.git*  
  --exclude=node_modules/ 
  --exclude=/wp-content/uploads/ 
  /path/to/local/wordpress/ user@host:/path/to/remote/wordpress/

The command is starting to get long and there are probably more things you want to exclude like wp-content/upgrade, WPEngine’s mu-plugin suite, etc. Alternatively you can put your excludes in a file (one pattern per line) and reference that instead:

vi rsync-exclude.txt

.git*
node_modules/
/wp-content/uploads/
/wp-content/upgrade/
/wp-content/debug.log
/wp-content/advanced-cache.php
/wp-content/object-cache.php

Then you can reference that file with the --exclude-from option:

rsync -avz --delete --exclude-from=rsync-exclude.txt /path/to/local/wordpress/ user@host:/path/to/remote/wordpress/

Keep in mind that exclude patterns beginning with a slash (/) are at the relative root of the sync folder, not the absolute root of the host. Also, the leading slash instructs rsync to exclude something in a specific location relative to the sync folder. By omitting the slash, rsync will exclude it everywhere.

For instance, the pattern .git* will exclude all .git files and folders (including .github, .gitignore, .gitattributes) throughout the project tree. The pattern /.git/ will just exclude the .git folder in the root of your project.

Extra work, but worth it

Using rsync instead of FTP does require a little extra brain power during setup than SFTP. Always test your setup on a staging site(!) where any mistakes won’t have catastrophic effects.

When using rsync, double-check your command at least 10 times.

—Aubrey Portwood, Senior Backend Engineer

As we refine working rsync setups, we apply those refinements to our deployment template so the next project to migrate to rsync deploys has the latest and greatest. Deploys go from minutes to seconds… well worth the effort!

The post Ditch FTP and Switch to rsync appeared first on WebDevStudios.

But the compatibility landscape of WordPress 5.0 and beyond is much different. The new WordPress block editor Gutenberg is built upon React, and the development pace of React, Gutenberg, and all things JavaScript, in general, is extremely fast. I’m hoping this can serve as a reference or forewarning to those trying to keep up.

Gutenberg Versions

When you’re trying to build a Gutenberg block that is compatible back to WordPress 5.0, navigating this landscape is tricky. Since the Gutenberg editor is developed as a separate project, they have their own versions that get bundled with the major WordPress releases. Trying to find this historical information can be difficult.

After some research and discussion, Senior Backend Engineer, Sal Ferrarello, and Frontend Engineer, Mike England, started a compatibility matrix, which can be found on GitHub. But that didn’t answer all of the questions and solve all of the issues. The official Gutenberg Handbook itself is based on the latest Gutenberg code, which is ahead of the current version of WordPress. Sal opened an issue highlighting that the blocks API documentation is based off of the master branch of Gutenberg.

Block API Reference

Sadly, Sal’s documentation version issue wound up being closed citing:

We’re fixing bugs more than we’re introducing new APIs at this point.

But shortly after the version matrix was created and the version issue filed, a new page showed up in the block editor handbook highlighting the version information:

Versions in WordPress

Still, this “official” table can be a bit confusing. When you look at it, there is a range of Gutenberg versions included in a particular WordPress release:

This is because bug fixes are back-ported into the WordPress release bundle. If you’re using it for an API reference standpoint, always go with the smaller release number.

React Versions

There are several things to think about if you want to provide backwards compatibility to WordPress 5.0. One consideration is the React version included in WordPress.

If you want to create Functional Components instead of Class Components in your Gutenberg block, that requires React version 16.8. WordPress 5.2 is when React 16.8 was included. The easiest way I found to determine which versions of WordPress include which versions of React is to go to the source.

You can find the package.json for WordPress 5.2 here. This includes React 16.8.4. You can replace “5.2” with the version you’d like to investigate.

If you’ve written functional components for distribution in the WordPress.org plugin repository, don’t forget to add the “Requires at least” field to your plugin header:

/**
 * Plugin Name:       My Plugin
 * Requires at least: 5.2
 */

That way, people will not be able to upgrade/install your plugin automatically, unless they’re on WordPress 5.2 or newer.

Block Compatibility

My best advice is to tread lightly and go slowly. React and Gutenberg aren’t great at reporting where your errors are through the browser console. To start, I install the WP-Downgrade plugin so I can easily go back and forth between past and present versions.

If you’ve got something working, test it out and commit your changes. Then, test it for backwards compatibility. When you’re dealing with more than one compatibility error at a time, it’s difficult to hone in on what is going wrong. WordPress might not even load your Guten-block code if there are errors; and it also may not print a message in the console.

The most common issue I’ve encountered is with importing WordPress components. Sometimes things work by importing from a package. Sometimes they’ll only work by destructuring from the global wp object.

WordPress Gutenberg import versus Destructuring Global wp

You may have to experiment with both to see what works for maximum version compatibility.

Example: ServerSideRender

@wordpress/server-side-render

The documentation says once you include it in your package.json you can either import it:

import ServerSideRender from '@wordpress/server-side-render';

Or destructure it from the wp global:

const { serverSideRender: ServerSideRender } = wp;

But neither of those work in WordPress 5.0 (Gutenberg 4.6.1) because @wordpress/server-side-render wasn’t a package yet. It also isn’t at wp.serverSideRender at that time, it’s at wp.components.ServerSideRender.

If you want it to work in WordPress 5.0, you’ll need to destructure it from the wp global like this:

const { ServerSideRender } = wp.components;

In new versions of WordPress, you’ll get this warning message in the console:

wp.components.ServerSideRender is deprecated. Please use wp.serverSideRender instead.

The user may never see that, and it sure beats them seeing this in the editor:

Deprecation Hunting

Other popular components that have moved since WordPress 5.0 are BlockControls and InspectorControls. I’ve got them working in 5.0 with the following browser warnings:

wp.editor.BlockControls is deprecated. Please use wp.blockEditor.BlockControls instead.

wp.editor.InspectorControls is deprecated. Please use wp.blockEditor.InspectorControls instead.

But how did I find them? Going to the source is always best. Clone the Gutenberg project and check out the tag for the most recent version of WordPress:

git clone git@github.com:WordPress/gutenberg.git
cd gutenberg
git checkout v8.6.0

You can browse the tags on GitHub or list them with git tag. After checking out the tagged version, start looking for the component that’s not working. For InspectorControls I used grep to find it:

$ grep -r InspectorControls .
...
packages/editor/src/components/deprecated.js: 'InspectorControls'
...

There’s a lot of output when searching, but the path of the deprecated.js file gave me a clue: packages/editor. It used to be in wp.editor and is now in wp.blockEditor (which has the path packages/block-editor). Again, the documentation isn’t great, so you have to do some sleuthing and gather context clues.

Good luck out there, and always keep compatibility in mind!

The post WordPress Blocks Backwards Compatibility appeared first on WebDevStudios.

NPM	Composer
npm install (libraries go in node_modules, executables in node_modules/.bin)	composer install (libraries go in vendor, executables in vendor/bin)
npm install --production	composer install --no-dev
npm install --package-lock-only	composer update --lock
npm install <package>	composer require <package>
npm install <package> --save-dev	composer require --dev <package>
npm install -g <package>	composer global require <package>
npm update	composer update
npm update <package>	composer update <package>
npm outdated	composer outdated
npm run <script-name>	composer run-script <script-name>

The Complete Picture

As developers, we’re used to saying, “It works on my machine.” A decade ago, this phrase was reserved for snarky conversations with your friendly quality assurance person or the product owner who is testing a feature.

As our technology tooling has become more advanced (read: more complex), I’ve seen it come up as inter-developer conversation, frequently between a frontend and backend engineers:

Composer and Node package manager (npm) are the de-facto package managers for PHP and JavaScript. We use them every day at WebDevStudios. Let’s help each other get to know their similarities and their differences, as both tools can do unexpected things that you may not realize.

Init

While initializing a project isn’t the most common command, it’s useful to cover it first; in case you want to try to initialize a Composer or npm project in an empty directory.

$ composer init

Composer will interactively ask you some questions about your PHP project including: package name, description, package type, etc. Newer versions of Composer will prompt you to add the vendor directory to your .gitignore file. You should do this!

You can also just create your own composer.json file. Here’s an example minimal composer.json:

{
    "name": "webdevstudios/composer-vs-npm",
    "description": "php side of composer-vs-npm",
    "license": "GPL-3.0-or-later"
}

npm has the same command:

$ npm init

It will also interactively ask you a few questions about your JavaScript project including: package name, description, license, etc. After gathering this info, it will create a package.json file.

You can instead create a package.json file yourself. A minimal package.json is just {}, but npm will warn you if you don’t have these fields:

{
  "name": "@webdevstudios/composer-vs-npm",
  "description": "js side of composer-vs-npm",
  "license": "GPL-3.0-or-later",
  "repository": "https://github.com/WebDevStudios/composer-vs-npm"  
}

Init Best Practices

For the npm package name, it’s a good idea to add a scope using the @ symbol, your organization name, and a slash before the package name. While it’s not required like Composer’s vendor name, it will help group your packages together.

npm does not offer to create an entry in .gitignore for the node_modules directory, but you should.

You can validate your composer.json file format by running:

$ composer validate

I recommend not including version in your composer.json. It’s just one more thing that developers will forget or ignore. Let your version numbers be managed through tagging in your version control software.

npm requires a version entry in package.json only if you’re publishing your package. If you’re publishing your package, make sure keeping this up to date is part of your workflow. Otherwise, I suggest to omit it.

Both Composer and npm use the same license strings. A license entry is not strictly required, but both will print a warning, if you don’t include it.

Saving Dependencies

I’m getting a little ahead of myself because we’re going to talk about npm install before the Install section below, but just bear with me. In Composer land, telling it that your project relies on a library is done by requiring it.

$ composer require <vendor>/<name>

This will instruct Composer to add an entry to the require section of your composer.json file, install the package (usually in a vendor directory), and create and/or update a composer.lock file with info about the version it installed.

npm does the same thing, but with their install command:

$ npm install <package>

This will instruct npm to add an entry to the dependencies section of your package.json file, install the package (in a node_modulesdirectory), and create and/or update a package-lock.json file with info about the version it installed.

Saving Options

You may have PHP or JavaScript dependencies that are only needed for development, and aren’t needed to use your project when it’s deployed. You can specify that those packages are installed as development dependencies:

$ composer require --dev <vendor>/<name>

$ npm install <name> --save-dev

Both Composer and npm can require specific versions of a package:

$ composer require <vendor>/<name>:<version>

$ npm install <name>@<version>

If you omit the version number, they’ll both specify the latest stable version with a carat (^) pre-pended. If you require lodash via npm, it will specify "lodash": "^4.17.20" in your package.json file. This means if you were to tell npm to update Lodash, it would upgrade to newer versions up to the next major version—5.0.0. If you ever get unexpected results from version numbers, you can use these excellent semantic versioning (semver) tools to test:

• Composer
• npm

Install

As the “Dad Joke Dog” meme explains above, the most common command to run is install.

$ composer install

Running this in a folder that has a composer.json file will instruct composer to read that file (along with composer.lock if present) and install any requirements specified.

If the composer.lock file is present, it will install the exact versions specified by that file, even if a newer version exists. If there’s no composer.lock file, composer will install the latest packages according to the version constraints in composer.json and create a composer.lock file with those versions.

Usually packages will go into a vendor directory, next to the composer.json file.

$ npm install

Running this in a folder that has a package.json file will instruct npm to read that file (along with package-lock.json if present) and install any requirements specified.

If the package-lock.json file is present, npm (similarly) will install the exact versions specified by that file, even if a newer version exists. If there’s no package-lock.json file, npm will install the latest packages according to the version constraints in package.json and create a package-lock.json file with the exact versions.

Installing without development dependencies

To install packages without the development dependencies, like you would for a production environment, run either of these commands:

$ composer install --no-dev

$ npm install --production

This will skip installing require-dev or devDependencies for Composer or npm (respectively).

Update

This is one of those sections where I like to ask:

Are you sure you want to do this?

$ composer update

$ npm update

I like to ask are you sure because when you don’t supply any arguments to update, Composer and npm have the potential to make a lot of changes that you may not have intended. Both will use the version constraints to update your specified dependencies (including dev dependencies) and it will update the child dependencies of the packages, too. So, if your version constraints are fairly “loose,” a lot of stuff is going to get updated, possibly some things you didn’t intend.

A more focused approach would be to upgrade one specific package, not all of them. Like this:

$ composer update composer/installers

$ npm update lodash

If you’re curious what is out of date, and what would be updated if you ran the update command without any arguments, you can run an outdated report instead:

$ composer outdated

$ npm outdated

Other useful commands

If you change something in your composer.json file that is unrelated to the version constraints—like reordering the required packages—Composer will complain that your composer.lock file is not up to date. To update just the content-hash part of the composer.lock file without updating any package versions, run:

$ composer update --lock

You can do the same thing with npm:

$ npm install --package-lock-only

Conclusion

As you can see, there are several commands that do the same thing and look the same in both Composer and npm. However, there are also commands that do the same thing but look very different.

It’s good to make sure you know what that command is going to do before you do it, so you don’t have to undo things you didn’t want to happen.

Are there any other commands you use often that I missed? Let us know in the comments.

The post Let’s Get Ready to Rumble! Composer vs npm appeared first on WebDevStudios.

One of the more recent issues was compatibility of the Select2 JavaScript library versions. It was mostly because two other popular plugins, Yoast’s WordPress SEO and WooCommerce, also use Select2. What is Select2? It’s the kick-ass library that lets you transform boring dropdowns to amazing searchable and formattable ones:

So what’s the big deal with ACF? Well, Select2 has gone through some major revisions as well, most notably the latest Select2 Version 4, which is not backwards compatible with Select2 version 3.x. So, if ACF brings in Version 4 and WooCommerce brings in Version 3, we’ve got problems.

Thankfully, ACF came up with an elegant way to deal with these incompatibilities by checking to see if another plugin had enqueued Version 3 and falling back to using a Select2 Version 3 adapter.

View the code on Gist.

Future-proof it or just fix it?

So, what does this have to do with custom ACF fields? Well, in my case there was an old custom-built ACF field that used Select2. To add the Select2 library to the dropdown, it used a JavaScript call to acf.add_select2() to add it. If you notice in the gist above, acf.newSelect2() was added in ACF 5.6.5, and it replaces acf.add_select2(). In the future, how can we avoid running into this problem? In practice, there are two options:

1. Extend an existing ACF field that is close to what you want to do.
2. Create a new (or updating an existing) custom field and use ACF to add Select2.

Your first option is the best one. Here’s why: it simplifies your code investment by leveraging as much as possible from ACF. But, I’m also including the quick-fix instructions specific to the Select2. That way, if you have an existing field that you just need to get working for the time being, you can do that as well.

Option 1: Simplify by extension

One of the fields I needed to fix that used acf.add_select2() was strikingly similar to an existing ACF field—the relational field called Taxonomy. The built-in ACF Taxonomy field also uses Select2. The only difference between the custom field that needed repair and the built-in one is that the custom field would display terms from multiple categories, instead of just one. I had an a-ha moment on a call with Corey Collins when he suggested aloud to let ACF handle the hard work and to just tweak what I needed. Brilliant idea, Corey!

The custom field used to look like this:

View the code on Gist.

Because the AcfFieldMultipleCategories class was essentially a copy of class-acf-field-taxonomy.php, it was almost 600 lines of code.

Instead of extending acf_field, I was able to instead extend acf_field_taxonomy and reduce the PHP code by half and get rid of the custom JavaScript entirely.

View the code on Gist.

What’s different?

Here’s a brief breakdown of the things that are different in the AcfFieldMultipleCategories class and why. You can compare much of the code above to what’s in class-acf-field-taxonomy.php for reference.

1. The class doesn’t get defined until init. This is because ACF doesn’t load the parent acf_field_taxonomy class right away.
2. Using initialize instead of __construct: ACF 5.6.0 switched to using initialize instead of __construct so I wanted to follow suit. Our class calls parent::initialize() to get all of the defaults from the taxonomy field, then sets only the fields we want to override.
3. AJAX actions for wp_acf: These actions are present on the parent, but when they’re registered, they reference a specific instance of an object—the parent acf_field_taxonomy class. We redefine them here to get called on our AcfFieldMultipleCategories instance.
4. Extra CSS classes in wrapper_attributes: We need our custom field to be rendered with a CSS class of acf-field-taxonomy. This is what the ACF Select2 library is looking for to attach to fields. Select2 will behave exactly how it would on a taxonomy field; we’re just changing the query that happens on the back end.
5. get_ajax_query has been overridden: It gets called from the parent ajax_query method. We override this to get a result set of terms from multiple taxonomies.
6. load_value has been overridden and simplified to remove filtering.
7. render_field has been overridden and simplified to only render a select field because that’s the only option we’re allowing.
8. render_field_select has been overridden to call a custom get_term_by_id function.
9. render_field_settings has been overridden to remove the Appearance setting (remember we only want it to display a dropdown). We also removed the Create Terms option, as we won’t be saving any new terms because they’re coming from multiple taxonomies.

Is it a lot? Sure, but it’s far less duplication than before and through simplification, making it less prone to bugs and errors. But if that’s still too much, can you take the easy way out…

Option 2: Just update Select2 calls

This option is an easier short-term solution but may postpone further compatibility issues. Just switch any calls from add_select2 to newSelect2. Any parameters to that function that were previously in snake_case need to be changed to camelCase. Here’s a diff of one that I updated:

-		acf.add_select2( $select, {
+		acf.newSelect2( $select, {
 			ajax: 1,
- 			ajax_action: "acf/fields/post_object/query",
- 			allow_null: 0,
+			ajaxAction: "acf/fields/post_object/query",
+			allowNull: 0,

That’s it. I chose this option for a different and far more complex custom ACF field. It had four inputs in one field, which is nothing like any built-in fields. This one is just going to stay as-is and will try to follow the ACF JavaScript conventions.

Getting Permission

When possible, I prefer the first method of doing things because it’s a better long term solution. You can do Option 2 in less than an hour and then still have time left over to convince your manager that Option 1 is better for the long term. Get some time scheduled to fix it the right way, and it’s a win-win for you and your project.

The post Creating, Extending, and Upgrading Custom ACF Fields That Use Select2 appeared first on WebDevStudios.

Content

This is what is going to get you onto the WordCamp roster. Whatever your topic, I urge you to consider the audience.

Picking a Topic

First of all, do not discount beginner talks because you’ve heard them before or you think no one is interested in them. Let me tell you about WordCamp Minneapolis 2013.

As organizers, we put a beginner talk in the smallest room because we made the same assumption—that it wouldn’t be a popular talk. We were wrong. The audience was so large that people were standing in the back of the room and overflowed through the doorway into the hall. Beginner talks are often the best, as there are always newcomers, and you’ll likely bring a fresh perspective to the subject as the presenter.

Besides the skill level of your presentation, think about who it is aimed toward: business owners or users, developers or designers, sales directors or SEO experts. Broad topics can be compelling, and the ones I’ve found the most interesting ask hard-hitting questions like, “So you’ve captured thirty percent-plus of the web; now what are you going to do?”

If you can ask deep questions and make a broad topic to appeal to a wide audience, that’s great. But, don’t make your talk so broad that it is uninteresting. Remember that your talk will occur simultaneously as someone else’s talk. People will be deciding on whether to go to your presentation or the other. It’s better to capture the smaller audience that is genuinely interested.

You can accomplish this by giving a very specific talk that addresses a very specific problem. Hopefully, it’s something you’ve experienced and solved yourself. That particular thing may have not (yet) been a challenge to an attendee, but they will likely still attend your talk because they want to know how to solve complex problems and genuinely be prepared for what lies ahead in their WordPress journey.

Peer Review

A great way to get feedback before giving your presentation is to have a peer review your slides, speaking notes, outlines, and any other materials you’ve put together.

If you’re doing a presentation on security, I would consider peer review a must.

The security world is full of best practices but also littered with questionable advice and security-by-obscurity tricks that won’t fool actual hackers. We don’t want to spread any misinformation. The fact that you’ll be speaking at a conference will make you the expert in that moment; so let’s get the facts right.

Otherwise, peer review is not necessary, but still extremely helpful. If you know someone in your area that has spoken at your local WordCamp, ask them to do a peer review. More likely, they’ll be flattered, not annoyed, that you consider them the expert. Flattery is a powerful weapon.

Submission

Once you’ve got your ducks in a row, it’s time to submit your talk. If you’ve just got an idea, you can simply submit it, but with this being your first talk, I suggest you be slightly more measured and prepared. There are a lot of WordCamps out there, and they’re not going away anytime soon.

Usually, you’ll just have to provide an overview, called an abstract, as part of the speaker submission. You’ll also likely have to submit a bio. Don’t be afraid to talk up your experience! In some instances, you might be asked about your speaking history. Thankfully, you’ll be able to put your local WordPress Meetup speaking experience here (more on that in the next section), even if it’s your first WordCamp talk.

Presentation

Once your talk is accepted… and it will be accepted. Do you know why? Because you’re not going to submit it to one WordCamp and let any rejection get you down.

You’re going to submit it to several WordCamps until it gets accepted.

Delivery

Let’s try this again…

Once your talk is accepted, the presentation is where the rubber meets the road. What makes a WordCamp talk great is how it’s delivered.

• Animate your voice. Use inflection. Don’t be monotone. If you’re speaking in a monotone voice, it will sound like you don’t care about the subject. If you don’t care about the subject, why should the audience care about it?
• Don’t read directly off of the slides. The slides are there to act as a hook to capture the audience. You can (and should) use them as a reference point, the same as your audience. It should convey the main idea of what you’re currently talking about, without spelling everything out word-for-word.

One exception to the don’t-read-off-of-the-slides rule is if you’ve got a quote you really want to share. If you do this, read it with the emphasis that you would want to hear, so it makes the same impression on your audience as it initially did on you.

Practice

The best way to get comfortable with your talk is to practice it. Give the talk to a friend or your family. Give it to them especially if they don’t have first-hand knowledge with the subject. They’ll just critique you on your delivery.

Then give the talk at your local WordPress Meetup (this is what I was referring to above under Submission). There are literally hundreds of WordPress Meetups across the nation and the world. They’re hungry for new speakers like you. Once you’ve polished up your delivery with friends and family, these are the people that are going to ask the tough and interesting questions about your content. They may ask or comment on something you hadn’t thought of. Revise and incorporate that feedback into your presentation.

Just Do It!

Often the biggest hurdle to even submitting a WordCamp talk is self doubt, impostor syndrome, and fear of the unknown. I want to tell you that the reason I love the WordPress community is because it is very welcoming. While we all share the love of WordPress, we all have different experiences. Your journey brings a different perspective and a different voice. Don’t be afraid to share your story. People want to hear about it.

The post Speaking at Your First WordCamp? Here’s What You Need to Know! appeared first on WebDevStudios.

What is it?

In the simplest terms, Single Sign-On is a way for someone to access multiple websites using one set of username and password credentials.

The WDS-specific implementation uses Google authentication, primarily because we use the Google apps suite for our work tools. But WDS-SSO can easily support any standard OAuth service. Here’s a list of features we built into our SSO solution:

• Google Auth support (including Two-Factor Authentication)
• Client/Proxy configuration makes setup a one-time task
• Enforces all sites involved to use HTTPS
• Uses industry standard JavaScript Web Tokens (JWT)
• Multisite support
• Selective role maps (including Super Admin) for individuals and/or sites
• Support for selective (multiple) domain authentication
• Optional SSO user removal feature on deactivation
• Extensible to work with any standard OAuth implementation

Why is it important?

At WDS we build a lot of websites. Currently there are almost 30 projects being worked on concurrently. When you consider that each site will have at least one staging site for quality assurance and client approval, it’s more than double that number.

What happens if a team member leaves WDS? Do we have to go through dozens of sites to track down their accounts and deactivate them? We used to do that. Now, most access is handled through their Google account. Deactivate that and they can no longer log into any site that uses Google authentication—including all of our SSO-enabled sites.

Not only do managers love this feature, it’s ultimately easier for everyone who uses it. Instead of entering a username and password for every site and clicking the blue Log In button, you just click the big orange WebDevStudios Login button.

How it works

Here is a flow diagram of how our SSO plugin suite works. Each circle represents a different site involved in the process. By splitting the responsibility up between a client and proxy site, only the proxy site needs to talk to Google—and it’s the only site that needs any API configuration. Client plugin installation is very simple.

As a user, it’s all very seamless. If you’re already authenticated with Google, it’s simple. Just click the big orange button:

If you’re not authenticated with Google, the process looks like this:

Part of the process you didn’t see (off-screen) was the Two-Factor Authentication piece, which is required per our security policy. I used my fingerprint and the Gmail app to double-check that it is indeed me.

Other security concerns that we address is the inter-site communication. If one of the sites (client, proxy, or Google) isn’t using HTTPS, there’s a chance for a man-in-the-middle attack where the token could be intercepted and altered, leaving the attacker to possibly pose as an authenticated user. WDS-SSO requires that all sites involved use HTTPS for this reason.

How our clients benefit

There are several benefits for our clients. It makes it easy for the right people—active WDS employees—to have the appropriate access to their development sites without having to bother the client.

As a policy, when it’s time to go live, we remove the WDS-SSO plugin. Upon deactivation, there’s an option to remove WDS-SSO users and reassign any content produced by them. What this does is remove WDS developer accounts and re-attribute their created content to the client. That way, a year down the road, a client isn’t wondering who this “Justin Foell” guy is and, “Why does he have access to my website?”

It’s a win-win for both WDS and our clients.

The post WDS Single Sign-On appeared first on WebDevStudios.

There are a couple of links in the documentation to the templating used with custom fields, but no start-to-finish example. Let’s do one here so you can start creating your own custom fields.

Setup

For this example, I created a plugin with a Beaver Builder module called “Post Category List” to show a list of posts that are in the selected categories. The plugin is very simple—only the minimum amount of components are needed to create a Beaver Builder module:

1. A module class that extends FLBuilderModule
2. A module registration call – FLBuilder::register_module()
3. A frontend.php template used for rendering

I purposely kept it as simple as possible. There’s no extra styling or JavaScript. I don’t go into detail about creating a custom module because the Beaver Builder documentation does it nicely. However, all code is provided for your review at https://github.com/WebDevStudios/wds-bb-custom-field.

Adding a Custom Field

When looking at the Beaver Builder documentation for field types, there’s no option for a “checkbox” field, and I wanted something similar to the category selection box seen when you’re editing a post:

This is where we need a custom field. Since the documentation isn’t super helpful in this regard, it’s time to use the tried-and-true method of reading the source code 

Registering a Custom Field

There are two components to a Beaver Builder custom field:

• A PHP file with the field markup & code.
• Field registration through the fl_builder_custom_fields hook

To start, you can make your custom field file as simple as possible, like this one from the Beaver Builder documentation:

View the code on Gist.

To register the field, use the fl_builder_custom_fields filter to add a field slug and the path to the field file to the list of Beaver Builder fields (line 50).

View the code on Gist.

Then in your module registration, you can use the newly registered field type in your module definition (line 90).

View the code on Gist.

With those pieces in place we can now do the work to customize our field.

Beaver Builder Field Examples

This is where snooping in the Beaver Builder plugin helped me connect the dots. In the Beaver Builder code, the best examples I could find are the ‘select’ and ‘post-type’ field types. You can find them at bb-plugin/includes/ui-field-select.php and bb-plugin/includes/ui-field-post-type.php. Here is the source code from the shorter ‘post-type’ field as an example:

<select name="{{data.name}}"<# if ( data.field.className ) { #> {{data.field.className}}<# } #>>
    <?php foreach ( FLBuilderLoop::post_types() as $slug => $type ) : ?>
    <option value="<?php echo $slug; ?>"<# if ( data.value === '<?php echo $slug; ?>' ) { #> selected="selected"<# } #>><?php echo $type->labels->name; ?></option>
    <?php endforeach; ?>
</select>

Beaver Builder fields are truly mixed-mode files. They contain HTML markup. They are run through the PHP processor to replace the <?php ?> code. And then anything within <# #> gets executed as JavaScript (JS) in the browser. Also replacements are made in JS where the Mustache style {{ }} tags are found.

Debugging Custom Fields

Keeping track of how all of these things interact can be confusing. For the PHP code, the answer is xdebug. For the JS, it’s not that simple. Normally I would visit the page in Chrome, open the Developer Tools, go find the JS file in the Sources tab, and set a break point to debug it. But the JS between <# #> is in-line and isn’t seen as traditional JavaScript because it’s getting executed through a JS eval() statement.

The solution I found was to insert a debugger; statement inside the inline <# #> JS code (line 15).

View the code on Gist.

You’ll have to uncomment debugger; in the example code to see it in action. Also the Developer Tools must be open prior to loading the page for execution to pause.

Once it’s paused you can make sure the markup generated by PHP looks good and that the JS is going to do the right thing. In this case, I set up a variable called checked which should add the checked="checked" attribute if this category is indeed checked. The checked var gets replaced in the checkbox input through the {{checked}} tag.

Whew! That’s a lot of checks!

Here’s what it looks like when you’re stepping through it in the debugger to make sure everything is working:

Ship It

Once you’ve confirmed everything is interacting the way you want it to, you’ll have a custom Beaver Builder field type to use on your project!

The saving of the checked values is handled by Beaver Builder and are now available for you to use in your frontend.php template. Check out our example code to see how we built a simple loop limited to those categories to build a list. Hopefully this helps you if you’re looking to take your Beaver Builder sites to the next level.

The post Beaver Builder Custom Fields appeared first on WebDevStudios.

If you’ve found your website in a funk, are considering revamping it, or are redoubling your efforts to produce content, here are some things to think about as the person in charge of your WordPress website.

1. Roles

This isn’t so much an issue of actual WordPress user roles and permissions, as it is about staff and resources. As a WordPress website owner, there are actually several roles and responsibilities you need to keep in mind. If you’re a superstar, you might be able to do them all yourself. However, if you’re planning on hiring someone to do all the things listed below (and do them well), expect to pay them handsomely.

A better approach would be to split the workload amongst people you trust, who are good at particular pieces of your website pie. Maybe even keep a couple experts on standby for the occasional heavy lifting.

2. Content Management

In the WordPress world, and the world at large, content is king. You should have a standard approach in format (how you write), messaging (what you write), and schedule (when you write). This way, your publications are clear and consistent.

Formatting (Style Guide)

Do you have a style guide and best practices established for your site? Smart companies are starting with the web and working from there. Using web friendly fonts and establishing logotypes with variations is a smart idea. You can ensure they work well on mobile, desktop, tablet, and even print and packaging. This will establish a consistent look and feel across all mediums.

Messaging

Then there are the words themselves. Are your writers following the same guidelines so their published content is consistent no matter who the author is? If it’s just you, you can write in whatever style you want, but remember that your voice establishes the tone of your company and your brand. Different authors write differently. Newspapers have long known this. Don’t be so quick to think that removing the author attribution from your WordPress theme is a solution—people like to know who wrote what they’re reading.

Schedule

How often are you going to publish content? “I’ll publish when I have something to say,” might be your approach, but that is not good enough. For your website to have a lasting impact, you’ll want to establish a schedule and stick to it. There’s room for experimentation in here, but having a plan is the foundation. If you start publishing daily articles, do you have a plan for when the idea well runs dry?

3. Measure Results

You’ve invested a lot in your website. The best way to leverage it to its fullest is to measure and track your results. Here’s what you should be measuring and considering:

• Your SEO rankings
• Your competitors and their SEO rankings
• Social media efforts (Are you effectively moving followers from your social media feeds back to your website?)
• Email marketing efforts (Are emails being opened? Are readers clicking and heading to your website?)
• Using analytics to the fullest (Don’t just look at visitor numbers. Use an analytics tool to pinpoint any areas on your site that are disrupting the user experience and fix them.)

4. Website Maintenance

Software moves fast. It is never a set-it-and-forget-it type of situation. Besides features and bug fixes, keeping your WordPress software updated is paramount to security.

When updates to WordPress or your plugins and themes are available, do you hit the update button then hope and pray, or do you have a plan? Do you have the ability to roll back the code (and data) if the changes break something? Do you have a staging site where you can run the updates first and see if anything is broken before doing it for all of your visitors? Do you have time to do all of this yourself? Do you need to hire a professional to maintain your WordPress website for you?

5. Website Support

There are lots of things that could go wrong here, lots of pieces to the web puzzle. First, there’s your domain name provider. Are you keeping up with the registration? When is your next renewal payment due? There’s no greater headache than losing your domain name.

You also have to stay on top of your hosting service. Did you make the right choice? Can your host handle your web traffic? When you have an issue, do they provide reliable support and solutions?

You may also have to retain a contract with someone to do maintenance and maybe keep an agency at arm’s length for development needs. There are several reasons why your website could break or go down, including internet outages,  expired DNS or secure certificates, and host-level upgrades to the operating system, PHP or the web server. It’s a good idea that every WordPress website owner has someone they trust on standby for when things go wrong.

Who you gonna call?

Here at WebDevStudios, we specialize in design & development—whether you’re starting from scratch or need a fresh new look. For updates and security, our WordPress support and maintenance division, Maintainn, partners with top-tier hosting companies for rock-solid performance. The company also keeps your site up to date and secure. We even have a website design studio established to cater to small businesses with smaller budgets.

However you decide to build a team, whether it’s you alone, a support staff you create, or a group of various companies that you hire, make sure that as the WordPress website owner you’re always proactive and not reactive. Have the right people in the right places where they can succeed and help your site (and your business) flourish.

The post 5 Things to Think About as a WordPress Website Owner appeared first on WebDevStudios.

Five for the Future (5FTF)—an ideal that WordPress companies should give 5% of their time back to the WordPress community.

When I joined WebDevStudios (WDS) in April of 2017, I considered the company’s ongoing participation in 5FTF a fringe benefit. I was even more excited when I learned that much of this contribution takes place during regular business hours. See, one of the core tenants of WDS is that we work “bankers hours,” meaning that evenings and weekends are for employees and their families. (Did I tell you WDS is awesome?) So by allowing the team to devote work hours to 5FTF, not only is WDS encouraging employees to give back, but the company is essentially donating its own resources to 5FTF, too.

After a year, I can say that Five for the Future is just another part of our values and company culture, which make it great to work at WDS. It’s a fringe benefit that is also a retainer.

Throughout 2017, I used most of my 5FTF time to support and improve the WP-Strava plugin I helped author, along with a few other developers. My words here are specifically applicable to that plugin, and free WordPress plugins in general, but they can really be applied to whatever you decide to pay it forward via 5FTF.

Giving back

5FTF is a time for giving. You give back to the community by using your skills and applying them to something you love—something of your choosing.

It can feel like time off because you’re not serving clients. Yes, free support requests are like clients, but it’s on your terms. This is a project you love, remember? On this day you can pick and choose whatever feature requests you like best, and turn them into reality. My favorite part is you can set realistic boundaries with your support commitment because you know when your next 5FTF day is. (Keep up with WDS’ Five for the Future contributions by following #5FTF on Twitter.)

Scheduling

There have been various iterations of 5FTF scheduling at WDS, from the entire company donating the day to the cause to teams that staggered their contributions on various days throughout the month. My coworker, Russell Aaron, talks about the various iterations of 5FTF scheduling WDS tried on this episode of WP Watercooler:

Whether you stagger in teams or participate simultaneously as a company, dedicating an entire work day, rather than the more nebulous “5% whenever you want” is a great regimen. It makes the time feel more substantial. You can take a deeper dive and get more done.

For the greater good

Why am I so head-over-heels about 5FTF? From the outside, it may seem rather self-serving, especially when I pour my time into my plugin. You might ask, “How is that giving back?”

Strava, being a fitness tracker of sorts, is for the greater good. It’s for my health and yours. Can we brag a little or compete along the way? Absolutely. If that competition drives you to do more, it’s a win-win.

Progress

Before I started at WDS, the last update to the plugin made by me was December 10th, 2014. The last one from our team was February 25th, 2015. I am embarrassed looking at these stats. For a couple months, the plugin languished into the dreaded “this plugin hasn’t been updated in over two years” funk.

I was able to release a new version, care of 5FTF, on May 10th, 2017, just a month after starting at WDS. Here’s what the release schedule looked like:

• 1.0 – December 10th, 2014
• 1.1 – May 10th, 2017
• 1.1.1 – May 26th, 2017
• 1.2.0 – December 8th, 2017
• 1.3.0 – December 26th, 2017

Some were minor releases; some were big feature additions. But it’s progress. Movement is being made, bugs are being fixed, and features are being added. I made 300% more releases in 2017 than I did in the previous three years. Now, that’s some statistical results to put in your pocket!

Do your best

When Five for the Future day comes around, put eight of your best hours into something. Do quick/small releases if you can. It makes users happy to see progress, and it will bring a greater sense of accomplishment. Most of all, know that because you’re committed to 5FTF, you can return to your project in a few weeks and make it even better.

The post What Five for the Future Means to Me appeared first on WebDevStudios.

We are saying goodbye to an old friend: the .dev top-level domain.

Feel free to let that one play while you read on…

What has changed? Well, to start Google bought the .dev top-level domain (TLD). Chrome 63 is the first release that forces HTTPS on .dev domains. So when you go to http://mysite.dev in Chrome 63 and get redirected to https://mysite.dev without any interaction with the server, you’ll know why.

In actuality, you can still use .dev in Chrome, but you need to enable HTTPS for it. You may also need to address any mixed-content errors—trying to load assets like CSS or JavaScript over HTTP when the site is HTTPS. These are good practices anyway, but you may not have planned on fixing that today.

If you’re working on a site that is specifically not HTTPS in production, you want to test as HTTP to make sure everything is 100%.

If you just want to get things done today, close Chrome and use Firefox, Safari, Opera or even Internet Explorer until you can change the top-level domain away from .dev.

Alternatives

Unbeknownst to all of the clever developers using .dev for development, the friendly folks over at the Internet Society hashed this out almost 20 years ago:

   To safely satisfy these needs, four domain names are reserved as
   listed and described below.

                   .test
                .example
                .invalid
              .localhost

      ".test" is recommended for use in testing of current or new DNS
      related code.

      ".example" is recommended for use in documentation or as examples.

      ".invalid" is intended for use in online construction of domain
      names that are sure to be invalid and which it is obvious at a
      glance are invalid.

      The ".localhost" TLD has traditionally been statically defined in
      host DNS implementations as having an A record pointing to the
      loop back IP address and is reserved for such use.  Any other use
      would conflict with widely deployed code which assumes this use.

Others have considered using some alternates in the face of the disruption Chrome 63 caused:

Since Google royally screwed us by snatching up .dev, let me propose a few other relevant local TLD options:

— (@JJJ) December 7, 2017

At WebDevStudios, we did a simple poll of the recommended IETF names and wound up with .test (mostly because it’s the shortest to type).

Why Standardize?

There are several reasons to standardize. When working with teams, configuration data is shared. It’s much easier to be able to transfer database data without reconfiguration.

Also, when working on client sites, if you have licensed software from Gravity Forms, Easy Digital Downloads, etc. their license/activation is based on a domain. If you standardize, only one development domain is used per project.

It’s really not a big deal to switch it up. Things will be okay. We promise. You don’t have to switch all of your development sites at once. Just switch them as needed. After you’re done, you might be asking why you didn’t start using .test back in 1999.

The post Google Chrome 63: Goodbye .dev, Hello .test appeared first on WebDevStudios.