Opened 2 years ago

Closed 2 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
Priority: high Milestone: 3.2
Component: Administration Version: 3.2
Severity: blocker Keywords: has-patch
Cc: designsimply, azaozz

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

Download all attachments as: .zip

Change History (7)

  • 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.

jorbin2 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

comment:3 follow-up: ↓ 4   ocean902 years ago

  • Cc azaozz added

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

ocean902 years ago

comment:4 in reply to: ↑ 3   azaozz2 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.

  • 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.