If all you want to do is highlight some text that includes code-related words like filenames, function names or plugin names, use <code></code> around those phrases in your text. Using <code></code> turns text into a monospaced font so that it appears differently in your posts than “normal” text. However, using <code></code> around an HTML tag doesn’t do anything except change the presentation of the tag, so the opening and closing angle brackets are interpreted to enclose an actual HTML tag. The result will be a mess and definitely not what you were hoping to see.

To make WordPress show code in a post without interpreting it, you have to do ONE of three things:

1. Use special character codes to replace angle brackets of tags.
2. Use the HTML tag <pre></pre> around the code.
3. Use a plugin to highlight the code syntax.

1. Special Character Codes

Angle brackets, < or >, are what WordPress uses to identify code, whether it’s HTML, inline styles of CSS, or PHP. Content inside angle brackets is interpreted as code by virtue of placement inside the brackets. Instead of interpreting this code we want WordPress to show the code to the site visitors and we can use special character codes to do that.

Character codes are special sequences of letters or digits that are used to represent textual characters. Every character that we see on the screen, including uppercase letters, lowercase letters, numbers, and symbols like <, >, #, $, %, ^, & or *, can be represented by character codes, sometimes called character entities.

Using character codes in posts looks a little strange in the editing panel, but when a browser comes across these codes they are interpreted and their textual equivalent is shown on the screen.

ASCII (American Standard Code for Information Interchange) character codes were developed to represent text in electronic devices and they follow a specific format. The format is that each character entity starts with an ampersand and ends with a semi-colon. The codes are a couple to a few letters or numbers. Numbered character codes always have a hash symbol right after the opening ampersand. Some entities can be represented by either numbered or named codes.

Examples of special character codes:

If you need to find a code for language sets other than English, try the unicode site for all the code charts you’ll ever need. There, you can find numeric codes for fun game pieces, like chess, mahjong or checkers, horoscope symbols, smiley faces, weather symbols, music notes, and much more.

Take caution: Just because you can enter a special code to represent a symbol, that doesn’t mean your computer will let you see it. Many operating systems will not have the proper fonts installed to make use of all of these codes, especially if they represent symbols that aren’t on your keyboard. Stick to the ASCII codes as many of the unicodes won’t be seen by your site visitors.

2. HTML tag: <pre>

Perhaps you’d like to show a block of HTML code on your post and have it shown as text. To make sure that your block of code is not interpreted as actual code, wrap it with <pre></pre> tags. The <pre> tag will change the appearance of the code into a monospace font, just like <code> does, but the difference is that <pre> also illustrates the code exactly as it was typed. All text, characters, spaces and line feeds will be reproduced exactly how they were entered. No code will be run when it’s protected inside the opening <pre> and closing </pre> tags.

3. Syntax Highlighter Plugins

A final way to illustrate code in a WordPress post or page is to use a plugin to highlight the code. Several plugins are available for syntax highlighting purposes.

One that I have been using lately is called Crayon Syntax Highlighter. It’s a great plugin that will colorize or highlight code that you wrap with shortcodes. There are lots of options if you want fine control over the color scheme. Themes come with the plugin so you have several choices for making your code look good.

There are two modes where you can highlight code differently using shortcodes, [crayon][/crayon] and [plain][/plain]. Use [plain] shortcodes when the colorized crayon is overkill or when you just want to show a small section of code. Crayon Syntax Highlighter supports a wide range of languages, including HTML, CSS, PHP and JavaScript, for starters.

The colorful [crayon] shortcode is controlled by options where you can pick the colors that you want for representing different sections or purposes in your code. Inline crayons are supported so you could put a line of code within a line of text and the code would be colorized.

Some other popular code-highlighting plugins include SyntaxHighlighter Evolved, WP-Syntax, and CodeColorer. I don’t have any personal experience with these plugins, but they are listed high in popularity at the WordPress Plugin Directory.

Need to Execute Code in a Post?

If what you’re really after is to put executable code in a post or WordPress Page, check out this post on executing PHP in WordPress blogs.

To control what scripts are used on your site it may be wise to learn how to disable scripts from loading in the first place. Similar methods can be applied to streamline the number of scripts or stylesheets loaded onto your site.

Check out this great tutorial on disabling scripts and styles. Thanks for sharing, Justin!

You’ll need to modify the functions.php file of your theme to remove styles or scripts. The technique is similar in each case.

