Stopping the auto-formatting madness

So I put in this donation form on a page and WordPress reformats it.  A <br /> tag was inserted between a dollar sign ($) and the input field tag for the amount so the $ appears above the box on the published page.

A Google search brought me to this post which suggests a way to disable all the auto-formatting for a page or post.  That’s a little extreme for me because that would require me to reformat the whole site or a little coding on my part to say I just wanted auto-formatting turned off for that particular page.

I wanted something simpler and found it with the WP-No-Format plugin. By using a couple lines of code, I can shield select parts of my text from auto-formatting by placing <!– noformat on –-> and <!– noformat off –-> around the code I want to protect.

I love the plug-ins that do one thing and do them well.

If you like the WP-No-Format plugin, why not send the author a donation? Great work like this that saves us time should be rewarded.

Taming Multiple Loops

So I’m calling a second query inside the Loop, but after the second query ends, the primary loop should take over, right?  Not in this case.

Turned out I needed to call the function wp_reset_query(); after the secondary loop.

Here was my setup: in the page.php template, I wanted a sidebar that displayed the content of another page.  The reason is some pages will need to have the same information displayed on the side, and I wanted to be able to control this on a per page basis. (There is probably a plugin for this, but programming is so much more fun.)

So in the page editor, I set up a custom meta called “sidebar-post” and set it to the path of the page I wanted to be displayed. Back in the page.php template, I set up the WP_Query call like so:

     $sidebar_post = get_post_meta($post->ID, ‘sidebar-post’, false);
     foreach ($sidebar_post as $sidebar_postitem) {
          $sidebar_querystring = ‘pagename=’.$sidebar_postitem;
          $sidebar_query = new WP_Query($sidebar_querystring);
          while ($sidebar_query->have_posts()) : $sidebar_query->the_post(); 
               the_content();
          endwhile;
     }

I set up the code so if I wanted to, I could show more than one page. Now I was able to get this page to display in the sidebar just fine, but page contents appeared again where the primary page content was supposed to be.

I tried a trick described here under the “Multiple Loops Example 2” where you set the primary query to a temporary variable, then set it back after the secondary loop.

     <?php $temp_query = $wp_query; ?>

     <!–  secondary loop processing //—>

     <?php $wp_query = $temp_query; ?>

But that didn’t work.  The secondary query was still in control.

So after some searching I found the wp_reset_query(); function which “destroys the previous query used on a custom Loop”.

So now my code looked like this:

     $sidebar_post = get_post_meta($post->ID, ‘sidebar-post’, false);
     foreach ($sidebar_post as $sidebar_postitem) {
          $sidebar_querystring = ‘pagename=’.$sidebar_postitem;
          $sidebar_query = new WP_Query($sidebar_querystring);
          while ($sidebar_query->have_posts()) : $sidebar_query->the_post(); 
               the_content();
          endwhile;
     }
     wp_reset_query();

And, just as advertised, it killed the secondary loop query and the primary content was displaying properly.

On a side note, I am planning on getting this work with both pages and posts.

Is “site” a reserved word?

I have 2 WordPress installs on the same domain and server. Custom (pretty) permalinks worked on one, but not the other. Domain names have been changed to protect the innocent. 

I have:
http://www.mysite.com/site
which is in development. And
http://www.mysite.com/wordpress
which has been around for a while.

Both have the custom permalink setting of /%category%/%postname%/

/site gives me a 404 error.
/wordpress works fine.

Their .htaccess files are identical except that /wordpress’s says "wordpress" where /site’s says "site".

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /site/
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /site/index.php [L]
</IfModule>

# END WordPress

The server is a Deluxe Linux server on Godaddy.

I followed the standard method of waiting after setting up the permalinks on a Godaddy server. I waited for days and /site still did not work.

/wordpress did not have the custom permalinks on yet.  It started working immediately after switching. (I think there may have been an existing empty .htaccess file.)

So, same versions of WordPress, same Linux server, similar setup, no weird plugins, same .htaccess file, same database with different prefixes for the tables.

I have tried reinstalling /site using the built-in updater.  I even tried deleting the database tables and uploading a fresh install of WordPress.

Then I had the idea to rename the "site" folder thinking maybe "site" was a reserved word or something.  So I went into the General settings, changed the paths to http://www.mysite.com/web, saved changes, and used FTP to change the folder name from "site" to "web".

It worked.

Even the .htaccess file was automatically changed.

Just to be sure, I changed "web" back to "site" and the permalinks stopped working until I changed it back to "web".

Does anyone have any insight?  Is this a WordPress, Apache, or a Godaddy thing?

Postie 1.3.2 and WordPress MU

There is a problem with Postie 1.3.2 and WordPress MU.

On the blogs within my installation of WordPress MU, I would get this error when I went to the backend of the blogs that had Postie 1.3.2 activated:

Fatal error: Call to undefined function wp_get_current_user() in /<install path>/wp-includes/capabilities.php on line 920

The quickest fix was to use FTP to delete the plugin and replace it with the earlier version of Postie (1.3.1).  You can get it here:
http://wordpress.org/extend/plugins/postie/download/

I activated Postie 1.3.1 and everything seemed to be OK.

Now I just have to remember not to update the plugin until the issue is resolved.

Update: The text of the message is coming through, but it drops the subject.  It was adding “(via Postie)” until I deactivated the Postie Filter plugin. Anyone know why it’s doing this?  Please comment.

XML Sitemap Generator Plugin for WordPress error

I hate SEO.

Hate it.

Hate it to death.

But it’s a necessary evil so I have to deal.

So I am very happy when I can find plugins that will do a lot of  the work for me.

One such plugin is the popular All In One SEO.

Another is the XML Sitemap Generator Plugin for WordPress which does just as the name implies: it generates an XML sitemap for your WordPress site. An XML sitemap helps search engines crawl through your site more thoroughly. The plugin can be configured to notify various search engines of changes to your site so they will queue up your site to get crawled again to find and index the new content.  You can also add the XML sitemap URL to your Google Webmaster Tools account.

After installing the plugin I kept getting an error when I tried to manually create a sitemap:

There was a problem writing your sitemap file. Make sure the file exists and is writable.

Note: I’m running WordPress on a Deluxe Windows Hosting account at Godaddy.com

I checked to make sure the folders and files had writable permissions and they did.

Then I noticed the setting on the plugin config page called “Location of your map file”.  I wondered if the plugin was having trouble finding the proper location to write the file.

The location setting was on “Automatic” so I switched it to “Custom location” and entered the relative path where I thought the file should be.  No good.

The “Custom location” also takes an absolute path.  Using an absolute path might come back to bite me later should the server change, but I wanted to make sure this worked.  So I wrote a quick PHP script to find the absolute path of my site root (where the sitemap XML should be located):

<?php
echo realpath(“index.php”);
?>

Realpath is a PHP function that retrieves the absolute path of the specified file.

I uploaded the PHP file to the root folder of my blog and ran it on the site.  I then copied and pasted the path into the Custom Path setting.

And it didn’t work.

I gave up for the day.  I came back today to try to fix the problem and found there was an update for that plugin that was available (3.1.6 as of this writing).  I updated the plugin, and it worked!

I’m not 100% it was the update that fixed it, but it’s working now.

Just to be sure, I switched it back to the “Automatic Detection” setting.  It failed.  Switching it back to Custom worked fine.