WPTT / control-color-alpha

A color control for the WordPress Customizer with support for RGBA colors (additional alpha channel).
GNU General Public License v2.0
38 stars 1 forks source link

enqueue path should be self-contained #2

Closed joyously closed 5 years ago

joyously commented 5 years ago

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.

justintadlock commented 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.

aristath commented 5 years ago

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.

aristath commented 5 years ago

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

joyously commented 5 years ago

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.

aristath commented 5 years ago

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)

aristath commented 5 years ago

The URL now gets calculated using code I posted above. The filter is still available if someone wants to use it, but won't be needed.