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

Support different plugin/theme paths than default ones #107

Open
strarsis opened this issue Mar 24, 2017 · 9 comments
Open

Support different plugin/theme paths than default ones #107

strarsis opened this issue Mar 24, 2017 · 9 comments

Comments

@strarsis
Copy link

A link to minit combined styles and javascript is added but the original script/style links are not removed.

@kasparsd
Copy link
Owner

I'm not seeing that issue on my personal site, for example. Can you please provide a sample URL?

@strarsis
Copy link
Author

I will try to prepare a minimal reproducible example for this issue.

Where are the enqueued styles/scripts removed in minit? I cannot find a wp_dequeue_script(...) invocation.

@kasparsd kasparsd changed the title script/style links not removed Original script/style links not removed Mar 24, 2017
@kasparsd
Copy link
Owner

kasparsd commented Mar 24, 2017

@strarsis We're removing them here where $this->handler is either wp_scripts() or wp_styles().

@strarsis
Copy link
Author

strarsis commented Mar 24, 2017

@kasparsd:
Edit: process($todo) receives indeed an empty array for $todo, but the line $todo = array_merge( $todo, $this->queue ); fills the empty $todo array with all the CSS files that shouldn't be added.

@strarsis
Copy link
Author

strarsis commented Mar 24, 2017

I found the reason, and the issue is actually not that the original file links aren't removed but those are skipped $src = $this->get_asset_relative_path( $handle );.
For most handles, src is actually empty. The reason for this is probably that WordPress Bedrock is used which has custom paths.
It should still be possible to get the right path with the WordPress core functions nonetheless.

@kasparsd
Copy link
Owner

Thank you @strarsis. That should only happen with "pseudo" packages or external scripts/styles. Does it fail at expanding the relative path in your case? Can you please debug it further?

@strarsis
Copy link
Author

strarsis commented Mar 24, 2017

@kasparsd: Yes, this also fails with "regular" assets.

		// Check if this is a local asset which we can include
		$src_parts = explode( $base_url, $item_url );

The variables are set like this:

$base_url = '//<hostname>/wp';
$item_url = 'http://<hostname>/app/plugins/flowplayer5/frontend/assets/flowplayer-v6/flowplayer.js';

The explode(...) fails, hence $maybe_relative will also contain a full URL and
then file_exists(...) will fail.

@strarsis
Copy link
Author

strarsis commented Mar 24, 2017

@kasparsd: I modified the get_asset_relative_path(...) function in PR #108 .
What is meant with the "trailing part of the local URL"? -
The URL to a plugin assets without the plugin URL prefix (e.g. "/plugins/")?

@strarsis
Copy link
Author

strarsis commented Mar 26, 2017

@kasparsd: An alternative approach would be requesting the resources from itself (the server), localhost with Hostname or even over its public facing IP address. This would guarantee 100% path resolution in all situation and even finding out issues with resources (404, not found).

@strarsis strarsis changed the title Original script/style links not removed Support different plugin/theme paths than default ones Apr 1, 2017
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