This works and I guess is a fine interim solution, if a little odd to use a text component strictly to render an image.
One point of note, with this approach I lose access to the alternative alignment option on mobile. For instance, it would make sense to have this left-aligned on web and center-aligned on mobile.
Is there a strong reason not to introduce width and width(mobile) attributes that would scale the source image accordingly for ultimate design flexibility?
The only option I have in that dropdown other than “Full” is “Large”. That doesn’t really give me design control, especially since I don’t know what the impact of it is on the site without trial and error. And in this case, setting it to “Large” presents the same as “Full” (i.e. it takes up the full column width).
Images like these would be used throughout the site. It should be uploaded to media once, and then should be reusable on different pages in whatever size/presentation makes sense for the page. For that to happen, having a text field where I could specify image width as px or % would be appropriate. As it is currently, I have to upload multiple copies of the same image at different sizes.
I’m using the Unyson image element, sitting inside a half-width (if I recall correctly) column, with header and text elements, inside a section.
It’s the AWS partner logo. The one there currently was sized specifically for the current space. When I replace it with a bigger image, the image takes up the full width of the column, which is undesirable.
The fix provided appears to resolve the main original issue. But I did observe a follow-up issue in the provided Beta. When I click on a menu item, I’m seeing the attached JS error in the console. It doesn’t appear to be causing a material issue, though.
Seems to be an issue in /wp-content/themes/jevelin/js/scripts.js. There are 2 instances of “a[href*=#]” that seemed to be causing the problem. I put quotes around the # and that seems to have resolved the issue.
I can’t say for sure whether that caused other collateral damage elsewhere. Also, I’m concerned my changes will be overwritten next time I update my theme. Please advise.
That looks to have resolved it for Safari; however, iPhone still only shows the image. For me, this isn’t that big of a deal, but for the fact that the page load takes a long time, as if it’s trying to download the MP4, all for no benefit. Is there a way to have the background video only play on web and just show image on mobile (or alternatively get it to play)?
One additional question. If I specify both MP4 and WebM URLs, does one get preference over the others or does everything get downloaded?
I’ve updated the page to have two sections. The first section is the problematic background video. The second section contains an “Output HTML” element with the specified video markup.
On Safari, the second section auto-starts and plays fine, so the problem seems to be limited to the background setup.
Swapping out the theme is a little more complicated. I’m not sure exactly how best to set that test up without disrupting the site.
Have you replicated this simple setup on your side?
I deactivated all the plugins per your suggestion and that didn’t fix the issue.
I changed the MP4 URL to point to a different (and much smaller) video and that didn’t fix the issue. (Note, this caused Chrome to play the new MP4, which tells me MP4 is favored over WebM. Not sure which one is preferable for the theme to pick when both are specified, or if it matters at all.)
I created a new simpler page (see URL in private) with just one section with background video. Same outcome. I tried also putting a video player element in the section/column, but it didn’t generate a video element on the page. Perhaps I did something wrong.
The URL is https://www.gavant.com/library/migrating-to-aws-cloud-case-study/. See first and second screenshot.
By setting the post style to Light (Header + Titlebar) per your screenshot, I see that lets me set the text, which is good, and it does then use the global titlebar color, which is good. But it also has other unintended style side-effects. The most notable and undesirable is that the background image extends into the header (i.e. the titlebar background image isn’t constrained to the titlebar). See third screenshot.