jessejones

@ibenic Thanks for response and explanation of how it works! ??

Yeah in theory, everything in the sitemap should be the majority of pages and the pages in it should link out to the majority of the site. The only exception would be pages that a user does not want to index, since its not part of the Sitemap, but these pages they could add to the “additional files” section.

For the files, does Simply Static keep some kind of running list if the file URL/asset (JS, CSS, image) has been found?

For most sites, it seems like the website pattern would be:
– Major CSS and JS files don’t change much between pages
– Image usage can vary greatly between pages, e.g. blogs typically have different images in every post.
– Occasionally there’s new JS/CSS if the page is somehow unique from the rest of the site, e.g. special layout, sale, new design, etc.

In the case of images/media, it might be possible to access the media section of the site. The majority of images a website contains will probably live here with some linked out externally, e.g. CDN.

• This reply was modified 1 year, 5 months ago by jessejones.

Thanks for the follow up @patrickposner and that sounds like a great idea! ?? I think this should resolve any theme or plugin that uses webpack or lazy loading.

Going through the error messages again, this seems like this could be more of a Webpack issue then anything else. Any page builder/theme that uses Webpack, e.g. Divi, Elementor, etc, will probably be effected depending on how the JS is fetched.

• This reply was modified 1 year, 6 months ago by jessejones.

The Simply Static versions were:
2.3.1 – Simply Static Open Source
1.3.1 – Simply Static Pro

Going to versions below x.3 resolved it.

One additional detail to add:
Latest versions of Simply Static show nearly double the number of pages/files then older versions. No page counts were increased.

I was able to temporarily resolve this by going down to older versions Simply Static.

@crstauf the absolute URLs part is the issue. How are you deploying your site?

As a workaround, if you’re doing deploys via Github repo, you can use a Github action to remove the absolute URL from tel and mailto links. Unless you need must have absolute links, I’d stick to relative links as it tends to be less error prone (in cases such as this and others).

@tejashapani-1 Can you provide some information on what theme or theme builder you’re using? Also what WP plugins are you using?

Some plugins that do things such as: caching, minify, etc, are no longer needed and the issue could be from some minification plugins. I’ve not experienced the issue you described with this plugin.

@bobm24 can you provide more information on your HostGator server? (e.g. how much memory, Apache/Nginx, is WP-Cron enabled, etc)

Thanks @patrickposner for your response!

@willes do you know what web server your WordPress instance is using? Can you post some of your site environment details? (Web server type, database, etc)

@ibenic This was a specific example to provide context, but what I mean is block level component CSS/JS dependency issues issues.

How elementor works, and most page builders, is every component will load its dependencies when used, e.g. you won’t see the the dependency links for JS/CSS files unless the component is used. In my case I’m using a “navigation” component. I saw errors with other components: image slider, dropdown navs, etc.

This issue though can be replicated with any components. The CSS and JS links for the dependency are in the DOM, so the expectation is Simply Static should be able to pick them up. The not picking them up is why I did the workaround I mentioned here:

A workaround, if any one else encounters this, you can:
– Manually copy/paste the asset URLs from your WordPress site into the correct directories in the compiled static site. As long as you don’t clear the entire static site when deploying, this should only need to be done once.

@ibenic thanks for your response!

To clarify, this happened in all versions of Simply Static (missing files), the number of broken assets increased though to the point where theme functionality is not usable, e.g. things for stuff like nav javascript were not being included, in this version.

• This reply was modified 1 year, 7 months ago by jessejones.

Follow-up:
Downgrading addressed this issue.

The cause seems to be, imho, theme file dependencies for block level elements/components.

Specifically, and not unique to Elementor, if a theme builder contains components/plugins that are used in it from 3rd party libs they won’t always get included. Simply Static seems to have issues finding the asset URL paths, even including them manually in settings does not appear to address this.

A workaround, if any one else encounters this, you can:
– Manually copy/paste the asset URLs from your WordPress site into the correct directories in the compiled static site. As long as you don’t clear the entire static site when deploying, this should only need to be done once.

• This reply was modified 1 year, 7 months ago by jessejones.

Awesome, thanks for the follow ups @patrickposner, @ibenic and finding a fix so quickly!

• This reply was modified 1 year, 7 months ago by jessejones.

Was able to get Simply Static to work by making some webserver changes, here’s what was changed (tldr: webserver Apache => Nginx):

Old site settings:
Webserver: Apache
PHP version: 8.1.9
Database: MySQL 8.0.16
WordPress Version: 6.2

New site settings:
Webserver: Nginx
PHP version: 8.1.9
Database: MySQL 8.0.16
WordPress Version: 6.2

[2023-04-19 07:30:40] Setting up
[2023-04-19 07:30:43] Fetched 409 of 409 pages/files
[2023-04-19 07:31:04] ZIP archive created: Click here to download
[2023-04-19 07:31:04] Wrapping up
[2023-04-19 07:31:04] Done! Finished in 00:00:25

^ it finished in less than < 30 secs with this change. This might not be a viable option for everyone and ideally Simply Static works with any common WordPress environment.