Closed joyously closed 5 years ago
With the Customize Section Button project, we went with not loading scripts/styles at all and just letting the theme/plugin author decide how to best do it.
See: https://github.com/WPTRT/customize-section-button#loading-required-css-and-js
Outside of that, we'd probably need a standalone "path URI" package with a function for getting the proper path URI based on where the package is installed.
This seems like an odd default.
The default is simply because that is the default path when using composer.
With the Customize Section Button project, we went with not loading scripts/styles at all and just letting the theme/plugin author decide how to best do it.
Yeah, I know... I'd simply like to automate things a bit. And though the filter may be a little odd, I'd like to avoid forcing authors to manually enqueue styles & scripts. If we build more packages the list may get a little long.
Can you use FILE and make the JS relative to the PHP file?
I can see this being used in themes, but also plugins, (I'd like to see it in core), so it makes sense to make it work without a filter being needed and without regard of the code using it.
Outside of that, we'd probably need a standalone "path URI" package with a function for getting the proper path URI based on where the package is installed.
I've been meaning to bring this up... I already have a package to handle these: https://github.com/kirki-framework/url-getter I've been using it without any issues in plugins & themes for quite a while. For example in a control-react-color package I recently built it's used like this: https://github.com/kirki-framework/control-react-color/blob/d29b8d0d9b8f07f5601c9c4c1bcc5adcc5fe3d85/src/Control/React_Color.php#L57-L61
The URL package I already have is not suitable for use in a TRT package, but the logic is sound and can be refactored. It would have to be rewritten so as to not be a multiton, there were valid reasons to have it like that for Kirki (it gets the same path multiple times depending on the installed packages and building it as a multiton actually improved performance by a few milliseconds), but not if we want to do something like this for the TRT.
A simple solution to get the URL would be something like this:
$folder_url = str_replace(
wp_normalize_path( untrailingslashit( WP_CONTENT_DIR ) ),
untrailingslashit( content_url() ),
__DIR__
);
^ That should work for both plugins & themes and just replaces the wp-content path with its URL. Of course it's not accurate 100% of the time, if the user has a custom implementation where their code is outside wp-content the above won't work. So we may want to leave the filter just in case they need to change it on their own
custom implementation where their code is outside wp-content the above won't work
Like it being in core? That's the reason I said it should be self-contained, meaning the JS should be relative to the PHP. It could be in the same folder or in a js folder right where the PHP is. I personally think that in order for it to work, you need all the pieces, so they should all be together and the JS loaded by the PHP class. Nothing fancy, just flexible in its simpleness.
Like it being in core?
No, like a developer cloning the repo in the root folder of their site, and then symlinking it or using it in their custom code.
That's the reason I said it should be self-contained, meaning the JS should be relative to the PHP. It could be in the same folder or in a js folder right where the PHP is.
It is in the same folder. However getting the URL from a PATH is not that easy in WP, there's lots of things to consider. The code I posted above is minimal and will take care of 99% of the cases (use in plugins & themes)
https://github.com/WPTRT/control-color-alpha/blob/78ba0de1e0594282dd305dff743166c8452458e1/src/ColorAlpha.php#L40
This seems like an odd default. Can the path be handled better? Can you use
__FILE__
and make the JS relative to the PHP file? I can see this being used in themes, but also plugins, (I'd like to see it in core), so it makes sense to make it work without a filter being needed and without regard of the code using it.