Suffice to say, it will usually be obvious when something is wrong with your WordPress theme. The most common reasons for things being off are:
The second point is pretty obvious when it happens. You see no images, or worse, you might get those little ugly "x'd" boxes in IE if they're called directly from the WordPress posts or pages. Fortunately, the solution is also obvious: you have to go in and make sure your images are named and referenced correctly inside any img
tags in your markup or background-image
declarations in your stylesheet.
For images that are not appearing correctly because they were mis-sized, you can go back to your image editor, fix them, and then re-export them, or you might be able to make adjustments in your stylesheet to display a height and/or width that is more appropriate to the image you designed.
For the latter two points, one of the best ways to debug syntax errors that cause visual "wonks" is not to have syntax errors in the first place.
This is why, in your workflow, you should be constantly checking for validation.
Let's have a look at some of the most common causes of problems with code.
The next issue you'll most commonly run into is mistakes and typos that are created by copying and pasting your WordPress template tags and other PHP code incorrectly. The most common result you'll get from invalid PHP syntax is a Fatal Error. Fortunately, PHP does a decent job of trying to let you know in which file and line of code in the file the offending syntax lives.
If you get a Fatal Error in your template, your best bet is to open the filename that is listed and go to the line in your editor. Once there, search for missing <?php ?>
tags. Your template tags should also be followed with parentheses, followed by a semicolon, such as ();
. If the template tag has parameters passed in it, make sure each parameter is surrounded by single quote marks, for example, template_tag_name( 'parameter name', 'next_parameter' );
.
Be aware of proper PHP notation
The proper way to notate PHP is as mentioned earlier, with a <?php
at the beginning and a ?>
at the end. The server will look for the beginning <?php
tag and start processing the PHP. Some developers use PHP shorthand—starting with just a <?
(no php added). This is risky as not all servers support it, so stick with <?php
in your opening tags.
The following screenshot shows the results of a PHP error, with reference to the line number in the file generating the problem:
As you can see, this is a simple typo - the have_posts()
template tag has been mis-typed. This tag appears at the beginning of the loop, so it should be easy to find and fix.
Finally, your CSS file might get fairly big, fairly quickly. It's easy to forget you already made a rule and/or just accidentally created another rule with the same name. It's all about cascading, so whatever comes last overwrites what came first.
The biggest cause of problems is duplicating selectors with different properties set. Beware of duplicating in this way, and if you do need to, ensure that the rule you want to be used by the browser is after any rule with duplicated selectors in your stylesheet.
For example, you may have the following rule for all of your headings:
h1, h2, h3, h4, h5, h6 { color: #333; }
And then, elsewhere in your stylesheet, you have a separate rule for h3 headings, which you want to be a different color:
h3 { color: #000; }
For the second rule to be implemented by the browser, you must put it lower down in the stylesheet than the first, so that it can override it.
Again, validating your markup and CSS as you're developing will alert you to syntax errors, deprecated properties, and duplicate rules that could compound and cause issues in your stylesheet down the line.