[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:  reopened
 Priority:  normal                               |   Milestone:  5.7
Component:  Security                             |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch has-unit-tests needs-dev-  |     Focuses:
  note                                           |  administration
-------------------------------------------------+-------------------------

Comment (by flixos90):

 Replying to [comment:31 johnjamesjacoby]:
 > ''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.

 This was named based on other cron hook functions that update an option.
 `wp_detect_https_errors` might be an option, but IMO it diverges from the
 existing naming and the name of the function sounds more like something a
 3P developer would be welcome to use, which is not the case, since that
 cron hook is internal to core. `wp_is_https_supported` is the "public"
 function to use.

 > ''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?

 The lack of a pattern here is a good point, though discussing this without
 deciding on a pattern blocks this ticket due to another problem. We could
 open a separate ticket to establish such a pattern, although arguably that
 would end up as something to contribute to the WP coding standards and
 best practices. Regarding your proposal, I don't think that is intuitive
 because it schedules the `wp_https_detection` action, not the logic to
 update that option. Technically a pattern to potentially establish could
 be `wp_schedule_{$hook_name}` (i.e. `wp_schedule_wp_https_detection`),
 although that reads weird so maybe the pattern should be
 `wp_schedule_{$hook_name_without_prefix}` (`wp_schedule_https_detection`)
 - the latter is what's currently being used.

 > ''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.

 With this one, I agree there's room for improvement. I like the idea of
 "local" already better than "owned". For the site checking whether output
 comes from itself could be indicated by the "local" term - the same way
 like you could access your own server internally from "localhost" I guess?

 > 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.

 This is something I years ago had a conversation about with @boonebgorges,
 and, while this is not documented anywhere (we definitely lack a best
 practices/patterns group!), he back then said that underscore-prefixed
 functions shouldn't be used anymore and that marking them with private is
 the guidance. I've stuck with that ever since - but I guess since it's not
 documented, not everyone is aware of that.

 Let's keep discussing to see whether it's worth updating these function
 names and how. I guess we have 1-2 weeks to get this defined, but before
 RC these should be set in stone.

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