WordPress is an excellent tool for building and running a site, fast. It is also one of the best CMSs out there, which is solid and easy to employ. WordPress has stayed a top choice among other CMSs because it allows for multi-users and multi-blogging, and because it’s a free open source platform of course.
Oh my, oh my. Using a premium theme with all the libraries and custom code stored into one sole file is not a good option. This because, the file, after a while, gets really big. As the theme is continuously developed and acquires new features it can grow up to even 1MB in size. Unfortunately, the file will be loaded across the site even if 8% of the code is used on some pages. This will cause pages to download and pre historic speeds and slower to render, especially if the code is render-blocking in the head section of the page. Also, it gets harder to manage the code contained in the file, as you cannot turn to
2. Giving names that are too generic
This is the moment to unleash some creativity. When developing a plugin, it’s smarter to use names that will not cause code conflict in the event there are other plugins with the same name. Plus, it also makes things easier to find when you have your own unique naming system.
But, sometimes in projects, you’ll have to abide by existing coding style, unless you’re working on something separate from the current one. If you must extend an existing plugin or theme that already abides by PHP coding standards for WordPress, then it’s a better idea to stay with them to maintain consistency and clean, easy to read code. There are some universal rules to optimize performance, apart from coding styles, such as using single quotes instead of double ones, and indenting code to be read, especially if we’re talking about nested code
3. Not taking full advantage of WordPress’ Core Functionality
WordPress has continuously updated libraries by their development core team, take advantage of this core functionality for lighter and easier to look-after project. By regularly updating WordPress, you have access to more components such as plugins and themes, or a WordPress core, and allow the website to be more secure in the event old code releases present vulnerabilities.
4. Not allowing for plugins to be easy to modify
Let’s start by saying altering a WordPress plugin or theme, in general, is not a good idea unless you are contributing to the development of its package and working on its code. If by accident an automatic update is carried out on the edited plugin or theme, all changes will be eliminated and you have to perform all the changes from scratch again. What fun.
That’s why using actions and filters, as well as using a child theme, are safer bets rather than altering the parent theme or plugin. Also, if you’re providing a free downloadable plugin on WordPress.org and afterward you’d like to produce a premium extension that would rely on the parent plugin, then it’s better to create the free plugin in a manner that it would be simple to extend and add premium extensions to.
5. Writing PHP code without taking into account the page could be cached in the future
Stick to the PHP coding standards and you can easily prevent this type of mistake. Often developers have the nasty habit of integrating PHP snippets into themes and plugins that are only working if the PHP code is enabled all the time.
6. Not using a version control system to track changes
Make sure child themes or custom plugins or any files that are custom-coded are under version control. Git, for example, records changes and helps developers work together on the same WordPress project or reset back to a previous version with ease if anything happens with the website. Furthermore, clients get the chance with Git to view all the work history done by the developers hired for the particular project, especially if it was a big and long-term WordPress tailored website. Even though it may be a little tricky to understand Git at first, it will be worth the extra time.
7. Enqueuing when not necessary