Upgraded to WordPress 2.8 Beta 1

May 18, 2009 by 2 Comments

Upgraded to WordPress 2.8 Beta 1.  So far so good, with only one weird error:

Fatal error: Call to undefined method SearchSpider::_weak_escape()

I traced this to the Search Unleashed plugin. It interferes with several critical operations including the saving of drafts, searching, publishing, etc. I have obviously disabled it in light of this. 

As far as actual WordPress bugs I’m most concerned about, it appears they are not going to fix the Ticket Trac issue I reported to them concerning out of order comments when threading is enabled.  This does not make sense to me as this is a fairly large problem that is very reproducable.  

Comments on the bug report seem to indicate this will require a fairly big change to the comment walker, but still.

Other than that, there is nothing obviously different about the beta. The admin interface is identical with no visual changes at all that I can see.   It appears that all of my plugins have surived this upgrade cycle. *crosses fingers* 

Haven’t tested Simple LDAP Login yet but I’m hopeful.

Filed Under: Uncategorized Tagged With: ,

Comments out of order in WordPress 2.7?

January 9, 2009 by 4 Comments

I have opened up a discussion on wordpress.org about comments getting out of order in WordPress 2.7.  So far, it seems to effect the zero level comments in threaded discussions. We have yet to trace it to a repeatable scenario, but the evidence is clear.  For example:

Comment 1 - Day 1
  Comment 5 - Day 2 (reply to Comment 1)
  Comment 7 - Day 4 (reply to Comment 1)
Comment 2 - Day 1
Comment 9 - Day 5
  Comment 10 - Day 6
Comment 3 - Day 2
  Comment 6 - Day 3 (reply to Comment 3)
    Comment 8 - Day 10 (reply to comment 6)
Comment 4 - Day 2

This is a fictional example but demonstrates the problems we’re seeing.  This may lead to a official bug trac.  If you have noticed this issue, please join the discussion.  We need more examples to figure out what is causing this.

Update:

Commenter Gh. Alex has figured out how to replicate this error on any post. From his comment on wordpress forums:

I have found a pattern for this problem.
1. Doesnt’t matter how many comments you have;
2. Doesnt’t matter what theme you have installed;
3. Comments show up in order if you disable threaded comments;

By default, most of the themes with threaded comments support have that “Reply” button removed when a comment reaches 3/4/5 (depending of your options) levels of comments. That’s great but how about the edit_comments.php section from the admin area? The reply link is still there even if you reach your selected number of levels.
So, if you reply to a comment that has reached the max numbers of comments, from the admin area, this comment will show up in the bottom of the page and messes everything up.
I’ve made a test post to see what i mean, i can easily replicate the problem.

Very sorry for my bad english, i hope you guys can understand what i have just said:)

Needless to say, we’ll be opening up a bug report with WordPress.

Filed Under: Uncategorized Tagged With: , ,

Fixing your theme so that it works with WordPress.com Stats…

December 29, 2008 by 3 Comments

WordPress.com Stats is one of the most popular WordPress plugins.  I have tried using it in the past, but it never collected stats.  I never actually pursued a solution to this because I was using another stats plugin that was partially functional and able to give me most of the information I wanted. 

Today I spent a little time searching the WordPress support forums and found that my theme was missing a function call that the plugin relies on. 

Simply put, in your theme’s footer.php file, right above your </body> and </html> tags, you need to add:

<?php wp_footer(); ?>

And that’s all there is to it. You can be sure that this is safe to add because every theme is supposed to have this line. wp_footer() doesn’t generate any output so you shouldn’t see any changes to your site’s display.

If it still doesn’t work, be sure you are testing it while logged out. (You can always use another browser to save time.) It will not register hits from a logged in user. Failing that, if you’re using the WP-Super-Cache (as you should be) plugin, try clearing your cache.

Filed Under: Uncategorized Tagged With: , , ,

Simple Post Template Version 1.0

December 24, 2008 by Leave a Comment

Over the past few days I made some fairly significant changes to Simple Post Template.  If you are upgrading, be sure to read the upgrade instructions first!

