Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Recommended way to handle non-php assets / paths? #82

Closed
jhard opened this issue Dec 4, 2023 · 2 comments
Closed

Recommended way to handle non-php assets / paths? #82

jhard opened this issue Dec 4, 2023 · 2 comments

Comments

@jhard
Copy link

jhard commented Dec 4, 2023

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?

@BrianHenryIE
Copy link
Owner

I just use relative filepaths, then have the assets folder included in the Composer autoload files or classmap key so it gets copied over. Example:

$js_path = realpath( __DIR__ . '/../../' ) . '/assets/bh-wp-logger-admin.js';

Although I'd probably do

$js_path = realpath( dirname( __DIR__ , 2 ) . '/assets/bh-wp-logger-admin.js' );

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!

@jhard
Copy link
Author

jhard commented Dec 6, 2023

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!

@jhard jhard closed this as completed Dec 6, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants