lzb/plugin_path
Points Lazy Blocks at a different copy of its own files, which is what a symlinked checkout or a plugin bundled outside wp-content/plugins needs.
The default is plugin_dir_path() of the core plugin file, ending in a slash. Four things read it. The require_once calls that load every class, the .asset.php build manifests that supply script dependencies and versions, the languages folder handed to wp_set_script_translations(), and the templates/template-not-found.php fallback rendered when a theme template is missing. A wrong string here is a fatal error on the require_once, not a missing asset.
Those require_once calls run while the plugin file is still loading, because lazyblocks() is called at the bottom of core-plugin/lazy-blocks.php. A filter added from a theme's functions.php, or from a plugin that loads later in the alphabet, is registered too late to affect them. Only an mu-plugin runs early enough. Added later, the filter still reaches the asset manifests, the translations folder and the template fallback.
Attributes
| Name | Type | Description |
|---|---|---|
$plugin_path | String | plugin folder path, with a trailing slash |
Usage
function my_lzb_plugin_path( $plugin_path ) {
// The plugin directory is a symlink, so resolve it to the real path
// before anything opens a file relative to it.
$real = realpath( $plugin_path );
return $real ? trailingslashit( $real ) : $plugin_path;
}
add_filter( 'lzb/plugin_path', 'my_lzb_plugin_path' );The path has to exist and end in a directory separator. realpath() strips the trailing slash and returns false for a path that is not there, so guard both, as above. Returning a URL instead of a filesystem path makes every require_once fail.
The Pro plugin resolves its own directory through lzb_pro/plugin_path, so a bundled install has to filter both.