In short, I’ve moved away from flat files and now store the template in the database. I execute PHP statements using eval. (A pretty nifty PHP function!) All settings are now stored and modified in the WordPress administration pages and you can select whether or not to prefill new posts with your template or click a button on the new post page.

New administration panel.

New administration panel.

New button (only appears when auto fill is deselected in admin panel)

New button (only appears when auto fill is deselected in admin panel)

I for one like the result.

That’s all for now.

Filed Under: Uncategorized Tagged With: , ,

How To Fix WordPress Automatic Upgrades in WordPress 2.5. – 2.7 (Plugins and WordPress)

December 9, 2008 by 18 Comments

Note: These instructions assume Apache is running as the user apache under the group apache. This may not be how your installation is setup.  For instance, my MediaTemple account runs apache under the user clifgriffin.com and the group clifgriffin.com.  Your mileage may vary.  Substitute your user and group for apache and apache in the instructions below.

If you’re looking for a quick solution, skip down to “The easy way”.

I manage three WordPress installations currently. Two are personal.  One is for my employer.  The personal installations are hosted with MediaTemple. The other is hosted internally on a Dell server with RedHat.

Quite awhile ago, I upgraded this WordPress installation to 2.5.1. At the time, I noticed that automatic plugin upgrades were not functioning, but I didn’t bother to figure out why.  After I upgraded to 2.7-RC1, I noticed that the same fate had befell WordPress upgrades. I couldn’t automatically upgrade WordPress or plugins.

When trying to upgrade, I would be presented with a screen asking for my FTP information, including hostname, username, and password.

So, today, armed with absolutely nothing else to do, I decided to attempt to fix this problem.  Initially, I was suspicious that the only way WordPress can do upgrades is by utilizing an ftp server on the current machine.  Fortunately, this was not the case–in fact its the last resort. While a few Google searches turned up nothing initially, I eventually found this which led me to this.  In this article, Keith outlays a few steps to fix this (if you need to fix this, do not perform the following steps…there is an easier way…read on):

  • Change the group for the wp-content/plugins directory to apache.
  • Manually define a WP_TEMP_DIR
  • Set write permissions for this folder and assign apache as the group for this folder as well.
  • Lastly, he recommends replacing the function getmyuid() with posix_getuid() in wp-admin/includes/file.php

This last step he identifies as either a bug or a feature. (He isn’t sure which.)

These steps seemed to fix the problem–especially the last one–but I wasn’t satifised the result. I’m using WordPress 2.7-RC1…that means this problem has persisted two major versions.  I decided to investigate further.

As Keith explaisn, getmyuid() and posix_getuid() return two different things.  getmyuid() returns the UID of the person who owns the script that is running.  posix_getuid() returns the UID of the process running the script.  This led me to believe that the underlying problem was not a bug and simply an issue of file ownership.

The easy way:

I reverted the changes to /wp-admin/includes/file.php and proceeded to do a recursive ownership change across my whole WordPress installation. I also made sure that wp-content/ was user writeable.  Simply put, run the following commands from the directory in which WordPress is installed:

chown -R apache:apache *
chmod 755 wp-content/

The first command sets both the owner and group of all files and folders in the current directory to apache.  It is important to do this because WordPress uses the apache user to accomplish the upgrade. If any of the files are owned by your user, root, or anyone else, it will fail.

After I made these changes, I was able to do all upgrades (both plugins and WordPress) with no issues.  Keith’s instructions are very nearly correct. They simply overlook the owner and focus on the group. The group may be important, but it isn’t the problem in this scenario.

If you do not have root access…

If you do not have root access, you will not be able to change ownership of the files.  You should be able to compensate for this with more liberal permissions.

If this is true for you, try setting wp-content/ to 775 instead of 755.

So, in short to enable automatic plugin upgrades on WordPress 2.5.1 and later:

  1. Change owernship and group of all WordPress files to apache.
  2. Make sure the wp-content/ directory is writeable by apache.

[Thanks to commenter Daniel for non-root user instructions.]

Filed Under: Uncategorized Tagged With: , , ,
«Older Posts