Hi,
thanks for your post, and sorry for the trouble.
Just for clarity: With different environment, do you mean things like a staging domain that is different from the live site’s domain?
Indeed, the full URL is used in this CSS file, see https://github.com/TablePress/TablePress/blob/2.0.4/classes/class-css.php#L334 . This behavior has been introduced 10 years ago. The reason why this is needed still exists, but I’m wondering if using root-relative URLs like
url(/wp-content/plugins/tablepress/css/build/tablepress.woff)
would also work, or if there are scenarios where this could cause problems (considering that other caching plugins might interact with the file, or that the file might be offloaded to a different server/CDN/domain, …). Do you happen to have an opinion on this?
So, in the meantime, my recommendation would be to do exactly that with a filter hook: The plugins_url() function offers the plugins_url filter hook that you could use to remove the domain.
Regards,
Tobias
Hello @tobiasbg
Sorry for this late reply.
Yes, our testing environments are:
So, yes, this is a problem when the CSS is embedded in the sources.
Using a relative path would probably work for us, but I guess there are some configurations which would be a problem.
Just wondering if you could implement a feature where we could regenerate the CSS? A button in the back-office or something like that?
Anyway, great plugin.
Kind regards
Hi,
thanks for the clarification!
Yes, using root-relative URLs could probably work, but I don’t really want to take the risk right now, to be honest. I’ll have to think about this some more, to rule out any negative side-effects.
In the meantime, you could regenerate the CSS on the different sites by making an arbitrary (“dummy”) change in the “Custom CSS” and saving that (and then maybe reverting that change).
Whenever the “Custom CSS” has been modified, the files will be regenerated (with the then-correct domain in those URLs).
Best wishes,
Tobias
