Team Staatic

The issue was confirmed to be due to resource limitations, which were addressed by adjusting concurrency settings and timeouts. Since there have been no further updates, we assume the solution worked.

If similar issues arise, please don’t hesitate to reach out.

hi @rafczy , thanks for the update. The error message indicates an issue with resolving the host, so it doesn’t seem related to the?ulimit. To help us investigate further, could you share your Site Health info?

Alternatively, please check under the Site Health status to ensure that both “Your site can perform loopback requests” and “Staatic can perform loopback requests” are listed under Passed tests. These loopback requests are crucial for Staatic to function correctly.

Looking forward to your feedback and helping you resolve this issue!

Hi @rafczy,

Thanks for reaching out, and sorry to hear you’re having trouble. It sounds like your WordPress site is having difficulty resolving its own host, which Staatic relies on to generate the static version by crawling the site.

Here are a few things you can try:

1. Check Site Health: head over to WP-Admin > Tools > Site Health. Look for any issues or errors that might be causing the problem. Fixing these is probably enough to resolve this issue.
2. DNS and hosts file: make sure your DNS settings are correct. You might need to add a DNS entry for my.host.com, or an entry in your /etc/hosts file to ensure it resolves correctly.
3. Check security settings: sometimes, firewalls or security plugins can block internal requests. Try temporarily disabling them to see if that’s the issue.

If none of these steps work, it would be helpful to check the Site Health info. You can get this by going to WP-Admin > Tools > Site Health > Info (tab) and clicking “Copy site info to clipboard”. You can send this info to us at [email protected], and we’ll take a closer look.

Please let us know if this helps or if you have any other questions.

Hi @andrelauret23 , thanks for your enthusiasm and for suggesting improvements to the Staatic plugin! We really appreciate your input. It turns out that configuring the Destination URL via WP-CLI is already possible using the built-in wp option update command.

Here’s how you can do it:

wp option update staatic_destination_url 'https://example.com/'

This command will update the URL directly in your WordPress database. You can find other settings related to Staatic in the wp_options table, usually prefixed with “staatic_”.

As for contributing, we currently don’t have a public GitHub repository. This is mainly due to the complex build process we have in place, which involves scoping vendor dependencies and downgrading PHP 8 code to PHP 7.4 to ensure compatibility across a wide range of environments. We’re actively exploring solutions to manage these challenges, so we can eventually open up the repository for public contributions.

In the meantime, if you have any cool features or improvements, you might consider creating a separate plugin to enhance Staatic’s functionality.

Thanks again for your interest and ideas. We’re excited to see what you come up with!

@andrelauret23 , thank you for your feedback and for outlining this suggestion clearly. Adding WP-CLI support for configuring the Destination URL is indeed a valuable idea, and we’ll definitely consider it for future updates.

If you have any additional suggestions or feedback, feel free to share them.

Since we haven’t heard back from you, we’ll go ahead and mark this as resolved. If the issue persists, please feel free to open a new topic. Thanks!

Hi @anthonyeden , thanks for reaching out. It seems there is some confusion regarding the --merge parameter. This feature, along with the --partial flag, is exclusive to the Staatic Premium version and is not available in the community edition. The ability to merge a subset of specified or automatically tracked changes is a key feature of the Premium version, alongside other advanced functionalities like integrated search and form handling.

We apologize for any confusion caused by the documentation and will update it to better clarify the differences between the versions. If you have any further questions or need assistance, please feel free to reach out.

Hi @kavish895, just checking in to see if there are any updates on the directory URL issue. If you could share your site URL or any updates on your end, that would be helpful.? Thanks!

Hello @error418, thank you for reaching out with your feature request. Adding a command to delete publications via CLI is indeed a valuable suggestion and we will definitely consider it for a future update.

In the meantime, please note that our system already includes an automatic cleanup routine that deletes publications older than 7 days. We understand that flexibility in this feature could be beneficial as well, so adding a filter hook to adjust the cleanup period is also on our radar.

We appreciate your input and encourage you to keep an eye on our changelog for any updates regarding these features.

We’re glad to hear that you were able to resolve the issue by adjusting the timeout limits. If you need any further assistance, feel free to reach out.

Thank you for updating us, and happy publishing! ??

Hello!

Thank you for your kind words about the plugin. We’re sorry to hear you’re encountering an issue where the build process stalls. When a publication stalls without any errors, it often indicates a HTTP timeout or an uncaught fatal error. Let’s work through some steps to resolve this.

First, we recommend trying to initiate the publication using the Staatic publish WP-CLI command instead of through WP-Admin. The CLI command bypasses the usual web request constraints such as memory and time limits. You can find detailed instructions on how to use the WP-CLI command in our documentation.

If using WP-CLI isn’t feasible, please enable WP_DEBUG and WP_DEBUG_LOG in your WordPress configuration and restart the publication process. When it stalls, check the /wp-content/debug.log file for any error messages. For detailed instructions, have a look here.

Should there be no errors in the log, it would be helpful if you could share the site health information. This can be done by navigating to WP-Admin > Tools > Site Health > Info (tab) and clicking “Copy site info to clipboard”. You can paste this information here or email it to us at [email protected].

Looking forward to your feedback.

Thank you for the update. It seems that Fleek.xyz hosting might require the index.html for directory URLs to work properly. To better assist you, could you share the URL to your site? If you prefer to keep this information private, you can email it to [email protected]. Thanks!

Thank you for clarifying your use case.

To address your requirement of excluding the /index.html part from URLs, we’ve added an experimental option in the development version of the Staatic plugin. You can download this version by going to the plugin’s page advanced view, navigating to Previous Versions under Advanced Options, and choosing the Development Version. Once downloaded, update your plugin to this version.

After updating, go to Staatic > Settings > Build, where you will find the option “Append /index.html to directory URLs”. Uncheck this option and click Save Changes at the bottom of the page. Then, start a new publication to apply these settings.

Please let us know if this resolves your issue or if you need further assistance.

Hi @kavish895,

When using the “Offline URL” option in Staatic, it generates relative links for static content, which is useful for viewing the site without a web server, using file:// URLs. In this case, each page’s index.html must be explicitly referenced because there’s no server to interpret URLs and serve the default index file.

Could you clarify how you’re running your static site locally? Are you using a web server like Nginx, or are you opening the files directly in your browser?

If you’re using Nginx, you can set a regular destination URL under Build settings, like / or https://www.mysite.local/, depending on your web server configuration. This approach allows Nginx to handle URL requests and serve default index files without needing to specify index.html.

If you’re opening files directly in your browser, the index.html must be included in the URL. What is your reason for wanting to omit index.html in this setup?

Thank you very much, @giampiero , for the wonderful review! Your support is truly appreciated and motivates us to continue enhancing our plugin.