Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Social | Hide irrelevant UI on social admin page #41393

Open
wants to merge 31 commits into
base: trunk
Choose a base branch
from

Conversation

manzoorwanijk
Copy link
Member

@manzoorwanijk manzoorwanijk commented Jan 29, 2025

Proposed changes:

  • Hide Social Notes if the Social plugin is not active
  • Hide connection screen and pricing page for WPCOM
  • Hide upgrade nudge for WPCOM
  • Add safe fallbacks for settings selectors for WPCOM
  • Hide shares data on WPCOM
  • Hide plugin footer on WPCOM
  • Hide license notice for WPCOM
  • Hide publicize toggle on WPCOM

Other information:

  • Have you written new tests for your changes, if applicable?
  • Have you checked the E2E test CI results, and verified that your changes do not break them?
  • Have you tested your changes on WordPress.com, if applicable (if so, you'll see a generated comment below with a script to run)?

Jetpack product discussion

Does this pull request change what data or activity we track or use?

Testing instructions:

  • Add the blog sticker to your site
    • wpsh
    • add_blog_sticker( 'jetpack-social-admin-page', null, null, blog-id-here );
  • Activate Social and Deactivate Jetpack
  • Goto social admin page
  • Confirm that you see the Social Notes settings
  • Now deactivate Social and activate Jetpack
  • Goto Social page again
  • Confirm that Social Notes is not visible
  • Goto social admin page for a Simple site
  • Confirm that all the UIs mentioned to be hidden in "Proposed changes" section are not visible
  • Toggle ON/OFF UTM settings
  • Confirm that it works fine
  • Turn UTM ON/OFF and share a post
  • Confirm that UTM is attached to the shared post URL

Copy link
Contributor

github-actions bot commented Jan 29, 2025

Are you an Automattician? Please test your changes on all WordPress.com environments to help mitigate accidental explosions.

  • To test on WoA, go to the Plugins menu on a WordPress.com Simple site. Click on the "Upload" button and follow the upgrade flow to be able to upload, install, and activate the Jetpack Beta plugin. Once the plugin is active, go to Jetpack > Jetpack Beta, select your plugin, and enable the update/social-hide-irrelevant-ui-on-admin-page branch.

    • For jetpack-mu-wpcom changes, also add define( 'JETPACK_MU_WPCOM_LOAD_VIA_BETA_PLUGIN', true ); to your wp-config.php file.
  • To test on Simple, run the following command on your sandbox:

    bin/jetpack-downloader test jetpack update/social-hide-irrelevant-ui-on-admin-page
    
    bin/jetpack-downloader test jetpack-mu-wpcom-plugin update/social-hide-irrelevant-ui-on-admin-page
    

Interested in more tips and information?

  • In your local development environment, use the jetpack rsync command to sync your changes to a WoA dev blog.
  • Read more about our development workflow here: PCYsg-eg0-p2
  • Figure out when your changes will be shipped to customers here: PCYsg-eg5-p2

Copy link
Contributor

Thank you for your PR!

When contributing to Jetpack, we have a few suggestions that can help us test and review your patch:

  • ✅ Include a description of your PR changes.
  • ✅ Add a "[Status]" label (In Progress, Needs Team Review, ...).
  • ✅ Add a "[Type]" label (Bug, Enhancement, Janitorial, Task).
  • ✅ Add testing instructions.
  • ✅ Specify whether this PR includes any changes to data or privacy.
  • ✅ Add changelog entries to affected projects

This comment will be updated as you work on your PR and make changes. If you think that some of those checks are not needed for your PR, please explain why you think so. Thanks for cooperation 🤖


The e2e test report can be found here. Please note that it can take a few minutes after the e2e tests checks are complete for the report to be available.


Follow this PR Review Process:

  1. Ensure all required checks appearing at the bottom of this PR are passing.
  2. Choose a review path based on your changes:
    • A. Team Review: add the "[Status] Needs Team Review" label
      • For most changes, including minor cross-team impacts.
      • Example: Updating a team-specific component or a small change to a shared library.
    • B. Crew Review: add the "[Status] Needs Review" label
      • For significant changes to core functionality.
      • Example: Major updates to a shared library or complex features.
    • C. Both: Start with Team, then request Crew
      • For complex changes or when you need extra confidence.
      • Example: Refactor affecting multiple systems.
  3. Get at least one approval before merging.

Still unsure? Reach out in #jetpack-developers for guidance!

Copy link
Contributor

github-actions bot commented Jan 29, 2025

Code Coverage Summary

Coverage changed in 3 files.

File Coverage Δ% Δ Uncovered
projects/js-packages/publicize-components/src/components/admin-page/support-section/index.js 1/6 (16.67%) -3.33% 1 💔
projects/js-packages/publicize-components/src/utils/shares-data.ts 0/7 (0.00%) 0.00% 1 💔
projects/js-packages/publicize-components/src/components/admin-page/index.tsx 15/16 (93.75%) 0.89% 0 💚

Full summary · PHP report · JS report

@manzoorwanijk manzoorwanijk requested a review from a team January 29, 2025 13:42
@manzoorwanijk manzoorwanijk marked this pull request as ready for review January 30, 2025 15:57
Copy link
Contributor

@pablinos pablinos left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we can get away with not using the is_wpcom checks. I think it might be worth having a utility function for it, rather than always checking the site.host value.

I've adjusted it to use the is_share_limit_enabled for the cards, but that seems a bit unnecessary now if we can't remove the other is_wpcom checks. I suppose the less we have the better?

@gmjuhasz Could you take a look at this please? I think we could probably merge it for the Jetpack release, and improve the WPCOM side of things before we enable it there.

: __(
'Connect your social media accounts and send a post’s featured image and content to the selected channels with a single click when the post is published.',
'jetpack-publicize-components'
) }
 
