Jared

Jumping in to say I’m facing the same issue — Avada Theme — except none of my products are syncing and it’s showing the same missing [description] value as the “Issue to resolve” for all of them.

Even more puzzling is the fact that according to Google’s very own Rich Results Test, the description field value is indeed there. You can see for yourself here: https://search.google.com/test/rich-results?id=Wg98GOjz4BzJmx08pAL8Yw

And also showing without errors using the validator.schema.org tool: https://validator.schema.org/#url=https%3A%2F%2Fwww.trogsworld.com%2Fproduct%2Fgolden-retriever-childrens-book-golden-smiles%2F

• This reply was modified 3 years, 1 month ago by Jared. Reason: Added schema.org test result
• This reply was modified 3 years, 1 month ago by Jared.

Shoot — I’m sorry — I spoke to soon.

Following your steps did result in the setup/connection prompt, but only as far as connecting the site to WordPress.com via Jetpack goes. Once I was reconnected, the account was already (or still) linked to the same Stripe account.

Again I tried clearing the Payments cache via Status > Tools. I performed all of the reconnecting steps not only in a private browser window, but in a totally different browser’s private window. And on top of that, I even created a brand new WordPress.com account for the connection. Despite all of that, I’m still connected to the same Stripe account. Sheesh!

You are a godsend, my friend. Thank you sincerely for the thoughtful response — and the only solution to both work and clearly demonstrate an understanding of the circumstances I laid out. The more formal Jetpack and WooCommerce support channels were not nearly as helpful, and I truly appreciate that fact!

Thanks man — feel free to reach out if ever interested in exploring the latest Avada Theme wrinkles and nuances at any point; I’d be happy to help facilitate that to whatever extent I could.

For now, I’ll give the Async approach a shot, and mark this support thread as resolved.

Thanks man — you truly are my favorite dev for a variety of reasons, and none more so than the fact that you provide such thoughtful, patient and timely support. The entire WordPress community is fortunate to have you.

After posting, I realized the high volume of scripts found in the wp-content/uploads/fusion-scripts/ directory, and thought that that may have been the culprit for the exploding cache size, but had hoped not, because it felt a little bit like the nuclear option to exclude all Avada Theme-generated JS. And given that this was never an issue previously (prior to Avada v7.4 I guess), I was even more hesitant to assign the “blame” there.

That said, the issue does indeed seem to stem from the fusion-scripts directory. After excluding the directory about 90 minutes ago, the Autoptimize cache size still sits at just 2%; prior to the exclusion, the cache size was growing to about 12% near-instantaneously (and growing rapidly with each respective page visit from there).

So that certainly seems to have gotten the cache size under control.

I guess the only question now is: how much has the Avada change (and, in particular, the new need to exclude the theme’s entire fusion-scripts directory, much like has long been the case for the fusion-styles directory) going to limit the abilities of Autoptimize in an Avada-theme-based environment? Seems like a good bit of Javascript—historically able to be aggregated by AO—will now be left to the capabilities of Avada itself. Hopefully the theme does a better job handling its own scripts than it has historically, because AO has really been the primary reason I’ve found Avada to be reasonably performant at all.

One more note though on exclusions, and the fact that, historically, it has been a good idea to exclude /fusion-styles, and now that excluding the /fusion-scripts/ directory seems like a must — it looks like the fusion-styles directory is much slimmer than it used to be. I’m wondering if now it might be “safe” to allow AO to aggregate the fusion-styles directory as well..

I’d be happy to remove wp-content/uploads from the list of CSS exclusions and see how that goes, but before I do that, a couple of more related questions if you don’t mind:

– Are you familiar with any of the changes brought by the Avada v7.4 update that might pain a clearer picture of what’s going on now? Is Avada creating separate Javascript files for each page/post now?

– Was the reason for excluding /wp-content/uploads by default on sites built using page builders (like Avada) based in the fact that each page had its own CSS file generated—which, in turn, would cause the AO cache size to grow rapidly—or was it less about cache size and more about correctly applying the proper stylesheet/styles in an appropriate manner?

It does help clarify things—very much so. Thank you sincerely, Frank. This plugin belongs on every site as far as I’m concerned.

Following up to say that I had to manually update that “not loading” page, unfortunately, so that our visitors could properly register. That’s obviously something that won’t make things easier to debug from your perspective when it comes to our production site. Sorry about that.

It might be worth noting, however, that adding /wp-content/themes/Avada-Child-Theme/ to the exclusion list seemed to actually make the problem more prevalent. I found the issue of missing custom stylesheet was occuring even *after* manually updating the event page while that file path was part of the exclusion list.

Sorry for all of the variability here. Win or lose in this situation, you have an amazing plugin and the level of support that you personally provide is truly unrivaled.

Ahh, no luck. I found one fairly quickly this time around —

Not loading /wp-content/themes/Avada-Child-Theme/style.css:
https://www.cfany.org/event/a-conversation-with-stacey-cunningham-the-first-female-president-of-the-nyse/

And for example purposes, here is one where the custom /style.css is loading:
https://www.cfany.org/event/nasdaq-and-cfanys-institutional-asset-management-group-present-etf-synapse-conference/

I’ll give that a shot this weekend. Unfortunately, it seems pretty random as to which event pages are affected following a cache-purge, so I’ll probably be able to tell you more definitively by Monday.

I really appreciate the help, man. Thanks so much!

Truly, you are the best. Enabling the “Remove querystring” setting did the trick.

It absolutely does, Frank.

Thank you so much for the quick response. I sincerely appreciate the support, as well as your phenomenal plugin.