pracko

Thank you!

Sounds good. I’m thinking maybe a box-sizing option at the container setting level might be confusing to some (i.e. they may not know what it means or what it does without referring to documentation). But if you added the targeted CSS .gb-container > .gb-container {box-sizing: border-box;} into GB itself, there would be no confusion and the container would just act as it always did in pre-FSE theme days. Just a thought, but maybe there’s a potential conflict with flexbox that I haven’t considered. Anyway, thanks for your consideration!

Upon further research, I found this:

https://github.com/google/fonts/issues/68

Seems that its the expected behavior, so no worries.

Just as a follow-up, I notice the following in my head tag now:

/* cyrillic-ext */
@font-face {
  font-family: 'Nunito';
  font-style: normal;
  font-weight: 400;
  font-display: swap;
  src: url(/wp-content/uploads/gstatic/XRXI3I6Li01BKofiOc5wtlZ2di8HDLshdTk3j77e.woff2) format('woff2');
  unicode-range: U+0460-052F, U+1C80-1C88, U+20B4, U+2DE0-2DFF, U+A640-A69F, U+FE2E-FE2F;
}
/* cyrillic */
@font-face {
  font-family: 'Nunito';
  font-style: normal;
  font-weight: 400;
  font-display: swap;
  src: url(/wp-content/uploads/gstatic/XRXI3I6Li01BKofiOc5wtlZ2di8HDLshdTA3j77e.woff2) format('woff2');
  unicode-range: U+0301, U+0400-045F, U+0490-0491, U+04B0-04B1, U+2116;
}
/* vietnamese */
@font-face {
  font-family: 'Nunito';
  font-style: normal;
  font-weight: 400;
  font-display: swap;
  src: url(/wp-content/uploads/gstatic/XRXI3I6Li01BKofiOc5wtlZ2di8HDLshdTs3j77e.woff2) format('woff2');
  unicode-range: U+0102-0103, U+0110-0111, U+0128-0129, U+0168-0169, U+01A0-01A1, U+01AF-01B0, U+0300-0301, U+0303-0304, U+0308-0309, U+0323, U+0329, U+1EA0-1EF9, U+20AB;
}
/* latin-ext */
@font-face {
  font-family: 'Nunito';
  font-style: normal;
  font-weight: 400;
  font-display: swap;
  src: url(/wp-content/uploads/gstatic/XRXI3I6Li01BKofiOc5wtlZ2di8HDLshdTo3j77e.woff2) format('woff2');
  unicode-range: U+0100-02AF, U+0304, U+0308, U+0329, U+1E00-1E9F, U+1EF2-1EFF, U+2020, U+20A0-20AB, U+20AD-20CF, U+2113, U+2C60-2C7F, U+A720-A7FF;
}
/* latin */
@font-face {
  font-family: 'Nunito';
  font-style: normal;
  font-weight: 400;
  font-display: swap;
  src: url(/wp-content/uploads/gstatic/XRXI3I6Li01BKofiOc5wtlZ2di8HDLshdTQ3jw.woff2) format('woff2');
  unicode-range: U+0000-00FF, U+0131, U+0152-0153, U+02BB-02BC, U+02C6, U+02DA, U+02DC, U+0304, U+0308, U+0329, U+2000-206F, U+2074, U+20AC, U+2122, U+2191, U+2193, U+2212, U+2215, U+FEFF, U+FFFD;
}
/* cyrillic-ext */
@font-face {
  font-family: 'PT Sans';
  font-style: normal;
  font-weight: 400;
  font-display: swap;
  src: url(/wp-content/uploads/gstatic/jizaRExUiTo99u79D0-ExdGM.woff2) format('woff2');
  unicode-range: U+0460-052F, U+1C80-1C88, U+20B4, U+2DE0-2DFF, U+A640-A69F, U+FE2E-FE2F;
}
/* cyrillic */
@font-face {
  font-family: 'PT Sans';
  font-style: normal;
  font-weight: 400;
  font-display: swap;
  src: url(/wp-content/uploads/gstatic/jizaRExUiTo99u79D0aExdGM.woff2) format('woff2');
  unicode-range: U+0301, U+0400-045F, U+0490-0491, U+04B0-04B1, U+2116;
}
/* latin-ext */
@font-face {
  font-family: 'PT Sans';
  font-style: normal;
  font-weight: 400;
  font-display: swap;
  src: url(/wp-content/uploads/gstatic/jizaRExUiTo99u79D0yExdGM.woff2) format('woff2');
  unicode-range: U+0100-02AF, U+0304, U+0308, U+0329, U+1E00-1E9F, U+1EF2-1EFF, U+2020, U+20A0-20AB, U+20AD-20CF, U+2113, U+2C60-2C7F, U+A720-A7FF;
}
/* latin */
@font-face {
  font-family: 'PT Sans';
  font-style: normal;
  font-weight: 400;
  font-display: swap;
  src: url(/wp-content/uploads/gstatic/jizaRExUiTo99u79D0KExQ.woff2) format('woff2');
  unicode-range: U+0000-00FF, U+0131, U+0152-0153, U+02BB-02BC, U+02C6, U+02DA, U+02DC, U+0304, U+0308, U+0329, U+2000-206F, U+2074, U+20AC, U+2122, U+2191, U+2193, U+2212, U+2215, U+FEFF, U+FFFD;
}

Are the cyrillic, cyrillic-ext, and vietnamese versions necessary? Is there any way to remove them to reduce overhead?

Hi Oliver,

I got it working. I think the issue had to do with me attempting to add too many font styles. When I just added the regular (400) weights for PT Sans and Nunito, it worked fine. But I haven’t confirmed this with further testing.

Yes, that’s the Spectra One theme I was referring to.

Point well taken, Tom. The problem is that the recent changes to those themes is causing GB containers to *not* perform as expected. Therefore .gb-container > .gb-container {box-sizing: border-box;} (or something along this line) should be added in a future update to GB (rather than added manually as a hack) so that containers will perform as expected despite what theme is being used.

As more block/FSE themes come into use, more users may begin to experience this problem. I’ve already encountered it with:
– TT3
– Spectra One
– and as David reported, TT2

Thanks for your consideration on this.

Cheers,
Paul

• This reply was modified 1 year, 6 months ago by pracko.
• This reply was modified 1 year, 6 months ago by pracko.

Hi David, thanks for tracking this down to changes in the latest TT themes and providing a temporary fix.

Knowing this, do you think it would be make sense for GB to add this CSS to a future update so that others don’t face the same issue?

Here ya go. First two examples are native groups just for performance comparison, the last two are GB containers. It’s the last GB container that’s the issue because box-sizing: border-box; is not being applied when padding is added to the inner container.

https://gp.systemwp.com/containers/

I tried testing again on TT3 with all plugins except GB deactivated.

The Global max-width setting in GB is set @ 1200px.

Still the same result. The inner container is wider than the established wide/max-width of 1200px when padding is added to the inner container.

With 30px padding on the inner container, the container expands to a width of 1260px. The inner container should maintain the max-width of 1200px though.

I checked with my code inspector and the inner container is indeed still not using box-sizing: border-box;

Thanks @mohsinbsf !

Good to know, thanks Judith!

Hi Joe, we just got another email from PayPal about the IPN issue. I don’t know what to do.

I still cannot view the IPN notification history in my PayPal account.

However, I did visit https://www.[REDACTED].org/?mt_paypal_ipn=true in a separate browser (Chrome) and there was a 503 error. When I visit that URL in Firefox however, I get a blank page but no error notice in the browser.

• This reply was modified 2 years, 2 months ago by pracko.

Hi Joe,

Unfortunately IPN history log is still not working for some reason:

Instant Payment Notification (IPN) history
Feature Not Available

Sorry, this feature is currently unavailable. We apologize for any inconvenience.

Please keep this thread open for now until I can get more information.

Thanks.

Hi Joe,

I do NOT get a 503 error, just a completely blank page. And there are no errors indicated in my console either.

This has been an ongoing issue for us for the past several years. Fortunately, we sell tickets for only about 2 months out of the year, so this isn’t a persistent issue for PayPal, but I’m worried that PayPal would shut our IPN service down if we were to sell tickets more often.

Let me know if you need anything else.

Paul

Hi @mahbubshovan,

I watched your video. But it doesn’t show performance across browsers. Which browser were you using, Chrome or Firefox? Additionally, there is no other page content (such as an embedded YouTube video) on the page below the accordions block, so I’m not sure this is an accurate 1:1 test.

In any case, I have already switched to a different plugin which didn’t have any of the cross-browser issues so I cannot provide you with a sample page unfortunately.

All the best,
Paul