Some CSS Variable names getting transformed from camel case to lowercase

[thomasfrobieter]

Our CSS variable names (defined in a CSS file included via < link >) are all written in camel case eg. "--blockWidth". After the static site export some of them become lowercase, so they won't work anymore.

Before:

@media (max-width: 689.98px) {.ct-container, .ct-container-narrow {--containerWidth: 88vw;}}
@media (min-width: 690px) {.ct-container, .ct-container-narrow {--containerWidth: 90vw;}}
.menu {--listIndent: 0;--listItemSpacing: 0;--listStyleType: none;}

After:

@media (max-width: 689.98px) {.ct-container, .ct-container-narrow {--containerwidth: 88vw;}}
@media (min-width: 690px) {.ct-container, .ct-container-narrow {--containerwidth: 90vw;}}
.menu {--listindent: 0;--listitemspacing: 0;--liststyletype: none;}

While, for example:

.ct-container, .ct-container-narrow {width: var(--containerWidth);}

stay camel case.

WP2Static version is: Version 6.6.7 Wordpress version is: 5.4.2

The site is deployed by FTP

[leonstafford]

Hi @thomasfrobieter,

Thanks for reporting! It's fixed within this repository, but not on wordpress.org yet (few more issues to sort).

You can get an installer that will work from here:

https://github.com/WP2Static/static-html-output-plugin/releases/tag/6.6.20

Download link: https://github.com/WP2Static/static-html-output-plugin/files/4789479/static-html-output-plugin-6.6.20.zip

Note, plugin name is changed from WP2Static to Static HTML Output for this installer, so can remove the WP2Static plugin before installing this one.

I'll close off the other reported issue, as similar fixed state within this repository.

Sorry for the extra headaches, I'd love to get the new version out on wp.org ASAP, but as a lot of people auto-update plugins, I want to make sure it's really stable.

Cheers,

Leon

[thomasfrobieter]

Hi Leon,

thank you so much! Works great (:

May i ask two OT questions about the new release?

1. We miss the FTP deployment in the new version, will this feature return in future releases?
2. We've used a path instead of a subdomain as Destination URL ("http://foobar.de/wp2static" vs. "http://wp2static.foobar.de") this doesn't work anymore, all ressources point to "http://foobar.de/wp-content" instead of "http://foobar.de/wp2static/wp-content". Is this a expected bahvoir or should i fill an issue?

[leonstafford]

Hi @thomasfrobieter - thanks for the feedback re FTP. For some things like this, I don't realize they were actually used a lot until I remove it and people let me know :D The reason I trimmed it, was that it had some issues and wasn't very reliable. There's work on an sFTP add-on for the https://github.com/WP2Static/wp2static project, which also allows for more easily creating add-ons by the open source community. This would be the more likely place to go for a seamless FTP integration when it's ready.

Re the subdirectory deployment URL - there's an issue in the other project's repository for the same issue https://github.com/WP2Static/wp2static/issues/573 you can see a bit of my thoughts on it there. Solution for today is to avoid using a subdir like that and if that path is a must for your site, ie deploying a WP blog to example.com/blog/ - do it with some mechanism on the hosting end.

Technically, it should be possible, as it was working in prior versions of the plugin. It's related to the URL rewriting, which is much simpler when we're doing somedomain.com to newdomain.com. There've been a lot of recent fixes to rewriting for issues that really needed to be solved. Part of that involved removing the option for relative URL rewriting, offline zip creation and some of the rewriting rule improvements rely on the URL's host or host:port.

I'd like to be optimistic that we can get it working well for a subdirectory deployment, too, but having dealt with the output source code from various WP sites of late, I'm not so sure. ie, we may have CSS files with a path like myimage.png or ../myimage.png, which in earlier versions, we'd convert those to full URLs like devsite.com/myimage.png before rewriting to the new destination. Now, I'm trying not to touch the CSS files besides rewriting any URLs that actually contain the dev site's URL host within them.

When there's a URL that the plugin can't safely rewrite, it will still be pointing to the same location on the dev and production sites. If we change some but not all URLs to the new productionsite.com/blog/, there's a chance for broken links, be it from HTML, JS or CSS.

So, I suggest to keep both dev and live site without subdirectory and if subdirectory is a must for the live site, then to do it with some rewriting, such as ^blog/* to https://myproxiedstaticsite.com$1

[thomasfrobieter]

Thank you very much for the information!

FTP is no problem at all.. just comfort, looking forward to the sftp plugin :)

Yeah subfolders, are a lot easier to manage in our case, but also not this important to us - a comfort thing.