Changes between Initial Version and Version 1 of Ticket #43443, comment 32
- Timestamp:
- 04/20/2018 06:31:56 PM (6 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #43443, comment 32
initial v1 4 4 Hm, if we plan for this to be reusable in the future, imho we should also plan for the log to be reusable. 5 5 6 Yeah, at first CPT may look heavier but the options table is just the wrong place to store this type of data. All options get loaded on each request, including on the front-end, which makes it a lot heavier than a CPT which is going to me loaded only when an admin visits the privacy screen.6 Yeah, at first CPT may look heavier but the options table is just the wrong place to store this type of data. All options get loaded on each request, including on the front-end, which makes them a lot heavier than a CPT which is going to be loaded only when an admin visits the privacy screen. 7 7 8 8 Another big disadvantage is that the hash, time, email are stored in a CSV which makes it impossible to look them up separately. If I remember right that was one of the main reasons a new DB table was so attractive. Given that such table will stay mostly empty on the great majority of sites, a CPT is the next best thing. … … 14 14 Hm, don't think so. `wp_count_posts()` uses a simple db query to count. We actually can do better as it has some specific stuff for posts and pages that is not needed. Making another similar function which is adapted to our needs would be the right thing in any case. 15 15 16 Also, this will be needed "once in a blue moon" when an admin visits one of the privacy screens :) 17 16 18 > > The main reason we started using CPTs was to not store the verification key in the options table :) 17 19 > 18 20 > No, the main reason for CPTs was to get a list table log without lots of heavy custom queries on meta data, since no one liked the idea of a custom table. 19 21 20 Hmm, think there has been some miscommunication here :) As a custom table would have been empty or almost empty on the great majority of sites, it d idn't make sense to add one. Even if we add one it will also need a whole new set of low-level functions to become useful. For example we would need to add or duplicate most stuff that drivethe list tables UI.22 Hmm, think there has been some miscommunication here :) As a custom table would have been empty or almost empty on the great majority of sites, it doesn't make sense to add one. Even if we added one it will also need a whole new set of low-level functions to become usable. For example we would need to add or duplicate most of the stuff that drives the list tables UI. 21 23 22 24 CPTs are the next best thing to a custom table. They can store a lot of information quite efficiently. Not using them to store the simple data needed for implementing email verification doesn't seem right. In addition, having two almost identical custom post types doesn't seem best.