WordPress Event Ticketing

Ah, custom code; it can change your site to do anything you dream of. Perhaps it's a simple code snippet to change how many posts show on your archive pages or maybe it's something more complex that modifies the functionality of WooCommerce. While the custom code is useful and can help transform your site, you shouldn't just blindly keep using it and throwing it in functions.php. Let's explore the whys and hows.

Why You Shouldn't Use Random Code You Don't Understand

Now I'm not saying you need to be an expert developer and understand every small part of the custom code you are using. But what you shouldn't do is blindly keep copying and pasting code without properly understanding what it does, why does it and if it's the best way to do such a thing. You most probably don't have time to go and learn to program and perhaps have no desire to.

Too many people are happy to browse around Stackoverflow, user groups and everywhere else and just keep copying and pasting snippet after snippet. If you ask the theme developer of the theme, you are using, and they provide you with a code snippet - use it. Likewise for plugin developers. But using the random code you've found, because you think it may solve your problem, isn't a wise move. You could be introducing a security risk to your website through badly written code, or you could introduce a plugin conflict with the custom code you've added. Neither of which are desirable positions to be in.

Don't Edit Your Parent Theme

This is something I've seen all too often; someone finds some code on a website or gets given a code snippet by a support team, and they go ahead and place it in the parent themes functions.php. Every time I see it, it's a shame. Some say users should know better, though personally, I feel it's more of an education problem. Support teams should always advise as to where the code should be placed (usually a child theme's functions.php).

 

If you edit your parent theme with that code snippet you've found or been given and then the parent theme has an update, your site may suddenly not work.

 

The primary reason for this being that whenever you add or customize anything in a parent theme or a plugin, all files are overwritten on a theme/plugin update. The only way round this would be to manually update the theme or plugin by only replacing files that have had modifications. Chances are though to do this effectively you'd need to be more of a developer, and no true developer would ever overwrite core functionality anyway, so it's kinda moot point.

What you should be doing with those code snippets, many say, is putting them in a child theme. Usually in a functions.php of a child theme. While this is perfectly fine for a few snippets, it can start to get difficult to debug if you have snippets upon snippets of code in a large child theme functions.php with no real structure or sense to it.

Why You Should Use a Custom Plugin

If you use a custom plugin, you cut out many of the issues with using a child theme functions.php. For example, let's say you have an issue on your website and something has gone wrong, and you have 15 snippets in your child themes functions.php. Usual practice would be to deactivate plugins one by one until you find the root of the conflict. But what if deactivating plugins does nothing? Then you need to switch themes, so you switch themes, and everything works great. Perfect! You may be thinking. Wrong, enable the parent theme it still works, now you're confused.

You only have some edits in your child theme can it break the site? Yes it can.

Now you're at the stage of having to go through your child theme removing snippets one by one until your site works again. Once you've found the snippet causing your site trouble you can remove it from your functions.php, re-activate your child theme and carry on with building and running your website. The issue with all this though is that had you have used custom plugins you could have got to this stage hours ago depending on how many plugins you have, saving you both time and potential lost revenue.

Aren't Plugins Difficult To Code?

It's a common myth that plugins are difficult to write per se. Of course, there are plugins that take hundreds and in some cases thousands of hours to build and develop. This, though, is because of what that particular plugin is trying to accomplish. If you just want to create a simple plugin to add a snippet to the process is relatively simple. First of all, make sure you get familiar with this page in the WordPress Codex. This page explains all about creating a plugin, best practices and the like. On the whole, you don't need to use these methods in your plugin as it's just a code snippet you are adding. Having familiarity with this page, though, is no bad thing and will help educate.

A page in the WordPress developer handbook you should be familiar with is the header requirements section. This page explains what's needed to make your plugin run.

For example:

/* Plugin Name: WordPress.org Plugin 
Plugin URI: https://developer.wordpress.org/plugins/the-basics/ 
Description: Basic WordPress Plugin Header Comment 
Version: 20160911 
Author: WordPress.org 
Author URI: https://developer.wordpress.org/ 
License: GPL2 
License URI: https://www.gnu.org/licenses/gpl-2.0.html 
Text Domain: wporg Domain Path: /languages 
*/

Let's explore this in some more detail

Plugin Name: The name of your WordPress plugin. Make sure this is unique. As for the purpose of this article we're just covering snippets, simply prefix the name with your initials and what the plugin does. I.e: "jk woo com text change". Sure it's not the prettiest of plugin names, but it doesn't need to be.
Plugin URI: The URL of the plugin where anyone who uses it can learn more about the plugin. You can just use a hash here #.
Description: A short description of what the plugin does.
Version: The version number of the plugin. Usually starts at 1.0 or 0.1 if beta/alpha.
Author: The Author of the plugin. Enter anything you'd like here, as it's just a plugin to be used on your own site.
Author URI: The URL of the authors websites
License: You don't need to declare a license and can remove this. If you are distributing the plugin however you'll need to pick the appropriate license which is beyond the scope of this article.
License URI: URL of the license
Text Domain: The text domain of the plugin used for translating. Should be a unique text domain for your plugin only.
Domain Path: The path of where the languages/translation files can be found.

Once you have your plugin header sorted, it'll be activatable in your WordPress admin. Of course for it to actually do anything you'll need to add your code snippet which can usually go into the main plugin file (usually index.php, main.php or plugin-name.php) place that PHP file in a folder the same name as your plugin, zip it up and upload to your site.

Conclusion

Creating a custom plugin to add each snippet to is the best way to go for easier debugging and a clearer path forward for your website. While it may seem daunting at first, it isn't too complex, and you'll be able to get it done in no time at all. Have you ever created a plugin for your code snippets? Maybe you prefer to use a child themes functions.php? Let us know in the comments below.