1. Find the ‘handle’ of the script that you’d like to remove.
2. Pass the script handle to wp_deregister_script().
3. Wrap one or more ‘deregistrations’ in a new function, like my_deregister_javascript() in this example.
4. Use add_action() with wp_print_scripts method and add your new function to the functions.php file of your theme.

function my_deregister_javascript() {
  wp_deregister_script('jquery-form');
}
add_action('wp_print_scripts', 'my_deregister_javascript');

From the reference on add_action in the WordPress codex we can see that two arguments are required, namely the $tag or handle of the script and the $function_to_add or the function to which the script is hooked. Two optional parameters can be added to the add_action function to specify the $priority or the order in which the functions are executed, and $accepted_args or the number of arguments that the function accepts. Generically,

add_action( $tag, $function_to_add, $priority, $accepted_args );

In the example above we’ve used ‘wp_print_scripts’ for $tag and ‘my_deregister_javascript’ for $function_to_add while the optional $priority and $accepted_args were not used. This will hook the new function ‘my_deregister_javascript’ to the action called ‘wp_print_scripts’.

Alternatively, a WordPress plugin could be used to manage the scripts and actions called for on your site. Use Google Libraries is a plugin built to detect the scripts needed for a site to run properly, including all the scripts called for by plugins and the active theme. Scripts are loaded in the proper order taking into account dependencies, whether previously known to WordPress or whether provided by the plugin and theme authors. This plugin uses the content delivery network (CDN) of google to supply the most popular javascript libraries, including jQuery and jQuery UI, among others.

Queue Up Your Scripts with Actions

Since jQuery itself is already included in the core of WordPress, how should we include a javascript file that we’ve created or even one of the popular jQuery plugins that rely on jQuery? WordPress helps us in this endeavor with a function called ‘wp_enqueue_script()‘ and two actions that are used to call this special function.

The actions are used for either the user side or the admin side, depending on the purpose of your javascript. Use the ‘wp_enqueue_scripts‘ action to call wp_enqueue_script() for use in your themes. If the script functionality is needed on the admin side, use ‘admin_enqueue_scripts‘ action instead.

The format of the wp_enqueue_script() function call is as follows:

wp_enqueue_script('$handle', '$src', '$deps', '$ver', '$in_footer');

where $handle is the name of the script as a lowercase string, $src is the URL to the script, $deps is an array of scripts that the script you’re calling depends on or the scripts that must be loaded first for your script to work, $ver is the script’s version number in string format, and $in_footer is a boolean value to indicate whether the script should be loaded in the <head> or at the end of the <body> in the footer.

The $handle string is the only required parameter, so the other four parameters are optional. The $src, $ver, and $in_footer parameters default values are ‘false’, and $deps defaults to an empty array.

It seems that $src would need to be a required option, but WordPress already knows about several scripts and where to find them. Consult the list of default scripts included with WordPress to pick up their handles.

For example, to queue the jQuery Color plugin, we’d simply use this:

wp_enqueue_script('jquery-color');

To include a script and specify the source, try this for including the jQuery Cycle plugin in the <head>:

wp_enqueue_script('jquery-cycle', 'URL', array('jquery'), '1.3.2');

The URL should not be a hard-coded value for local scripts. Refer to the Function Reference pages in the codex for proper URL formats for plugins and themes.

Register Your Scripts First

Make sure that your scripts are registered first before calling them. Registering a script basically tells WordPress where to find the code for your script. Use the function wp_register_script() to specify the location and handle of your script. The format is similar to the wp_enqueue_script() function:

wp_register_script('$handle', '$src', '$deps', '$ver', '$in_footer');

The parameters have the same meanings and default values as used with wp_enqueue_script(). When in doubt, see what the WordPress Codex has to say about wp_enqueue_script() and wp_register_script().

Create a Function for the Header

Put it all together using wp_register_script(), wp_enqueue_script(), and the appropriate action to call the functions. Create a simple function, like id_scripts() below, and use the add_action() hook to queue up the scripts.

function id_scripts() {
   wp_register_script('script_alpha', 'URL', array('jquery'), '1.0');
   wp_enqueue_script('script_alpha');
}
add_action('wp_enqueue_scripts', 'id_scripts');

As a side note jQuery itself doesn’t have to be queued via a statement like wp_enqueue_script('jquery');, because it is listed as a dependency of ‘script-alpha‘ in this case.

