Make WordPress Core

Opened 10 years ago

Closed 10 years ago

#6844 closed defect (bug) (invalid)

Updated to 2.5.1 - Can't save/publish new posts

Reported by: ZeusII Owned by:
Milestone: Priority: normal
Severity: normal Version: 2.5.1
Component: Administration Keywords: new post, administration
Focuses: Cc:


I've just updated to 2.5.1 (replaced all files and run upgrade.php). Everything works fine with the exception that I can't save or publish new posts.

Once I enter the post or edit page for a blogpost, the save and publish buttons start flashing and Browser CPU usage goes up to 100% till I exit the page.

Tried with Opera 9.5b2, Firefox and Iexplore 7.0. Also tried disabling ALL plugins and disabling WPLANG to default to english. Tried disabling the advanced text editor (tinymce) in profile without success.

My server information: PHP 4.4.4-8+etch4 MySQL 5.0.32-Debian_7etch1-log Apache 2.0 (don't know the exact version)

Change History (19)

#1 @ZeusII
10 years ago

Forgot to mention, the page or adding or editing "pages" works fine.

#2 @mdawaffe
10 years ago

As an interim workaround, you can probably disable JavaScript.

#3 @ryan
10 years ago

Possibly related to #6707. I cannot reproduce in Firefox or Safari on Mac OS or Firefox on Linux, however. Have you tried doing a force reload or clearing browser cache?

#4 @ZeusII
10 years ago

mdawaffe', disabling javascript allows me to edit/post new entrys. that's what I'm doing right now.

ryan, I tried erasing all the cache and with browsers that didn't have any cache at all from my blog as I usually use Opera only :)

Also I redownloaded the 2.5.1 package and reuploaded it to the server but the problem persists.

#5 @ryan
10 years ago

Tried with Opera 9.27 and couldn't reproduce. Will try with Opera beta next.

#6 @DD32
10 years ago

I'm running the latest Opera 9.5 Builds (95b2 build 9945) on branches/2.5 right now and theres no JS issues with publishing on my end.

The only issue i've seen was previously Opera would crash when inserting a link with TinyMCE, but that issue is fixed now..

#7 @ZeusII
10 years ago

It's not a browser dependand issue as I tried with different ones.

This is really a major problem and I don't know what to do, It's javascript related for sure.

My site it's now unusable :7

#8 @rainwater
10 years ago

Do you have any plugins hooking into the admin page (or themes)? With 2.5.1, my posts page broke because of some changes that I haven't tracked down. Apparently using ob_start from the admin_head is no longer possible (I was using it to hide categories). I do wish this behavior is changed back to the 2.5 implementation.

#9 @ZeusII
10 years ago

I disabled all the plugins 3 times but the problem persisted.

#10 @ZeusII
10 years ago

I've done a fresh installation on another folder of my server and this one works fine, what could be the problem with my main installation then?

Tried removing plugins, putting default theme, no luck... save/post buttons keep flashing and cpu goes up to 100%


#11 @ZeusII
10 years ago

  • Resolution set to fixed
  • Status changed from new to closed

Well, after many try's, I finally solved the problem

I really don't know the cause. I just deleted "everything" (including htaccess) in my web folder, and reuploaded all the files (from the same 2.5.1 as before).

At this moment, my site was with the default theme and all the content I had before, no plugins enabled. Post page worked fine. Reenabled permalinks, everything ok.

Then, I reuploaded, enabled and configured all the plugins I got installed (one by one) testing the site and the post panel. Finally I reenabled my theme.

I don't know what could have happened, but everything is working fine after doing this, so I asume there was some strange problem with my installation.

#12 @DD32
10 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

#13 @DD32
10 years ago

  • Resolution set to invalid
  • Status changed from reopened to closed

#14 @michaelpark
10 years ago

  • Resolution invalid deleted
  • Severity changed from blocker to normal
  • Status changed from closed to reopened

I'm having the same problem, and I can';t seem to fix it by uploading fresh files.

I do have the Word Count patch (http://trac.wordpress.org/ticket/4807) implemented. Could that cause this behavior?

#15 @beaulebens
10 years ago

I just started seeing this problem on a test installation of WPMU (which I don't think was doing it before), but it appears to be somehow related to the WP core files.

I am seeing (through Fire-Bug) that the page is repeatedly requesting "admin-ajax.php" via AJAX, and the response it gets back is "0". It's just sitting there doing this over and over which is what loads the CPU and prevents anything useful from happening on the page.

Don't know if that helps.

#16 follow-up: @DD32
10 years ago

I am seeing (through Fire-Bug) that the page is repeatedly requesting "admin-ajax.php" via AJAX

You cant see what the Post Params are can you?

#17 in reply to: ↑ 16 @beaulebens
10 years ago

Replying to DD32:

You cant see what the Post Params are can you?

I was just getting that together actually :)

When I go to edit a post, the form POST data being sent to admin-ajax.php is empty. When going to post a new entry, the POST contents are (copied from Fire Bug, so each line is key<tab>value):

action	autosave
autosave	0
autosavenonce	f8a933b6fa
comment_status	open
ping_status	open
post_ID	-1209520678
post_type	post
temp_ID	-1209520678

#18 @intoxination
10 years ago

The problem in MU is different. I just attached a patch on MU's track for that problem:


Something you might want to do is view the source on the write post page and see what the autosaveinterval is set at:

<script type='text/javascript'>
/* <![CDATA[ */
	autosaveL10n = {
		autosaveInterval: "AUTOSAVE_INTERVAL",
		previewPageText: "Preview this Page",
		previewPostText: "Preview this Post",
		requestFile: "http://crooks.ath.cx/wp-admin/admin-ajax.php",
		savingText: "Saving Draft&#8230;"
/* ]]> */

That's the output from MU and as you can see the constant for AUTOSAVE_INTERVAL wasn't set in wp-settings, so it echoed out the constant name. Perhaps your wp-settings.php file didn't overwrite when you upgraded?

#19 @michaelpark
10 years ago

  • Resolution set to invalid
  • Status changed from reopened to closed

I apparently forgot to upload the upgraded files in the root folder; e.g., the "wp-settings.php" file. The problem has now disappeared... so intoxination is correct.

Note: See TracTickets for help on using tickets.