However, with this convenience comes a paradox of choice. There is often too much information to choose from.

When you want to learn about a particular web development topic, you may wonder which path to take. Should you read a blog post about it or dive into the developer documentation? In this blog post, we’ll explore the differences between the two and help you decide which one to choose.

Web Development Blog Post vs. Developer Documentation

First, let’s define what we mean by a blog post and developer documentation. A blog post is an informal article written in a conversational tone that aims to educate, entertain or inform readers about a particular topic. It is usually written by an individual or a group of individuals and may offer a unique perspective or point of view on a topic.

Web developer documentation, on the other hand, is a technical document that provides detailed information about a product or service. It’s usually written by the product creators or developers and is intended to help users understand how to use the product or service effectively.

So, when should you read a blog post versus the developer documentation? Well, it depends on your goal and the information you need.

When to Read a Blog Post

If you are looking for insights or best practices from WordPress development experts who have used the product or service, blog posts can be a valuable resource. Blog posts are usually written by professionals who have hands-on experience with the technology and can provide real-world examples and advice on how to use it effectively.

Also, blog posts are ideal when you’re looking for a general understanding of a web development topic or want to learn from someone’s personal experience. For example, if you’re interested in learning about the benefits of Headless WordPress, a blog post could offer you some personal insights into how Headless WordPress has helped the author’s clients. Or, if you’re interested in learning about an alternative way to debug React, a blog post written by a senior backend engineer could give you some valuable insights and tips.

Benefits of Reading a Blog Post

Blog posts can be an excellent way to get started on a web development topic, and they’re often written in a more conversational tone, making them easier to understand. They can also be a great way to learn about a topic from someone who has experienced it first-hand, which can make the learning experience more relatable and engaging.

In our software world, blog posts can also be an excellent source of information for staying up-to-date with the latest trends and developments in the software industry. For example, if you are interested in learning about a new programming language or framework, reading blog posts from experts in the field can help you stay informed and ahead of the curve.

I want to give you an example of some blog posts about one of our flagship products, the Custom Post Type UI Plugin, this type of article allows you to stay up to date on the latest news about this product from another’s point of view person or expert:

• The History of Custom Post Type UI
• Custom Post Type UI Supports WPGraphQL
• How to Create WordPress Custom Post Types With Plugin

When to Read Developer Documentation

Documentation, on the other hand, is ideal when you need specific information about a product or service. If you’re figuring out how to use a new technology or software, documentation is the best place to start.

Designed to be technical and comprehensive, developer documentation provides everything you need to know in one place. This includes the features, functions, and capabilities of that product or service.

Documentation can be particularly useful when you’re trying to troubleshoot or need to understand a specific feature or functionality. It’s also helpful when you’re looking for step-by-step instructions.

Developer documentation is typically written by the software vendor or publisher, so it is generally reliable and updated. It also covers all the essential topics and features of the product or service. This ensures you have a good foundation to build upon.

Based on the blog post example above, here is the documentation of the same product.

Conclusion

When choosing between a web development blog post and developer documentation, it’s important to consider your goal. A blog post is the way to go if you are looking for:

• General Information
• Expert or Personal Insights
• Real-World Examples
• The Latest Industry Trends

If you need specific information or step-by-step instructions, developer documentation is the way to go.

It’s worth noting that both blog posts and documentation can be valuable learning tools, depending on your needs. Ultimately, it’s up to you to decide which one is the best fit for your learning style and goals.

The post Understanding Web Development: When to Read a Blog Post or the Developer Documentation appeared first on WebDevStudios.

Sometimes though you need something very specific–a field that doesn’t fit in with any of the fields built into CMB2. Don’t abandon hope; adding new field types to CMB2 is super simple! There are really only two things you need to define for any custom field: what the actual field markup is and how the data is saved. Luckily, CMB2 provides two easy hooks to give you this power!

Make the Field

To define your field markup, you need to hook into the ‘cmb2_render_{field-type}’ action. Let’s say we want to make a field with an input box for first and last names; we’ll call it a ‘human_name’ field. Based on that, our action to hook into is ‘cmb2_render_human_name’.

function cmb2_render_human_name( $field, $escaped_value, $object_id,
          $object_type, $field_type_object ) {

  echo $field_type_object->input( array( 'type' => 'text' ) );
}
add_action( 'cmb2_render_human_name', 'cmb2_render_human_name', 10, 5 );

As you can see, using CMB2’s built in field creation methods makes it incredibly simple to build your own fields.

Save the Data

Now that we have the markup, we need to do something with the data from the field when it is submitted. While our previous function was just outputting a basic input field, here I want to do a bit of checking to make sure the value given matches up with the format we expect.

