Is it right to assume that this old ticket will never get resolved / the Paypal issue fixed because Pro-Sites is no longer being developed?

Hello! I know this ticket is ancient now, but I just wanted to let ya know that it seems some recent updates with Hummingbird and the CDN have fixed whatever was wrong. It appears everything is working now. So I'm going to Resolve this ticket. Thank you for your help!

Hello and thank you for your help! Sorry we've been super delayed in responding. Just to update where we're at on this: We have contacted the host to see if we can increase I/O limits. We're awaiting their feedback. In the meantime, things have changed a little bit... It looks like when you made tweaks, whatever those tweaks were, Snapshot now completes both snapshots and full backups on our server. However, it only completes them and stores them on our servers. It never backs them up to either the HUB or our alternate location, Google Drive. How come that's happening? It can finish the backup, but then not an upload to the other places? That seems strange. Additionally, because of this, these backup files are never removed from our server. This is causing a major issue because every few weeks our storage limit is maxed out with these massive backups files. So we're being forced to log in and manually delete these via FTP every week or two. Not an ideal setup. Please let me know your thoughts. Thanks!

Okay I apologize for my huge delay. We had a terribly busy month. I'm picking this back up now. Thank you for being so helpful and thorough @adamczajczyk! That's helpful to know the two CDNs are different with different purposes. I wasn't quite sure how that worked. Makes sense now. I suppose we'll give them each a try again separately and see if they work for us yet. I think you were right with the old "et" directory being for Divi. It had been on the server at one point. It's no longer used and so I went ahead and removed the "et" folder as well. No problems. So, I guess that leaves me with just trying to switch up the Elementor print out method for its CSS like you suggested. I'm just puzzled why that didn't used to mess up and but just started recently (in March when I first posted this issue). We never had problems with it in the many months prior. Maybe cause of an update you all did with Hummingbird? Who knows, maybe it isn't the issue anyway. I'll try it and find out. Quick question though: Doesn't changing the print out method for the CSS to be inline / included like that rather than compiling in a separate file make the whole process slower? Maybe it doesn't matter since we're running a caching plugin like Elementor that compresses and caches it all anyway? I don't know. I'm still learning the whole way caching/compressing/combining/gzipping and all that work together.

Okay I apologize for my huge delay. We had a terribly busy month. I'm picking this back up now. Thank you for being so helpful and thorough @adamczajczyk! That's helpful to know the two CDNs are different with different purposes. I wasn't quite sure how that worked. Makes sense now. I suppose we'll give them each a try again separately and see if they work for us yet. I think you were right with the old "et" directory being for Divi. It had been on the server at one point. It's no longer used and so I went ahead and removed the "et" folder as well. No problems. So, I guess that leaves me with just trying to switch up the Elementor print out method for its CSS like you suggested. I'm just puzzled why that didn't used to mess up and but just started recently (in March when I first posted this issue). We never had problems with it in the many months prior. Maybe cause of an update you all did with Hummingbird? Who knows, maybe it isn't the issue anyway. I'll try it and find out. Quick question though: Doesn't changing the print out method for the CSS to be inline / included like that rather than compiling in a separate file make the whole process slower? Maybe it doesn't matter since we're running a caching plugin like Elementor that compresses and caches it all anyway? I don't know. I'm still learning the whole way caching/compressing/combining/gzipping and all that work together.

Okay I apologize for my huge delay. We had a terribly busy month. I'm picking this back up now. Thank you for being so helpful and thorough @adamczajczyk! That's helpful to know the two CDNs are different with different purposes. I wasn't quite sure how that worked. Makes sense now. I suppose we'll give them each a try again separately and see if they work for us yet. I think you were right with the old "et" directory being for Divi. It had been on the server at one point. It's no longer used and so I went ahead and removed the "et" folder as well. No problems. So, I guess that leaves me with just trying to switch up the Elementor print out method for its CSS like you suggested. I'm just puzzled why that didn't used to mess up and but just started recently (in March when I first posted this issue). We never had problems with it in the many months prior. Maybe cause of an update you all did with Hummingbird? Who knows, maybe it isn't the issue anyway. I'll try it and find out. Quick question though: Doesn't changing the print out method for the CSS to be inline / included like that rather than compiling in a separate file make the whole process slower? Maybe it doesn't matter since we're running a caching plugin like Elementor that compresses and caches it all anyway? I don't know. I'm still learning the whole way caching/compressing/combining/gzipping and all that work together.

Okay I apologize for my huge delay. We had a terribly busy month. I'm picking this back up now. Thank you for being so helpful and thorough @adamczajczyk! That's helpful to know the two CDNs are different with different purposes. I wasn't quite sure how that worked. Makes sense now. I suppose we'll give them each a try again separately and see if they work for us yet. I think you were right with the old "et" directory being for Divi. It had been on the server at one point. It's no longer used and so I went ahead and removed the "et" folder as well. No problems. So, I guess that leaves me with just trying to switch up the Elementor print out method for its CSS like you suggested. I'm just puzzled why that didn't used to mess up and but just started recently (in March when I first posted this issue). We never had problems with it in the many months prior. Maybe cause of an update you all did with Hummingbird? Who knows, maybe it isn't the issue anyway. I'll try it and find out. Quick question though: Doesn't changing the print out method for the CSS to be inline / included like that rather than compiling in a separate file make the whole process slower? Maybe it doesn't matter since we're running a caching plugin like Elementor that compresses and caches it all anyway? I don't know. I'm still learning the whole way caching/compressing/combining/gzipping and all that work together.

Hello Adam Czajczyk Thanks for the thorough response. Really appreciate it. I've pondered if there's a server side caching in place as well. I didn't think there was, but I went ahead and double checked things to see for sure. I asked the Support with A2 and they said there's not either. They offer it as a plugin which we do not have installed (wish our last host would have done it this way). Anyway, there is no other caching mechanism in place besides Hummingbird then... apart from something maybe Elementor is doing. The weird thing though is the file that Hummingbird kept pulling back up that we deleted was the exact same file, as in, even the same long gibberish file name. Not just a new file, compiled with the old files, but the exact same file name as the one we deleted and emptied. Almost as if it was caching the cache or something weird. But again, where would it be storing these duplicates? Would there be any strange conflict with the new CDN? We had it on for a while but a bunch of our users lost their images on their site so I shut that off (future support ticket, cause we want to use the CDN). But I pondered if there's something still affecting the site now from that? Other question just for certainty: (A. Hummingbird creates the wphb-cache folder in our directory structure, right? We have another one on the same level simply called "cache" and it contains a folder called "et" which contains multiple more number directories that all seem to be empty. It may be left over from our old server, or maybe it's Elementor. If it's not Hummingbird, I'm going to delete it. I don't think it was the problem though as they're all empty. Thanks for your help!

Hello Predrag Dubajic Thanks for your quick help with this. A message has been sent to you with all the info you requested using the form you gave. Please let me know what you do and when you're finished / what we need to do next. Thanks so much for your help!

Update: I've had to turn this off for now because it simply isn't working. It doesn't matter how many times we dump the cache and recheck the files, it isn't updating. We manually delete the files ourselves from the server, and it still somehow comes back with old ones from who knows where. What is going on!? Where is it even loading those from?