Team Staatic

We’re very sorry about this. It appears something slipped through our testing process. In order to make our plugin compatible with as many environments as possible, we downgrade our PHP code to support PHP versions all the way down to 7.1. During this process, a critical dependency got downgraded incorrectly, causing the fatal error you’re experiencing.

We are actively working on a patch that should resolve this issue. As soon as it’s ready, we will update this thread. Thank you for your patience and understanding.

Hi Ben,

Sorry to hear that you’re experiencing these issues.

A few questions to help us diagnose the problem:

1. Did this happen after an upgrade of some kind, or did it occur out of the blue?
2. When the publication is stuck at “Preparing publication,” it often indicates that Staatic is unable to successfully perform loopback requests. Can you check the Site Health report to see if there are any issues reported there?
3. If the Site Health report doesn’t show any issues, could you send us the Site Health Info report by emailing it to contact@staatic.com?

Regarding the second issue:

• Is this the same setup with Windows 10 via XAMPP?
• Did this site also get stuck at “Preparing publication” earlier?
• Could you provide the number of results (to get an indication of the site’s size) and the deployment method being used?

Looking forward to your information. If you prefer to share some details privately, feel free to email us at contact@staatic.com.

Thank you for your detailed response and kind words! We’re happy to help.

After further investigation and trying to reproduce the exact issue you’re experiencing, we have identified several key points.

We can confirm that the issue you are seeing is indeed caused by the file path length exceeding the Windows maximum path length of 260 characters. Although Staatic correctly writes the files of the static version of your site into the configured target directory, certain applications and system functions may not handle it properly when the path length exceeds this limit.

Interestingly, when right-clicking the file with the long path in Explorer and selecting “Copy as path”, the path is converted using the 8.3 filename convention (short filenames), e.g., C:\Users\zachb\Documents\ZACHSD~1\Projects\ACTIVE~1\UBSWOR~1\PROJEC~1\STAATI~1\STAATI~1\WP-CON~1\uploads\ELEMEN~1\thumbs\UBS-LO~1.JPG. While the regular path does not display correctly in the browser, this shortened path does.

To make the static version of the site work, you will either need to use a web server to host it, or place the files in a different path that does not cause any file paths to exceed the limit of 260 characters when using Offline URLs.

The appended 40 characters to the PNG file name appear to be caused by Elementor. When selecting a custom image resolution, Elementor may generate a scaled version of the image at the exact resolution required, resulting in these longer filenames.

Regarding the URL mismatch, it is possible that there are two versions of the image, or the image path may have been altered in some way. Staatic simply takes over the file names as they appear on the dynamic version of your site and only alters the beginning of the URL to ensure compatibility with offline sites or different domains.

Hopefully, this information helps resolve the issue. If you continue to experience problems, please feel free to reopen the issue or open another topic, and we’ll be happy to assist further.

• This reply was modified 1 year, 11 months ago by Team Staatic.

We’ve identified that the Pagination block editor widget sometimes generates query string links instead of pretty URLs, which can cause issues, especially on static sites. The root of this issue seems to be tied to how the Pagination block interacts with the WordPress theme and settings. Specifically, if the query loop does not inherit from the global query, it generates query string URLs, which are not compatible with all setups.

A successful workaround that has helped in this scenario involves setting the desired page as the site’s “Posts page” under Settings > Reading in WP-Admin. This adjustment ensures that the Pagination block correctly inherits from the global query and thereby generates pretty URLs.

For those experiencing similar issues, please try adjusting your “Posts page” settings and consider the compatibility of your WordPress theme with the block editor’s pagination widget.

After further testing and feedback, we’ve made an additional update to the development version of the plugin, which has now successfully addressed the problem. This fix will be included in version 1.9.3 of the plugin, scheduled for release later this week.

Thanks @benleow, for your assistance on this issue.

Hi Ben, thanks for reaching out and detailing the issue you’re experiencing.

Normally, the default setting (“/404_not_found/”) should work seamlessly and be used on the deployed static site, including when hosted on Netlify. I’m sorry to hear that you’re encountering difficulties with the 404 page not displaying as expected.

We attempted to reproduce the issue you’ve described but were unable to encounter the same problem. This leads us to believe that there might be a specific configuration or condition in your site setup that is causing this behavior.

To help us diagnose and resolve this issue, could you please provide us with some additional information:

• Site Health Info: navigate to Tools > Site Health > Info in your WordPress dashboard. Click Copy site info to clipboard to copy this information.
• Publication Logs: while having “Extensive logging” enabled in Staatic > Settings > Advanced, start another publication process. Once the publication has completed, retrieve the logs by going to the publication details, clicking on the Logs tab, and then clicking the Export button at the top of the page.

Please send the site health info and exported log file to contact@staatic.com. This info will help us pinpoint the issue more accurately.

Thanks for clarifying the details. We now understand the issue stems from how Nginx handles your site’s file structure.

Nginx has a feature that automatically redirects requests to directories missing a trailing slash. This appears incompatible with Staatic’s default file structure, resulting in URLs with an unwanted trailing “/”.

There are a couple options to address this:

1. Configure Nginx by changing the try_files declaration to:
   try_files $uri $uri/index.html $uri/ /index.html;
   This should serve the correct page immediately instead of redirecting. However, we realize this may not be possible in all setups.
2. Use Staatic’s development version with an updated file structure. We’ve made changes so the file structure works with Nginx out of the box. You can download this version by:

• Going to the Staatic plugin page
• Selecting “Advanced View”
• Under “Advanced Options > Previous Versions”, choose “Development Version”
• Click “Download”

The development version should resolve the issue with unwanted slashes in your URLs. Please install this updated version of Staatic and let us know if you have any other questions or run into any issues.