WordPress.org

Making WordPress.org

Opened 3 years ago

Last modified 4 weeks ago

#859 reopened enhancement

Warn WordCamp organizers when their site is in Coming Soon mode

Reported by: iandunn Owned by: iandunn
Milestone: Priority: low
Component: WordCamp Site & Plugins Keywords: good-first-bug has-patch commit
Cc:

Description

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.

Attachments (9)

859.patch (16.8 KB) - added by JayantiC 20 months ago.
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.
859.2.patch (2.5 KB) - added by JayantiC 20 months ago.
I have changed editor and created new patch file.
859.3.patch (2.8 KB) - added by JayantiC 20 months ago.
Thank you for feedback. I have improved code accordingly. Please find attachment.
859.4.patch (4.2 KB) - added by grapplerulrich 4 months ago.
coming soon notice.jpeg (210.7 KB) - added by grapplerulrich 4 months ago.
859.5.patch (4.1 KB) - added by grapplerulrich 3 months ago.
859.6.patch (4.5 KB) - added by coreymckrill 3 months ago.
859-screenshot.jpeg (76.3 KB) - added by grapplerulrich 2 months ago.
859-screenshot.2.jpeg (70.3 KB) - added by coreymckrill 2 months ago.
With #FFE399 background and #23282d text.

Download all attachments as: .zip

Change History (40)

#1 @iandunn
21 months ago

#1168 was marked as a duplicate.

#2 @iandunn
21 months ago

  • Owner set to iandunn
  • Status changed from new to accepted

#3 @JayantiC
21 months ago

I am going to work on this issue.

This ticket was mentioned in Slack in #outreach by jayantic. View the logs.


20 months ago

@JayantiC
20 months ago

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.

This ticket was mentioned in Slack in #outreach by jayantic. View the logs.


20 months ago

#6 @iandunn
20 months ago

@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
20 months ago

I have changed editor and created new patch file.

This ticket was mentioned in Slack in #outreach by jayantic. View the logs.


20 months ago

#8 @iandunn
20 months ago

  • Keywords needs-patch added

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
20 months ago

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

#9 @iandunn
20 months ago

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

#10 @grapplerulrich
9 months ago

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.

#11 @melchoyce
4 months ago

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.

#12 @grapplerulrich
4 months ago

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

Last edited 4 months ago by grapplerulrich (previous) (diff)

#13 @coreymckrill
4 months ago

  • Keywords has-patch ui-feedback added; needs-patch removed

#14 @grapplerulrich
4 months ago

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' );

This ticket was mentioned in Slack in #meta by sergey. View the logs.


4 months ago

#16 @grapplerulrich
3 months ago

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

This ticket was mentioned in Slack in #meta-wordcamp by coreymckrill. View the logs.


3 months ago

#18 @coreymckrill
3 months ago

  • Keywords commit added; ui-feedback removed

@coreymckrill
3 months ago

#19 @coreymckrill
3 months ago

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

#20 @grapplerulrich
2 months ago

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

#21 @melchoyce
2 months ago

Can someone post a screenshot of the notice in question?

#22 @grapplerulrich
2 months ago

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

#23 @melchoyce
2 months ago

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

@coreymckrill
2 months ago

With #FFE399 background and #23282d text.

#24 @coreymckrill
2 months ago

  • Resolution set to fixed
  • Status changed from accepted to closed

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

#25 @grapplerulrich
4 weeks ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

@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;
}

#26 @iandunn
4 weeks ago

  • Priority changed from normal to low

This ticket was mentioned in Slack in #meta-wordcamp by iandunn. View the logs.


4 weeks ago

#28 @iandunn
4 weeks ago

  • Resolution set to fixed
  • Status changed from reopened to closed

In 6055:

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

Fixes #859
Props grapplerulrich

#29 @iandunn
4 weeks ago

Thanks @grapplerulrich, that's fixed now :)

#30 @grapplerulrich
4 weeks ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

@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

#31 @iandunn
4 weeks ago

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

Note: See TracTickets for help on using tickets.