Episode 062: Top Mistakes You Should Make as a WordPress Beginner

Mistakes are a great way to level up as a WordPress developer. Debugging for a example, is almost an art form of fixing mistakes. We’ve all been there, sometimes its a code mistake, sometimes its something we realize we DEFINITELY should not be doing till after the fact. Today we discuss some of those

Do NOT Code in the WordPress “Editor”

If you have been around WordPress long enough you may have noticed in the menu under “Appearance” or “Plugins” you see (sometimes) something called “Editor”. This is a dangerous thing, and should not be used. For those of you who haven’t seen it or don’t know what it is, its basically a textarea (text box) code editor. There is no syntax highlighting or default spacing like you get in a IDE or text editor app, just plain code.

DO NOT code here. No matter how tempting it may look ’cause you can access that coveted “functions.php” file that you see the instructions on StackOverflow talk about, do not code here. Using a IDE or text editor will greatly help you since again you get syntax highlighting as well as automatic spacing, and autocomplete. Another reason to stay away is because as soon as you make a mistake, you could lock yourself out with white screen, then you’ll be forced to fix it the right way anyway.

The right way

If you have a GIT workflow, this will bypass all of that since you are coding directly to the server, via WordPress (bad idea!). If you don’t, but still use FTP, then next time you push up your local, it won’t match, overriding what you’ve done. From a workflow perspective, really not a good idea. Stick to your workflow, whatever it may be. Git, FTP, etc. don’t use the editor, so many bad things can happen.

Use WordPress Templates

One of the biggest mistakes that we may make when first starting out, especially when coming from vanilla PHP or maybe HTML, is we put a lot of content into the templates instead of using the WordPress admin to power a template.

If you have content on the page, it should be powered by the WordPress WYSIWYG text edit whenever possible.

Exceptions to the rule

When you are a developer working on a site that you manage, sometimes its just easier to do things like hard code content, especially on the front page or home page. I think this is a valid exception since sometimes you don’t need this to be powered by an admin since you won’t change it often, or you don’t mind changing it in the code to maybe even avoid 1 more DB call.

Also if your navigation is not going to change, while I would always recommend using WordPress menus, there may be a good use case for not using them since the navigation won’t change allowing you to skip that extra code and DB call.

Enqueue Your Scripts!

This is one of my biggest pet peeves. If you need to inject a script tag (<script>) into your site to add functionality, UI, etc. DO NOT just paste the HTML tag into the header. This is a big mistake as you are avoiding one of the best parts of WordPress, enqueue’ing. You should always enqueue scripts because it gives you the leverage to only enqueue where you need, or when you need (in what order) thanks to dependencies.

The only exception I will not get mad over is Google Analytics because I don’t (personally) typically like printing code to the header, and Google Analytics is a whole block of code vs. just a JS file. If you want to put it into a JS file then include that, that may be a smart way about it, but otherwise I don’t mind just copying this into my WordPress theme’s header file and being on my way.

Use WP_DEBUG, Don’t Leave it On

One of the last things I will write about (but not the last thing we talked about) is WP_DEBUG, I think it is highly underutilized by a lot of developers who actually create plugins and are actively working on them. It is also under utilized by beginner developers.

WP_DEBUG is an easy way to debug as you are developing a site theme or plugin. It will print out the errors including deprecated warnings so you can easily track down any problems before you get support tickets for them, or your site breaks. There is also a handy WP_DEBUG_LOG constant which will create a log file for things that do not print, and that way you have an easy to find log of the errors on your site. I use this heavily while working because I want to make sure my site(s) have 0 and as close to 0 warnings as possible before I launch new code.

Just don’t forget to turn it off! I know I have left it on a few times, and pretty sure it may be on right now, but that is why I love it, ’cause I can quickly see errors and hopefully, fix them quickly. But yes, that is NOT RECOMMENDED especially if you are a beginner. Make sure your production environment does not have WP_DEBUG turned on (logging can be fine).

Make More Mistakes

Always make mistakes, as I said before, it is how you learn. Sometimes you don’t realize what you are doing is almost criminal till after the fact and you realize how much you shouldn’t have done it. Sometimes knowing its something you shouldn’t be doing comes with knowledge as apposed to just having someone tell you so. So keep making mistakes, it is one of the best ways to level up as a developer.



WordPress Mistakes

One thought on “Episode 062: Top Mistakes You Should Make as a WordPress Beginner

  1. Shivam Sahu says:

    Great article, and while I knew most of these tips there are a still a few I didn’t know about. One thing I see on some new (and maybe even older) WordPress site is people don’t disable/remove the meta admin widget from their sidebar. No reader/viewer/client/customer, etc needs to see a link for you to log into your WordPress dashboard when they got to your site. That tab is completely useless (just go to yoursite.com/wp-admin) and should be removed as soon as your site is active.

Leave a Reply

Your email address will not be published. Required fields are marked *

Please enter an e-mail address

This site uses Akismet to reduce spam. Learn how your comment data is processed.