When enqueuing a custom script that depends on a jQuery plugin, specify jQuery and its plugin in the $deps parameter of the wp_register_script() action for the custom script. For example, if your custom script depends on the jQuery Cycle plugin, which itself depends on jQuery, use array('jquery', 'jquery-cycle') for the $deps parameter. This specifies that both jQuery and its plugin Cycle should be loaded (in that order) before the custom script.

Place this code in the header.php of your theme. Remember, first register the javascript file, then enqueue it and make sure this is done before the wp_head(); statement. Your custom script can then be placed in header.php after the wp_head() call.

Use Theme functions.php to Safely Reference Your Script

When using a child theme take note that the header.php in a child theme will override the default header.php in the parent theme. Instead of placing the script-queuing code in the header, one could more safely put this code in functions.php. The advantage to that way is that the functions.php of a child theme is processed before the functions.php of the parent theme. Both the parent and child theme functions.php are processed, unlike header.php files.

If you’re the least bit unsure about messing with header.php, then just use functions.php to queue up your javascript files. Don’t forget the opening and closing PHP tags in functions.php, else it won’t work. Put the javascript that would come after the wp_head() call in a separate .js file in the child theme and you’re good to go.

Verify that everything is working correctly by viewing the source of the HTML document for a WordPress post that should have the script included. The <script> tags should be visible in the header or in the footer depending on how the scripts were called.

Yet another good reason to upgrade your browser is to take advantage of newer features. Caching of images and other often-used files can be controlled by your browser.

IE 9 apparently has caching defaulted to ON. Firefox 5 does not.

Here’s how to enable caching in Firefox.

• Type “about:config” in the address bar and hit enter.
• Accept the warning by clicking on the “I’ll be careful, I promise!” button.
• Scroll down to ‘browser.cache.disk.enable’ and double click. You will see the value in the fourth column toggle from false to true, if caching was not enabled already.
• Scroll down to ‘browser.cache.memory.enable’ and double click to enable by setting it to true.

That’s it! The performance of your Firefox browser will speed up, noticeably so. After enabling caching, the time to download pages from a client’s site went from 6-10 seconds to 2-3 seconds!

Making the content appear quickly in front of site visitors should be a goal for all site developers. And besides, reducing the load on your server is always a good idea, don’t you think?

To cache a header image, or other images for that matter, or to make sure that files aren’t downloaded too often, use an Expires Header in your .htaccess file.

#Expire Header
<FilesMatch "\.(ico|jpg|jpeg|png|gif|js|css|swf)$">
ExpiresDefault "access plus 2 months"
</FilesMatch>

Note that all types of image files, as well as stylesheets, javascript, flash and other file types, can be cached with this Expire Header.

According to the Codex -

In Version 2.6, users were given the ability to move their /wp-content/ directory to anywhere they want, and many users already keep all WordPress files (like /wp-admin/ and /wp-includes/) in an unusual place.

In case you’ve moved the files for your WP installation, you probably have a good handle on paths and how to traverse them. For those who don’t, it can be a hair-pulling experience to find the right path. Once the right path is found, work can continue.

WordPress Paths

To help avoid those DUH! moments, here are some functions and constants that WordPress has defined regarding paths. Once you’re familiar with these functions, writing useful and working code should become easier. Optional parameters may be of use in modifying the output for several of the following templates, including $path, $file or $scheme.

plugin_basename()

Usage: plugin_basename(__FILE__); Returns: the name of the plugin and file, such as “myPlugin/myPlugin.php”

get_theme_root()

Usage: get_theme_root(); Returns: path to themes directory. No trailing slash.

get_theme_root_uri()

Usage: get_theme_root_uri(); Returns: URI for themes directory. No trailing slash.

get_theme_roots()

Usage: get_theme_roots(); Returns: Themes directory with a leading slash, like “/themes”.

site_url()

Usage: site_url(); Returns: Site directory with no trailing slash.
http://www.site.com OR http://www.site.com/wordpress

admin_url()

Usage: admin_url(); Returns: Admin directory with trailing slash.
http://www.site.com/wp-admin/

content_url()

Usage: content_url(); Returns: Content directory with trailing slash.
http://www.site.com/wp-content/

plugins_url()

Usage: plugins_url(); Returns: Plugins directory with trailing slash.
http://www.site.com/wp-content/plugins/

includes_url()

Usage: includes_url(); Returns: Includes directory with trailing slash.
http://www.site.com/wp-includes/

home_url()

