roots / acorn

Laravel components for WordPress plugins and themes
https://roots.io/acorn/
MIT License
824 stars 94 forks source link

packages not discovered due to numerous issues with package manifest search paths #410

Open montchr opened 3 weeks ago

montchr commented 3 weeks ago

Version

5.0.0-beta.0

What did you expect to happen?

What actually happens?

Packages are not automatically discovered because Acorn attempts to find them outside of my project, where WP_CONTENT_DIR is only one level below composer.json:

https://github.com/roots/acorn/blob/b72fd726c02fe5d268eda54e797452bc6db8f09e/src/Roots/Acorn/Application.php#L240

In the current implementation of Application::registerPackageManifest(), $composerPaths assumes a Bedrock-like project structure where the project root is two directory levels higher than WP_CONTENT_DIR.

When the project root (i.e. directory containing the top-level composer.json) is only one level above WP_CONTENT_DIR, the current implementation of Application::registerPackageManifest() will attempt to find packages outside of the project directory…

Steps to reproduce

System info

Guest: DDEV Host: NixOS (nixos-unstable)

Log output

No response

Please confirm this isn't a support request.

Yes

retlehs commented 3 weeks ago

Thanks for the issue. In your steps to reproduce, you're missing running wp acorn acorn:install or manually adding the post-autoload-dump script noted at https://roots.io/acorn/docs/installation/

Use a default WordPress project structure

But WordPress doesn't load your Composer deps, so how are you loading Acorn?

What are the contents of your application-mu-plugin.php file?

Where are you setting ACORN_BASEPATH? What is the actual code you're using?

montchr commented 3 weeks ago

Sorry for the confusing reproduction steps, which I added from memory.

What is the actual code you're using?

I will try to publish a sample repo but currently the project template I'm using is private, so I'll have to do some cleanup first for it to be an actually-usable project for repro. The project uses a Bedrock-like wp-config.php+config/+.env directory setup. The main difference is that the project root is also the web root (with sensitive file access denied via Nginx), and app is wp-content. WordPress core files are scattered everywhere, as prescribed. So, for the most part, I follow Acorn installation instructions for plugin-based install.

Where are you setting ACORN_BASEPATH?

//config/application.php

But WordPress doesn't load your Composer deps, so how are you loading Acorn?

Composer autoloader is loaded in //wp-config.php, identical contents as Bedrock's //web/wp-config.php.

I boot Acorn using roots/bedrock-autoloader to load the mu-plugin from subdirectory. Here is application-mu-plugin.php:

<?php

declare(strict_types=1);

/*
 * Plugin Name:  Wordpress But Lowercase P: Site Plugin
 * Plugin URI:   https://github.com/kleinweb/
 * Description:  It is a website
 * Version:      1.0.0
 * Author:       Klein College of Media and Communication
 * Author URI:   https://github.com/kleinweb
 * License:      GPL-3.0-or-later.
 */

use Kleinweb\Lib\Application;

// Initialize the Acorn application.
add_action('after_setup_theme', static function () {
    Application::configure()
        ->withProviders([
            /*
             * Package Service Providers
             */

            /*
             * Application Service Providers
             */
            App\Core\Providers\AppServiceProvider::class,
            App\Core\Providers\AssetsServiceProvider::class,
        ])
        ->boot();
}, priority: 0);
montchr commented 3 weeks ago

With a composer.json in the ABSPATH directory, replacing dirname(WP_CONTENT_DIR, 2) with ABSPATH allows package auto-discovery.

I overrode Application::registerPackageManifest() in a custom Application class extending Roots\Acorn\Application here: https://github.com/kleinweb/lib/commit/c5c4324ce2df2736ca024112ddf923019d4c5e0d

Edit: That's definitely not acceptable for Bedrock-based setups, however! I don't have a clever solution to supporting both 1-level and 2-level WP_CONTENT_DIR depth without keeping around the bug that could allow access to files outside of the project.