Team Staatic

Thanks for reaching out and sorry to hear you’re running into an issue creating a static version of your WordPress site.

To better understand the situation and determine if the Windows maximum path length is the root cause, could you please provide the exact path of your site on the Windows file system? For a default site path using LocalWP with a Windows username “Username”, the path length for the logo file would be 193 characters:

C:\Users\<Username>\Local Sites\urbanbirdservices\app\public\wp-content\uploads\2024\03\elementor\thumbs\UBS-Logo-2024-02-06-High-Quality-Cornerless-qlggdi1juyf9cleg0psnukzxka2r3my325cxh7weie.png

When deployed to the default Local Directory target directory, this path extends to 227 characters:

C:\Users\<Username>\Local Sites\urbanbirdservices\app\public\wp-content\uploads\staatic\deploy\wp-content\uploads\2024\03\elementor\thumbs\UBS-Logo-2024-02-06-High-Quality-Cornerless-qlggdi1juyf9cleg0psnukzxka2r3my325cxh7weie.png,

which is still below the Windows default maximum path length of 260 characters (for more details, see Microsoft’s documentation on maximum file path length).

Given that you’re encountering a crawl error for the logo, it suggests there might be another underlying issue. Staatic functions by crawling/visiting each page and asset on your site as a regular (non-authenticated) visitor would. It follows any internal links within your site’s scope and processes them to ensure compatibility with a static site version.

To address the 404 error Staatic reports while attempting to retrieve the logo, please check if the logo displays correctly on the dynamic version of your site at https://urbanbirdservices.local. Also, verify if the logo URL referenced in the HTML source code of the page matches the one references in the error reported.

If reducing the path length resolves the issue, implementing shorter names before generating the static site is indeed the best practice.

Looking forward to your feedback to help resolve this issue.

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.

Thank you for your review. We’re sorry to hear about the issues you’re encountering with our plugin. Ensuring it functions correctly for all users, both free and premium, is a priority for us.

Please rest assured, it is not our practice to compromise the functionality of our free version to prompt upgrades. We’re eager to resolve this issue and make sure our plugin meets your expectations. For assistance, you can either open a support topic on the support forum or email us directly at [email protected]. We provide dedicated support to all our users, regardless of their subscription status.

Looking forward to hearing from you.

Hi Ashley, thanks for posting your issue regarding pagination. Generally, static sites do not support query strings (e.g., ?page=2). Instead, pagination should be handled with pretty permalinks, such as /page/2/, /page/3/, etc. This should work seamlessly with Staatic.

To better assist you, could you please provide the following details:

• An original HTML snippet where pagination is implemented on the dynamic site.
• A HTML snippet of the same after being processed by Staatic.
• The configured “Destination URL”, which can be found under Staatic > Settings > Build in your WordPress dashboard.

If there are any specific configurations or additional details you think might be affecting how pagination is handled, those would be helpful as well. For a comprehensive view of your site’s setup, you can provide the site information by navigating to WP-Admin > Tools > Site Health > Info (tab) and clicking “Copy site info to clipboard”, then sending it to [email protected].

Looking forward to your response to help get this sorted out!

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.

Thank you for supplying the necessary details. From the information you provided, it seems we have pinpointed the potential source of the issue. To verify our hypothesis, could you please download and install the development version of the plugin by visiting https://www.ads-software.com/plugins/staatic/advanced/ (select Advanced Options > Previous Version > Development Version > Download), and then proceed with initiating a new publication process?

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 [email protected]. This info will help us pinpoint the issue more accurately.

You’re correct – the version signature for the development build is currently the same as the stable 1.9.2 release. This signature will be updated with the next major stable version.

I’m really glad to hear that the adjusted file naming convention in the development version has resolved your issue with the unwanted trailing slashes! And that serving the static files through Nginx is now working smoothly.

Thank you for confirming that everything is operating as intended. We appreciate you taking the time to test the development build and provide feedback. Do not hesitate to reach out if any other questions come up.

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.

Thanks for the follow-up and the details about your setup. It helps us narrow down the issue with your permalink structure after using Staatic.

To ensure we’re on the same page, it sounds like the HTML Staatic generates has the correct links ending in “.html”, and your C# script only adjusts the static file/directory structure post-generation. This makes me wonder exactly where the “.html/” issue crops up in your workflow.

A few more questions for clarification:

1. When and where exactly do you notice the URLs ending with “.html/”?
2. You mentioned using Docker, but could you specify the web server(s) or proxy(s) setup? The server configuration might influence how URLs are handled and displayed.

Understanding these details is crucial for us to pinpoint the issue accurately.

Looking forward to your response.

Hello Edson,

Thank you for reaching out and for providing a detailed explanation of the issue you’re encountering with your blog’s permalinks. We understand your concern regarding the URL structure and its potential impact on SEO.

Staatic is designed to adapt to the permalink structure you’ve configured within your WordPress settings. If your permalinks are set to include “.html” at the end, like “/%postname%.html”, Staatic should normally generate links that exactly match this structure, resulting in URLs like “/some/page.html”. The presence of “/some/page.html/index.html” on the filesystem is due to how Staatic organizes content for web delivery. This technical detail is primarily for serving the files correctly and should not affect how your URLs appear to visitors or search engines.

However, the issue you’re experiencing, where a trailing slash is added to your URLs, making them appear as “/year/month/blog-post.html/”, is something we can certainly look into. This behavior isn’t expected based on the permalink structure you’ve described.

To help us diagnose and address this issue more effectively, could you please provide us with your site’s Health screen information? This can be found by going to Tools > Site Health > Info (tab) in your WordPress dashboard. There, you’ll find a button to copy the information to your clipboard. Once you have that information, please send it to us at [email protected].

Additionally, we appreciate you sharing the C# program you created to address this issue.

Thanks in advance for providing the requested information.

@angelseee, we’ve made progress on the issue you reported. Our team was able to reproduce the problem and has developed a solution. This fix has been included in the newly released version 1.9.1. We apologize again for any inconvenience this may have caused and expect that the latest version will resolve the issue in your environment. Thank you for your patience and understanding.

If for some reason you’re still encountering issues, please feel free to reopen the topic.

@angelsee, we apologize for the difficulties you’ve encountered with the update. It appears the adjustments we made to URL and path detection, intended to enhance compatibility with environments such as Bedrock and WPMU, especially on the Windows platform, may be contributing factors. We’re actively working to replicate the issue you’ve described and will provide an update promptly. We sincerely regret any inconvenience this has caused.

Currently, deploying directly using FTP is not an out-of-the-box feature in our plugin. However, you can achieve this by utilizing tools like CurlFtpFS, which allows you to mount remote directories locally. By combining CurlFtpFS with our “Local Directory” deployment method, you can effectively deploy via FTP right now.

We understand the value of having native FTP support and will consider adding this feature in future updates. Thanks for your input!

Thank you for your feedback and suggestions. We are glad to hear that the new filter hooks have been working well for you.

Your suggestion for a GUI textarea for custom code is noted. It’s an interesting idea that could simplify the user experience. We’re also considering your other suggestions, like options for URL redirections and gzip compression.

If you have any other ideas or feedback, please feel free to share them with us.