Make WordPress Core

Changes between Initial Version and Version 1 of Ticket #55942, comment 73


Ignore:
Timestamp:
05/07/2023 06:57:32 PM (12 months ago)
Author:
azaozz
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #55942, comment 73

    initial v1  
    33> I'm sorry but this is not correct. You're referring to what register_setting() was intended for use originally, but that hasn't been the case since 4.7, so at this point for longer than 6 years. The function is also responsible for...
    44
    5 Yea, you're right. I think I understand where you're coming from. Unfortunately the "expansion/refactoring" in 4.7 made this a "try to do everything" type of function which is pretty bad design from software architecture point of view. So now it has many flaws and mixes up settings for HTML form elements with settings for the REST API and with settings for the retrieval of data from the database. Thinking it is a bad idea to continue to expand its scope.
     5Yea, you're right. I think I understand where you're coming from. Unfortunately the "expansion/refactoring" in 4.7 made this a "try to do everything" type of function which is pretty bad design from software architecture point of view. So now it has some flaws and mixes up settings for HTML form elements with settings for the REST API and with settings for the retrieval of data from the database. Thinking it is a bad idea to continue to expand its scope.
    66
    77> what is your concern with handling the database type for an option centrally?
    88
    9 Because it is mostly useless to try to "handle" it outside of the database. The initial idea of this ticket was to store the type of the option/meta value in the database. I.e. it is not possible to change and is set by the data type of the last `update_option()`. This would have fixed some of the "weirdness" with the options and meta APIs.
     9Because it is mostly useless to try to "handle" it outside of the database. The initial idea of this ticket was to store the type of the option/meta value in the database. I.e. it would have been impossible to change (unless hacking directly in the DB). The type would have been set by the data type of the last `update_option()`. This would have fixed some of the "weirdness" with the options and meta APIs.
    1010
    1111Unfortunately it became clear that this is pretty much impossible to implement without breaking back-compat, and would introduce edge cases with caching. Trying to use external "register" comes with pretty much the same strings attached, and in addition there is a chance for it to become out of sync with the values in the DB. That would be a disaster :)