WordPress.org

Make WordPress Core

Opened 4 years ago

Closed 4 years ago

Last modified 18 months ago

#37889 closed defect (bug) (invalid)

"Add post" overwriting a previous post in 4.6

Reported by: tgelles Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: Posts, Post Types Keywords:
Focuses: administration Cc:

Description

Since updating to 4.6, adding a second post shortly after the first, overwrites the first post. The editor is blank, but the auto-generated permalink is for the pre-existing post. This goes for CPTs and normal posts.

Additionally, I can no longer "take back" posts if someone else is editing.

I am running running PHP 5.6.22 on CentOS 6.8, Apache/2.2.15 (Red Hat)

There is a thread here with similar issues raised: https://wordpress.org/support/topic/wordpress-46-has-caused-significant-issues

http://i.stack.imgur.com/4zz5I.png

Change History (14)

#1 @SergeyBiryukov
4 years ago

  • Component changed from General to Posts, Post Types

I've seen some similar reports on Russian support forums, so apparently some certain configurations are affected, could not reproduce it though.

#2 @lukecavanagh
4 years ago

  • Component changed from Posts, Post Types to General

@tgelles

Does the same issue happen with no plugins active and Twenty Sixteen as the active theme?

#3 @tgelles
4 years ago

@lukecavanagh I cant confirm that as I am currently unable to create a simple sandbox on the server, but there in another WP multisite installation on the same server that is not having these issues AFAIK.

As such I am currently looking to see if this issue is being caused by any these network activated plugins:

Admin Menu Tree Page View
Black Studio TinyMCE Widget
Email Post Changes
KSAS Global Widgets
miniOrange SSO using SAML 2.0
mobble
Post Indexer
Post Thumbnail Editor
Query Monitor
Quick Page/Post Redirect Plugin
Snapshot
SSH SFTP Updater Support
Stage Switcher
User Last Login
User Role Editor
User Switching
Network Deactivate
WordPress MU Domain Mapping
WP Migrate DB Pro
WP Security Audit Log
WPMU DEV Dashboard

Last edited 4 years ago by tgelles (previous) (diff)

#4 @adamsilverstein
4 years ago

Hello @tgelles, thanks for the bug report!

Can you please describe the exact steps you are following to reproduce the issue?

You said "adding a second post shortly after the first, overwrites the first post." I tested creating posts in sequence several different ways including saving as draft, publishing and could not reproduce the issue. Are you creating the posts as the same user?

What happens when you try to "take back" posts if someone else is editing?

#5 @tgelles
4 years ago

1) If I tried to "take back" my posts, the page would refresh with the same prompt as before: "This content is currently locked. If you take over, X will be blocked from continuing to edit."

2) I am creating posts as the same user. My steps were:

Add New Post --> Fill out title, content, etc, publish or draft
Click "add new post" and the page would refresh,
Begin typing, but the generated permalink of the most recently created post.

Similarly, If I were to go back to the main Posts admin page, I'd have to refresh my browser to see the new post.

I made some major tweaks to my htacess file, removing the[6G Firewall 2016 sections https://perishablepress.com/6g/], plus this legacy material:

# BEGIN GZIP
<ifmodule mod_deflate.c>
AddOutputFilterByType DEFLATE text/text text/html text/plain text/xml text/css application/x-javascript application/javascript image/svg+xml application/octet-stream 
</ifmodule>
# END GZIP

and

# Browser Caching: http://code.google.com/speed/page-speed/docs/caching.html#LeverageBrowserCaching
#
# Set the cache-control max-age
# 1 year
Header set Cache-Control "max-age=14400, public, must-revalidate"
<FilesMatch "\.(ico|pdf|flv|jpg|jpeg|png|gif|js|css|swf|svg|woff|ttf|eot|otf)$">
Header set Cache-Control "max-age=31622400, public"
</FilesMatch>
# 2 DAYS
<FilesMatch "\.(xml|txt)$">
Header set Cache-Control "max-age=172800, public, must-revalidate"
</FilesMatch>
# 4 HOURS
<FilesMatch "\.(html|htm)$">
Header set Cache-Control "max-age=14400, must-revalidate"
</FilesMatch>
# Remove ETags
FileETag None

And, for now, it seems to have done the trick...? Somehow?

The url: wp-admin/post-new.php?post_type=people&wp-post-new-reload=true is now appearing whereas before I believe the '&wp-post-new-reload=true ' was not included in the URL.

I am continuing to monitor everything, but I'm wondering if those edits could be a culprit?

(n.b. post_type=people is a CPT of mine. The same behavior was happening for normal posts + any CPT)

Last edited 4 years ago by tgelles (previous) (diff)

#6 @adamsilverstein
4 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to invalid
  • Status changed from new to closed

@tgelles - Thanks for sharing the details of how you resolved this issue for your install, this may help other users who have a similar issue.

Since this was was a configuration issue with your .htaccess file and not a WordPress issue I am going to close this ticket. If you continue to see the problem and think they are related to WordPress itself, you can re-open the ticket.

#7 @adamsilverstein
4 years ago

  • Version 4.6 deleted

#8 @tgelles
4 years ago

Thank you @adamsilverstein and @lukecavanagh.

Turns out it was the expired headers in the .htaccess file. Similar solution here for those using either apache or nginx:(https://wordpress.org/support/topic/wordpress-46-has-caused-significant-issues?replies=6#post-8822970)

#9 @lukecavanagh
4 years ago

@tgelles

Glad you got the issue fixed.

#10 @SergeyBiryukov
3 years ago

  • Component changed from General to Posts, Post Types

#11 @SergeyBiryukov
3 years ago

#38881 was marked as a duplicate.

#12 @SergeyBiryukov
3 years ago

If you're experiencing this issue, try adding this to the active theme’s functions.php file to see if it makes a difference:

function add_pragma_no_cache_header( $headers ) {
	$headers['Pragma'] = 'no-cache';
	return $headers;
}
add_filter( 'nocache_headers', 'add_pragma_no_cache_header' );

Pragma is a client request header that normally shouldn’t be present in server response. In earlier WordPress versions it was added for compatibility with older IE versions that didn’t understand Cache-Control. In WordPress 4.6 it was removed as no longer necessary, see [37944].

However, some environments might have weird or invalid cache control headers, and restoring Pragma might help in that case. I’ve seen an article on this issue (in Russian), although the author didn’t fully understand the change and fights the symptom instead of the cause.

In a recent support forums thread, these Apache settings were the culprit:

<IfModule expires_module>
  ExpiresActive On
  ExpiresByType text/html "access plus 600 seconds"
  ExpiresByType application/xhtml+xml "access plus 600 seconds"
</IfModule>

<IfModule headers_module>
  <FilesMatch "\\.(x?html?|php)$">
    Header set Cache-Control "max-age=600, private, must-revalidate"
  </FilesMatch>
  Header unset ETag
  Header unset Last-Modified
</IfModule>

#13 @SergeyBiryukov
18 months ago

#41251 was marked as a duplicate.

#14 @francishunger
18 months ago

I'm using in my .htaccess for speed optimization:

ExpiresByType text/html "access plus 1 month"

Using the functions.php snippet as described above

and

putting a .htaccess into the wp-admin directory, which would set the Expires to access plus 0 seconds and overwrite the other .htaccess made the trick.

so the .htaccess in wp-admin looks like

<IfModule mod_expires.c>
 ExpiresActive On
 ExpiresByType text/html "access plus 0 seconds"
</IfModule>
Last edited 18 months ago by francishunger (previous) (diff)
Note: See TracTickets for help on using tickets.