Usage: home_url(); Returns: Home directory with no trailing slash.
http://www.site.com

ABSPATH (constant)

Usage: ABSPATH. Returns: Home directory with no trailing slash.

TEMPLATEPATH (constant)

Usage: TEMPLATEPATH. Returns: Path to current theme with no trailing slash.

There are a few more functions for multisite installations and backwards capability specified in the Codex.

PHP Paths

Some PHP functions worth noting -

• __FILE__ returns the filename of the script that is currently being run
• dirname() returns parent directory’s path for a given filename with no trailing slash
• basename() returns the filename component of path without any parent directories
• getcwd() returns current working directory

Use the functions or constants indicated to build your paths instead of hard-coding them. You’ll save yourself a LOT of trouble when it comes time to move your WordPress installation to a new server or directory.

WordPress takes your blog content and runs it through some backend shenanigans to create the output that you see on the screen. WP expects to find other content in posts, like text and images, not code.

To run PHP code inside a blog post or Page, you’ll have to work a little differently than simply filling up the space in the text editor.

There are two ways (at least) of using PHP inside WP blogs to produce the desired output. The first way is to set up a WP template page that points to a pre-written PHP page that is identified in a Page. The second way is to use a plugin that facilitates PHP code execution inside content areas in WordPress. Both ways have their advantages and disadvantages.

Using WP Template Pages to Execute PHP Code

A template page is used to identify a pre-written PHP page. By saying “a pre-written PHP page” I mean a .php file that you’ve already written and which has been executed successfully by a server. A template file has at the top of it a PHP comment which identifies the template name followed by an include statement that identifies the .php file. WP template files must follow this format to be properly identified by the WordPress engine as a template file.

<?php
/*
Template Name: soccer-roster
*/
include (TEMPLATEPATH . ‘/soccer-roster.php’);
?>

The above snippet  is a complete template file which indicates the name of the template as “soccer-roster” and the path to the associated PHP file, soccer-roster.php. The template file is best saved with “template” in the file name. It must be located in the site’s theme folder.

After creating the template file and .php file, upload both to the theme folder. Create a blank Page. Do not put anything where you would normally write the content, but go ahead and give it a meaningful title. On the Add New Page page, look for the “Page Attributes” widget. Click the down-arrow to expand the list of templates and select your template. Using the example above, you would select the “soccer-roster” template. If the template is not stored in the theme folder, it will not appear in this drop-down list. Save the page and preview it. The PHP code, from soccer-roster.php, should be executed just as you would expect.

PROs

• No interference from WP, code interpreted as stand-alone PHP.
• Page renders as expected.

CONs

• Can only be used with Pages, not posts or text widgets.
• May have to wrestle with adapting PHP output into style of site.
• CAUTION: Use a child-theme to safely save site-specific template files.

If your site relies heavily on plugins, using template pages may be the best method, see below. If it’s not a big deal to style the PHP output pages like the rest of your site, creating WP Pages that use templates is a breeze. If you need to put code in a post or text widget, keep reading.

Using WP Plugins to Execute PHP Code

Modifying WordPress themes is not for everyone, so using a plugin to execute PHP code may be the easier option. There are more than a handful of plugins available for the task. I chose to use Exec-PHP plugin for WordPress. It is a very well documented plugin. Thank you, Sören.

Download, unpack, upload and activate the plugin in the usual fashion. Verify these settings to make the plugin do its magic:

• Disable tag balancing by unchecking ‘WordPress should correct invalidly nested XHTML automatically’ in the Settings/Write menu.
• Disable the WYSIWYG editor (visual editor) in the user’s settings through the Users/Your Profile menu.
• Assign the ‘unfiltered_html’ capability to the user, if user is not the administrator. Can use role manager plugin to assign this capability to other users.
• Assign the ‘exec_php’ capability to the user, if user is not the administrator. Can use role manager plugin to assign this capability to other users.

Once I disabled the visual editor, my site was ready to go.

PROs

• Easy, just change a couple of settings in blog admin. Plugin gives highly visible warning on Add New Post or Add New Page pages if the settings are not correct.
• PHP code can be written in the normal fashion using the <?php ?> tags. It does not need to be marked up in any special way as it might with other plugins.
• PHP can be used in text widgets and posts, as well as Pages.

CONs

• Can’t use plugins that embellish or rely on the WYSIWYG editor.

Didn’t try any other PHP-execution plugins because Exec-PHP worked as soon as the visual editor was disabled.

