Make WordPress Core

Opened 14 years ago

Closed 14 years ago

#17546 closed defect (bug) (fixed)

Unable to publish multiple posts using QuickPress without first refreshing the page

Reported by: designsimply's profile designsimply Owned by: azaozz's profile azaozz
Milestone: 3.2 Priority: high
Severity: blocker Version: 3.2
Component: Administration Keywords: has-patch
Focuses: Cc:

Description

When publishing posts using the QuickPress widget in a blog's Dashboard you are required to refresh the page before you can post another time.

To reproduce:

  1. Open a WordPress dashboard.
  2. Publish a new post on your blog using QuickPress.
  3. Enter a new title and body content and try to publish this second post.

The Publish button will be deselected and cannot be activated to publish another post. Refreshing the page resets QuickPress so that another post can be published.

Ideally QuickPress would allow more posts without requiring a page refresh. Posting quickly with this tool is great for many users and forcing a page load is a hassle for some.

Possible resolutions:

  • Add a "Reset form" link to the updated notice that appears after a QuickPress post is saved.
  • Or, reset the form automatically after a 5-10s delay.

Attachments (2)

17546.diff (828 bytes) - added by jorbin 14 years ago.
17546.patch (1.3 KB) - added by ocean90 14 years ago.

Download all attachments as: .zip

Change History (7)

#1 @nacin
14 years ago

  • Component changed from General to Administration
  • Keywords needs-patch added; dev-feedback removed
  • Milestone changed from Awaiting Review to 3.2
  • Priority changed from normal to high
  • Severity changed from normal to blocker

This is a regression. We simply need to restore its old behavior.

@jorbin
14 years ago

#2 @jorbin
14 years ago

  • Keywords has-patch added; needs-patch removed
  • Version set to 3.2

Patch switches to using removeAttr rather then attr and an empty string

#3 follow-up: @ocean90
14 years ago

  • Cc azaozz added

Seems like a .attr() vs .prop() case.

@ocean90
14 years ago

#4 in reply to: ↑ 3 @azaozz
14 years ago

Replying to ocean90:

Yes, .attr() vs .prop() vs removeAttr() vs .removeProp() (vs .data()?). Apparently .removeProp() removes that property completely so you can't set it to true|false later. Seems the proper way for here is .prop('something', false) as in your patch.

#5 @azaozz
14 years ago

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

In [18024]:

Fix another .attr() vs .prop() case, props ocean90, fixes #17546

Note: See TracTickets for help on using tickets.