<ExternalLink href="https://jetpack.com/redirect/?source=social-plugin-publicize-support-admin-page">
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We need to update these on WPCOM, or we might be able to handle it via the Jetpack redirect code. I'm not sure if we have the current site type.

<GlobalNotices />
{ ( ! hasSocialPaidFeatures() && showPricingPage ) || forceDisplayPricingPage ? (
{ ( ! is_wpcom && ! is_woa && ! hasSocialPaidFeatures() && showPricingPage ) ||
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was thinking we probably shouldn't show the pricing page on WoA either. I think we can see the plan there, but it would make for a more consistent experience.

@@ -92,7 +92,8 @@ const SocialModuleToggle: React.FC = () => {
{ ! is_wpcom
? __(
'When enabled, you’ll be able to connect your social media accounts and send a post’s featured image and content to the selected channels with a single click when the post is published.',
'jetpack-publicize-components'
'jetpack-publicize-components',
/* dummy arg to avoid bad minification */ 0
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

TS won't be happy with this. A better solution will be to use __ in one string and _x in the other with some optional/empty context.

*
* @return {boolean} Whether the site host is wpcom.
*/
export function isWpcomSite() {
Copy link
Member Author

@manzoorwanijk manzoorwanijk Feb 3, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All these utils should ideally goto script-data js package utils, because these are not specific to Social.

But, we should use optional chaining when calling them to avoid Quad Layers plugin mess.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right, I can move them, this projects/js-packages/publicize-components/src/utils/script-data.ts also sounded like utils for script data tho.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done in f4d39a6

@tbradsha tbradsha removed this from the jetpack/14.3 milestone Feb 3, 2025
Copy link
Contributor

@gmjuhasz gmjuhasz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For me this seems to work for me well

CleanShot 2025-02-04 at 15 45 30 png

Copy link
Contributor

@gmjuhasz gmjuhasz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Now I don't see it on simple sites 🤔 Doing some more testing

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants