You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've seen that you're considering deprecating delete_vendor_files -- what's the recommended way to reference library assets for enqueue?
#31 touches on it and that looks fine for file that you only need to read and can reference with relative paths, but it changes the files' location relative to the composer.json and the library would have to be aware.
My use case: I have an internal library that also includes some CSS and JS that it loads itself (it knows the current plugin's main file) using wp_enqueue_style and plugin_dir_url, with vendor/some-vendor/library/assets/some.css.
With delete_vendor_packages set to true they'd be deleted. With delete_vendor_files set to true, they remain in the vendor directory and referencing them works the same way it would if Strauss wasn't involved.
I could let them be moved as well and then try to find the location of the assets, and look for the path I can get from PHP files relative to the plugin file and fall back to vendor if I don't find the assets there but that feels too much like fitting the library to work with the tool that it shouldn't need to be aware of.
What's the intended/clean way to handle this kind of situation?
The text was updated successfully, but these errors were encountered:
I think you're overthinking it by your library's code seeking further than the library's directory itself.
Are you using symlinks?
Longer term, you could leave them in their original location, include them with Webpack and then omit the original directory from your plugin archive. But I don't know how to do that myself yet!
Hey, thanks for your reply (and all the work on Strauss!)
Your example will work, I believe. I've never considered feeding anything but the original, real main plugin file (i.e. plugin-name/plugin-name.php) into plugin_dir_url, I've always just assumed that's what has to be done (and then concatenate the path + file I actually want to get the URL for). But this should work nicely, the path is within the plugin and Wordpress can figure it out.
The documentation doesn't even say I can't just throw any file in there, so I have no idea where I got it from. Probably done it this way since the beginning of time and never questioned it. Another thank you for broadening my horizon!
I've seen that you're considering deprecating delete_vendor_files -- what's the recommended way to reference library assets for enqueue?
#31 touches on it and that looks fine for file that you only need to read and can reference with relative paths, but it changes the files' location relative to the composer.json and the library would have to be aware.
My use case: I have an internal library that also includes some CSS and JS that it loads itself (it knows the current plugin's main file) using
wp_enqueue_style
andplugin_dir_url
, withvendor/some-vendor/library/assets/some.css
.With
delete_vendor_packages
set totrue
they'd be deleted. Withdelete_vendor_files
set to true, they remain in the vendor directory and referencing them works the same way it would if Strauss wasn't involved.I could let them be moved as well and then try to find the location of the assets, and look for the path I can get from PHP files relative to the plugin file and fall back to vendor if I don't find the assets there but that feels too much like fitting the library to work with the tool that it shouldn't need to be aware of.
What's the intended/clean way to handle this kind of situation?
The text was updated successfully, but these errors were encountered: