Plugins API - inconsistent results for short_description if being trimmed.

[polevaultweb]

My plugin has a short description longer than 150 characters in the readme.txt (due to the ampersand being turned into it's HTML entity taking it over the limit).

However, the API request for 'plugin_information' returns different results for the short_description at different times of the day.

curl --location -g --request GET 'https://api.wordpress.org/plugins/info/1.2/?action=plugin_information&request[slug]=wp-user-manager&request[fields]=short_description'

It can return:

The most customizable profiles & community builder WordPress plugin with front-end login, registration, profile customization and content restrict …

Which is 150 chars if you don't count ' …'

But then a later call to the API returns:

The most customizable profiles & community builder WordPress plugin with front-end login, registration, profile customization…

It feels like some double trimming is happening somewhere along the line.

[dd32]

In 10565:

Plugin Driectory: Readme: When trimming the short_description to length, decode HTML entities first to limit it to displayed length rather than computed length.

This also ensures that the … is only applied after a shortened string, and restores the functionality to limit it to a full setence if one ends between characters 120-150.

See #5570.

[dd32]

I'm unable to find any double trimming, as the trimming only happens at plugin import stage, not during the API requests.. I'm going to leave this ticket open though and keep running some API requests to see if it can be caught.

If you see it happen again, checking what this other API returns might be useful:

curl --silent 'https://wordpress.org/plugins/wp-json/plugins/v1/plugin/wp-user-manager' | jq .short_description

In [10565] above I did alter the import process to account for encoded HTML entities in the determination of whether it needs to trim or not, it's still counted during the actual trimming, just not during the determination of whether to do so.

$ curl --silent --location -g --request GET 'https://api.wordpress.org/plugins/info/1.2/?action=plugin_information&request[slug]=wp-user-manager&request[fields]=short_description' | jq .short_description

"The most customizable profiles & community builder WordPress plugin with front-end login, registration, profile customization and content restriction."

I had considered that maybe the scenario here was a bad translation, but it doesn't look like this plugin has any translated descriptions, and looking at other translated plugins, the short_description translations aren't trimmed to 150char, eg, Hello Dolly spanish at 157char:

$ curl --silent --location -g --request GET 'https://api.wordpress.org/plugins/info/1.2/?action=plugin_information&request[slug]=hello-dolly&request[fields]=short_description&request[locale]=es_ES' | jq .short_description
"Esto no es solo un plugin, simboliza la esperanza y entusiasmo de toda una generación resumidos en las dos palabras más famosas cantadas por Louis Armstrong."

[polevaultweb]

@dd32 thanks for looking into this.

Running my CURL command today gets the shorter incorrect result
​http://g.recordit.co/uUBcRRVjMM.gif

Running your command with the different API returns the full data

❯ curl --silent '​https://wordpress.org/plugins/wp-json/plugins/v1/plugin/wp-user-manager' | jq .short_description
"The most customizable profiles & community builder WordPress plugin with front-end login, registration, profile customization and content restriction."

[polevaultweb]

Weirdly, the plugin_information API request just briefly returned the full non trimmed content, then on the next request went back to the incorrect shorter text

[dd32]

This appears to be fixed, I haven't been able to duplicate it in the last 2 months with various checks being run against multiple plugins.