Admin: "You are not allowed to edit this post."

The only thing I haven’t tried is switching the site’s theme to Twenty Ten, because that would cause absolute havoc on the live site.

Just switch it for fey moments.

Thanks t-p, we’ll have to try it late at night when traffic dies down.

I guess my question is, why would the front-end theme even matter anyway? The problem isn’t in getting posts to display on the site; they display just fine. If it’s a PHP-related issue (again, no errors in the log but I need to enable E_NOTICE in the admin section) then since the PHP files are in /wp-admin/ and /wp-includes/, how could files in /wp-content/themes/ even affect a user’s ability to create a new post?

Maybe I’m overlooking something but I don’t see how they’re related.

Update #2:

So we figure the only reason the theme swap should matter are the template functions included. Since this is a business-to-business site and traffic is low on the weekends, I swapped the theme to Twenty-Eleven this morning. No luck. Even with that theme active, we still go the same error message.

The hosting company assures me that there are no corruption issues with the DB and they claim that everything looks normal. They said there were a few minor errors in the DB a few days ago, but they figured they existed before the issue arose and they went through and cleaned them up.

Very, very frustrating and confusing.

Last night the hosting company had their graveyard tech wipe the site entirely and restore it from a backup version from what we think was before the problem started showing up. Obviously this didn’t fix it or I would have just been updating on that. :\

Anyone? Bueller?

RESOLVED

Finally got this resolved. It turned out to be a problem with the WordPress database.

This morning as I was debugging, I checked the value of the hidden input field for post_ID in a developer copy of the site (on another server) that is running correctly and the version of the live site, and noticed that the field populated with the next incremental value from the DB table wp_posts, while the “broken” version returned zero.

I did some digging around and narrowed down where the incorrect value could be passed in. Firebug was showing that the site was hitting the database and getting a normal response (no “invalid username”, etc.), but it was returning “0” for the post_ID rather than what it should have been, 5746.

I went into /wp-admin/includes/post.php down to the function get_default_post_to_edit on line 403, then commented out line 423 where it grabs the post_ID from the DB and sets it. Instead, I put in $post_id = "5746" and forced it to recognize the next incremental value.

At first, it didn’t seem to do much good, but after refreshing the page a few times and trying to force it to accept, the database stored the value and allowed me to save the post with that ID.

After that I removed all of my comments and echoes and tried making a few new posts from scratch, using Firebug to track the incremental post_ID value in the hidden form input, and everything works perfectly. It allows us to save to draft, publish, and all other new post functions as normal.

As to what caused this exactly, I don’t know. I’m guessing it was some type of data “hiccup” in the database system. At least now if we ever run into this again, we know how to fix it.

Hopefully this can help someone else in the future as well.

Does anyone now if this has been fixed in 3.3.1??

SOLVED – AN EASIER SOLUTION (for me at least)

Pickleburp’s post above got me thinking so I checked the “create New Post” form’s source code and sure enough a value of zero was allocated to the hidden field “post_ID”.

I then checked the posts database table in PHPMYADMIN and found that the ‘auto_increment’ setting on the post_ID field had somehow been turned off. Switching this ON fixed the issue.

As a side note, I had imported all the posts from blogger and this may have caused the issue since many other members had run imports prior to encountering this issue.