IT Crowd Popcorna

The WordPress Noob: Common Mistakes

A question appeared on the “Advanced WordPress” Group on Facebook

What are some of the most common mistakes made by WordPress developer newbies?

I decided to quickly punch out a few things I’ve encountered in my years of WordPress development. Figured that it would be a shame that the list that got so much praise would end up getting buried on Facebook to never be seen again. If you’re a noob I hope this helps!

These all relate to WordPress development, but a lot of them can also just apply to “any old Web development”. Each item below is a word for word duplication of what was on the post, and then I decided to elaborate on each list item.

The List

  1. Modifying purchased Themes, losing changes after an update.
    • Many developers and companies take the “easy way out” and buy Plugins and Themes. There’s nothing wrong with this. There is an amount of ignorance into purchasing these products though. People pay money, then have a product, then very quickly void the warranty. They edit the product they bought. That causes things to break and it also opens the door to when an update for your product comes out, you will lose all the changes you’ve made.
    • It’s best to customize outside the product. That can be done with plugins meant for adding code or child themes.
  2. Modifying core.
    • This is a “cardinal sin” within the craft of Web development. Doubly so within WordPress development. To edit the “core” is to change WordPress itself. Now outside of the inherited problems of #1 above — voiding the warranty, losing your changes on updates — which will surely happen, you also diminish the effectiveness of everything to happen within WordPress or within the community. Bug reports are no longer valid. Plugin installs and Theme installs will be less effective and so on. It’s a big deal, it doesn’t make anyones life easier, most of all not yours. Do not do this.
  3. Copy/pasting code.
    • An oldie but goodie, this has to do with taking the works of others, applying it to attempt to solve a problem you’re having and not actually understanding what it’s doing. You could be causing new problems, opening up new security holes, causing performance problems, breaking functionality and so on. In development, there is little to be gained by glossing over the details.
  4. Not using hooks.
    • One of the most attractive things about WordPress is the Hook System, here’s the list of hooks. In full disclosure, I was being speedy on this item and didn’t bother to clarify the difference between Hooks, Actions or Filters. But I believe noobs do not know or do not use these as they should when first starting out. Having a fundamental understanding and appreciate of the power of these will save you time and expand your options in ways that I cannot do justice in this post.
  5. Never learning how core works and just going straight to a framework.
    • Nothing will stunt your growth like never learning how a system works and just jumping straight into someone else’s work. If you don’t know PHP and you jump into WordPress, you’re not going to be as sharp with PHP as someone who knows how to do it from scratch. You won’t be as good at WordPress development if you jump out of WordPress and into someone else’s “wrapper” for WordPress.
    • This is not an issue of originality, or pride. Do all the work, learn your craft. There are no shortcuts. If you stay with it, you will be successful.
  6. Editing templates from the admin screen.
    • This is honestly a feature I believe should be removed from Core. It’s an invitation into doing work you should not be doing. Most of all in a production environment. If you need to do development, follow a staged process and do it with proper tools and not a gimped text editor through a web browser.
  7. Not enabling Search Engines to crawl a production site.
    • Too many times do I see a website go live and for three months it has been up and search engines have not been crawling the site. You can look up ways to check this, but just make sure that when it’s “live” that your search engines can see it.
  8. Not disabling Search Engines on a staging site.
    • More of the same form above. You don’t want your development URLs being crawled. Be sure to test that and not take it on face value that it’s protected and not being indexed.
  9. Doing a search and replace on a database and not knowing about serialized data.
    • This one bites many developers in the ass. You bring a site down locally, and then you just do a search and replace on the database dump and put it back in place. What could go wrong? In short… everything. Don’t do it. You’ll break stuff and lose stuff.
  10. Using plugins to create Custom Post Types and Fields.
    • There are plugins like ACF — these are great solutions for many things. Many times however, I see developers build a Theme, Plugin or Site and take fundamentally important features that the project depends on and store those field configurations in the Database. Versioning databases is… hard. If you use ACF, fantastic — export your configurations and version them like normal code.
  11. Creating a ton of thumbnail sizes.
    • Noobs, this should be obvious, but if you have 10 thumbnail sizes, then every time someone uploads an image, that image PLUS 10 more variations are created. This takes up a ton of disk space and is just a bad idea.
  12. Installing a bunch of plugins.
    • Each time you install a plugin, you introduce a new risk. You may be adding some functionality, but with that you are in one way or another slowing your site down, introducing new security holes, causing new bugs. In general a site doesn’t need 30 plugins. It can normally be done with around 5 or less.
    • A personal feeling I have is that a massive collection of plugins is lacking clarity of purpose.
  13. Not knowing about the WP-CLI
    • Oh man… the suffering that could be avoided if you just knew about this tool. It makes EVERYTHING easier. You want to reset a password? No problem. You want to update all of your plugins? Easy. How about doing a PROPER search and replace on a database? Yeah there’s an app for that… and it’s called “this fucking tool right here”.
  14. Not understanding PHP/HTML/CSS/JavaScript
    • Pretty basic here. If you’re doing web development and you don’t know any of the core languages of web development, you’re going to have a bad time.
  15. Writing SQL queries without using prefix variables.
    • If you’re going to write queries, read this. Basically, prefixes can change, if you hardcode wp_ to everything – you’re going to have a bad time.
  16. Not setting salt keys.
  17. Not knowing how to use WP_DEBUG.
    • Can’t fix what you can’t see. If you don’t know how to see the errors, or read the logs, then you’ll probably be writing bad code, or installing bad plugins and you won’t know the difference. Ignorance is only bliss until your site blows up.
  18. Not knowing how caching actually works.
    • WordPress does not cache “out of the box”. You need plugins to handle the fundamentals of caching. You can also operate outside of that system if you wish and do some or advanced stuff. Basics here would be “do not install multiple caching plugins” and “WordPress does content management well and it doesn’t specialize in caching”. Your caching experience will be dependent on the solution you choose.
  19. Writing multiple/duplicate queries for posts at the template level.
    • WordPress runs a lot of queries, some of which are at the template level. Learn about pre_get_posts and the rest of the actions/hooks/filters that help wrangle control of when and how queries are ran. Otherwise you’ll run the default query, then your query.
  20. Having tons of errors/notices/unexpected output.
    • Relates to the WP_DEBUG (17) above. JavaScript errors will hurt you immediately and cause the most obvious problems. Server side errors will expose data to exploiters that you don’t want them to know about. One of my favorites is seeing errors being stored into the database, that’s a damn good feeling. Keep your site clean.
  21. Writing bad code that throws JS errors and breaking core WP functionality.
    • This relates to the one above. I see it a lot. I even see it in reports to the WP core team. A plugin is installed, it was badly written, now the Editor doesn’t work.
  22. Not updating WordPress Core/Plugins.
    • This is how you get exploited. Core updates are mandatory, not just a good idea. Plugin updates are almost as important.
  23. Updating WordPress Core BEFORE updating Plugins — bad idea.
    • One of my favorites. You may have fallen victim to this more recently with some of the removal of deprecated code. Basically, you want to upgrade Core last, because if the plugins haven’t caught up and Core removes something, it will take the site down. If you update the plugins, they should not break at all and if they do, most of the time WordPress will deactivate them and you can carry on.
  24. Committing and pushing passwords and such in the codebase.
    • Not exclusive to WordPress, but I all too often see wp-config files in repositories. Here are some examples.
  25. Bloating the .htaccess file.
    • These files filled with rules that “optimize” the performance of a site. This goes back to not understanding or testing the realities of things. Also I see developers add tons of redirection rules. Use a plugin for redirects. That’s a really good use for a plugin.
  26. Not canonicalizing domains.
    • Things like www, and non-www or other subdomains should all route to the same primary domain. Here’s some documentation from Google.
  27. Not knowing how the template hierarchy works
    • Save yourself a whole lot of trouble by reading the WordPress article on that.
  28. Not versioning their code.
    • Do you want to lose all your hard work? That’s how you lose all your hard work! Learn git.
  29. Not making backups prior to deploying changes or upgrading.
    • Everyone is in such a rush these days. Especially if you are a noob. Take the time to create a copy of EVERYTHING before updating. Files can be recovered, data is always much harder to get back. WordPress core does an amazing job at upgrading most of the time. But Plugins and Themes can be very sloppy about this and actually wreck your database.
  30. Doing work live.
    • Another cardinal sin. This is a great way to wreck your day. It’s like not preparing at all for a public speech and getting up there and realizing you don’t remember what you are supposed to be talking about. Do your work within a staging environment. Test your changes. Then put them up so the world can see them. Remember… the WORLD is looking. Don’t forget that 😀

