Warn WordCamp organizers when their site is in Coming Soon mode

[iandunn]

Sometimes organizers forget -- or aren't aware -- that the Coming Soon plugin is activated on their new WordCamp site, and they publish posts or perform other actions that they shouldn't until the site is live. Email notifications are sent out when posts are published, but users won't be able to view the posts.

Several potential solutions were ​discussed. We need to land on a solution, and then get a patch to implement it.

[iandunn]

#1168 was marked as a duplicate.

[JayantiC]

I am going to work on this issue.

[JayantiC]

I have added: 1) notification at top right corner for coming soon mode 2) Display notice at publish article page 3) User can't publish article in coming soon mode.

[iandunn]

@JayantiC, it looks like the diff shows every line as having changed, probably because your text editor changed tabs into spaces, or Unix line endings into Windows line endings, etc.

Because of that, it's very difficult to see what actually changed. Ideally, a patch should only touch the lines that need to be changed in order to complete the specific task; 1397.patch is a good example.

Can you change that setting in your editor, and then generate a new patch? You'll be able to preview the changes before upload the patch by running svn diff.

[JayantiC]

I have changed editor and created new patch file.

[iandunn]

Thanks @JayantiC, this is a good good first pass attempt.

While there are always multiple ways to solve a problem, often WordPress has a specific way of doing things, and there are a few changes that need to be made to conform to that. I also have a couple general recommendations to improve the code, and some minor nitpicky things just to make it perfect.

Major changes

• Functions should only do 1 thing, so display_coming_soon_notice() should be modularized.
• Rather than using JavaScript to print messages in the DOM at runtime, there is a WP action you can use to hook into the rendering process of the Publish metabox.
• Rather than using JavaScript to disable the Publish button, use WordPress' capabilities system to remove the publish_posts capability. See current_user_can().
• Use get_current_screen() instead of the $pagenow global. Accessing globals directly should be avoided whenever possible. the API functions are the best way to get/set data because they're forwards-compatible and will avoid creating an unintended side-effects
• You'll need to check that only the post post type is affected. Otherwise custom custom post types like Speakers would also be prevented from publishing.

Minor changes

• There's no need to pass $this by reference when registering the action callback
• add_node() should be used instead of add_menu(), since add_menu() is an alias for add_node().
• Use the reference to $wp_admin_bar that gets passed by the admin_bar_menu action handler, rather than accessing the global directly
• Check out WordPress' coding standards for PHP; there are several things related to indentation, spacing, and Yoda conditionals that need to be tweaked.
• When localizing strings, only the text itself should be translated, not the surrounding CSS, etc.
• The plugin uses the wordcamporg text domain, rather than coming-soon

[JayantiC]

Thank you for feedback. I have improved code accordingly. Please find attachment.

[iandunn]

Great, thanks :)

I think the only major change left is for the capabilities. Removing capabilities from individual roles isn't the best approach, because it has to be done to each role, and there might be roles generated by other plugins in addition to the ones that Core creates.

Capabilities are one of the least understood aspects of WP development, but typically it's best to use the user_hap_cap filter to modify primitive capabilities, and map_meta_cap to modify meta capabilities.

Minor changes:

• Use the reference to $wp_admin_bar that gets passed by the admin_bar_menu action handler, rather than accessing the global directly
• Check out WordPress' coding standards for PHP; there are several things related to indentation, spacing, and Yoda conditionals that need to be tweaked.
• block_new_post_coming_soon() should have PHPDoc
• Variable names should be clear, descriptive and self-documenting; e.g., $message instead of $msg
• Replace sample-text-domain
• ​Use placeholders for variables in translated strings

[grapplerulrich]

It would be great if we could remove the publish button while the site is in coming soon mode. I just accidentally published a post as I am updating the content.

[melchoyce]

Can someone add screenshots for the latest patch?

It would be great if we could remove the publish button while the site is in coming soon mode. I just accidentally published a post as I am updating the content.

WordCamp Boston uses the time we're in Coming Soon mode to pre-write and publish pages and posts and work on our site design — I definitely still want the ability to publish while in coming soon mode.

