Since we don't have much dependence on libraries via composer anyway, we've decided to reduce that further. For any that remain (perhaps just Semver), we plan to modify the namespace to avoid collisions with the same dependencies in other WordPress plugins that may run alongside this one.
This addresses the class of issues indicated by this support issue, where our dependence on GuzzleHttp creates a conflict with iThemes BackupBuddy.
[x] A bunch of stuff
[x] Move away from version being constrained by clients--only by the site admin
[x] Fix the ReleaseProviderIntegrationTest like the ConfigControllerTest
[x] Revisit the use of fa() as a global function for access the Font Awesome plugin singleton. Might that conflict with pre-existing functions by that name?
[x] Put all plugin modules under FortAwesome namespace to avoid namespace collision
[x] Remove Semver dependency, the last remaining dependency
[x] Fix up all integrations according to use FortAwesome namespace
[x] Revisit what is included in load_spec, both in fa()->load_spec() and the array passed as an argument to font_awesome_enqueued. Now that that version has been removed from that structure, and usePro is not included in it, it seems more strange to have that array be given a sense of priority as the load_spec.
[x] Double-check documentation for any API changes
[x] Fix security warning in React bundle
[x] Update to latest WordPress: 5.1.1
[x] Investigate error when deactivating Font Awesome
[x] Verify that integration plugin-sigma still works (Font Awesome plugin as composer dependency)
Since we don't have much dependence on libraries via composer anyway, we've decided to reduce that further. For any that remain (perhaps just Semver), we plan to modify the namespace to avoid collisions with the same dependencies in other WordPress plugins that may run alongside this one.
This addresses the class of issues indicated by this support issue, where our dependence on GuzzleHttp creates a conflict with iThemes BackupBuddy.
ReleaseProviderIntegrationTestlike theConfigControllerTestfa()as a global function for access the Font Awesome plugin singleton. Might that conflict with pre-existing functions by that name?FortAwesomenamespace to avoid namespace collisionFortAwesomenamespaceload_spec, both infa()->load_spec()and the array passed as an argument tofont_awesome_enqueued. Now that that version has been removed from that structure, anduseProis not included in it, it seems more strange to have that array be given a sense of priority as the load_spec.