As mentioned either method will get you there, it’s just a matter of style. If you need the visual editor to create your posts, use the template method. If you want to put PHP code in posts and text widgets, use the plugin method. Good luck!

The improvements in WordPress continue. Check the state of your blog’s health by running the new Health Check plugin. Currently, it will check for the versions of PHP and MySQL that are running your blog. In order to work with WP 3.2, your server will need to be up-to-date and running —

• PHP version 5.2 or greater
• MySQL version 5.0.15 or greater

In an attempt to help others into the 21st century, WordPress will no longer work using PHP 4 or MySQL 4.

WordPress will also drop support for Internet Explorer 6. Yay! There are other improvements coming, so stay tuned!

• modify the child-stylesheet to make things look how you want
• create child-directory for new child theme
• add template files to child-directory, if you wish
• upload child-directory to /wp-content/themes/
• activate new child theme

The child-stylesheet must be saved with the name “style.css” in the child-directory. The child-stylesheet header (which has to be at the top of the sheet) must contain a few lines that identify its parent theme, like so:

/*
Theme Name:     Twenty Ten Child
Description:    Child theme for the Twenty Ten theme
Author:         Your name here
Template:       twentyten
Version:        0.1.0
*/

@import url("../twentyten/style.css");

{put new style rules here}

You can add a line for the Theme URI: and Author URI:, if you like. Only the Theme Name: and Template: lines are required, the others are optional.

The @import rule indicates the directory of the parent theme and the location of the stylesheet. All you have to do is put in the new css rules below the import line.

That’s it!

If modifying the stylesheet doesn’t quite get all the changes you want, realize that you can add any template file to the child-directory and that will over-ride the parent file with the same name. For example, say you want to stick in a block for an advertisement right under the header image. Copy header.php and add a new <div> at the bottom of the page just below <div id=”main”> and stick the ad code in this division. Upload this new header.php into the child-directory and it will replace the one from the parent template.

Activate your new child theme and see how it looks!

You can just let it ride and those comments identified by Akismet as spam will silently disappear in a month’s time. In the meantime your database will be getting bigger and bloated with thousands of lines of useless information. Will this bog down your blog? Perhaps it will.

I found another reason to manually delete all the spam comments on one of my WP blogs. From the WP Dashboard I saw 1000+ spam comments and went to edit the comments. When I clicked on ‘spam’, the anti-virus software on this computer, AVG, detected a threat on the spam comments page and blocked my access to it. Even after shutting down the browser and returning to the edit spam comments page another day, the AVG software wouldn’t let me in. How could I delete the spam if I can’t get to the page to do it? Even if I could get to that page it would take a long time to delete so many comments. There must be a better solution to getting rid of spam comments in WordPress.

So, how do you mass delete spam comments in WordPress? Check out this excellent video that provides a solution using phpmyadmin and your WordPress blog database.

Steps to follow:

1. sign in to CPanel
2. open up phpmyadmin and select the WP database
3. click on “wp_comments” table and browse to see the comments
4. backup database by clicking on database name in left column, click on export tab, select all tables under Export, select SQL, check “save as file”, click Go to download database backup to your computer
5. select comments table, by clicking on the table name wp_comments, then click on the SQL tab
6. use an sql query to mass delete spam comments in WordPress by typing the following in the Run SQL Query box:

   DELETE FROM wp_comments WHERE comment_approved = 0

   Click Go, click OK.

7. Comments deleted!

If you are using a spam catcher, like Akismet, the value for comment_approved may be set to “spam”, so you’ll need to alter the query as follows:

DELETE FROM wp_comments WHERE comment_approved = ‘spam’

Don’t forget to use the single quote marks to enclose the word spam.

Verify that the number of records in the comments table has been reduced to the number of approved comments. Hooray!

Optimize the WordPress database by going to the Structure tab, or clicking on the database name in the left column, and at the bottom of the table listing click on “Check tables having overhead”. Choose “optimize table” from the spin box on the right and all the extra space that those nasty spam comments took up will be released and the database optimized.

Go back to database view and verify that the overhead space has been removed. The size column now represents the space that is actually used by the database.

Refresh your WP blog and the spam comments will be gone. Isn’t is great to see ZERO spam comments?!

Alternatively, you can catch spam before it lands in your WP blog by modifying the function.php file in your theme using these excellent directions from Tejaswini.

Also, try Soumen Halder’s list of ways to reduce comment spam on WP blogs.