Installing WordPress
This video demonstration shows you how to install WordPress. I perform a demo installation using Windows 7, Firefox and Filezilla FTP client. My website is hosted on CPanel which is used to create the database.
This video demonstration shows you how to install WordPress. I perform a demo installation using Windows 7, Firefox and Filezilla FTP client. My website is hosted on CPanel which is used to create the database.
One of the first things you should do after installing a new WordPress blog is configure backups. Though WordPress does feature an export feature that allows you to save much of your content to XML, there isn’t a full-blown backup feature built into the WordPress Core. You’ll need to download a WordPress backup plugin.
These are the minimum features that I look for in a backup plug-in. You may have different requirements than my own but if your backup plug-in doesn’t provide these features, you will eventually find it lacking.
I use DropBox to store business records and other important files, and so I’ve settled into using the WordPress Backup to DropBox plugin for most of my sites. The plug-in provides all of the features that I mentioned above. In addition it gives me access to those backups from my PC via the DropBox desktop application, and gives me confidences that my backups are occurring when I scheduled them because I can see the files updating in real-time.
Another excellent and popular plugin is Backup Scheduler. It allows you to specify what gets backed up (database, files, or everything), and has the option to send you the backup via email.
Have you ever heard people who upgrade to the latest version of Windows complain about the experience?
When you upgrade to a new operating system there’s a good chance that the update will contain flaws that need to be addressed by hotfixes and service packs, your hardware manufacturer may not have compatible drivers yet, and certain applications just won’t work.
WordPress isn’t so different. When you update WordPress you can run into incompatibilities in plug-ins, themes, and even your own customizations. WordPress updates are usually trouble-free and will only break very complex or poorly maintained sites. But problems can and do occur, so I recommend holding off a few weeks before updating WordPress sites.
Unless an update contains a fix for a known security vulnerability, let early adopters work out the kinks first before updating your blog.
Don’t rush into an update unless you really need it. You can find out just how critical an update is by checking the WordPress Development Blog widget on your WordPress Dashboard or by clicking the Current WordPress Version link at the WordPress Codex . WordPress has a lively community and you can usually expect plugin compatibility to be tested within a few weeks or months of a WordPress update being released.
There are fewer things more annoying about the WordPress platform than watching your carefully-crafted markup go straight to Hell. If you’ve used WordPress for more than 10 minutes you probably know what I’m talking about.
The primary culprit is a filter called wpautop that automatically applies to post and page content. The wpautop filter converts double line breaks to sets of opening and closing paragraph tags. It works fine if your posts are text only, contain no images, no short codes, and only the most basic inline markup. Throw a few block-level elements into a post or a shortcode or two, however, and watch your markup devolve into a tangled mess of improperly-nested tags.
You can usually tell if wpautop is causing HTML validation to fail if the W3C Validator is giving you the errors:
document type does not allow element "xxx" here
followed by
end tag for "xxx" omitted, but OMITTAG NO was specified
Seeing this combination of errors, particularly when the tag in question is a <p> tag, is a pretty good indication that wpautop is to blame.
The following are a few common solutions for living with, or without, wpautop in WordPress.
If you are comfortable with HTML markup you may be better-served by just disabling wpautop completely and specifying all of your own HTML markup when writing blog posts. You can disable wpautop either by installing a plug-in that does it for you (this one for example), or by adding the following lines to your theme’s functions.php file:
remove_filter( 'the_content', 'wpautop' ); remove_filter( 'the_excerpt', 'wpautop' ); |
remove_filter( 'the_content', 'wpautop' ); remove_filter( 'the_excerpt', 'wpautop' );
I like to use the wpautop-control plugin, which allows you to set wpautop to enabled or disabled by default, then switch it on or off on a post-by-post (or page-by-page) basis. This allows me to develop complex pages with wpautop disabled, but leave it enabled for simpler blog content created later by my clients.
I’ve recently been working on a WordPress project in which I made the mistake of starting with a commercial theme that, while beautiful and feature-rich, was a complete mess in terms of code quality. HTML validation is always a requirement on my projects, but a poorly-written WordPress theme combined with WordPress’ own tendency to butcher code by inserting poorly nested <p>’s (more on that later) can make validation a real chore.
The W3C’s Validator is a great tool and the Web Developer Toolbar‘s quick access to it makes the process go even faster. But with nearly 100 static pages to validate in addition to several hundred imported blog posts written by nontechnical authors, I needed something better.
Enter the Web Design Group’s HTML Validator. This validator isn’t that different from the W3C validator, but it provides an additional key feature: the “validate entire site” option. By checking this box the validator will spider the URL you provide and validate the first 100 pages that it finds within the same domain.