BONUS ROUND

Since I posted this, lots of feedback and such has been given. Here are some I missed, probably because I blacked them out intentionally.

  1. Kudos to Leo for reminding me that people still use “admin” as a username. Don’t do that. Use ANYTHING but that.
  2. Related to the above, please use a password that is secure… just read this from XKCD.
  3. Scott brought up that lots of users do not clean up inactive Plugins or Themes. It’s a great point. Clean your room. Inactive Plugins and Themes are still exploitable. Delete them if they are not going to be used.
16 Comments
  1. Reply Ulrich February 15, 2016 at 02:37

    Could you elaborate on point 25? Why is a plugin better then making changes to the .htaccess?

    • Reply Sterling Hamilton February 15, 2016 at 07:36

      An .htaccess file that sets PHP values, that has hundreds or thousands of rewrite rules in it, that has a ton of “optimization” rules in it and things for caching is a few things. It’s not maintainable. It’s easy to lose/forget about when moving the site. Apache should not be used to manage redirections at scale, there are hard limits (20,000 if I remember correctly). All of those things aside, noobs barely understand what is happening in that file. Of course there’s a stack overflow on some of this: http://stackoverflow.com/questions/4435482/is-it-okay-to-have-a-very-long-htaccess-file — in short, if you know what you are doing, know your performance needs, and have a firm grasp on how .htaccess scales — then have at it.

      • Reply mattpramschufer February 17, 2016 at 10:41

        I might have to disagree, the htaccess IS where redirects are suppose to live. If you have your Redirection Plugin do the redirect it still needs to load up core WP, then query the database to see if a rule needs to be enforced and then execute upon it.

        I agree if you are having thousands of redirects then first off, you are doing something wrong and need to rethink your approach but if you have handful of redirects then .htaccess is the place to go.

        I speak from experience with utilizing the redirection plugin, and trying to redirect a highly traffic’d page to a static s3 page during a flood of traffic. Enabling redirect via Redirection Plugin will still not help, users will have to wait for that redirect to be processed through WordPress and then implemented. Adding the rewrite rule to the .htaccess it is actually Apache / Nginx that processes that before PHP even loads.

        • Reply Sterling Hamilton February 17, 2016 at 14:09

          I can see where you are coming from.
          But never forget, that .htaccess goes from top to bottom. If you have thousands of rewrites there, potentially you have regular expressions, which are expensive, then you have to do them in order of priority.

          Outside of performance concerns are maintenance concerns. Managing thousands of rewrites in a text file sucks. Using a UI with a search makes life a little easier at scale. I’ve seen people get very confused as to the order in which rewrites happen, how to use flags properly, where do the expressions catch and not catch.

          NGINX isn’t factored in (from what I understand anyway) if you’re using .htaccess — it’s only for Apache.

          A simple database query to find the proper rule makes sense.
          It might seem expensive to start off with, but at scale it might make more sense.

          .htaccess files are generally “dump” meaning they all work the same way, they traverse all folders and such as traffic hits the site, assets and what not.

          With a little logic overhead you can scale that back to only reference post types, or types of queries.

          I agree with you, needing to even approach this kind of problem means you’re in a lame problem.

          I also believe that redirects need to be cleaned up often and new ones need to be added. Or they need to be updated. Making constant changes to an .htaccess file, versioning that, committing that and so on can be a pain.

          It’s going to boil down to personal experience and preference.

          • chriswgerber March 11, 2016 at 12:55

            mattpramschufer is right. You should make the changes to your Nginx/Apache vhost/site file and perform the update on the webserver before it needs to run php, connect to your database, and redirect you. Even using an .htaccess would be better since it doesn’t require the server starting a PHP and MySQL process for almost nothing.

            All you’re doing is taking the regular expressions away from the websever (where everything is compiled and it is completely designed to handle complex rules) and pushing it into PHP, where it is horribly designed to handle regex and spins up unnecessary resources over and over again for nothing. It’s not like those regular expressions aren’t being parsed, they’re just being done by PHP instead, in addition to thousands of other computations and file opens that need to be done to get to the redirect plugin and parse saved rules and finally redirect the person.

            It comes down to this: If you had to choose between having apache/nginx run 5,000 redirects a minute or having Apache/Nginx pass 5,000 redirects a minute to php, which starts up MySQL, which performs the redirect and closes the connect, which would you chose? Which do you think is more performant? Especially if you have 10,000 rules to go through. You would trust PHP over a web server, a server specifically designed to parse and redirect requests?

            If it’s about having a long list, then write a generator. Use Chef. Use Puppet. Create a tiny script that will generate the nginx config and place that on your server. It’s not “Use WordPress or write out a million location blocks”. It’s not black and white. There are more than two answers. If you’re going to say “Well, we have to use WordPress because this one other way is horrible”, then find another way. Heck, write a script that parses the rules from the plugin and generates your vhost or nginx configs.

            Either way, use a plugin because you have no idea what you’re doing and don’t want to find a better way. Don’t use a plugin because you think it’s the most performant option.

  2. Reply DR CHARLES LEE February 15, 2016 at 02:41

    Good one mate!

  3. Reply William Kowalski February 15, 2016 at 10:33

    Thanks for posting this. About that WP-CLI thing. I always hear experienced programmers talk about their preference for the CLI over any kind of visual interface. I have used it to a small extent, SSHing into my servers and moving a few things around, uploading files, etc. But I fail to see any real superiority there. So far it seems to me like apples and oranges. Why is the WP-CLI so much easier? What specifically does it allow you to do that you can’t do with a visual interface? Thanks for any light you may be able to shed on this for me.

    • Reply Sterling Hamilton February 15, 2016 at 10:54

      It all runs faster than through a CLI, and for when you use SSH you learn to live there. I commonly do the following with the CLI: Add/Update Users, Import/Export database files, Update core, plugins. Manage the cache, clearing and what not. Executing crons by hand. Searching and replacing databases, and within the CLI it handles serialized data. Installing and removing plugins. Doing this all from the CLI makes it easier to do commits and such as well right after something is successful. You can also generate test data. Here’s a post on some of the features: https://www.smashingmagazine.com/2015/09/wordpress-management-with-wp-cli/

    • Reply chriswgerber March 11, 2016 at 12:57

      Automate. You can’t automate a GUI interaction (easily and reliably). You can automate a script though. And if you have to do something once, do it. If you have to do it a second time, automate it. Someone asks you to make a change; make the change. If they ask you again, write a script to do it so that you don’t have to go through and do it again.

  4. Reply Samedi Amba February 16, 2016 at 00:01

    Well written, esp the WP CLI.

  5. Reply Nicholas Turbanov February 18, 2016 at 01:43

    I just learned/realized a few weeks ago that all WP usernames are attainable simply by ‘?author=$userID’. This makes changing your default admin username completely moot. That is, of course, unless you explicitly disable author archives, which I would assume is extremely uncommon.

    Now most WP devs probably don’t realize this (I sure didn’t) but I’m sure someone looking to hack your site does. Or am I missing something here?

    • Reply Sterling Hamilton February 18, 2016 at 06:20

      That’s more of an advanced topic. Security in WordPress by understanding core could be the title lol

      Anyway, here’s a fun trick. If all of your usernames start with things like “!” such as “!administrator” — the author pages will not render that.

      For my website, let’s say my ID is 1 and my userid has a series of prefixes or suffixes that are special characters, it will only show URL friendly characters.

      Now you don’t need to worry about people knowing the username. Not that they won’t try and guess — but you’ve removed the common “admin” username low hanging fruit.

  6. Reply David February 21, 2016 at 15:33

    Thanks for the enlightenment

  7. Reply David March 5, 2016 at 03:36

    There is no doubt that almost every blogger or webmaster do these WordPress mistakes once in their life.

    & These mistakes help them to learn something new again and again with time.

    You have listed here almost all the major WordPress mistakes which bloggers do including me.

    I have also did so many mistakes in my WordPress blog. I can remember when I started my 1st blog, I never created any BackUp of my WordPress site. One day, by mistake I deleted the database of my blog from Cpanel and It created a major issue in my site.

    I didn’t knew anything about it so I started my blog again by re-installing the WordPress.

    That was the unforgettable mistake because It contained hard work of almost 2 months and I completely losed it by deleting the database.

    After that day, I always take complete BackUp of my each site.

    Thanks for covering such a nice article so that people can learn about these mistakes and also can avoid them. 😀

  8. Reply Sal Ferrarello March 8, 2016 at 08:16

    Lots of great information and reminders here, nice work.

    I do have one note about #5. “Never learning how core works and just going straight to a framework.”

    When I started using the Genesis framework, it improved my understand of WordPress core based on its use of Hooks and Filters and made me a better WordPress developer. I’ve also heard this same feedback from other Genesis developers.

    Thanks for the great post.

Leave a Reply