function cmb2_sanitize_human_name( $override_value, $value ) {
  $value = sanitize_text_field( $value );

  $names = explode(' ', $value);

  if ( count( $names ) < 2 ) {
    return '';
  }

  return ucwords( $value );
}
add_filter( 'cmb2_sanitize_human_name', 'cmb2_sanitize_human_name', 10, 2 );

First, I sanitize the field to prevent any issues with malicious inputs, then I split it up into words and confirm that there are at least two names given, and finally I run the string the ucwords which capitalizes the first letter of each word to make it a bit prettier!

More Info

This was a super basic rundown of adding your own fields to CMB2, but you can also add onto this with custom CSS and JS for more complex field behaviors, more complex custom field markup, and a lot more. Take a look at the CMB2 documentation about creating fields for more info!

The post How To Make a Custom Field For CMB2 appeared first on WebDevStudios.

Commercial Themes / Plugins

When I was a freelancer, I used to think commercial themes were the bomb. They had everything: sliders, tons of short-codes, page templates, page builders, the works… However, the more I learned about WordPress, I learned the first and major problem of commercial themes is their ability to be extended. The objective of a business is to retain it’s customers, and what’s the easiest way to do that? Do not make your theme developer friendly!

Nowadays when a developer sees a commercial theme, he’s going to do one of three things: make the theme his own so he can write the code to his specifications, make a child theme and risk spending tons of extra hours fixing the core theme anyhow, or spend hours on end reading the documentation (if any) on the theme to set it up how the client wants it, if that’s even possible.

I could go on and on about commercial themes, but in short, most of the time a theme from these top sellers are not extendable. There are usually very little to no filters/actions beyond what WordPress already offers. Sometimes it’s just an oversight on the developer’s part, other times it may be a business decision which I understand, but I believe in ALWAYS writing your code as if another developer will need to add to it or take away from it later.

I want to conclude this section in saying not all commercial themes are bad, just do your research before you decide “This has everything, I’m gonna buy it!”. Do you really need thirteen sliders?

The WordPress Way

WordPress has two very nifty methods, which I’m sure you’ve used their counterparts, add_action and add_filter, which are do_action and apply_filters. So many times when working with a theme have I wished a filter was used, but most of the time it’s not.

Most of the time, you can create a child theme, and overwrite the template you’re working on, adding in the filter you need. However, if the filter/action you want to add resides in the functions file (functions.php) you have to literally replace all functions with your own, and replace all calls to those functions everywhere they’re called, in turn bringing more files into your child theme. Before you know it, you’re in a spider web of function calls. I’ve been there. Plugins are double hard to muck with, it’s even harder to extend a plugin, and you’re absolutely limited to what the plugin developer has allowed you to modify.

 Hooks are provided by WordPress to allow your plugin to ‘hook into’ the rest of WordPress; that is, to call functions in your plugin at specific times, and thereby set your plugin in motion… – WordPress.org

You are usually using these hooks to edit the core functionality of WordPress in certain circumstances, but, these hooks aren’t just for hooking into things. They’re also available so other plugins can hook into your content.

What to use, and when to use it!

Always think of the future use of your plugin or theme. If it’s a form, maybe a user may want to add more fields later down the road or maybe some sort of authentication method that a developer will need to hook into. There’s absolutely no reason you cannot hook into it and provide data related to the function/display call.

I personally use the do_action method sparingly when I create themes or plugins (plugins mainly because I’m no designer). My rule is that if a user wants to output content that is displayed and shouldn’t need to edit content, arguments, or some other setting in the current context, then I use an action!

The apply_filters method, on the other hand, is always in my back pocket. This is really handy for allowing another developer to overwrite output, modify custom queries, and tons more things. My rule here is to filter all the things…not kidding. If I’m running a custom post type query somewhere on the site, it has a filter; if I’m outputting stuff to the front-end, it will have a filter. Though there are special cases that I don’t use filters such as option panels and other settings related pages. If you’re using CMB2 for this, that’s handled for you…you are using CMB2, right?

Conclusion

The above methods are not the be-all, end-all methods of extending plugins and themes. PHP itself has some very nifty things up its sleeve such as Class Extensions and Implementations, or, if you’re the stickler for formatting, but still want extendability, Abstract Classes is the way to go. (Thanks to Ben for that one!)

Bottom line: You have zero reasons for not making your plugin or theme developer friendly. Yeah, sure, we can extend your theme to no end, but if it’s a pain in the rear, we will more than likely fork your theme, and make it our own. And when it comes to plugins, please, I’m begging you, please make them developer friendly! Think of the future people, please?

If you have your own methods to make a theme or plugin is extendable please do share. I love knowledge–you can never have too much of it!

The post Making Developer-Friendly Themes and Plugins appeared first on WebDevStudios.