CP latest fresh nightly install with some plugins:
CP directory integration (CP directory)
Switch to CP (CP directory)
cloudflare (WP repo)
easy form builder (WP repo)
fx builder (CP directory / GitHub)
security optimizer (WP repo)
shortcodes ultimate (WP repo)
updrafts (WP repo)
w3p seo (CP directory / GitHub)
wp paypal (optional - WP repo)
wp optimize (WP repo)
Theme: Archetype (CP directory).
Going to Customizer to upload logo and clicking the Select Logo button should open a modal to effectively upload a logo, and then all the needed steps should follow in the media library.
Current behavior
What happens is that clicking the Select Logo button does nothing. The site is in debugging mode and no PHP errors are shown, deactivating plugins does not affect the issue - itâs still impossible to upload a logo. Tried reverting to The ClassicPress Theme same result.
console has these errors:
Content-Security-Policy warnings 2 An iframe which has both allow-scripts and allow-same-origin for its sandbox attribute can remove its sandboxing. customize.php MouseEvent.mozPressure is deprecated. Use PointerEvent.pressure instead. tinymce.min.js:2:8857 MouseEvent.mozInputSource is deprecated. Use PointerEvent.pointerType instead. tinymce.min.js:2:8857 An iframe which has both allow-scripts and allow-same-origin for its sandbox attribute can remove its sandboxing. customize.php
Possibly the last warning pointing to an iframe having both allow-scripts and allow-same-origin attribute in customize.php might be the culprit?
I am not a JS expert but I suspect itâs not TinyMCE because in Firefox Dev Edition these warnings about MouseEvents are common and they do not stop Customizer from working.
Since this is the latest nightly where all the changes to widgets have been released and Customizer has shown in the past that it is affected by this kind of changes, could that be related?
Possible solution
Checking if the JS code is really involved in customizer not opening the Upload Logo modal.
@timkaye I hope this is not related to all the great work you did with widgets⌠I am starting to think Customizer heard that we want to dismiss backbone.js and wants to throw tantrums.
Reverting to 2.5 stable from latest nightly fixed the issue. that site was migrated to nightly to test it so it went from being a working fresh install, to having Customizer issues to going back to stable and having no more issues.
This confirms that something in latest nightly release is the culprit.
@MattyRob While taking a look at @ElisabettaCarraraâs report, I noticed that the script at /wp-includes/js/plupload/plupload.js was changed as part of the Text widget PR. That surprised me a great deal, because I donât remember doing that and canât see why I would have because I was working with FilePond. Looking through the PR commit history, I canât see one that changes it either. And it seems to have gone back to an earlier version too.
Any idea whatâs happened there? I donât think itâs the sole cause of what @ElisabettaCarrara reported, but I suspect itâs part of the problem.
I recall that commit was issued to solve a bug where customizer was duplicating input fields in response to widget modifications. I hope reverting it wonât complicate things. And I am starting to see why people question customizer existence.
@ElisabettaCarrara - I have no reason to disagree with your description of the rationale, but the first commit I listed above, despite itâs description, simply overwrites src/wp-includes/js/plupload/plupload.js so I suspect it does not deliver the functionality expected based on the commit message.
checking better this is the PR that was used to fix that bug in customizer that I am mentioning
And is one of the many that were included in that merge. This means that those two you mention above were issued to address underlying customizer problems maybe caused by the bug or something else.
The overrides in plupload.js deal with deprecations of libraries mainly but this could not be the issue here me thinks (since the libraries were deprecated but core now has the ones to use instead that were indicated in the file).
I think restoring the plupload.js to the old is however going to affect the widgets since they now rely on the new libraries? I might be wrong because I really am not a senior dev and never handled such complex problems⌠but I suspect that the issue is not just reverting that file back.
to be noted: issues are generally coming from the intersection of these:
widgets
customizer
file upload
tinyMCE
deprecated libraries
where the bug that had the duplication of widget was directly related to widgets abd customizer, while this one âseemsâ related to media upload and customizer but it could also be something else entirely.
Great detective work, @MattyRob ! I think that commit must have been a mistake. I donât use git, but it should be easy enough to write a PR to reverse this. And I donât think doing so will adversely affect the widgets, @ElisabettaCarrara .