Repository navigation
Check for pre existing inline styling rules before inserting plugin related styling #658
Description
Bug Description
As raised by one user in the support forums, in cases whereby third party plugins or WordPress core have existing inline styling added to elements of their site, without closing these rules (via a ; suffix), the Performance Lab plugin will insert it's own styling (ie. dominant color styling: --dominant-color: #736e5e;) merged in place with existing rules. This results in the dominant color styling not applying (along with the third party plugins inline styling).
While this isn't specifically a Performance Lab issue, to improve the likelihood of this happening, consider checking for pre-existing inline styling rules when inserting the dominant color and any other inline styling. If there is inline styling added via other means, check whether they are closed. If not, include a prefix ; to the dominant color styling.
Steps to reproduce
- Add a cover block to a WordPress post
- To ensure there is inline styling added, change the "Focal Point Picker", as per this recording. In this case, the inline styling will appear similar to: style="object-position:22% 59%"
- Check your sites source code, notice the inline styling isn't closed (doesn't have a semi colon)
- Enable the "Dominants Color module" within the Performance Lab configurations
- Notice that the styling added via the dominant color is merged with the Cover block styling, rendering both redundant
Screenshots
Below: Example of inline styling with the Cover block - notice there is no closing semi colon:
Below: Example of inline styling with the Cover block, with another plugin that also adds it's own inline styling to the same element - there is no distinction between the rules, they're merged.
Additional Context
- We do add a closing ; to the inline styling added via the Dominant Color option
- Tested on with WordPress 6.1.1 and newer Beta versions
- Separate GitHub issue raised on this over on the Gutenberg repo: Cover Block: Inline styling doesn't add a closing semicolon gutenberg#48258
Activity
eclarke1 commentedon Mar 3, 2023
@felixarntz I have added this to 'Infrastructure' but please do let me know if this is not correct.
cc @pbearne
mukeshpanchal27 commentedon Mar 6, 2023
@jamesozzie I spent some time attempting to reproduce the problem but was unable to do so. Can you please check it again from your end?
jamesozzie commentedon Mar 6, 2023
@mukeshpanchal27 I wonder is this because there is no dominant color styling added. I don't see any styling added when checking at present on a couple of sites (version 2.0). I don't see any when testing at present. I'll do some further testing but let me know if you can see dominant color styling on your side.
jamesozzie commentedon Mar 6, 2023
@mukeshpanchal27 I was able to create this on another site, but only after upgrading to WordPress 6.2-beta4. If you check the cover image on that page the dominant color inline styling comes after the focal point picker related styling.
The steps to recreate are the same as highlighted about, just be sure to update to WP 6.1.2 (where this also exists) or 6.2-beta4. When using the standard WP 6.1.2 the dominant color styling appears first, with a closing semi colon, resulting in no error. It should be reproducible also in other situations, if you add some inline styling to a WebP image, and don't close the CSS rule.
I can grant you a login to any of those test sites if you wish.
mukeshpanchal27 commentedon Apr 17, 2023
@jamesozzie Sorry for the late reply. I'm not able to reproduce the same issue can you please setup one demo site and share the access with me so I can check it? Thanks.
jamesozzie commentedon Apr 17, 2023
@mukeshpanchal27 I'm not longer able to to reproduce this now with WordPress 6.2 released and live.
I also tried some inline styling, however, the dominant color markup is always added first, resulting in no issue. I suspect it's still possible to encounter the issue if there is markup added before the dominant color styling, so I'm not sure how to proceed.
mukeshpanchal27 commentedon Apr 20, 2023
@jamesozzie I have raised the PR that solves this edge case issue. Check PR's description for steps to replicate the issue.