Team Staatic

Thanks for letting us know it worked! If you have any more questions or need further help, feel free to start a new topic.

Hi @webverts.

First of all, thanks for using Staatic! While there’s currently no built-in feature in the interface to change the 404 path, you can achieve this through a custom action hook.

You can find a working example of such a script here: https://gist.github.com/staaticdotcom/c42db4699118b3c83518be431a340013. To use it, simply download the staatic_post_processor_cloudflare.php file and place it in your /wp-content/mu-plugins folder (you might need to create this folder if it doesn’t already exist). Once you’ve done that, on the next publication, the 404 page should be stored as 404.html.

We’re also considering adding direct support for this feature from the interface in future updates, but for now, this should serve as a solid workaround.

Let us know how it goes, and feel free to reach out if you have any questions or run into any issues!

Since we haven’t heard back from you, we’ll consider this issue resolved for now. If you’re still experiencing any problems, please feel free to reopen the topic or start a new thread. Thank you!

Thank you, @hatisenang , for your review and feedback! We’re glad Staatic is helping with your site conversions.

We do support incremental pushes using the Publish Selection feature, which allows you to update only a subset of your site’s pages. Our premium plugin expands this further with the Publish Changes feature, which automatically publishes new, updated, or deleted posts/pages. If that’s what you’re looking for, the premium version might be worth considering.

Thanks for supporting Staatic!

Thanks for providing the additional information. It appears that the high number of resources is causing a timeout during the Netlify deployment initialization step. By default, an additional path is configured under Staatic > Settings > Build to include everything in your wp-content/uploads directory, which might be including too many files.

You can try disabling this additional path temporarily so that the Staatic crawler only includes the directly referenced assets and see if this helps. If this doesn’t resolve the issue, we recommend using the WP-CLI publish command for large deployments, as it bypasses the resource limits that the web publisher encounters.

For more details on the WP-CLI publish command, please refer to the documentation here.

Please let us know if this helps.

Hi @slawa19, just checking in to see if you were able to resolve the timeout issue you were experiencing during the deployment of your static site. If you’re still having trouble, please let us know so we can assist you further. Thanks!

Hi @slawa19, sorry to hear you’re running into a timeout issue during the deployment of your static site. To help us better understand the issue, could you please provide some additional details:

1. Which deployment method are you using (e.g., Local Directory, S3, etc.)?
2. Can you give us an idea of the size of your site? Specifically, how many resources does the publication encompass? You can find this information from the publication detail page’s summary view, as well as the resources tab list view.

Additionally, it might be helpful to check your site’s health information. You can do this by going to WP-Admin > Tools > Site Health > Info (tab) and clicking “Copy site info to clipboard.”. You may email this information to [email protected] if you prefer.

Looking forward to your feedback.

Since there hasn’t been any update for a while, we’ll be marking this issue as resolved due to inactivity. If the issue persists, please feel free to reopen the thread.

Since there hasn’t been any update for a while, we’ll be marking this issue as resolved due to inactivity. If the issue persists, please feel free to reopen the thread.

We have just released a patched version 1.10.3 that should resolve this issue. Please update to this version and let us know if it addresses the problem. Thanks again.

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, hope you’re doing well. Just wanted to follow up and see if the publication process was successfully resolved, as there hasn’t been any update for a while. Thanks!

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 [email protected]?

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 [email protected].

Thanks for the update and confirmation. You’re very welcome! If you have any further questions or need additional assistance in the future, please don’t hesitate to reach out.

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 10 months ago by Team Staatic.