#2934 closed defect (bug) (fixed)
Coming Soon Page doesn't completely hide WordCamp content
Reported by: | RMarks | Owned by: | RMarks |
---|---|---|---|
Milestone: | Priority: | low | |
Component: | WordCamp Site & Plugins | Keywords: | good-first-bug has-patch needs-testing |
Cc: |
Description
While setting up https://2017.birmingham.wordcamp.org and while the Coming Soon Page was enabled, I happened to share https://2017.birmingham.wordcamp.org/call-for-vounteers/ in Slack and saw the details of the page because of the Open Graph tags.
See https://wordpress.slack.com/archives/C02QB8GMM/p1499361698479917 where I brought this up and a bit of discussion.
Should the Coming Soon Page option block 100% of the site's content?
Attachments (5)
Change History (20)
#1
@
7 years ago
- Keywords needs-patch good-first-bug added
- Owner set to coreymckrill
- Status changed from new to accepted
Thanks for the report @RMarks ! I imagine that there is some meta data in the document header that we would want to keep, but certainly the Open Graph stuff doesn't need to be there when Coming Soon mode is enabled (unless maybe the Open Graph data should just be updated to reflect the mode?) It also seems to me that the RSS feed and the REST API shouldn't reveal post content while Coming Soon is active.
#2
@
7 years ago
- Summary changed from Coming Soon Page doesn't complete hide WordCamp content to Coming Soon Page doesn't completely hide WordCamp content
I've attached a diff that partially addresses the issues in this ticket. The diff removes the Open Graph tags added by Jetpack. I welcome feedback on this part.
I'm looking for suggestions on what's the best way to filter the published posts from the various feeds (/feed, /comments/feed) and search (/?s=) when the Coming Soon option is enabled.
Thanks!
#4
@
7 years ago
@RMarks the patch looks good. The only thing I would recommend, and it's fairly minor, is that instead of wp_loaded
you use an action hook that's a little bit closer to when the jetpack_enable_open_graph
hook gets fired (which happens during wp_head
). The template_redirect
hook, for example. That way, it's more likely the routine will only run on requests that are relevant to its functionality. With wp_loaded
the routine will run on nearly all requests, including those for backend WP Admin screens.
#5
@
7 years ago
Thanks @coreymckrill. I've updated the hook and attached a new diff based on your suggestion.
I'm also still looking for suggestions on the second part of my post from comment 2 above.
#6
@
7 years ago
@RMarks for the feeds, you'll want to short-circuit them using the "do_feed_{$feed}"
action hooks. See the do_feed()
function in Core.
For the search, I don't have any suggestions off the top of my head, other than to look for some similar action or filter hook that you can use to stop the search before it runs.
This ticket was mentioned in Slack in #meta by rmarks. View the logs.
7 years ago
#8
@
7 years ago
@RMarks My suggestion would be to use $feed = get_default_feed();
and add_action( "do_feed_{$feed}", function(){} );
#10
@
7 years ago
- Owner changed from coreymckrill to RMarks
- Status changed from accepted to assigned
#12
@
7 years ago
- Keywords has-patch needs-testing added; needs-patch removed
I worked with @briandichiara and @icaleb at WCUS Contributor Day to identify what filter to use to disable the REST API. Today, if you browse to /wp-json/wp/v2/pages/ or another REST endpoint, you'll see the following error:
{"code":"rest_cannot_access","message":"The REST API has been disabled while in Coming Soon mode.","data":{"status":403}}
Source of page while logged out.