feat: add first-class theme support for slic here and slic run

[claudiosanches]

Summary

• Root cause: running slic here from a themes directory set SLIC_PLUGINS_DIR to the themes dir, causing plugins (WooCommerce, etc.) to be installed/cloned inside wp-content/themes/ and mounted as wp-content/plugins/ in the container. slic run also broke because host path resolution always used SLIC_PLUGINS_DIR even for theme targets.
• Fix: introduce a themes-directory mode (slic_here_is_themes()) that is detected when SLIC_HERE_DIR == SLIC_THEMES_DIR, and replace all direct slic_plugins_dir(slic_target()) calls in command files with get_project_local_path(), which already handled the 'theme' project type correctly in project.php.
• Docs: document the themes directory as a first-class slic here option in the README, including the correct WPLoader suite config pattern for activating a theme under test.

Changes

src/slic.php

• Add slic_here_is_themes() helper — returns true when SLIC_HERE_DIR equals SLIC_THEMES_DIR
• Update get_valid_targets() to include theme targets when in themes-directory mode (previously they were only included in site mode)
• Fix build_command_pool() and maybe_build_install_command_pool() to use get_project_local_path() for build-file detection instead of slic_plugins_dir(target)

src/commands/run.php

• Replace slic_plugins_dir(slic_target()) with get_project_local_path() so the Codeception config lookup resolves correctly for theme targets (SLIC_THEMES_DIR/<theme> rather than SLIC_PLUGINS_DIR/<theme>)

src/commands/using.php

• Same path resolution fix for the displayed target path

README.md

• Add "Themes Directory" as option 2 (between Plugins Directory and WordPress Directory), documenting the correct slic here workflow for theme development and the WPLoader theme: config key pattern

Backwards compatibility

Fully backwards-compatible for plugins. get_project_local_path() returns SLIC_PLUGINS_DIR/<target> when get_project_type() is 'plugin' — identical to the previous slic_plugins_dir(target) behaviour. The slic_here_is_themes() check in get_valid_targets() is additive and only fires when pointed at a themes directory.

Test plan

• slic here from a themes directory: slic info shows SLIC_PLUGINS_DIR pointing at the plugins directory and SLIC_THEMES_DIR pointing at the themes directory
• slic use <theme> resolves and slic using displays the correct themes-directory path
• slic run wpunit executes from the correct wp-content/themes/<theme> workdir in the container
• slic composer install detects composer.json correctly for a theme target
• Existing plugin workflows (slic here from a plugins directory or WordPress root) are unaffected

🤖 Generated with Claude Code

[bordoni]

Lets wait until we get a couple more approvals.

Create a PR for testing this.

[glaubersilva]

I used this branch to create some tests for the portal theme, and it seems to be working great! Here is the commit for reference: https://github.com/stellarwp/commerce-portal-theme/pull/86/changes/4e965e65b9baffc4869132a16fb4b773968f890d

[glaubersilva]

@claudiosanches Yesterday I ran the tests on my macOS machine using this branch and it worked fine, but today when running on my WSL/Ubuntu setup I hit a few problems. I documented everything here: https://github.com/stellarwp/commerce-portal-planning/blob/main/epics/10-checkout/backups-quota-implementation-plan.md#test-10--automated-wpunit-tests

One thing that still required a manual step after setup was editing SLIC_HERE_DIR in .env.slic.run to match SLIC_THEMES_DIR. Without that, get_project_type() returns 'site' (since SLIC_HERE_DIR equals neither SLIC_PLUGINS_DIR nor SLIC_THEMES_DIR), and slic runs commands from /var/www/html instead of the theme subdirectory — so vendor/bin/codecept isn't found.

The root cause is in here.php: when slic here is run from a themes directory (no wp-config.php found), the else branch sets SLIC_PLUGINS_DIR = $here_dir and leaves SLIC_THEMES_DIR pointing at the slic default — so SLIC_HERE_DIR never equals SLIC_THEMES_DIR.

A small addition to the else branch in here.php would eliminate the manual step: detect whether a sibling plugins/ directory exists and, if so, treat the current directory as the themes root automatically:

} else {
    $sibling_plugins_dir = realpath( dirname( $here_dir ) . '/plugins' );
    if ( $sibling_plugins_dir && is_dir( $sibling_plugins_dir ) ) {
        // Themes-directory mode: set SLIC_THEMES_DIR = current dir and
        // SLIC_PLUGINS_DIR = sibling plugins/ so SLIC_HERE_DIR == SLIC_THEMES_DIR
        // and get_project_type() correctly returns 'theme'.
        $env_values['SLIC_HERE_DIR']    = $here_dir;
        $env_values['SLIC_WP_DIR']      = $wp_dir;
        $env_values['SLIC_PLUGINS_DIR'] = $sibling_plugins_dir;
        $env_values['SLIC_THEMES_DIR']  = $here_dir;
    } else {
        $env_values['SLIC_HERE_DIR']    = $here_dir;
        $env_values['SLIC_WP_DIR']      = $wp_dir;
        $env_values['SLIC_PLUGINS_DIR'] = $here_dir;
        $env_values['SLIC_THEMES_DIR']  = $themes_dir;
    }
}

This covers both standard WordPress (wp-content/themes/ beside wp-content/plugins/) and Bedrock-style layouts (content/themes/ beside content/plugins/). Existing plugin workflows are unaffected. With this change, setup from a themes directory becomes:

cd content/themes
slic here   # auto-detects themes mode — no manual edit needed
slic use commerce-portal-theme
slic composer install
slic run wpunit