Pegasaas

Hi Cez,

Actually, what had happened was that you were thrilled with the product, and then several months in you asked for a feature which was not planned for development in the foreseeable future. You were informed that if that wasn’t going to suit you, we could process a refund at that time. After taking a couple more months to decide, you asked for a refund at which point we said it wasn’t possible because our gateway doesn’t offer refunds pass a particular point (180 days, although George mistakenly said 3 months in his email to you). Remember, you did subscribe to a yearly commitment, which got you a preferred rate.

But by all means, give a one star rating to a small business because you had a change of mind and demanded a refund beyond the point that the normal process would allow. Or the posted normal 30 day refund. Maybe if you stomp your feet and shout at social media you’ll get your way.

But don’t forget to explain, though, that you also did receive an amount back of 50% (half a year) through another avenue. Why? Because this isn’t a money making venture, it’s a venture of love. I do it because I’m passionate about making web sites faster, not about holding on to $350.

Life is too short to fight over something so ridiculous.

Brandon Devnich
Founder
Pegasaas.com

Hi @happywishes20official

Sorry to hear about the trouble you’re experiencing.

Just deployed an update which if you can update the plugin (via the Plugins panel in WordPress) should resolve this issue. Please let me know if this update resolves (or does not resolve) your issue.

If it does not, the only solution is to delete the wp-content/plugins/pegasaas-accelerator-wp/ folder via SFTP, your web hosting control panel “File Manager”, or by using a WordPress plugin such as WP File Manager.

Kind regards,
Brandon Devnich
Pegasaas

Hi @jesusinica

Yes, it is compatible with Nginx, but there are a few things to consider as there are some differences between how Pegasaas operates on an Apache server vs Nginx.

With an Apache server, we will generate a .htaccess file which creates instructions for the web server to fetch cache from a specific location on the file system for the fastest possible Time to First Byte.

Nginx servers do not use .htaccess, but instead they use their own internal configuration file (.conf) that can only be changed by the server administrator. It is not editable by the plugin. This nginx.conf file is quite powerful, and because there is usually only one of them per website (opposed to the many .htaccess files for an Apache server), provided the nginx.conf is set up to fetch local cache, it can be a much faster solution.

But that is only if the Nginx web server is manually configured to look for the cache in a particular way. And, again, as Pegasaas does not have access to the nginx.conf file, nor does it know how the web server file system is setup up (so far as paths to our cache is concerned), Pegasaas cannot automatically build this routing into an nginx.conf file.

So what that means is, that although Nginx can be faster because there’s not as much upfront overhead (because it doesn’t spend a lot of time looking and possibly parsing .htaccess files for subfolder upon subfolder), that the Ngnix server has to use a fallback mechanism to fetch cache. This fallback mechanism involves and requires the WordPress core be engaged. Code in the plugin (that is run via WordPress) handles the check for existing cache and then serves the cache very very early in the page load session. Unfortunately, that can be 200ms – 2500ms longer than the Apache .htaccess method simply due to the load on the server resources at the time, or the memory usage and plugin code that is invoked for your particular WordPress installation.

Some Nginx platforms, such as Kinsta, use Nginx and often will have a gateway caching system which will cache your pages for you. It’s designed to provide fast caching. Unfortunately, it will not allow for plugins that use dynamic methods such as Pegasaas does to provide optimized HTML. We have to bypass those systems in order to take advantage of PageSpeed scans and optimized HTML.

So in short, Nginx is fast, but its speed can’t be leveraged for fetching file based cache.

Another issue with Nginx is that often static resources are explicitly thrown static 404 page when the resource cannot be found. As we often build optimized resources on the fly using the WordPress 404 handler (that invokes the WordPress system), we have to use a secondary mechanism that is not as reliable. This is only used, however, on the Pegasaas Guest API installations however, as our Premium API uses our CDN which doesn’t require the WordPress 404 handler to generate optimized content.

So to sum up, Nginx can be fast, for a static website, but not so much when a dynamic third-party caching and optimization plugin is involved.

I hope that answers your questions!

Kind regards,
Brandon Devnich
Pegasaas

Hello @singfa

I believe we have simply just not updated the version that it is compatible with in the readme file. We run the latest (as well as the upcoming version) of WP on our development server, and it has been running without issue there.

I’ll see about getting this update in the next day though.

Thank you for the heads up.

Brandon Devnich
Pegasaas

Hi @bruno4italy

Sorry to hear about the problems. We’re investigating this today for you.

Kind regards,
Brandon Devnich
Pegasaas.com

Hey @ctingom

I think I just answered your question through our online chat, just five minutes ago. ??

But for anyone else who is reading this:

Yes, plugin works with WP Engine. You can skip through the Cloudflare step by entering any old email in the email field, an then a space in the api-key field.

Last time I checked, WP Engine wasn’t forcing Cloudflare on anyone, but I can investigate your DNS settings if you want to add it to our ongoing thread back at our website.

Kind regards,
Brandon Devnich
Pegasaas

Thanks you so much for your kind words Horace!

Hi @sfehmi

I believe the support team replied to you via our ticketing system earlier today, but just in case you didn’t see it, what we saw was that your home page is currently getting 87-89/100 for mobile.

Please see screenshot: https://prnt.sc/12hlzpo

I think probably what you were seeing was a scan that was performed in between when the page cache was cleared, and when the optimization was complete.

But, if you continue to get inconsistent scores, or maybe it is the dashboard that is reporting these scores, please do feel free to reach out to me directly via the ticket system (request me by name) and I’ll dig right into it.

Kind regards,
Brandon Devnich
Founder | Head of Development
Pegasaas

Hi Kezily,

I think it could because the number of image optimizations has exceeded the amount included in the Guest API (100). But that said, we should still cache an unoptimized copy of the image in our folder. Right now, it looks like a placeholder (blank) image is being saved in some cases:

https://belyoung.com.br/wp-content/pegasaas-cache/wp-content/uploads/2021/03/Post-site-2-650×427.jpg

Although there is an original available:

https://belyoung.com.br/wp-content/uploads/2021/03/Post-site-2-650×427.jpg

I’ve reset the number of image optimizations for this site, regardless. You’ll need to manually clear/reoptimize the blank images from the “Cache” tab.

Here is an example of where you’d go in the Pegasaas dashboard:

https://prnt.sc/11rncpc

If you continue to experience this, please reach out to me via our contact page at pegasaas.com/contact/ so that we can launch a more in-depth investigation.

Sincerely,
Brandon Devnich
Pegasaas

Hi Kezily (@kezily)

I believe this is probably related to the auto-optimizing routine we use for images. It sounds like maybe you’re on server which bypasses the WordPress 404 handling for static resources, which is often the case with Nginx servers. We have handling built in to the plugin that allows for this, however it may be that our system hasn’t detected this condition and so it hasn’t added the extra code to the web pages.

I’d be happy to investigate further. First, I’d ask for the domain name that you’ve installed the plugin to. With that, I can launch an investigation on our end here to see if that is the case.

Best regards,
Brandon Devnich
Pegasaas

Hi @jliuzza7

Just following up on this. As I haven’t heard from you, I’m going to mark this as resolved. If you’re still experiencing this, please feel free to reach out to us via pegasaas.com/contact with your website details.

Kind regards,
Brandon Devnich
Founder | Head of Development

Hey @jliuzza7

This sounds like our output buffer capture system is being a bit “greedy”, and not firing procedural based output buffer functionality from the plugin that your short codes use.

If you were to re-enable the plugin, put it into “diagnostic” mode, and then let me know what the domain is, I can ping the plugin to tell him what output buffer handlers are registered and will see if there’s an quick fix.

Kind regards,
Brandon Devnich
Founder | Head of Development
Pegasaas

I’m sorry to hear that.

Do you feel we deserve a one star rating because a feature on a free plugin didn’t work as intended, possibly due to an unknown server incompatibility? I kindly ask you to reconsider.

Sincerely,
Brandon Devnich
Pegasaas

Hi @abhay-raj

I’d be happy to investigate why the images are not loading after optimizing. Would you be open to allowing me to troubleshoot?

Kind regards,
Brandon Devnich
Pegasaas

This message is to update this thread with our findings.

We did not hear back from Noor about the actual URL that they were having problems with, so we could not troubleshoot their site. However, we did have a report of a similar issue.

We have updated the plugin to resolve this other user’s issue, and are hoping that it also solves Noor’s issue. If not, then we look forward to hearing back from them with the URL of the page that is having issues.

Until then, we’re marking this issue as resolved.