Opened 10 years ago
Closed 8 years ago
#30279 closed defect (bug) (invalid)
"Notification Confirmation" window when saving a post
Reported by: | ricardobraz | Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | 4.0 |
Component: | Administration | Keywords: | reporter-feedback close |
Focuses: | Cc: |
Description
Recently, I found an issue at WP 4.0
In a project there was many Custom Post Types, each one of them for a specific area of the site. The user should publish his posts in respective CPTs, as WP always worked.
But, after the user click at "Publish/Update" button, gets as result a "Notification Confirmation" browser alert, asking if the user desires to leave or stand at that page. Well, if user press "leave this page" button the post all post is going to be saved.
I found what makes that non-sense window runs.
The "Publish/Update" button has 3 classes, one of them is "primary-button".
In that case, there was a Welcome Panel with a anchor tag, with "primary-button" class. When i removed that class, everything worked fine. If i return it, the message will come back.
That's seriously weird!
If a developer wants to use the same styles as "Publish/Update" button, he only would need to use the same class, that's a "principle of html". However, he will get that problem. For some reason, the publication/update process has something related with the class "primary-button", when it already has an id called "publish".
This could be changed.
The publication/update process should be related with an unique element of the page, in this case, the id="publish". So, developers could use the same style for their buttons in dashboard page, and, wouldn't receive those "Notification Confirmation" alerts.
For a dev, that's not a problem. But guess when a normal user, our customers, for example see that message in action. They think their sites aren't working well.
Hi ricardobraz,
While testing to see if this was still a bug, I couldn't reproduce this issue. Could you please test your code vs. the current WordPress trunk and see if it is still an issue. If it is, could you upload some sample code that demonstrates the issue so that it can be reproduced.