Fix URL length calculations for long Permalinks

[justinmaurerdotdev]

Description of the Change

There were a couple of issues present having to do with the calculation of tweet length.

First, the calculation for the Classic Editor was using the permalink preview to calculate the hypothetical permalink length. That's great until the permalink gets long, and then the preview is shortened with "...". So, the real permalink would be longer than the calculated one.

Second, Twitter currently shortens all URLs to 23 characters. So, technically, any URL should just be calculated as 23 characters.

From https://developer.twitter.com/en/docs/counting-characters

URLs: All URLs are wrapped in t.co links. This means a URL’s length is defined by the transformedURLLength parameter in the twitter-text configuration file. The current length of a URL in a Tweet is 23 characters, even if the length of the URL would normally be shorter.

From https://developer.twitter.com/en/docs/tco, evidently there's an API endpoint that returns the current maximum URL length. In some cases, shorter URLs may not reach the maximum length, but in all cases, the maximum is the maximum.

In this PR, I:

• Set up a new constant, AUTOSHARE_FOR_TWITTER_URL_LENGTH, to store the current URL length published by Twitter. This could be set to false to revert to using the real URL lengths. This could be refactored to get the most current value from the help/configuration endpoint, as described here.
• Localized that Twitter URL length value in localize_data() as adminAutoshareForTwitter.twitterURLLength.
• Added a way of calculating the accurate hypothetical permalink length for the Classic Editor (I haven't worked with Gutenberg much, and did not spend any time checking the implementation there).
• Set the default behavior everywhere to use the twitterURLLength value instead of the actual permalink length. twitterURLLength can be set to false in the localize_data() implementation to force real permalink calculations (because each implementation falls back to real permalink calculation when the twitterURLLength is false.
• Modified the compose_tweet_body() method to also use the defined twitter URL length for its calculations.

How to test the Change

To be honest, I am not familiar with the Cypress framework enough to write an automated test. And I'm not sure if all of the files I've touched are in scope for those types of tests anyway. I would be happy to help pair-program tests for this, or dialogue about them here.

To manually test the correct functionality, there are two scenarios to test: 1) the correct default, which is to treat all URLs as the same length and 2) the fallback, in case we want to disable that feature.

To test the fallback

• Set the AUTOSHARE_FOR_TWITTER_URL_LENGTH value to false in the main plugin file.
• Start a new post.
• Write a title that exceeds WordPress's permalink preview length (e.g. "This is my super duper, really long post title that definitely isn't going to fit in the preview").
• The calculated tweet length should be exactly the length of the intended permalink plus the 5-character padding.
• Then try to write a custom tweet.
• The tweet body validation should properly use the real permalink length, so that the calculated length is the true permalink + the length of the message + the 5-character padding.

To test the currently-intended behavior

• Set the AUTOSHARE_FOR_TWITTER_URL_LENGTH value back to 23 in the main plugin file.
• Start a new post.
• Write a title that exceeds WordPress's permalink preview length (e.g. "This is my super duper, really long post title that definitely isn't going to fit in the preview").
• Try to customize the tweet with content that is exactly 252 characters long. 280 - 23 (the current maximum URL length for tweets) - 5 (the pre-existing padding used for the plugin).
• The tweet should be successful/valid at 252 characters, no matter what the URL length.

This should work in Classic Editor and Gutenberg (I think, but wasn't sure about the plugin build process). In both cases, the Tweet should successfully send without errors when the post is published.

Changelog Entry

Fixed - Bug fix for issues calculating tweet length

Credits

Props @justinmaurerdotdev

Checklist:

• I agree to follow this project's Code of Conduct.
• I have updated the documentation accordingly.
• [see my comments above] I have added tests to cover my change.
• [?] All new and existing tests pass.
  I get Error: ENOENT: no such file or directory, scandir '/Users/justinmaurer/.wp-env' When I try to run the cypress:run script. I'm not really familiar with .wp-env and don't know what's expected to be in there (or how to set it up).

I'm aware there is probably some discussion or cleanup needed to make my commits fit the package standards, but I wanted to submit it at this stage to get some feedback about what exactly is missing, and whether there's some other plan (or better way) to handle this.

[iamdharmesh]

@justinmaurerdotdev Thank you for the PR and for sharing useful information on how Twitter counts URL characters. I will get this reviewed very soon.

[iamdharmesh]

@justinmaurerdotdev Thank you for the PR and very detailed information. This is amazing. We may need to change a bit on how we want to keep using the current URL length counter for local setups instead of identifying using fallback based on the value of AUTOSHARE_FOR_TWITTER_URL_LENGTH constant. Otherwise, All looks good to me. I have added some comments on the code to check.

Thank you.

[justinmaurerdotdev]

I've refactored this a bit to have the AUTOSHARE_FOR_TWITTER_URL_LENGTH constant itself set as the plugin loads, so that that constant can be the source of truth for whether the shortening should happen, and what length to use (integer for length, otherwise it should be false). The switch is dependent on the new is_local() function, added to utils.php, as suggested.

[justinmaurerdotdev]

Sorry for the extra notifications today. Was able to test in both types of environments and realized the JS was sometimes doing string concatenation instead of numeric addition. Otherwise, I'm pretty sure this is (at least functionality-wise) ready to go. I'm not sure what it means that I'm assigned on this PR, but let me know if you need anything from me.

[iamdharmesh]

Hi @justinmaurerdotdev, Sorry for the delay in the review. Thanks for making the additional changes. PR looks amazing now. I have made minor tweaks to the usage of fixed URL length and additional slash(/) in URL length calculation in the classic editor. PR is ready to merge. Please let me know if you see anything wrong with the tweaks I made, I would love to fix it.

Thanks again for this great contribution.

[justinmaurerdotdev]

Was out of the office last week, but this looks good to me. Very glad to see this fixed. Thanks for working with me on it!