Matt Schofield

Thanks @mrdaro

A band-aid for anyone whose Android donors are struggling with this. This will set the third slide content properly within the iframe, but with reduced textbox widths. Setting textbox width to 100% breaks the form CSS again, so don’t do that. The 210px works okay.

Follow the GiveWP documentation for customising the styles of your multi-step forms – here

I used this php snippet – here

This is the CSS I’ve used to band-aid the styling problem for focus responsive browsers (Android Edge/Chrome etc…);

@media (max-width: 551px){
		input {
		position: unset;
		width: 210px !important;
		}}

Hi Rick

This is the Google Mobile Friendly Test – https://search.google.com/test/mobile-friendly

It’s important for our pages that contain donation forms that they pass Googles mobile friendly test, which helps ensure the pages are indexed and promoted by Google to mobile devices.

To pass the test, we’ve removed Featured Images from the pages that contain multi-step donation forms. But with this issue not being specific to just Astra (also happens in Twenty Twenty), and with likely all your customers wishing to have our Donations pages indexed and promoted as highly as possible by Google, it may be worth trying to nip this problem out. We’re unlikely the only customers using featured images on Donations pages. But… like I said, the pages that contained Featured Images and Multi-step forms rendered and functioned perfectly well on both mobile and desktop. It’s possible Googles test is tripping up on something and reporting a fail in error.

@wpfangirl Your browser didn’t receive the stylesheet MIME-type it was expecting from the server. A “text/css” was called from the server, but as it doesn’t exist, the 404 gets delivered to the browser as a “text/html”. With strict MIME checking enabled, the error message you’ve received is the right one.

Thanks @jonathanbardo

I’ve set this up as per your instructions on our Stage and it works perfectly. Thank you. Have turned the threshold down to 0.01 and it’s just what we need.

Marking as resolved. Thanks

Thanks @jonathanbardo

The link below will take you to one of our pages containing the animated block.

https://complete.training/specialist/assisting-and-moving-people-facilitators-training/

Thanks

I have to disagree. It would be mostly noticed by every visitor to any page with tabs near the top of the page. And Google see’s it too, and gives it a score that impacts SEO under the Content Layout Shift assessment. Google doesn’t see or grade the CLS of objects outside of the viewport, so any tabs further down the page content have no impact. And the call for occasion for visitors to refresh a page that’s partially scrolled is minimal really.

It’s just unfortunate for our use-case that the top of the page is where our tabs are required because this is a perfect tabs plugin otherwise. And it’s unfortunate that the animation approach we need to use to hide the fouc is itself also a compromise.

We’re staging another tabs plugin at the moment that’s performing okay, but will check back in the hope you’ve found a fix at some point. A bit nervous you mentioned low priority, that’s all. Thanks again for looking.

Back behind http auth.

Thanks again for looking. Marking as resolved.

No worries.

Have enabled in case useful to review.

The fixed header does hide the tab group. But that the tab group opens to the .top of the page on a click event, and not to the active position of the uppermost (active) tab… is that intended? The content jump seems very jarring to me.

If I edit out the JS from line 180, the transition is beautiful. I’m happy to dequeue and enqueue an edit if the above is as intended though.

Thank you for looking for us. Great plugin, thank you.

Thanks.

I’ve brought the staging site out of http authentication. Please could you let me know when you’re done so I can lock it again? Thank you.

You’ll see our current tab plugin in the upper part of the page, and yours (Tabby) at the bottom. We intend to replace the old one with yours.

https://staging.complete.training/supplementary-qualifications/award-in-principles-of-coshh-level-2/

@bayejid00 I’ve found a problem since submitting my ticket that you may be able to reproduce. The WP Tabs 2.1.1 update has also impacted the styling of a plugin in the back-end.

The plugin is Search and Filter by Code Amp. To reproduce:

1/ Deactivate WP Tabs plugin
2/ Install and Activate Search and Filter by Code Amp
3/ IN WordPress Dashboard, Navigate to Search and Filter > Search and Filter.
4/ Select “Add a new search form”
5/ Observe the styling of the “Setting and Defaults panel”, with the buttons for “General… Display Results… Posts…” along the top.
6/ Activate WP Tabs plugin
7/ Repeat steps 3, 4 and 5 above. Observe the styling change to the “Settings and Defaults” panel since activating the WP Tabs plugin. The options for “General, Display Results…Posts…” etc… are now barely visible.

I hope that’s helpful and you might be able to reproduce the problem.

Thanks @bayejid00

Support ticket submitted

Thanks, @bayejid00

Unfortunately the stage needs to remain behind http authentication. Do you have an address I could share a temporary password?

Hi @agizzie. See my update to previous thread. I think our problems are possibly related. The 2.1.1 update has impacted the CSS and JS of at least one other plugin I manage. Possibly more, but I’m not seeing anything obvious. I’m sticking with 2.1.0 on our production site for now.