[grapplerulrich]

@iandunn I have fixed the items you have mentioned above.

@melchoyce I have attached a screenshot. You can still publish pages and any other post type. Only Posts would be blocked from posting. The reason for this is that Jetpack sends out emails to subscribers when you publish the post.

I think we should shorten the text in the admin bar to something like "Coming Soon" and change the background to orange. I am not that great with CSS so could use some help.

[grapplerulrich]

As discussed in the ​meeting we will disable the Jetpack emails instead of disabling publishing.

Looking into the Jetpack Subscriptions documentation I see there is an option to enable per post emailing option. I will need to test is the sending out emails is disabled by default with this filter. After looking at the code I think so but would like to double check in the UI. This would allow for emails to be sent out but only if the checkbox is disabled.

add_filter( 'jetpack_allow_per_post_subscriptions', '__return_true' );

[grapplerulrich]

@coreymckrill Sorry it took a bit longer than expected. I have changed it that no emails are sent by Jetpack when the coming soon mode is on.

[coreymckrill]

@grapplerulrich I was doing some local testing before committing and I noticed a couple of things. The changes I made were substantial enough that I wanted you to take a look before I commit (see 859.6.patch​)

• I thought the Admin Bar flag and the Edit Post notice should be more visible so I changed the color to orange, and in the base of the Admin Bar flag, moved it to the left side instead of floated right.
• It turns out that only admins have the necessary capabilities to change the status of Coming Soon mode, so I removed the links to the Customizer if the current user can't do it.
• Minor code reorganizations.

[grapplerulrich]

@coreymckrill The changes look good. The only problem that I saw is with the colour contrast between the orange background and the white text.

[melchoyce]

Can someone post a screenshot of the notice in question?

[grapplerulrich]

@melchoyce I have uploaded a screenshot. The colour used for the background is #ffb900

[melchoyce]

Yeah, that contrast is too low. Yellow backgrounds are hard — maybe something like #FFE399 background instead with #23282d text.

[coreymckrill]

With #FFE399 background and #23282d text.

[coreymckrill]

In 5956:

WordCamp: Warn organizers when their site is in Coming Soon mode

• Show a flag in the admin bar when Coming Soon mode is enabled.
• Link the flag to the relevant section of the Customizer if the current user has the capability to change the mode.
• Show admin notice on Post screens warning that subscribers will not be notified while in Coming Soon mode.
• Prevent Jetpack post notification emails from being sent whil in Coming Soon mode.

Fixes #859
Props JayantiC, grapplerulrich

[grapplerulrich]

@coreymckrill If there was no link then the text colour is white. This can be soon on any WordCamp where the coming soon is enabled but the user is not an admin.

I noticed it for WordCamp Columbus. ​https://2017.columbus.wordcamp.org/

By adding .ab-item fixes it. The correct CSS is:

#wpadminbar .wc-coming-soon-info .ab-item, #wpadminbar .wc-coming-soon-info a {
    background: #FFE399;
    color: #23282d;
}

[iandunn]

In 6055:

WordCamp Coming Soon Page: Add styles for unlinked menu bar item.

Fixes #859
Props grapplerulrich

[iandunn]

Thanks @grapplerulrich, that's fixed now :)

[grapplerulrich]

@iandunn Thanks! Sorry I was not clear where the change needed to be made. The CSS should be changed in https://meta.trac.wordpress.org/browser/sites/trunk/wordcamp.org/public_html/wp-content/plugins/wordcamp-coming-soon-page/classes/wordcamp-coming-soon-page.php#L343

Let me know if you need a patch.

The change needed to build upon 5956

[iandunn]

Ah, I missed that, thanks for pointing it out. I'll look for some time to update it. No need for a patch.

[iandunn]

In 6664:

WordCamp Coming Soon Page: Remove redundant CSS.

r6055 added styles to the CSS file, even though the rules already existed in admin_bar_styling(). This updates the latter like r6055 should have done. This also format the CSS to improve readability.

Props grapplerulrich
Fixes #859