Changes between Initial Version and Version 1 of Ticket #40047, comment 4
- Timestamp:
- 03/12/2017 08:08:17 PM (8 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #40047, comment 4
initial v1 3 3 4 4 In my own projects I often use wrapper classes for WordPress objects that make interaction with them easier, and if a type supports meta, I include this functionality as I consider it valuable. So it would not benefit me personally, but I think it's useful to anyone who uses the `WP_Post`/`WP_User`/`WP_Comment`/`WP_Term` objects as is. 5 On the other hand, multisite's `WP_Site` and `WP_Network` could have something like this too, for site and network options respectively (due to recent discussions between what conceptually differs between options and metadata). If these options became available in the same way as we're discussing meta, chan ges would be high that people would unexpectedly do many unnecessary `switch_to_blog()` calls. So the possibly high complexity / cost of retrieving such a value gets kind of obscured when one can assume these values are like class properties. Not a strong argument against it, but something to consider.5 On the other hand, multisite's `WP_Site` and `WP_Network` could have something like this too, for site and network options respectively (due to recent discussions between what conceptually differs between options and metadata). If these options became available in the same way as we're discussing meta, chances would be high that people would unexpectedly do many unnecessary `switch_to_blog()` calls. So the possibly high complexity / cost of retrieving such a value gets kind of obscured when one can assume these values are like class properties. Not a strong argument against it, but something to consider. 6 6 7 7 Maybe introducing a method `get_meta()` on all of these classes would be a better solution, for explicit and clear access, and they would still make it a bit easier to retrieve metadata compared to calling `get_*_meta()` with the object's ID.