[buddypress-trac] [BuddyPress Trac] #7663: Allow using Content-Security-Policy without unsafe-inline
buddypress-trac
noreply at wordpress.org
Fri Jan 19 10:04:26 UTC 2018
#7663: Allow using Content-Security-Policy without unsafe-inline
-------------------------+----------------------
Reporter: bymiki | Owner:
Type: enhancement | Status: closed
Priority: normal | Milestone:
Component: (not sure) | Version: 2.9.2
Severity: normal | Resolution: wontfix
Keywords: |
-------------------------+----------------------
Changes (by DJPaul):
* status: new => closed
* resolution: => wontfix
* milestone: Awaiting Review =>
Comment:
Thanks for writing, @bymiki.
I can't talk for all instances, but for these two, they are dynamic
variables which handle translations for UI elements. This means we can't
put them into a JS file. Both come from use of WordPress'
`wp_localize_script()` function, which means you're going to have the same
problem with parts of WordPress.
I think this quite topical at the moment, because obvious WordPress'
Gutenberg feature requires translated strings, and I know there's work
going into WordPress to improve and perhaps change how JS translations and
other dynamic strings (nonces, etc) are handled.
See #WP10237 and #WP32067, and the myriad of linked tickets from those
(#WP39941, and so on).
I think because we have so few contributors compared to WordPress (by
orders of magnitude), this is an area we don't have resources to pioneer a
solution for, and I'd argue we don't *need* to, given the focus in
WordPress itself around this sort of area.
If a future WordPress changes the APIs in a backwards compatible fashion,
BuddyPress is fixed. If the WordPress community finds a different approach
to solve this, then yes, we'll update.
Thanks for the suggestion, and I apologise that I can't say "we'll fix
this soon".
--
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/7663#comment:1>
BuddyPress Trac <http://buddypress.org/>
BuddyPress Trac
More information about the buddypress-trac
mailing list