Jetpack Extensions: Use different keys to avoid conflicts between WP and JP extensions - #19665
Conversation
Generated by 🚫 dangerJS |
You can test the changes in Jetpack from this Pull Request by:
|
You can test the changes in WordPress from this Pull Request by:
|
There was a problem hiding this comment.
Hi @hassaanelgarem 👋🏼 . Thank you for working on this! I left one non-blocking suggestion, and the changes are looking good to me.
This change means we will have to migrate the extensions' data since they are no longer shared between WP and JP. This will be done in a coming PR [...]
Please note that this PR and the changes you've planned in the next PR need to be all-or-nothing; If we merge this, we must also merge the addition to the migration process.
My recommendation is to either put everything in this PR or don't merge this PR until both the PRs are green. I can't help but think about the risks due to the very tight time constraints 😅
What do you think?
|
|
||
| import Foundation | ||
|
|
||
| @objc extension AppConfiguration { |
There was a problem hiding this comment.
As we will be having a couple of "similar-but-different" configuration files, (e.g., WidgetConfiguration, AppConfiguration, AppConstants), I think it would help to add some documentation/warning here (and in the counterpart file) stating that the keys must be in-sync with the counterpart file.
While this doesn't entirely prevent mistakes, I feel it still helps to deter human errors. More detail on this: #19479 (comment)
There was a problem hiding this comment.
Thanks for linking this comment thread 👍.
Yes, we went for this solution without too many discussions, simply following the pattern that was already established with AppConfiguration files. However, it does have drawbacks with discoverability and the necessity to build both targets to ensure there're no errors.
|
|
||
| import Foundation | ||
|
|
||
| @objc extension AppConfiguration { |
momo-ozawa
left a comment
There was a problem hiding this comment.
Works as described. Will we be able to target 21.3, given the code freeze is coming up very soon?
| var wordPressNotificationsEnabled: Bool { | ||
| get { | ||
| guard let userDefaults = userDefaults, | ||
| userDefaults.value(forKey: WPNotificationsEnabledKey) != nil else { |
There was a problem hiding this comment.
There'll be conflicts with these after my latest merge.
WPNotificationsEnabledKey and subsequently AppConfiguration.Extension.NotificationsService.enabledKey are no longer needed and could be deleted.
# Conflicts: # WordPress/Classes/Services/NotificationFilteringService.swift # WordPress/Classes/System/Constants.m
…ns-copy-data # Conflicts: # WordPress/Jetpack/Classes/Utility/DataMigrator.swift
@dvdchr Agreed. I've added a "Do not merge" label, and I'll remove it once #19666 is ready. @mokagio FYI. |
dvdchr
left a comment
There was a problem hiding this comment.
Just noticed a typo 😅 But it's looking good overall. ![]()
…copy-data Jetpack Focus: Copy Extensions' data to JP
Fixes #19591
Description
This PR fixes an issue where jetpack extensions were conflicting with WP extensions. This is done by using different keys for the WP and JP extensions.
P.S: This change means we will have to migrate the extensions' data since they are no longer shared between WP and JP. This will be done in a coming PR and will follow the same pattern as the one in #19663, that's why this PR depends on #19663's branch.
Testing Instructions
Regression Notes
Potential unintended areas of impact
N/A
What I did to test those areas of impact (or what existing automated tests I relied on)
N/A
What automated tests I added (or what prevented me from doing so)
N/A
PR submission checklist:
RELEASE-NOTES.txtif necessary.