{"id":3604,"date":"2024-04-01T20:49:56","date_gmt":"2024-04-02T01:49:56","guid":{"rendered":"https:\/\/promincproductions.com\/blog\/?p=3604"},"modified":"2024-04-01T20:49:58","modified_gmt":"2024-04-02T01:49:58","slug":"litespeed-image-optimization-with-quic-cloud-not-pulling-down-images","status":"publish","type":"post","link":"https:\/\/promincproductions.com\/blog\/litespeed-image-optimization-with-quic-cloud-not-pulling-down-images\/","title":{"rendered":"LiteSpeed Image Optimization with QUIC.cloud Not Pulling Down Images"},"content":{"rendered":"<p>I struggled for several months with getting image optimization through LiteSpeed to pull <code>.webp<\/code> versions of my WordPress sites images down from QUIC.cloud.  With my initial setup it worked as expected.  And then stopped.  Why?  I finally figured out what the issue was, and I am now successfully getting <code>.webp<\/code> images to pull down from the QUIC.cloud CDN.  I wanted to share my success story with you in hopes that it can help with your struggles as well!<\/p>\n\n\n\n<p>Upon initial setup, it is advised to manually click the <strong>Send Optimization Request<\/strong> and <strong>Pull Images<\/strong> buttons in the WordPress admin on the LiteSpeed plugins <strong>Image Optimization<\/strong> page.  I did that and it seemed to be working.  From there the WordPress <code>cron<\/code> system (scheduled tasks) should take over and essentially run these buttons for you every 15 minutes (up to 200 images per day).  This is the part where I started experiencing issues.<\/p>\n\n\n\n<p>Day after day, the percentage of images processed would not change.  Yet there were no errors in the log files.  If I attempted to manually click the buttons, a success message would say that it successfully added the images to an async process.  (async meaning it&#8217;ll run in the background)  Yet the percentage of images completed would never update.<\/p>\n\n\n<div class=\"wp-block-image\">\n<figure class=\"aligncenter size-full\"><img decoding=\"async\" width=\"600\" height=\"600\" src=\"https:\/\/promincproductions.com\/blog\/wp-content\/uploads\/2024\/04\/litespeed-wordpress-optimized-images-not-pulling.png\" alt=\"Optimized images not pulling into WordPress from QUIC.cloud\" class=\"wp-image-3646\" title=\"Optimized images not pulling into WordPress from QUIC.cloud\" srcset=\"https:\/\/promincproductions.com\/blog\/wp-content\/uploads\/2024\/04\/litespeed-wordpress-optimized-images-not-pulling.png 600w, https:\/\/promincproductions.com\/blog\/wp-content\/uploads\/2024\/04\/litespeed-wordpress-optimized-images-not-pulling-500x500.png 500w, https:\/\/promincproductions.com\/blog\/wp-content\/uploads\/2024\/04\/litespeed-wordpress-optimized-images-not-pulling-150x150.png 150w, https:\/\/promincproductions.com\/blog\/wp-content\/uploads\/2024\/04\/litespeed-wordpress-optimized-images-not-pulling-450x450.png 450w\" sizes=\"(max-width: 600px) 100vw, 600px\" \/><\/figure>\n<\/div>\n\n\n<h2 class=\"wp-block-heading\">Setup Overview<\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li>WordPress (v6.4.3)<\/li>\n\n\n\n<li>Hostinger Cloud website hosting <\/li>\n\n\n\n<li>LiteSpeed WordPress Plugin (v6.1)\n<ul class=\"wp-block-list\">\n<li>Configured based on <a href=\"https:\/\/www.hostinger.com\/tutorials\/litespeed-website-optimization-tool\/#3_Refine_Page_and_Image_Optimization_Options\" target=\"_blank\" rel=\"noopener\" data-lasso-id=\"997\">this Hostinger LiteSpeed Tutorial<\/a><\/li>\n<\/ul>\n<\/li>\n\n\n\n<li><a href=\"https:\/\/www.quic.cloud\/\" target=\"_blank\" rel=\"noopener\" data-lasso-id=\"998\">QUIC.cloud<\/a> account<\/li>\n\n\n\n<li>Cloudflare<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">What is QUIC.cloud<\/h2>\n\n\n\n<p>QUIC.cloud is a CDN service that offers a whole host of optimization services that can aid in boosting website performance.  This includes page optimization, critical CSS generation, caching, and &#8211; in the case of this discussion &#8211; Image Optimization.  They offer some free services (at times up to a threshold) as well as paid services.  <a href=\"https:\/\/www.quic.cloud\/\" target=\"_blank\" rel=\"noopener\" data-lasso-id=\"999\">QUIC.cloud<\/a>&#8216;s host of services and global network of servers offer many benefits to boosting page load times of WordPress sites.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">How to fix Optimized Images Not Pulling Into WordPress from QUIC.cloud<\/h2>\n\n\n\n<p>After a lot of debugging and trial and error I found the root of the issue.  I had added an IP restriction directive to a <code>.htaccess<\/code> file in the <code>wp-admin\/<\/code> directory to block undesired visits to the WordPress admin.  However, the <code>.htaccess<\/code> directive did not include the webservers IP address which &#8211; is needed since the LiteSpeed WordPress cron request calls the server itself.<\/p>\n\n\n\n<p><code>h<span style=\"background-color: initial;font-family: inherit;font-size: inherit\">ttps:\/\/www.example.com\/wp-admin\/admin-ajax.php?action=async_litespeed&amp;nonce=34be8c0f1c&amp;litespeed_type=imgoptm_force<\/span><\/code><\/p>\n\n\n\n<p>Because the webservers IP was blocked by the <code>.htaccess<\/code> directive, a status code of <code>403 Forbidden<\/code> was returned by the webserver.  The way LiteSpeed built their plugin, it uses async logic.  When the <strong>Pull Images<\/strong> button is clicked or it&#8217;s action is called by the <code>cron<\/code>, the process to pull images from QUIC.cloud to the WordPress server is queued up to run in the background.  The request to trigger the queue <em>technically<\/em> succeeds given how the WordPress <code>wp_remote_post()<\/code> function works for async requests.  Thus no error are returned to the user at this time.  Then when the async process runs it fails silently due to the <code>403<\/code> status code.<\/p>\n\n\n\n<p>In my case the issue was from a <code>403<\/code> due to an IP restriction in <code>.htaccess<\/code>.  But there could be several other reasons that a <code>403<\/code> status code is returned and thus this same failure occurs.  LiteSpeed has outlined the other reasons in their <a href=\"https:\/\/docs.litespeedtech.com\/lsws\/cp\/cpanel\/403-error\/\" target=\"_blank\" rel=\"noopener\" data-lasso-id=\"1000\"><code>403<\/code> Error Debugging Guide<\/a><\/p>\n\n\n\n<h3 class=\"wp-block-heading\">.htaccess Directives that Caused a 403 Status Code for LiteSpeed QUIC.cloud Image Optimization<\/h3>\n\n\n\n<p>Initially I was using this directive in the file <code>wp-admin\/.htaccess<\/code> to restrict access to the WordPress Admin for non-whitelisted IP addresses.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>&lt;LIMIT GET&gt;\norder deny,allow\ndeny from all\nallow from 123.45.67.890 # office IP address\n&lt;\/LIMIT&gt;<\/code><\/pre>\n\n\n\n<p>The first flaw noticeable here is that this does not include the webservers IP address.  Additionally, in hindsight after doing some additional research on Apache <code>.hataccess<\/code> directives, this isn&#8217;t all that good of a restriction as it does nothing for <code>POST<\/code> or other methods.  To address both of those concerns, this is the directive I&#8217;m not using that resolves both of these issues.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>&lt;LimitExcept GET POST PUT OPTIONS&gt;\n        &lt;LIMIT GET&gt;\n        order deny,allow\n        deny from all\n        allow from 987.65.432 # Webserver IP address\n        allow from 123.45.67.890 # office IP address\n        &lt;\/LIMIT&gt;\n\n        &lt;LIMIT POST&gt;\n        order deny,allow\n        deny from all\n        allow from 987.65.432 # Webserver IP address\n        allow from 123.45.67.890 # office IP address\n        &lt;\/LIMIT&gt;\n&lt;\/LimitExcept&gt;<\/code><\/pre>\n\n\n\n<p>The <code>LimitExcept<\/code> directive says that all are limited with the exception of the listed methods.  Then the <code>LIMIT<\/code> directive defines how to handle specific methods.  In this case, deny from all but those IP addresses specifically allowed.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Validating that Images are Pulling from QUIC.cloud to WordPress Server<\/h2>\n\n\n\n<p>There were several ways to validate that things were finally working after the change was applied.  Keep in mind that the image optimization process runs in a queue and processes 200 images per day.  Thus this validation process will take a bit of time to ensure all is working as it should.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Image Optimization Percentage and Count in WordPress Admin<\/h3>\n\n\n\n<p>In the  WordPress admin, go to <strong>LiteSpeed Cache -&gt; Image Optimization<\/strong> and monitor the percentage and count in the <strong>Image Information<\/strong> section.  This number should of course grow over time up to 100% (though if you continue to add images to the WordPress site the percentage growth may be skewed a bit).<\/p>\n\n\n\n<div class=\"wp-block-columns is-layout-flex wp-container-core-columns-is-layout-9d6595d7 wp-block-columns-is-layout-flex\">\n<div class=\"wp-block-column is-layout-flow wp-block-column-is-layout-flow\"><div class=\"wp-block-image\">\n<figure class=\"aligncenter size-full\"><img decoding=\"async\" width=\"596\" height=\"509\" src=\"https:\/\/promincproductions.com\/blog\/wp-content\/uploads\/2024\/03\/image-optimization-stuck-at-1-percent.png\" alt=\"Image optimization process has been stalled at 1%\" class=\"wp-image-3618\" title=\"Image optimization process has been stalled at 1%\" srcset=\"https:\/\/promincproductions.com\/blog\/wp-content\/uploads\/2024\/03\/image-optimization-stuck-at-1-percent.png 596w, https:\/\/promincproductions.com\/blog\/wp-content\/uploads\/2024\/03\/image-optimization-stuck-at-1-percent-500x427.png 500w, https:\/\/promincproductions.com\/blog\/wp-content\/uploads\/2024\/03\/image-optimization-stuck-at-1-percent-150x128.png 150w, https:\/\/promincproductions.com\/blog\/wp-content\/uploads\/2024\/03\/image-optimization-stuck-at-1-percent-450x384.png 450w\" sizes=\"(max-width: 596px) 100vw, 596px\" \/><\/figure>\n<\/div><\/div>\n\n\n\n<div class=\"wp-block-column is-layout-flow wp-block-column-is-layout-flow\"><div class=\"wp-block-image\">\n<figure class=\"aligncenter size-full\"><img decoding=\"async\" width=\"587\" height=\"505\" src=\"https:\/\/promincproductions.com\/blog\/wp-content\/uploads\/2024\/03\/image-optimization-processed-to-17-percent.png\" alt=\"The image processing percentage has grown to 17% after removing the IP restrictions\" class=\"wp-image-3619\" title=\"The image processing percentage has grown to 17% after removing the IP restrictions\" srcset=\"https:\/\/promincproductions.com\/blog\/wp-content\/uploads\/2024\/03\/image-optimization-processed-to-17-percent.png 587w, https:\/\/promincproductions.com\/blog\/wp-content\/uploads\/2024\/03\/image-optimization-processed-to-17-percent-500x430.png 500w, https:\/\/promincproductions.com\/blog\/wp-content\/uploads\/2024\/03\/image-optimization-processed-to-17-percent-150x129.png 150w, https:\/\/promincproductions.com\/blog\/wp-content\/uploads\/2024\/03\/image-optimization-processed-to-17-percent-450x387.png 450w\" sizes=\"(max-width: 587px) 100vw, 587px\" \/><\/figure>\n<\/div><\/div>\n<\/div>\n\n\n\n<h3 class=\"wp-block-heading\">Media Gallery in the WordPress Admin<\/h3>\n\n\n\n<p>The images that have been optimized will show optimization statistics in the WordPress Admin Media Gallery.  Go to <strong>Media -&gt; Library<\/strong> in the WordPress admin.  The image optimization process starts with the oldest images and works to the most recent.  For that reason, if the image optimization is not at 100% yet, you will not see data in the <strong>LiteSpeed Optimization<\/strong> column yet.  Navigate through the pages of images to find where the optimization process is at and see the statistics.  After the next day when more images are processed, you should notice that the <em>most recent optimized image<\/em> should have changed.<\/p>\n\n\n<div class=\"wp-block-image\">\n<figure class=\"aligncenter size-full\"><img decoding=\"async\" width=\"903\" height=\"657\" src=\"https:\/\/promincproductions.com\/blog\/wp-content\/uploads\/2024\/03\/image-5.png\" alt=\"Image optimization percentage shown in the WordPress Media Gallery\" class=\"wp-image-3620\" title=\"Image optimization percentage shown in the WordPress Media Gallery\" srcset=\"https:\/\/promincproductions.com\/blog\/wp-content\/uploads\/2024\/03\/image-5.png 903w, https:\/\/promincproductions.com\/blog\/wp-content\/uploads\/2024\/03\/image-5-500x364.png 500w, https:\/\/promincproductions.com\/blog\/wp-content\/uploads\/2024\/03\/image-5-768x559.png 768w, https:\/\/promincproductions.com\/blog\/wp-content\/uploads\/2024\/03\/image-5-150x109.png 150w, https:\/\/promincproductions.com\/blog\/wp-content\/uploads\/2024\/03\/image-5-600x437.png 600w, https:\/\/promincproductions.com\/blog\/wp-content\/uploads\/2024\/03\/image-5-450x327.png 450w, https:\/\/promincproductions.com\/blog\/wp-content\/uploads\/2024\/03\/image-5-825x600.png 825w\" sizes=\"(max-width: 903px) 100vw, 903px\" \/><figcaption class=\"wp-element-caption\">The break point of images that have been optimized and those that have not yet.<\/figcaption><\/figure>\n<\/div>\n\n\n<p>This screenshot shows the breakpoint of those images that have been optimized and those have not yet been optimized.  The original images are optimized &#8211; which typically aren&#8217;t a huge change given that most images are highly compressed to start with.  The WebP images show a larger gain as the algorithm used to generate them has significant gains over a JPG or PNG algorithm.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Analyze Optimized Images on the Filesystem<\/h3>\n\n\n\n<p>One could also see the image optimization progress by checking the images on the filesystem.  This of course requires direct access to the webserver via FTP, a website admin like HPanel, or a terminal connection.  The optimized original JPG\/PNG and WebP images are stored right along side of the uploaded images in the <code>wp-content\/uploads\/<\/code> directory.  The images are organized in a <code>year\/month\/<\/code> directory structure based on when the images were uploaded.<\/p>\n\n\n\n<p>For each uploaded image after the images are optimized you&#8217;ll see the following:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><code>image-name.bk.jpg<\/code>: This is the original image that was uploaded and now renamed to include the <code>.bk<\/code> to indicate it&#8217;s a backup file.<\/li>\n\n\n\n<li><code>image-name.jpg<\/code>: This is the optimized version of the originally uploaded image (which was renamed to include <code>.bk<\/code> in the filename).<\/li>\n\n\n\n<li><code>image-name.jpg.webp<\/code>: This is the optimized <code>webp<\/code> version of the original image.<\/li>\n<\/ul>\n\n\n\n<p>In addition to these original full sized images, there are additional resized images based on the image sizes used by the theme of the site.  Thus the same variants of the above images will also show with a <code>-WxH<\/code> in the filename.  These smaller dimension images are critical to ensure that smaller file sizes are used when a full-sized image isn&#8217;t needed (which is most of the time).<\/p>\n\n\n\n<p>It is beneficial to note how the QUIC.cloud image optimization quota works.  Let&#8217;s assume that theme has 3 different size variants of an image (<code>150x150<\/code>, <code>300x649<\/code>, <code>500x500<\/code>).  Those three sizes plus the original image are all considered 1 image for the quota of QUIC.cloud.  Thus 200 original uploaded images plus all of their size variants will be processed per day.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Other Findings<\/h3>\n\n\n\n<p>One other issue I found in this process was that the <code>.htaccess<\/code> entry I made &#8211; per a suggestion from a post found <em>somewhere<\/em> on the internet &#8211; wasn&#8217;t a very good solution for what it was intended to do&#8230;  It only restricted <code>GET<\/code> requests but everything else was wide open to the world&#8230;  A good reminder that you can&#8217;t trust everything you read on the internet.  And yes, that statement is ironic as it&#8217;s written in a post on the internet.  No offense taken if a <em>trust but verify<\/em> methodology is used by those that take guidance from this post.  This is just a record of one mans findings &#8211; results may vary.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Other Debugging Methods Explored<\/h2>\n\n\n\n<p>At this point, the tutorial is essentially complete.  As pointed out above the root of the issue was a <code>403<\/code> status code returned by the webserver which prevented pulling of images from QUIC.cloud to the webserver which was self-inflicted by a <code>.htaccess<\/code> directive.  But in the process of finding the final solution, I went through a series of other investigatory steps.  I documented them along the way.  While they technically aren&#8217;t valid to the solution, there might be some value to others in the process I took and the other areas that were considered as possible issues.  So here goes some ramblings about un-fruitful debugging.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Manually Trigger Image Optimization<\/h3>\n\n\n\n<p>Since the images weren&#8217;t processing on a schedule, I figured they might if I manually trigger them despite the LiteSpeed module saying I shouldn&#8217;t.  So in the WordPress admin I went to <strong>LiteSpeed Cache -&gt; Image Optimization<\/strong> and triggered the three buttons to see if I could get anything to work.<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Clean Up Unfinished Data<\/strong><\/li>\n\n\n\n<li><strong>Send Optimization Request<\/strong><\/li>\n\n\n\n<li><strong>Pull Images<\/strong><\/li>\n<\/ul>\n\n\n\n<p>None of these did much of anything beneficial though.  Really they are doing the same code logic as the <code>cron<\/code>.  That means they always ran into the same <code>403<\/code> error I had been hitting all along.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Refresh QUIC.cloud connection<\/h3>\n\n\n\n<p>I attempted to refresh the connection between my WordPress site and QUIC.cloud.  Open and honest &#8211; I&#8217;m not 100% sure what this all does.  But it doesn&#8217;t seem harmful.  In my situation, it didn&#8217;t seem beneficial either though.  I saw several references from the QUIC.cloud staff posted on help forums indicating this may help in some cases though.<\/p>\n\n\n\n<p>In the WordPress Admin:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Go to: <code>LiteSpeed Cache -&gt; General -&gt; Domain Key<\/code><\/li>\n\n\n\n<li>Click the <strong>Redetect<\/strong> link in the top right corner of this section<\/li>\n<\/ul>\n\n\n\n<p>After this, try to send and pull images again manually or wait for the CRON job to complete running.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">DNS Proxy Status<\/h3>\n\n\n\n<p>The tech-stack for this WordPress site includes having it&#8217;s DNS hosted at Cloudflare.  Within that, the <code>A<\/code> Record and <code>CNAME<\/code> are configured to be <strong>Proxied<\/strong>.  This means that the IP address of the webserver is actually masked by a Cloudflare IP address which adds another layer of security as bad-actors can&#8217;t find the true IP address of the webserver.  Hard to attack what you can&#8217;t find!<\/p>\n\n\n\n<p>The thought here is that the obfuscated IP address was causing issues.  The IP of the webserver is configured in the LiteSpeed settings both in the WordPress Admin as well as in the QUIC.cloud configuration.  If the IP address of the server isn&#8217;t what it is due to being proxied, that could cause a communication breakdown.<\/p>\n\n\n\n<p>For the record, the webserver IP address is configured under <code>LiteSpeed Cache -&gt; General -&gt; Server IP<\/code> in the WordPress Admin as well as in QUIC.cloud at <code>Settings -&gt; Server IP<\/code> when clicked into a domain.  (<code><a href=\"https:\/\/my.quic.cloud\/dm\/www.example.com\/setting\" target=\"_blank\" rel=\"noreferrer noopener\">https:\/\/my.quic.cloud\/dm\/www.example.com\/setting<\/a><\/code>)<\/p>\n\n\n\n<p>But to be clear, I found that this is not a necessary change to make and I ended up leaving the <strong>Proxied<\/strong> check box enabled in Cloudflare and still found success in getting the images to optimize via QUIC.cloud.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Manually Trigger the WordPress Cron<\/h3>\n\n\n\n<p>The QUIC.cloud image optimization process relies heavily on the WordPress <code>cron<\/code> infrastructure.  So this prompted me to explore if the <code>cron<\/code> was running correctly or not.  One way to determine if it&#8217;s running or not is if the sites themes and plugins are auto-updating (if configured).  They were, thus implying that all was running as expected.  But if you have doubt and really want to force the cron to run you can do so by simply opening this URL in any web browser.  NOTE: insert your actual domain name in place of <code>example.com<\/code>.<\/p>\n\n\n\n<p><code>https:\/\/www.example.com\/wp-cron.php?doing_wp_cron<\/code><\/p>\n\n\n\n<p>When you open that page you&#8217;ll just see a blank page.  This is expected and how WordPress designed the <code>cron<\/code> system.  But sadly you won&#8217;t see immediate results in the image optimization just by visiting this page.  This action kind of just raised a flag saying &#8220;I&#8217;d like the <code>cron<\/code> to run now&#8221;.  But the there are many things that get run when this occurs and most are at set intervals like every 15 minutes, twice a day, etc.  I believe the image optimization runs every 15 minutes and thus you still need to wait a while for it to run.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Manually Trigger an Image Pull Request from Local Machine<\/h3>\n\n\n\n<p>This is where things get more technical and you have an opportunity to break things if you don&#8217;t do things correctly.  But this is how the status code of <code>403<\/code> was identified and ultimately lead to solving the root issue that prevented the optimized images from pulling down from QUIC.cloud.  Debugging what the code is doing gives all the information &#8211; the trick is knowing how to read the code, what files are of imporatance, and how to get useful information out of it.<\/p>\n\n\n\n<h4 class=\"wp-block-heading\">Identify the Image Optimization Pull URL<\/h4>\n\n\n\n<p>After reading the code, it was identified the process <em>stopped<\/em> when the pulled images URL was requested.  The URL called is from the webserver to itself via a <code>GET<\/code> request.  It is an authenticated request with a <code>nonce<\/code> (a one time token).  There are two ways to find this URL.<\/p>\n\n\n\n<h5 class=\"wp-block-heading\">Built In LiteSpeed Debug Logging<\/h5>\n\n\n\n<p>Enable the LiteSpeed debug logging from the WordPress Admin by going to <strong>LiteSpeed Cache -&gt; Toolbox -&gt; [6] Debug Settings<\/strong> and setting the <strong>Debug Log<\/strong> option to <strong>On<\/strong> and clicking the <strong>Save Changes<\/strong> button.  NOTE: you&#8217;ll want to turn this off at some point as leaving this on long term is not ideal.  This will write data to a file at <code>wp-content\/debug.log<\/code> relative to the WordPress root directory.  Additionally you may want to delete this file after you are done with your research as it will not be helpful long term.<\/p>\n\n\n\n<p>The issue with this file is there is a lot of data in it and finding the desired URL is difficult unless you know what you are looking for.<\/p>\n\n\n\n<h5 class=\"wp-block-heading\">Manually Create Debug Logging<\/h5>\n\n\n\n<p>Using a text editor (nano, vi, vim, Notepad++, etc.), open file <code>wp-content\/plugins\/litespeed-cache\/src\/task.cls.php<\/code>.  Around line 107 look for a function called <code>async_call()<\/code>.  Go near the bottom of this function and right before <code>wp_remote_post<\/code> add this line.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>error_log( \"url: \" . $url . PHP_EOL, 3, \"\/path\/to\/debug.log\" );<\/code><\/pre>\n\n\n\n<p>Replace <code>\/path\/to\/debug.log<\/code> with a file location you can write to on your server.  This code is going to log data to that file that we will need to reference.  Save the file.<\/p>\n\n\n\n<p>Go into the WordPress Admin to <code>LiteSpeed -&gt; Image Optimization<\/code> and click the <strong>Send Optimization Request<\/strong> button.  Wait a minute or two.  Then click the <strong>Pull Images<\/strong> button.<\/p>\n\n\n\n<p>Now look into the <code>\/path\/to\/debug.log<\/code> file &#8211; data should now have been written to that file.  That URL has a nonce that is unique to your server and thus needs to be fetched this way.  With that URL captured, the edit to the file can be reverted.  The URL will look something like this:<\/p>\n\n\n\n<p><code>https:\/\/www.example.com\/wp-admin\/admin-ajax.php?action=async_litespeed&amp;nonce=34be8c0f1c&amp;litespeed_type=imgoptm_force<\/code><\/p>\n\n\n\n<h4 class=\"wp-block-heading\">Manually Call the Pull Images URL<\/h4>\n\n\n\n<p>With the URL identified, a test request can be made to see what the status code is.<\/p>\n\n\n\n<p><code>curl -H 'Content-Type: application\/json' -d '{\"timeout\": \"0.01\",\"blocking\": \"\",\"sslverify\": \"\"}' -v -X POST https:\/\/www.example.com\/wp-admin\/admin-ajax.php?action=async_litespeed&amp;nonce=34be8c0f1c&amp;litespeed_type=imgoptm_force<\/code><\/p>\n\n\n\n<p>This can be done via a command line terminal with the above <code>curl<\/code> command.  If this is done on the same machine as the webserver it will use the same IP address as what WordPress did.  Given that was the root of the issue outlined in this tutorial, the status code was still a <code>403<\/code>.<\/p>\n\n\n\n<p>This can also be done from any desktop machine using a software called <a href=\"https:\/\/www.postman.com\/\" target=\"_blank\" rel=\"nofollow noopener\" data-lasso-id=\"1001\">Postman<\/a>.  Click the <strong>Import<\/strong> button and paste the <code>curl<\/code> command into Postman and then send the request.  This request will come from the IP address of that desktop machine.<\/p>\n\n\n\n<p>Regardless of the method used, the request should come back with a decent sized response.  But what is important here is the status code.  If using <code>curl<\/code> from the command line, look for the line that starts with <code>HTTP<\/code> and see what the number after it is.  For this to be successful, it needs to be a <code>200<\/code> (meaning things worked as they should).  However any other status indicates issues.  See below in the <a href=\"#references\">references<\/a> section for a link to other reasons a <code>403<\/code> status code may be returned.<\/p>\n\n\n\n<p>This bit of debugging is where the epiphany moment came.  Initially this URL was hit via Postman which was coming from the whitelisted IP address and thus things worked.  But when WordPress ran this same request it always failed.  Thus the IP restriction in the <code>.htaccess<\/code> file was part of the issue here.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"references\">References<\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li><a href=\"https:\/\/docs.litespeedtech.com\/lsws\/cp\/cpanel\/403-error\/\" target=\"_blank\" rel=\"noopener\" data-lasso-id=\"1002\">LiteSpeed <code>403<\/code> Error Debugging Guide<\/a><\/li>\n\n\n\n<li><a href=\"https:\/\/httpd.apache.org\/docs\/2.4\/mod\/core.html#limitexcept\" target=\"_blank\" rel=\"noopener\" data-lasso-id=\"1003\">Apache LimitExcept Directive<\/a><\/li>\n\n\n\n<li><a href=\"https:\/\/httpd.apache.org\/docs\/2.4\/mod\/core.html#limit\" target=\"_blank\" rel=\"noopener\" data-lasso-id=\"1004\">Apache Limit Directive<\/a><\/li>\n<\/ul>","protected":false},"excerpt":{"rendered":"<p>I struggled for several months with getting image optimization through LiteSpeed to pull .webp versions of my WordPress [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":3646,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"wprm-recipe-roundup-name":"","wprm-recipe-roundup-description":"","_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_feature_clip_id":0,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_post_was_ever_published":false},"categories":[9],"tags":[526,23],"class_list":["post-3604","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-wordpress-development","tag-litespeed","tag-wordpress"],"jetpack_featured_media_url":"https:\/\/promincproductions.com\/blog\/wp-content\/uploads\/2024\/04\/litespeed-wordpress-optimized-images-not-pulling.png","jetpack_shortlink":"https:\/\/wp.me\/p4BbcR-W8","jetpack_sharing_enabled":true,"amp_enabled":true,"_links":{"self":[{"href":"https:\/\/promincproductions.com\/blog\/wp-json\/wp\/v2\/posts\/3604","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/promincproductions.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/promincproductions.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/promincproductions.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/promincproductions.com\/blog\/wp-json\/wp\/v2\/comments?post=3604"}],"version-history":[{"count":25,"href":"https:\/\/promincproductions.com\/blog\/wp-json\/wp\/v2\/posts\/3604\/revisions"}],"predecessor-version":[{"id":3653,"href":"https:\/\/promincproductions.com\/blog\/wp-json\/wp\/v2\/posts\/3604\/revisions\/3653"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/promincproductions.com\/blog\/wp-json\/wp\/v2\/media\/3646"}],"wp:attachment":[{"href":"https:\/\/promincproductions.com\/blog\/wp-json\/wp\/v2\/media?parent=3604"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/promincproductions.com\/blog\/wp-json\/wp\/v2\/categories?post=3604"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/promincproductions.com\/blog\/wp-json\/wp\/v2\/tags?post=3604"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}