[wp-trac] [WordPress Trac] #47577: Detect HTTPS support and provide guidance

[WordPress Trac]

#47577: Detect HTTPS support and provide guidance
-------------------------------------------------+-------------------------
 Reporter:  flixos90                             |       Owner:  flixos90
     Type:  enhancement                          |      Status:  closed
 Priority:  normal                               |   Milestone:  5.7
Component:  Security                             |     Version:
 Severity:  normal                               |  Resolution:  fixed
 Keywords:  has-patch has-unit-tests needs-dev-  |     Focuses:
  note                                           |  administration
-------------------------------------------------+-------------------------

Comment (by johnjamesjacoby):

 A few thoughts.

 Some of these new function names do not follow closely the recommended
 pattern. Relatedly, that means my admittedly aging brain has a harder-
 than-expected time understanding what they are intended to do without
 additional study.

 * wp_update_https_detection_errors - update what errors, from where?
 * wp_schedule_https_detection - schedule how and for what? Cron?
 Deletion/Addition?
 * wp_is_owned_html_output - Owned by who? Me?

 ''wp_update_https_detection_errors'' seems to be named what it is because
 it calls update_option() internally (which is an assumption on my part)
 and doesn't provide much benefit to include that detail in the function
 name, as the storage mechanism is not contextually relevant. It could be:
 **wp_detect_https_errors**, which is vague about its storage but assertive
 about what it does.

 ''wp_schedule_https_detection'' is following the pattern laid out by other
 wp_schedule_ functions, which are inconsistently named as well.
 update_network_counts, update_checks, delete_old_privace_export_files.
 Youch. Maybe **wp_schedule_update_https_detection** is better, even though
 it's not great?

 ''wp_is_owned_html_output'' is introducing a new global term related to
 content ownership. I'd like this to be reconsidered to avoid any possible
 future collisions with other APIs like roles & caps, multisite networks,
 etc... For example, #5942 wants to introduce an "Owner" role. If that
 happens, this function name would probably be undesirable.
 **wp_is_local_html_output** maybe? But "local" has similar connotations
 with development environments... Not sure about this one.

 These functions are also all marked as `@access private` but not prefixed
 with an underscore. Natch, this is broadly inconsistent, but has been
 enforced as recently as 5.5.0 with
 `_wp_register_meta_args_allowed_list()`. Just want to make doubly sure
 this was considered and makes sense for these here.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/47577#comment:31>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform