patrickposner

Hey @chromatix,

thanks for the report!

Your assumption is correct!

The filter is too aggressive and should be limited to XML files. We are working on this and will ship a fix with one of the following updates.

You can disable it all together with the following code snippet:

add_filter( 'ss_excluded_by_default', function ( $excluded ) {
	unset( $excluded['feed'] );
	return $excluded;
} );

Hey @followalter,

I haven’t had enough time to fully dig into this but I assume the problem is caused here: https://github.com/Simply-Static/simply-static/blob/17ded0b32c3bb837d5dc4ef79880b95884a3b488/src/tasks/class-ss-setup-task.php#L181

It’s not as simple as swapping out wp_content_dir with wp_content_url as you can see here: https://github.com/Simply-Static/simply-static/blob/17ded0b32c3bb837d5dc4ef79880b95884a3b488/src/tasks/class-ss-create-zip-archive.php#L102

I wonder if that is caused even earlier – when getting the temporary file path.
Did you adjust the path accordingly in the settings (Simply Static -> Settings -> Debug -> Temporary File Path)?

Hey @markus35425,

thanks for reaching out!

That is indeed a problem that happens now and then and is caused by the package we are using behind the scenes: https://github.com/voku/simple_html_dom

It’s not optimization, but rather a W3C validity check – the crawler essentially attempts to auto-fix invalid HTML (such as empty attributes) without a way to stop it.

However, we are working on a replacement that is based on the new WordPress HTML API.
We even have a fully functional branch in our GitHub repository already: https://github.com/Simply-Static/simply-static/tree/html-api

If you’d like, you can reach out to [email protected], and we’ll work together to resolve the issue. We can send you a fully built release file for testing and adapt the integration as needed.

Hey @kawata12345,

thanks for the report!

We are aware of this.
Sadly, it has nothing to do with our crawling; it is a bug in AIO SEO.

To make things worse, our developer contact from AIO SEO was let go two months ago, and now I don’t have much hope that this will be solved in the future.

We might build an exception for this in the future, but as it is the only SEO plugin producing this issue, it’s not a high priority.

Hey @abitofmind,

good question!

It depends.

With the pro version (and our own Basic Auth implementation), you won’t face any issues, as we implemented all these edge cases to allow seamless usage of Gutenberg on Static WordPress. Our own website is also running on Gutenberg (FSE theme + blocks) and is protected via Basic Auth.

The free version is a bit trickier – it works better now than it did in the past. However, you can still run into issues, especially with third-party plugins (think of custom blocks) adding Rest API endpoints without proper privilege management.

If you want to do it on your own (with Basic Auth), definitely exclude “wp-json” from the protection, and also consider excluding “admin-ajax.php” because of the heartbeat pings.

Hey @stevekris73,

happy to help!

I can see two potential problems here:

The markup:

Simply Static probably does not know yet about the markup structure, and that’s why it’s not fetching the content of the HTML attribute.

We have a filter to do this, but if you can show me an example, we can also add it right away into the plugin:

add_filter('ss_match_tags', function( $tags ) {
$tags['div']  = [ 'href', 'src', 'style' ];
$tags['li']   = [ 'style' ];
$tags['span'] = [ 'style' ];

return $tags;
} );

Timeout during fetching:

Another reason for this could be a timeout while downloading the file via wp_remote_get().

The easiest way to check that would be to use the debugging mode and search inside the log file for the URL of the file: https://docs.simplystatic.com/article/72-how-to-use-the-debugging-mode

You can also adjust the default configuration of the arguments we pass to wp_remote_get to (for example) increase the timeout limit: https://docs.simplystatic.com/article/12-ssremotegetargs

Hope that helps!
Patrick

Hey @ees2025,

thanks for the follow-up!

That’s a bit out of scope regarding our free support (we avoid doing any code-related stuff here).
However, I would probably handle it via JavaScript instead of PHP.

I’m sure there was a valid reason for that back in the day, but you probably get to your desired result quicker by parsing the URL via JS and having the $subnav_url as part of the DOM (as a meta tag, for example) to compare based on the DOM elements.

Hey @golfaccountant,

my bad, that is entirely on us!

It’s because “feed” is part of our automatically excluded URL patterns.

You can either enable “Include Feed URLs?” in Simply Static -> Settings -> General -> Include or use the following code snippet to help with that:

add_filter( 'ss_excluded_by_default', function ( $excluded ) {
	// Remove "feed" from excluded
	if ( isset( $excluded['feed'] ) ) {
		unset( $excluded['feed'] );
	}

	return $excluded;
} );