Changes between Version 1 and Version 2 of Ticket #55942, comment 73
- Timestamp:
- 05/07/2023 07:00:40 PM (16 months ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #55942, comment 73
v1 v2 15 15 > Cleaner that common, plain PHP, by adding an extra argument to make the function convert types? 16 16 17 Yea, imho it is a bit cleaner. Also reduces calls to `maybe_unserialize()` when the expected type is not array or object.17 Yea, imho it is a bit cleaner. Also eliminates calls to `maybe_unserialize()` when the expected type is not array or object. 18 18 19 19 > If not centrally registered, not in the database, it's guessing what the type was (intended to be) before saving. … … 29 29 > A refined register_setting/register_meta or two new, simpler register_setting_type/register_meta_type that work in some logical connection with each other, could be a way forward. 30 30 31 Not sure about that. In addition to not being backwards compatible a "central registry" would not add any value for core or plugins that just need to save some data to the DB (option or meta). On the opposite, it will be a hindrance as once registered they will not be able to change the data type as that may break other plugins' expectations. In addition other plugins may break when the original plugin is deactivated.31 Not sure about that. In addition to not being backwards compatible a "central registry" would not add any value for core or plugins that just need to save some data to the DB (option or meta). On the opposite, it may be a hindrance as once registered they will not be able to change the data type as that may break other plugins' expectations. In addition other plugins may break when the original plugin is deactivated as the "registered type" would go away.