Plugin Support
Frank
(@staaticfrank)
Hi @acekin262, thank you for the kind words, and especially for recommending Staatic to your friend. It is great to hear that the gallery layout and lightbox carried over well in your test.
The folders have different roles, even though two of them can look the same after a successful publication:
deploy is the finished static site. This is the folder to copy, serve, or keep as the local archive.staging is Staatic’s working copy. Staatic builds the next version there first and then mirrors it to deploy. It remains in place after the publication, which is why you can currently view the same site from both folders, but it will be cleared and rebuilt when a new publication starts.resources is Staatic’s internal store for the generated page and asset contents. The finished site in deploy does not need this folder to function.
If the archive will be opened directly from the computer rather than through a local web server, publish it with Destination URL set to Offline URL and enable Append /index.html to directory URLs.
For the cleanest portable archive, you can also use the Download action for the publication under Staatic > Publications. With the default Symlink/Copy Uploads setting disabled, that produces a zip of the complete generated site. If you enabled that option on Linux, disable it and publish again, or make sure a manual copy of deploy follows the uploads link so that the image files are included.
I would not manually delete resources from the original WordPress installation as Staatic may still need it to download or redeploy retained publications.
I hope that clears up the folder structure, and thanks again for the recommendation!
Thank you for the explanation and deployment. What I exported as plain HTML content functions perfectly on Cloudflare platform as well. This is a very useful and well functioning plugin, and the support is quick and well explained. Thank you again.
Hello again. I have a couple of questions on some of the settings on a shared hosting account. Probably two settings are critical for a successful completion: HTTPP Delay and HTTP Concurrency. The first is set at zero and the latter is at 4. My gut feeling is that some delay may be necessary so that Staatic can run and complete the deployment. What may be a reasonable delay in milliseconds? Will the hosting company try to slow down the running process and thus interrupt it if there is no delay? The site my friend will attempt to export to HTML is
https://www.dennisgoulet.us/ .
Thank you.
-
This reply was modified 2 weeks, 6 days ago by
acekin262.
Plugin Support
Frank
(@staaticfrank)
Hi @acekin262,
Good question. You do not normally need to add an HTTP Delay for Staatic to complete a publication. The default settings are 4 concurrent requests and no delay.
- HTTP Concurrency controls how many pages or files Staatic can request at the same time.
- HTTP Delay adds a short pause before those requests are made.
The hosting company would not normally interrupt Staatic simply because the delay is set to zero. On a more limited shared-hosting account however, making several requests at once can cause the site to respond more slowly or occasionally return errors or timeouts.
The site contains several image-heavy galleries, so using slightly gentler settings for the first full publication is reasonable.
A good starting point would be:
HTTP Concurrency: 2
HTTP Delay: 250 ms
I would run the first publication during a quieter period. If it completes without errors, you can keep these values or return to the defaults later for a faster publication.
If the log shows repeated connection errors or timeouts, reduce HTTP Concurrency to 1. You could then increase the delay to 500 ms if needed. I would not start with a delay of several seconds because that can make a large publication unnecessarily slow without necessarily making it more reliable.
Hello again,
My friend’s attempts to get a static copy of his site failed several times. I tried doing the same on my cloned site and my attempt failed as well. After a few failures, I changed the parameters as follows:
HTTP timeout 120
HTTP delay 250
HTTP concurrency 2
Publication task timeout 360
It was going at a steady rate and I captured a short screen video last night. However, this morning, I got the message that it failed about four hours after I started it with a message “Publication failed during crawl task”. You can view the short progress video:
https://www.dropbox.com/scl/fi/469dhdmfsnp3cuulq474d/Video_2026-08-30_204518.mp4?rlkey=2d29zt0pzj7s8l3v551y3lfw6&dl=0
My site has about 830 posts, 550 or so NextGEN Galleries, and thousands of photographs. Will Staatic convert my site to static content that I can run on my computer? If the full site is too heavy a load, can I attempt to do it in segments, and how? Are the parameters I ended up with reasonable, or do they need changing?
Thank you for your help.
PS The cPanel indicates that I have used allocated number of files:
596,297 / 600,000 (99.38%)
If this is the problem, I guess I am hitting a brick wall.
-
This reply was modified 1 week ago by acekin262.
Plugin Support
Frank
(@staaticfrank)
Hi @acekin262,
Thanks for the recording. It shows Staatic had discovered roughly 132,135 crawlable URLs and had processed 1,388. Those are not necessarily all photographs; they can include gallery originals, thumbnails, generated variants, pages, scripts and other files.
The timing strongly matches Staatic’s overall four-hour publication limit. The 360-second Publication Task Timeout only controls individual processing passes; it does not extend the whole publication. The visible crawl error is generic, so the exported log is needed to confirm this. Your HTTP settings are already reasonable and conservative and I would not slow the crawl further.
The cPanel file limit is very likely a major part of the problem. Only about 3,700 file entries remain, while Staatic needs additional files for the crawl, its working data and the finished site. Please ask your hosting provider to increase the account’s file or inode limit before another attempt.
The site size itself is not necessarily unsupported, and a completed publication can run locally using Offline URL with Append /index.html to directory URLs enabled. Publish Selection is useful for testing one gallery, but separate selections do not simply combine into the first complete archive.
The first route I would try is excluding the large media directory from the crawl, publishing the pages and regular assets, and then assembling the archive on your computer by copying the gallery files into the same paths. This should avoid making Staatic download and process every photograph separately. We first need to confirm which path contributes most URLs, because NextGEN can use separate original, thumbnail and cache directories and the offline links still need testing.
Could you share the failed publication’s exported JSON log and a screenshot of Settings > Build showing Additional Paths and Excluded URLs? That should tell us what can be excluded and copied safely.
Thank you for the quick response. There is one expandable notice in the logs. It is an itemized list with lines like:
root-info/wp-includes/class-wp-hook.php(353): Staatic\Vendor\WP_Background_Process->maybe_handle()
Would you like me to send you all from #0 to #7? If there is another JSON log file somewhere else, tell me where to find it and I will share that too. I had to delete the contents of the Resources folder as I needed more file usage. That folder had subfolders from 1-9 and a-f I believe, with many files.
Do I understand correctly that Staatic is configured to run for four hours and should generally finish the job in that time frame? If I exclude all the NGG content folders and the WordPress uploads folders, can I simply copy those folders to the same structure after Staatic finishes the job?
Thank you again.
Plugin Support
Frank
(@staaticfrank)
Hi @acekin262,
Thanks for checking. Yes, please send the full expanded entry including the error line immediately above #0 and frames #0 through #7.
Alternatively, you can download the JSON from Staatic > Publications > Details > Logs > Export. That contains the same failure and the surrounding log entries, so there is no need to send both. Since this is a public forum, please redact account names, private server paths or URLs and sensitive query-string values before sharing it.
The 0-9 and a-f folders you found were Staatic’s internal resource store. Deleting them does not remove the publication logs or an existing deploy directory, and a new full publication will recreate the resources it needs. It does mean that older publications may no longer download or redeploy correctly because their stored files are gone.
Four hours is the default safety limit, not the time a publication is normally expected to take. If a later processing pass sees that the publication has exceeded that limit, it is stopped and marked Failed. The error detail should confirm whether that is what happened here.
Yes, that approach should work for the static media files. Remove or disable any Additional Paths entries that include the NGG or uploads directories, then add their public URL roots under Excluded URLs, including the recursive wildcard; for example /wp-content/gallery/ and /wp-content/gallery/*. After the publication finishes, copy those folders into the same relative paths in the archive on your computer. Keep the NextGEN plugin files included and skip wp-content/uploads/staatic when copying uploads.
Finally, disconnect from the internet and test that gallery’s thumbnails, full-size images and lightbox. Features that rely on AJAX or WordPress itself may not work in a fully offline archive, which is why the one-gallery test is important.
Much appreciated! Here is the information, I removed the common root path from all lines:
Log Summary
- 2026/08/30 at 8:29 pm – Starting publication
- 2026/08/30 at 8:29 pm – Initializing crawler
- 2026/08/30 at 8:37 pm – Finished initializing crawler (132042 enqueued)
- 2026/08/30 at 8:37 pm – Crawling started for ‘https://testbed.keptlight.com/‘
- 2026/08/31 at 12:29 am – Publication failed during crawl task
The publication process took too long and was canceled.
RuntimeException: The publication process took too long and was canceled. in /wp-content/plugins/staatic/src/Publication/BackgroundPublisher.php:227
Stack trace:
#0 /wp-content/plugins/staatic/vendor/deliciousbrains/wp-background-processing/classes/wp-background-process.php(256): Staatic\WordPress\Publication\BackgroundPublisher->task()
#1 /wp-content/plugins/staatic/src/Publication/BackgroundPublisher.php(155): Staatic\Vendor\WP_Background_Process->handle()
#2 /wp-content/plugins/staatic/vendor/deliciousbrains/wp-background-processing/classes/wp-background-process.php(167): Staatic\WordPress\Publication\BackgroundPublisher->handle()
#3 /wp-includes/class-wp-hook.php(353): Staatic\Vendor\WP_Background_Process->maybe_handle()
#4 /wp-includes/class-wp-hook.php(377): WP_Hook->apply_filters()
#5 /wp-includes/plugin.php(523): WP_Hook->do_action()
#6 /wp-admin/admin-ajax.php(192): do_action()
#7 {main}
Thank you very much.
In the settings, Additional Paths, /root/wp-content/uploads is explicitly added with a check mark on Recursive option. Can I add folders to exclude from that folder by year, or can that additional path be removed? I was thinking of excluding the uploads folder entirely, along with gallery and unused themes in the themes folder.
Plugin Support
Frank
(@staaticfrank)
Thanks for sending the full log. That confirms the publication hit Staatic’s four-hour limit.
The first thing I would change is the recursive /root/wp-content/uploads entry under Additional Paths. That tells Staatic to add every file below uploads, whether the site uses it or not, and is likely the main reason the crawl became so large. This works well on smaller sites, but in your case I would remove that entry entirely rather than excluding individual years.
For the next attempt, leave uploads out of Excluded URLs. Staatic will still find the images and other files that the site actually references without automatically adding the entire media library.
There is no need to exclude unused themes either. Their files are not normally crawled unless the site references them, while the active theme and plugin files need to remain available.
Before retrying, please check the current cPanel file count and use Publish Selection to test one representative gallery.
If the NextGEN media still makes that smaller crawl impractical, you can then exclude its media path and copy the complete gallery folder into the same relative location in the archive on your computer.
I am trying a new run with the following changes:
- I removed the check mark from the include URL with Recursive at the end, neither is checked
- Added several URLs to the exclude group with the root path at the beginning of each
/wp-content/uploads/*
/wp-content/gallery/*
/wp-content/dijitaldokuman/*
/wp-content/cache/*
- Under the Publication Resources tab, it still lists many from /uploads
- In about 30 minutes, the crawl indicator is at 2,340 / ~18,955 (12%) and going
- I will report when the process finishes or fails
Thank you for your guidance.
The last attempt failed at exactly the 4-hour mark. I brought the parameters to their default and ran once more. It was going at a good clip but failed again. This time I am pretty sure it hit the number of files limit on my account. I am reporting not a failure of Staatic but to share information that excluding folders with a large number of files with default parameters would most likely work. In fact, the files and folders in the staging folder display content as expected. But I do not know how complete the duplication is. It did its best to produce an HTML replica, and the pages I navigated displayed properly as if on the live site.
Thanks for all your help.
-
This reply was modified 4 days, 19 hours ago by acekin262.
Plugin Support
Frank
(@staaticfrank)
Hi @acekin262,
Thanks for reporting back. Reducing the crawl from about 132,000 URLs to about 19,000 shows that removing the recursive uploads entry made a substantial difference. At the rate shown in that run, it was still on course to take about four hours, which explains why it reached the same limit. The default HTTP settings can make it faster, but they do not change that overall limit.
Given the earlier 99.38% usage, the hosting file limit is a very plausible cause of the latest failure. The final error line would confirm that, but there is no need to send another full log unless you would like us to check it.
It’s also encouraging that the pages in staging look correct, but after a failed publication that folder may contain older or partial output. Excluded images may also be loading from the live site while you are online.
I would pause further full attempts until the account has more file capacity or test from a local WordPress copy with sufficient storage. Keep the recursive uploads entry disabled and after a successful publication, copy the excluded media separately and test the archive offline.
Thanks again for sharing the results. This is useful information for other large media-heavy sites as well.
