magestyx

Hi, Marko. Thanks for responding quickly.

I understand W3TC doesn’t remove actual files, I’m just saying that during the Combining process maybe some are being removed from the ‘gathering up’ process or something to that effect. We updated additional sites today that seem to have this same issue – removing any combining solved the problems right away.

One of the main pages we’ve been troubleshooting is: https://www.blackcommunitydevelopersgroup.org/testimonials/

Currently combining is off so it looks correct – also see here for reference: https://imgur.com/MsVmm0e

As soon as we turn on Combine in any way for CSS, we get this: https://imgur.com/a3iUeCs
The plugin displaying the testimonials is called Strong Testimonials. There doesn’t seem to be anything unusual about the plugin, but W3 is leaving out its files like /wp-content/plugins/strong-testimonials/public/css/grid.css if we have Combine on. With only Minify on, it works and gives a file like: https://www.blackcommunitydevelopersgroup.org/wp-content/cache/minify/f0e9f.css

With Combine on, it leaves out 100% of that grid.css file’s content. As mentioned, this is just one specific example. We also found where it leaves out CSS files from AIO SEO. But many other plugins like GiveWP it includes the CSS files in the combine process just fine.

We’re stumped, but we’re getting the feeling why Combine has been a volatile setting on many sites we manage. This whole time we thought maybe files were combined in different orderings or something like that which broke the pages or functions, but perhaps really the issue is that Combine is leaving out entire files.

Magestyx

I was finally able to get the export working as well. I believe the limitation has to do with the number of steps involved combined with the number of users. I tested the export on an old version of the site we’re working on and also a new one. On both, we raised the server PHP/memory settings way up. The old site, being more complex (which is why we’re redoing it) had nearly 550 steps. The new, simpler site we were migrating to only had 250 or so. It never had an issue exporting. To finally get it to work, I had to export only one month of a time of users (according to registration date). In some cases, there were so many it’d still throw that error, so I had to export a single month and also export Subscribers separately, then Authors, etc.
Broken down to smaller segments, it still took a while with so many steps, but it did ultimately export. And the imports all went fine as usual.

The only way I could get the exporting to work was to break it down into exporting much smaller segments of the users. Only one role at a time and only new ones for 1-2 months at a time. Took a ton of time but, fingers crossed, it finally seems to have worked.
On the import as well I had to manually break a number of the CSV files into multiple smaller pieces.

For testing, I just tried exporting only the Admin role since there’s less than 10 on the site, and the process started. However it started going through ‘approximately 549 steps’ – and slowly. Eventually the ‘Error thrown in the server’ showed again at “Step 499 of approximately 549 steps – 90%”.
What a bad time for this plugin to not work anymore. ??
I don’t remember there ever being so many steps – it’d simply output a CSV file.
I see a past post said something about a PHP8 error, but we’re on 7.4. On probably 15+ sites we’ve used this plugin on, this is the only time it’s ever failed.

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

I’ve used this plugin many times before, but suddenly today I’m getting this exact same error and result. Using Plesk/LAMP servers – all very standard.
Any further ideas on this to share? There are no PHP errors on the server – only the one in the console which isn’t helpful at all.

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

Ok, found it –
/wp-content/plugins/custom-codes/assets/script/codemirror/addon/edit/closebrackets.js
Edit the ‘pairs’ and ‘closeBefore’ vars line 13 & 14 to:
pairs: “()[]{}”,
closeBefore: “)]}:;>”,

Basically you’re just removing anything in the pairs to do with single and double quotes.

HUGE nuisance solved.
It’d be great to have this as a config setting so we don’t have to edit this each time there’s a plugin update.

Cheers,

Magestyx

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

Solved. As I was writing the original post a thought occurred to me –
The shortcode PHP was actually being added to functions.php via the CodeKit Codes plugin – a great plugin we use on all sites. It normally works with everything, however this turned out to be a super rare case where the PHP code has to be added directly into the functions.php and not to functions.php via the Codes plugin.
Seems an update on the Github pages would’ve been prudent by the devs, though. Based on no conclusive replies there it looked like the issue was never solved.

Note that the Unlimited lifetime/unlimited site version of this Ele Custom Skin plugin is only available until the end of this month – July 2022 – and it’s a heck of a deal for what is an essential Elementor addon in our opinion.

Magestyx

We have tried countless fixes for this issue. We’re on a standard LAMP/Plesk server with nginx and have tried every fix we can find for .htaccess, apache configs, nginx configs, etc. mod_headers is verified working. We’ve tried PHP FPM by Apache and Nginx, tried numerous apache/nginx settings on/off. NOTHING fixes this.
If anyone has a solution to this issue, please speak up.
Magestyx

James,

you’re right. I gave the widget a min-height and it works fine now:

#ns_widget_mailchimp_form-4 {
min-height: 57px;
}

Thanks!

magestyx