rpc.pingomatic.com still using HTTP

[bhubbard]

It looks like rpc.pingomatic.com still doesn't support https. I would like to see it support HTTPS, and then have WordPress default to using https for it.

​screenshot of Update Services field

[sabernhardt]

Update Services field on Writing Settings screen

[sabernhardt]

Thanks for the report and sorry for the long delay!

The rpc.pingomatic.com subdomain still does not seem to support HTTPS, but I made a patch to update the schema for new sites if the subdomain gets SSL.

All unit tests passed with only the schema.php change. I also wanted to update the unit test to check both HTTP and HTTPS, and (only) the 7.0-multisite test failed. The failure notice mentions a timeout. (I had planned to try a pull request on my fork first. :facepalm:)

When this is completed, the ​Update Services support article will need updating (both the screenshot and the list).

[sabernhardt]

#62979 was marked as a duplicate.

[sabernhardt]

My branch is updated, and all tests passed.

I also wanted to update the unit test to check both HTTP and HTTPS

I did not explain why the unit test checks both, but I think it was because existing sites would still have the HTTP URL.

[matt]

HTTPS is supported now on rpc.pingomatic.com, so we can update the default setting if we haven't already.

[sabernhardt]

A commit probably could be backported too, but I'll add this to 6.9 for now.

Do you think it's worth updating to https in the sanitize_option() function?

The existing code for ping_sites would be replaced with something along hte lines of:

`php
case 'ping_sites':

$value = explode( "\n", $value );
$value = array_map(

function ( $url ) {

$url = trim( $url );
$url = sanitize_url( $url );
if ( str_ends_with( $url, ':rpc.pingomatic.com/' ) ) {

$url = set_url_scheme( $url, 'https' );

}
return $url;

},
$value

);
$value = array_filter( $value );
$value = implode( "\n", $value );
break;

Do you think it's worth updating to https in the sanitize_option() function?

I don't think _I_ should make a more elaborate patch, but I have a few questions and comments.

• Does the sanitize_option() replacement only run when updating some option in the Writing Settings or options.php?
• Noticing the auto-corrected Update Services field could be a _little_ awkward after the user saves changes to an unrelated option such as the default post category or format.
• I like how the example uses array_map and array_filter only once each.
• Apparently sanitize_url( trim( $url ) ) can be on one line (WP_Customize_Manager::_sanitize_external_header_video() has it that way).
• The ​list of ping services in documentation does not have trailing slash. Could this account for that possibility?

• Does the sanitize_option() replacement only run when updating some option in the Writing Settings or options.php?
• Noticing the auto-corrected Update Services field could be a little awkward after the user saves changes to an unrelated option such as the default post category or format.

I was having a dumb moment and thought sanitize_option ran when getting the options, but I must have been thinking of another filter. You're right, it would be confusing.

• The ​list of ping services in documentation does not have trailing slash. Could this account for that possibility?

I think for the root directory of a domain it's implied.

I wonder if an upgrade routine would make sense for existing sites

• Update schema.php for new sites, and try updating the unit test. - props @sabernhardt
• Add upgrade routine to set the scheme to https

Questions:

• Should sanitize_option be updated to force HTTPS? I decided against it to allow for site owners choosing not to. But I might be wrong.
• The ​upgrade services documentation includes alternative providers. rpc.twingly.com now uses HTTPS too, should that be upgraded too?

https://core.trac.wordpress.org/ticket/42007

I wonder if an upgrade routine would make sense for existing sites

I've created an alternative PR with an upgrade routine, see ​https://github.com/WordPress/wordpress-develop/pull/9085

Should sanitize_option be updated to force HTTPS? I decided against it to allow for site owners choosing not to. But I might be wrong.

I agree with your decision here. It's also not necessary as long as the DB upgrade runs.

The ​upgrade services documentation includes alternative providers. rpc.twingly.com now uses HTTPS too, should that be upgraded too?

I like this idea and it seems like it's not something that needs to wait on this change. PR submitted for that update ​https://github.com/WordPress/Advanced-administration-handbook/pull/401

[jorbin]

In 60421:

Pings/Trackbacks: Use HTTPS for services that now support it.

This updates the default on new installations for rpc.pingomatic.com to use https while also upgrading existing sites that use rpc.pingomatic.com or rpc.twingly.com to use https for those two domains.

Props sabernhardt, peterwilsoncc, jorbin, bhubbard, matt.
Fixes #42007.

[jorbin]

Reopening for second committer signoff on merge to 6.8 branch

[jorbin]

In 60422:

Pings/Trackbacks: Use HTTPS for services that now support it and update DB.

Update DB to the correct version not the version from in development.

Follow-up to [60421].
Unprops jorbin.
See #42007.

[audrasjb]

@jorbin confirming [60421] and [60422] are good for a 6.8 branch backport.

[jorbin]

In 60428:

Pings/Trackbacks: Use HTTPS for services that now support it.

This updates the default on new installations for rpc.pingomatic.com to use https while also upgrading existing sites that use rpc.pingomatic.com or rpc.twingly.com to use https for those two domains.

Reviewed by audrasjb.
Merges [60421] and [60422] to the 6.8 branch.

Props sabernhardt, peterwilsoncc, jorbin, bhubbard, matt.
Fixes #42007.

[peterwilsoncc]

There's a mismatch of version numbers in version.php and the upgrade routines following r60421 and r60422 -- I'll get a fix in in the next few hours.

[peterwilsoncc]

Replying to peterwilsoncc:

There's a mismatch of version numbers in version.php and the upgrade routines following r60421 and r60422 -- I'll get a fix in in the next few hours.

Not naming names, but someone was looking at the WP version in the built version of the code base rather than the wp-dev version of the code base 🤦‍♂️