Make WordPress Core

Opened 7 years ago

Closed 7 years ago

#17546 closed defect (bug) (fixed)

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

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


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 7 years ago.
17546.patch (1.3 KB) - added by ocean90 7 years ago.

Download all attachments as: .zip

Change History (7)

#1 @nacin
7 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.

7 years ago

#2 @jorbin
7 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
7 years ago

  • Cc azaozz added

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

7 years ago

#4 in reply to: ↑ 3 @azaozz
7 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
7 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.