Sign up to save your podcasts
Or
Share Episode 062: Top Mistakes You Should Make as a WordPress Beginner
Share to email
Share to Facebook
Share to X
Share to email
Share to Facebook
Share to X
Or
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 (
View all episodes
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 (