{"id":443,"date":"2012-10-18T14:00:28","date_gmt":"2012-10-18T12:00:28","guid":{"rendered":"https:\/\/wprealm.com\/?p=443"},"modified":"2012-10-18T14:00:28","modified_gmt":"2012-10-18T12:00:28","slug":"the-ten-commandments-of-wordpress-development","status":"publish","type":"post","link":"http:\/\/wprealm.local\/the-ten-commandments-of-wordpress-development\/","title":{"rendered":"The Ten Commandments of WordPress Development"},"content":{"rendered":"
About a year ago I made an inventory of all the WordPress websites I created together with my colleagues over the past few years. I found out that we used a lot of different approaches. It lacked standardization. What we needed was a uniform approach to development and, of course, a philosophy. At first I was a little flabbergasted, I really did not know where to start. Of course we all knew about the Codex, the forums and tutorial websites, but we did not have any contact with the WordPress community at all<\/em>.<\/p>\n This was something that needed to change. We decided to hire a local WordPress expert and invited him to give us some advice with respect to this matter \u2013 our expert came from Friesland<\/a>. Do you feel yourself situated in the same position as I was one year ago? Then this might be your starting point too. WordPress is used all over the world. So you are bound to find an expert near you.\u00a0 Good places to start searching are WordPress forums in your own language, WP Meetups and amongst WordCamp organizers.<\/p>\n I received a lot of tips and pointers to start my standardizing approach. I immediately started to draft a list of focus points, in fact a list of the most pressing points at that very moment. I chose to limit my list to ten focus points for me and my colleagues to work on and I called them: \u201cThe Ten Commandments\u201d.\u00a0 A short list, that is what I wanted, as well as a constantly evolving list of points, , raising the bar as we went along.<\/p>\n My first version of the Ten Commandments featured items like: \u201cEnqueue your scripts correctly\u201d and \u201cOnly use one stylesheet, and use the right one\u201d. Nowadays I don’t feel I have to remind myself and my colleagues about these items, so other items were added to my list. A month ago I reworked the original list into a new one with new, more general, focal points. I wrote them down on a big whiteboard in our office, no developer can miss it. Here they are, my current ten commandments:<\/p>\n You would not believe how many plugins and themes, and how much custom code triggers notices and warnings. All these low level errors can cause memory leakage, causing your site to consume more memory than needed. WP_DEBUG is also a useful tool to find out if you are using any deprecated functionality.<\/p>\n Our expert, Remkus, also wrote a post about this some year ago<\/a>. Wouldn\u2019t it be nice if we all wrote our code as shown in the WordPress Coding Standards<\/a>?\u00a0The standards, as set by WordPress core developers, are the cumulation of years of experience. Adhering to these rules leaves you with a clean readable code other people would love to read to. There is a reason for the motto \u2018code is poetry\u2019.<\/p>\n Your code should not only be easily readable by others, but others should also be able to understand why you chose to write a bit of code in a certain manner. There are many ways to skin a cat, explain to your co-workers why<\/em> you wrote it like that. There are documentation guidelines in the Codex<\/a>.<\/p>\n You should know how WordPress works internally. When are (mu)plugins loaded? When are database queries being performed, when are theme files loaded and so on? There is a great deal you can learn from reading the core. It\u2019s inspiring!<\/p>\n I have written a lot of code in the past that could easily be substituted with a function or procedure that is already embedded in the core. If only I knew it was there\u2026 Browse through the core files (as stated in my previous commandment) and figure out how these all work. You will be amazed with what you can find in there. Like these utility functions<\/a>.<\/p>\n A lot of people write code for WordPress in themes and plugins. Chances are that your function name, or class of variable is the same as someone elses.\u00a0 You should always namespace it. I use my inititals FPL, like: This remains a really important issue. Today and most probably forever. WordPress is loaded with tools enabling you to write secure sites. The best read for this is chapter 6 of this book<\/a>. You do own that book, right?<\/p>\n This is an extension of my previous commandment. Using nonces secures all the functionality your forms need. Check out this page in the Codex<\/a>;\u00a0using nonces makes sense!<\/p>\n Living in Europe, we are used to talking and writing a lot in different languages.\u00a0 Don’t be surprised when your client requests his plugin or theme be available in other languages or even dialects, either now or in the future. Do you write your code with localization in mind? That’s makes your task of adding another language easier in future. WPtuts has a nice tutorial about localization for themes and plugins<\/a>.<\/p>\n We are building high-performance-sites. With everything that you write or include, be it a database query, PHP code, HTML, CSS, JavaScript or assets like images, you always should keep performance in mind. Simply each and every nanosecond counts.<\/p>\n1. Always set WP_DEBUG to true during development<\/h3>\n
2. Adhere to WordPress Coding & CSS-standards<\/h3>\n
3. Comment your code<\/h3>\n
4. Learn how the core works, read the actual lines of code<\/h3>\n
5. Use WordPress internal functions and APIs whenever you can<\/h3>\n
6. Namespace your code<\/h3>\n
fpl_functioname();<\/code><\/p>\n
7. Never trust user input!\u00a0Sanitise\u00a0& escape!<\/h3>\n
8. Use nonces<\/h3>\n
9. Internationalize your code<\/h3>\n
10. Performance, performance, performance<\/h3>\n