Scott at Code of Conduct

Hi timoverhoofstad,

That’s really perplexing. How were you setting up the Require local?

Did it look like this?

<RequireAny>
Require local
Require ip 188.201.89.66 91.220.21.0/24 217.123.145.109 91.225.166.33
</RequireAny>

Note that if you used RequireAll instead of RequireAny, it many have ignored the Require local portion.

• This reply was modified 9 years, 7 months ago by Scott at Code of Conduct.

Thanks Pierre, that helps. Would you be able to send me the custom function you’re using to transform the email addresses?

Best,
Scott

Sounds good. Thanks for the update, Pierre!

Hi Pierre,

I’m having a hard time recreating the issue you’re running into. I’m using the WordPress Twenty Fifteen theme and every page where I try to add a mailto:myemail@example.com the email comes across exactly as that. I’m not seeing the behavior you describe in posts or comments on either the WordPress site or when it gets exported to a static site.

Is there a plugin that is modifying the email addresses, or a specific theme?

Best,
Scott

Hi Neoras,

Sorry it took so long to get to get back to you on this. I took a look into this issue and I couldn’t recreate it. I created a WordPress page containing an image with the path you provided:
<img src="/wp-content/uploads/2016/01/Filtergrößen.jpg">

I was able to view the page/image on WordPress (so far, so good). From there I generated a static site, and I was still able to view the page/image. Simply Static had maintained the filename in the static files:
<img src="http://www.static-site.dev/wp-content/uploads/2016/01/Filtergrößen.jpg">

It’s possible that I fixed something in the last 8 months that resolved this issue for you. But, it’s also possible there’s some different in the OS you’re running WordPress on, or the version of WordPress / PHP, or something else. I’d love to learn more if you happen to see this.

Scott

• This reply was modified 9 years, 7 months ago by Scott at Code of Conduct.

Hi Pierre,

Could you try this one more time with v1.7.0 of Simply Static? I just tried it now with the following iframe tag:
<iframe src="/datas/form.php" width="100%" height="580" frameborder="0" scrolling="no" style="border:0;"></iframe>
(copy and pasted from above)

and I got this result:
<iframe src="http://www.static-site.dev/datas/form.php" width="100%" height="580" frameborder="0" scrolling="no" style="border:0;"></iframe>
(which seems to work fine)

That’s the first I’ve seen where Simply Static is horribly mangling the HTML like that, but let me know if it’s still an issue.

Thanks,
Scott

Story time.

WordPress has a feature whereby it automatically redirects URLs without a file extension and without a trailing slash to a URL with a trailing slash.

For example, WordPress would redirect http://www.example.org/blog/page/2 (no trailing slash) to http://www.example.org/blog/page/2/ (trailing slash).

Simply Static normally picks up on redirects and creates a redirect html page. However, in the case of WordPress’s no-trailing-slash to trailing-slash redirect, Simply Static makes an exception, since those URLs are effectively equivalent. If the page that WordPress is redirecting to is the same except for a trailing slash, then Simply Static ignores the redirect.

In the case of aviboy2006’s site the redirect is coming across as just a path — /blog/page/2/. Simply Static is trying to compare that to the full URL of the page — http://www.example.org/blog/page/2 — and is determining that those aren’t equivalent. Simply Static should convert the redirect URL to an absolute URL before doing the comparison.

That’s the bug. You could say that the theme should be fixed so that the URLs have trailing slashes, but I prefer to think that Simply Static should be intelligent enough to accept and understand WordPress’ quirks and work around them.

Thanks for commenting Pierre (as always)! 🙂

• This reply was modified 9 years, 7 months ago by Scott at Code of Conduct.
• This reply was modified 9 years, 7 months ago by Scott at Code of Conduct.