fool4Christ

Okay, I’m not out of ideas just yet.

Try this, taking advantage of the WordPress template hierarchy:

Create a home.php template file with the modified index.php code copied into it — the code to call the two most recent posts.

In index.php, place the default post display code.

This way, whenever the main page is displayed, home.php will be used. On paged displays, index.php should be used.

Ah, good call, spencer. I didn’t notice that at first in FireBug. It does indeed look like the problem is caused by one or more unclosed DIV tags appearing within the posts.

This post in particular seems to be the culprit:
https://puuurfectdesigns.com/blog/archives/10

Editing it in the plain text editor to remove any unnecessary tags — looks like all that’d be necessary is the em tag around the last bit of the post — should do wonders for you. ??

It looks like both your sidebar and your footer code are wrapped in the same DIV elements that your main content column is.

It looks as though moving the sidebar & footer DIVs down below the close of the #content DIV should fix it up.

If you are not comfortable performing the alterations yourself, you are welcome to ZIP up your theme files and email them to me at rick.beckman @ gmail.com and I will send you the altered files as soon as possible.

When you say it displays index.php again, I’m not sure what you mean.

Is it only displaying two previous posts, as opposed to ten?

If that’s the case, perhaps a conditional in index.php is in order, something along the lines of this:

<?php if ( is_home() ) query_posts('posts_per_page=2'); else query_posts(); ?>

Adam, I’m not sure what would be causing the Fatal Error; however, I can suggest an alternative means of switching the privacy options.

Visit wp-admin/options.php on your blog. If you haven’t come across this screen before, don’t be surprised — it’s not linked to anywhere within the admin panel. It’s purpose is simply to show all of your blog’s configuration options — anything placed in the options table of your database, whether plugin, theme, or core. Be careful what you change within this screen!

Anyway, you’ll want to find the blog_public option in that list. If you want your blog to be indexed by search engines, make sure blog_public option is set to 1 and save.

Finally, visit your blog and View Source. Ensure that the following bit of code does not appear:

<meta name='robots' content='noindex,nofollow' />

I tried that first, actually, adding the “10” when I saw that “priority” variable mentioned on the Codex. I added it thinking it might make a difference.

It didn’t. Neither works.

You can check out my currently used code here:
https://rickbeckman.org/wp-content/plugins/php-linkifier.phps

Still doesn’t work. :\

Anyone have any ideas on what I can check to see why this isn’t working?

Are more details needed?

Andy, I had that same suspicion and verified it before posting here. I even hardcoded both the Blog & Site URLs within wp-config.php so there wasn’t any question about it.

:\

(I’m enjoying the stats immensely on a handful of other blogs, though. Great job!)

Tags help to categorize your posts with sites like Technorati, so yes, they may provide a benefit in attracting visitors.

Tag archives on your blog itself also provide search engines pages of similar content to index — in addition to simple category archives — which provides yet another entry point for visitors.

The way I look at it, categories & tags work together quite well.

Categories are like folders. Say you have these folders: Current Events, Technology, Meta, and Sports.

Those are broad; tags let you get more specific and allow you to connect content posted in one category with content in another.

For instance, you might have posts in the Technology cat about WordPress plugin releases you are interested in. Such posts may be tagged “WordPress, plugins” or so. And you may also have in your Meta category a post describing the plugins you are currently using on your own blog — again, the same tags would be used.

The depth of organization is entirely up to each user, but having categories & tags together provides a very powerful framework for organization, in my opinion.

I’m having a similar problem with a blog hosted on a subdomain. On the domain itself, I have the stats plugin (w/ API key) working fine.

On the subdomain blog, which is owned by someone else, his API key won’t work for the plugin there. It says the blog was already registered with my API key — subdomains aren’t considered separate from the domain by the WordPress.com system, it seems. When entering my API key on the subdomain blog, it works, but the stats displayed on the Dashboard are the domain’s stats, not the subdomain’s.

So if your problems are arising on a blog hosted on a subdomain and an API key has already been used on the domain itself, that may be the source of your problems.

Bump.

“ins” is an (X)HTML tag, if I’m not mistaken.. [INS]Content “inserted” into a page…[/INS] (brackets replaced by proper HTML markup, of course)…

It is used to denote information that has been edited into a post at a later date. Contrast this with the DEL tag, which denotes information to be removed from a post at a later date (or something like that).

By default, INS content is underlined and DEL content is struckthrough. Both can be altered via styling, as usual.

Hmmm, it would seem that I should have searched the Codex, as its documentation of wp_list_pages() has been quite helpful.

However, that doesn’t help fix the bug that if a Page includes the “nextpage” tag, that the menu breaks while viewing that page…

Bump.