Open coleh33 opened 7 years ago
I should have mentioned that I am using it by including the kirki library in a parent theme. I have not tested symlinking with plugin version.
I did however temporarily fix it by just setting the URL path by changing the function below.
public function set_url() { Kirki::$url = get_template_directory_uri() . '/libraries/kirki'; }
@coleh33 Can you please try pulling the latest dev version from this repository and test if this still happens if you remove your custom set_url function?
I tried and it is still resolving to a full server path.
This one is a bit weird... The main issue is that I can't replicate the issue so far so I'm sorry but I'll have to ask you to check this again... I just pushed another commit that could possibly fix this. Can you please pull the latest commits on the develop branch and see if it works for you now?
Closing for now since there has been no update in more than a month. If the issue still occurs with the latest develop version feel free to reopen this and post an update on your current status. 👍
Sorry for not responding to this. I updated the KIRKI library to the latest development version and it still gives a ton of 404 errors for assets on symlinked directories. Not sure why but it's still being an issue that I have to resolve with what I posted above.
I'm using a theme that uses this plugin and ran into the same issue. My setup is that I have hte wp-content folder symlinked to a different mount. I had to apply the fix above to get it to work otherwise it injected the absolute path to the file that's symlinked everywhere (it showed up on the browser console as part of the path giving an error as the file wouldn't be at that location).
I'm hitting this now and took a while to track down. I have Kirki in my plugin (autoloaded via Composer) and my plugin is symlinked into multiple local WP installs. When move the real plugin into WP it works fine, but anytime it's symlinked I get errors.
FWIW, the files are not 404'ing though:
I just get broken fields. Still trying to figure out what is actually breaking.
As the OP mentioned, my issue seems to be in set_url as well.
When symlinked (Wrong):
echo set_url_scheme( Kirki::$url ) . '<br />';
/Users/JiveDig/Plugins/mai-styles/vendor/aristath/kirki
When not symlinked (Right):
echo set_url_scheme( Kirki::$url ) . '<br />';
https://sandbox.test/wp-content/plugins/mai-styles/vendor/aristath/kirki
Sorry for all the posts.
I have a working solution. I don't love having this code, but I do love having one local repo of all my plugins and symlinking them to all my local installs for dev/testing.
This works:
$url = Kirki::$url;
if ( false !== strpos ( $url, '/Users/JiveDig/Plugins/' ) ) {
add_filter( 'kirki_config', function( $config ) use ( $url ) {
$config['url_path'] = str_replace( '/Users/JiveDig/Plugins/mai-styles/', plugin_dir_url( __FILE__ ), $url );
return $config;
});
}
It appears that the library has issues when symlinking. I have alot of WordPress sites setup on a server that all share the same theme and plugins so I tend to use symlinks, however it appears to be breaking asset paths for KIRKI. I'm wondering if how the scripts are being enqueued are not following the Wordpress suggested functions? Because of this it is trying to setup the path to the assets to something similar below.
http://site.com/wp-content/plugins/var/www/deploys/themes/theme-name/2.7-beta3/theme-name/libraries/kirki/modules/field-dependencies/field-dependencies.js?ver=4.7.3
Is there a way to correct this so that it doesn't resolve to the full server path and just uses the correct path to the plugins folder which then will honor a symlink?