TheRealMikeD

I’m having a similar problem. I have the preloader scheduled to run daily. But right now, the message next to the “Run Now” button says, “Last preload finished at 5:24 PM, February 10, 2023,” which was four days ago, as of this writing. I am showing these errors in my DevTools console:

21:39:47.279 load-scripts.php?c=0&load%5Bchunk_0%5D=utils,underscore,backbone,wp-util&ver=6.1.1:8 Uncaught ReferenceError: jQuery is not defined
at load-scripts.php?c=0&load%5Bchunk_0%5D=utils,underscore,backbone,wp-util&ver=6.1.1:8:1384
(anonymous) @ load-scripts.php?c=0&load%5Bchunk_0%5D=utils,underscore,backbone,wp-util&ver=6.1.1:8
21:39:47.301 modal-3-2-12.min.js?ver=3.2.12:1 Uncaught TypeError: t.template is not a function
at modal-3-2-12.min.js?ver=3.2.12:1:149
at modal-3-2-12.min.js?ver=3.2.12:1:904
(anonymous) @ modal-3-2-12.min.js?ver=3.2.12:1
(anonymous) @ modal-3-2-12.min.js?ver=3.2.12:1

I installed WP Crontrol, and it looks like the schedule for the “wpo_page_cache_schedule_preload” event is correct – once daily, with the next occurrence scheduled for tomorrow.

It looks like I had debug logging turned off, so there is nothing of interest in there at the moment. I turned it back on, and will update if something pertinent appears.

What does “The calls are made on host machine” mean? Are calls being made TO the host machine from an external server? Or are calls only being made FROM the host machine?

Also, how am I meant to downgrade? Where would I get the older version?

As I mentioned in my original post, the site is on my local computer. So I am the host. I typically use a VPN, but I tried turning the VPN off, and I still get the same error.

Are curl calls being made into the host machine? Or only out from the host machine? Calls to the host machine from outside the local network are obviously going to fail, as the machine is behind a router and has no ports exposed to the internet to receive incoming connections.

@texasbiz, I gave up. As my fallback, I began using WP-Optimize, which generates static html files and serves them in place of calling PHP each time. You don’t get the advantage of improved security that you would with a pure static site, but you do get improved performance.

In case you use the WP REST API, WP-Optimize does not cache API responses, but I found another plugin which does: WP REST Cache. Between these two plugins, I am seeing enough performance improvements to give up on trying to generate a pure static site for now.

If it’s vitally important that you have a pure static site, you might consider some paid services like HardyPress or Strattic.

In case this helps some other users, I was seeing that jpeg and png files were still being served on my site. I realized that the CDN that I use (Cloudflare in my case) was serving responses which had been cached prior to me generating webp files using WP-Optimize. If you are using a CDN, you may see similar results. You can clear your CDN’s cache manually to see the webp files get served, or you can just wait for the cache to expire.

Roger that, @texasbiz. I don’t know how much time I’m going to have for trying to make this plugin work. If I can’t make it work fairly quickly, I’ll probably just look for a different solution. But I will happily report back if I find anything.

I was able to get into the database, and as I suspected, the wp_simply_static_pages has no records in it.

I’m experiencing the same thing. Nothing seems to be happening.
PHP 7.4 on a Dreamhost shared server
WP 6.0
SimplyStatic 2.1.5.8

The same version of the plugin works great on my dev machine at home. I wonder if the process is timing out on the Dreamhost server. There is no way to know, as there is no notice in the UI and there doesn’t seem to be any log. Everything looks good on the Diagnostics page.

I ssh’d to the server and looked in the plugin’s static-files directory, which is where I believe the temp files should be written. It is empty.

I also tried enabling Debug Mode, and there is no debug.txt file getting created in the plugin’s directory.

I am trying to get a look at the wp_simply_static_pages table in the database, but right now phpMyAdmin is timing out on Dreamhost. If that gets fixed, I’ll post an update.

It still doesn’t make sense that another plugin using CLI would trigger the sending of a Wordfence alert email when Wordfence is not installed on the site. How would another plugin know to do that? Unless the emails are being deliberately and maliciously forged, which I don’t believe to be the case.

The thing that really seems suspicious to me is that some of the emails indicate a login from an admin-level user who doesn’t exist in the local WP database. But that user does exist on the production site. That makes me suspect that the alert email is being generated from the production site, but is for some reason reporting incorrectly that it is coming from the local dev site.

Supporting that theory, the details of the alert email (username and IP) match entries in the successful login attempts table in Wordfence on the production site. The date and time are offset by precisely four hours (which might be accounted for by timezone settings) – the successful logins table reports the events four hours later than the email.

The only question is how Wordfence on the production site knows the URL of the dev site, and why it is incorrectly substituting it for the URL of the prod site.

Hi @wfadam,

Thanks for the response. On the local version of the site, I am not explicitly using WP-CLI. It’s always possible that some plugin uses it without my knowledge. I’m not sure how I would detect that, though.

Also, I’m not sure how I would get you that diagnostic report if Wordfence is not installed on the site.

Now, as I mentioned in the original post, Wordfence is installed on the production and the staging versions of the site, and I do use WP-CLI on those sites when I deploy code changes. I could get you diagnostic reports from either of those sites and see if something is getting confused as to which site it is coming from. Would that be of use?

Thanks!

Thanks for the response, @devnihil.

It doesn’t seem terribly urgent, given the state of WP Log Viewer’s development. I might file a bug report if I find a few free minutes. I really just wanted to make sure you all were aware of it in case something similar happens to another user.

Probably the best solution is for me to A) file a bug report with WP Log Viewer; and B) look for another, more updated, plugin which provides the same functionality as WP Log Viewer, since that one looks like it may have been abandoned. Too bad. I find it super-useful.

Cheers!

The new attribute works well. Thanks for letting me know!

You are absolutely correct. Enclosing font names in quotes is a best practice, and I am embarrassed that I missed that. It’s probably because I often write CSS through Chrome Dev Tools (connected to the files on my filesystem), and I don’t think it is adding the quotes automatically.

Thanks so much for looking into it so quickly!

Cool. I will leave my patch in place until you release an updated version that includes this fix.

Thanks!

So I was able to patch this issue by augmenting the problematic code as follows:

if (isset($GLOBALS['dae_settings'])) {
    $dae_settings = $GLOBALS['dae_settings'][ $download_id ];
} else {
    $dae_settings = get_post_meta( $download_id, 'dae_settings', true );
}

With this patch, all the HTML gets output correctly when calling do_shortcode() from the theme’s PHP code. The inline CSS does NOT get output in this case, but as a theme developer, I actually like it better this way. It allows me to write my own CSS that will be consistent throughout the theme without having to use !important to override a lot of styles.