Changes between Version 1 and Version 2 of Ticket #14179, comment 37
- Timestamp:
- 07/21/2017 06:16:30 PM (8 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #14179, comment 37
v1 v2 3 3 I can see an issue in the case of author and author URI changes. If either of those are changed then existing users from before the switch would lose benefits of update notifications (and lose the future updates too!). 4 4 5 Also sometimes themes are willingly traded to other users - I see it mostly with themes that authors do not have time to maintain, they pass to someone who wants to maintain it. Currently the new theme owner will inherit active installs with the theme. If the UID changed with author switch then the new author will not inherit the userbase along with the theme and the pre-existing users will no longer get updates. It is expected that if a theme willingly changes hands then the existing users will come along with the theme. 5 Also sometimes themes are willingly traded to other users - I see it mostly with themes that authors do not have time to maintain, they pass to someone who wants to maintain it. Currently the new theme owner will inherit active installs with the theme. 6 7 If the UID changed with author switch then the new author will not inherit the userbase along with the theme and the pre-existing users will no longer get updates. It is expected that if a theme willingly changes hands then the existing users will come along with the theme. 6 8 7 9 To fix that newly added UIDs would need to be relational with any previously generated UIDs of the same theme so that pre-existing users are not lost (and they don't miss out on possible updates) when UID changes. 8 10 9 Linking of UIDs in this way should not negate any of the fixes for of popular/actives abuse nor the issue of non-org themes being updated from .org source of matching slug/name with the above proposal.11 Linking of UIDs in this way should not negate any of the fixes for popular/actives abuse nor the issue of non-org themes being updated from .org source of matching slug/name with the above proposal intends to deal with. 10 12 11 13 P.S. If we're thinking about CPU load then making the UIDs relational like this will almost certainly result in many more lookups and additional processing to combine stats across different UIDs. I haven't tested total load if such changes were made but I would imagine it's not a negligible amount.