Symbolic link causes invalid plugin/theme slug specified error.

[stefthoen]

I'm getting these errors when I'm trying to scaffold tests with: wp scaffold plugin-tests name-of-plugin or wp scaffold theme-tests name-of-theme. Strangely enough it doesn't happen with all plugins/themes.

This is the output I get when I run wp plugin list:

+----------------+----------+-----------+---------+
| name           | status   | update    | version |
+----------------+----------+-----------+---------+
| akismet        | inactive | available | 3.2     |
| hello          | inactive | none      | 1.6     |
| new-plugin     | inactive | none      | 0.1.0   |
| timber-library | active   | none      | 1.2.4   |
| twitterfeed    | inactive | none      | 0.5     |
+----------------+----------+-----------+---------+

When I try to scaffold tests for akismet it works. When I do the same for hello by running wp scaffold plugin-tests hello it fails: Error: Invalid plugin slug specified. In the list above hello and twitterfeed fail, the other three work.

wp scaffold theme-tests name-of-theme also fails with Error: Invalid theme slug specified, but it's more consistent because I can't seem to get it to work for any of the themes I have installed.

What is your system?

lsb_release -a

No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 16.04.1 LTS
Release:        16.04
Codename:       xenial

uname -a

Linux russell 4.4.0-78-generic #99-Ubuntu SMP Thu Apr 27 15:29:09 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

Which version of PHP are you using?

which -a php

/usr/bin/php

php -v

PHP 7.0.15-0ubuntu0.16.04.4 (cli) ( NTS )
Copyright (c) 1997-2017 The PHP Group
Zend Engine v3.0.0, Copyright (c) 1998-2017 Zend Technologies
    with Zend OPcache v7.0.15-0ubuntu0.16.04.4, Copyright (c) 1999-2017, by Zend Technologies

Which version of WordPress are you using?

$wp_version = '4.7.5';

Can you share the results of which wp ?

which -a wp

/usr/local/bin/wp

stat $(which wp)

  File: '/usr/local/bin/wp'
  Size: 6804077         Blocks: 13296      IO Block: 4096   regular file
Device: 814h/2068d      Inode: 6035154     Links: 1
Access: (0755/-rwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2017-06-06 19:24:44.356297046 +0200
Modify: 2017-06-06 19:24:23.548641754 +0200
Change: 2017-06-06 19:24:41.528343781 +0200
 Birth: -

Are you running any packages? If one is causing a problem, you can use --skip-packages to skip loading them

aaemnnosttv/wp-cli-dotenv-command 

[gitlost]

It won't work for hello.php because it requires plugins to be in their own directory (the error message should be improved though) (edit: although you can specify --dir=<dirname> and it should work). Edit2: Is twitterfeed in its own directory? I see it's your own plugin https://github.com/stefthoen/twitterfeed - I just installed it (0.5) and ran wp scaffold plugin-tests twitterfeed and it worked.

Re themes does it not work for twentysixteen and/or twentyseventeen?

[stefthoen]

Hi @gitlost, thank you for going out of your way and actually install a copy of my plugin. I really appreciate it. You are correct in that those two themes don't work, but I think I figured out what the problem is.

I was using a symbolic link for my themes folder and my twitterfeed plugin. If I don't use symbolic links everything works fine. The thing that threw me off was that that the themes and plugins get picked up by wp theme list and wp plugin list and that hello.php fails because of the lack of its own directory, as you said. Is there any reason why scaffold shouldn't work with symbolic links?

[gitlost]

Oh that's interesting - I see it's failing in Scaffold_Command::check_target_directory after doing a real_path() Scaffold_Command.php#L792 which resolves symbolic links but will then fail the comparison to WP_PLUGIN_DIR.

I think that's a bug! I don't think it should do that check if it's a symbolic link (ie treat it similar to the way it treats --dir=<dirname>).

[gitlost]

I think looking at the history of this that realpath() is the wrong thing to use here - only want to make path canonical ie resolve dot and double dot stuff, not interested in its existence (hence the check before assigning at Scaffold_Command.php#L792) or whether symbolic link or not.

Symfony has a nice and simple canonicalize path function Symfony\Component\DomCrawler\AbstractUriElement::canonicalizePath which could be used instead.

I'll open a PR to add it to WP_CLI\Utils (as it should be generally useful) and then do a PR here using it (see issue_22/src/Scaffold_Command.php#L796).