9

After upgrading my Homestead and installing my packages I came across a strange bug. On calling php artisan the following was given as output:

In LoadConfiguration.php line 68:

Unable to load the "app" configuration file.

A few people suggest that this is the cause of Windows (10) capitalising the filenames. However this can't be seen in my folders and also does not apply in my Ubuntu (18.04) environment.

Looking in the source code of LoadConfiguration.php we can see that it is using the Finder class from the symfony/finder component.

foreach (Finder::create()->files()->name('*.php')->in($configPath) as $file) {
    $directory = $this->getNestedDirectory($file, $configPath);

    $files[$directory.basename($file->getRealPath(), '.php')] = $file->getRealPath();
}

The problem is that the finder does return an iterator that somehow cannot find my config files. A simple scandir($configPath) returns all files:

.
..
app.php
and all other files

Wrapping the call in iterator_to_array() returns an empty array [].

The following object is returned by adding ..->in($configPath)->getIterator():

Symfony\Component\Finder\Iterator\PathFilterIterator {#47
  #matchRegexps: []
  #noMatchRegexps: array:2 [
    0 => "#(^|/)\..+(/|$)#"
    1 => "#(^|/)\..+(/|$)#"
  ]
  innerIterator: Symfony\Component\Finder\Iterator\FilenameFilterIterator {#43
    #matchRegexps: array:1 [
      0 => "#^(?=[^\.])[^/]*\.php$#"
    ]
    #noMatchRegexps: []
    innerIterator: Symfony\Component\Finder\Iterator\FileTypeFilterIterator {#39
      -mode: 1
      innerIterator: RecursiveIteratorIterator {#42
        innerIterator: Symfony\Component\Finder\Iterator\ExcludeDirectoryFilterIterator {#46
          -iterator: Symfony\Component\Finder\Iterator\RecursiveDirectoryIterator {#48
            -ignoreUnreadableDirs: false
            -rewindable: null
            -rootPath: "/home/vagrant/somepath/api/config"
            -subPath: null
            -directorySeparator: "/"
            path: "/home/vagrant/somepath/api/config"
            filename: "app.php"
            basename: "app.php"
            pathname: "/home/vagrant/somepath/api/config/app.php"
            extension: "php"
            realPath: "./config/app.php"
            aTime: 2019-07-02 09:28:30
            mTime: 2019-01-31 17:43:49
            cTime: 2019-07-02 16:32:52
            inode: 429
            size: 9727
            perms: 0100777
            owner: 1000
            group: 1000
            type: "file"
            writable: true
            readable: true
            executable: true
            file: true
            dir: false
            link: false
          }
          -isRecursive: true
          -excludedDirs: array:9 [
            ".svn" => true
            "_svn" => true
            "CVS" => true
            "_darcs" => true
            ".arch-params" => true
            ".monotone" => true
            ".bzr" => true
            ".git" => true
            ".hg" => true
          ]
          -excludedPattern: null
          innerIterator: Symfony\Component\Finder\Iterator\RecursiveDirectoryIterator {#48}
        }
      }
    }
  }
}

Assume I do not know anything about these type of iterators. Two things stand out to me:

  • A lot of innerIterator's are present.
  • One iterator can find something #48, we can see our config/app.php, but is inside a ExcludeDirectoryFilterIterator.

Has anybody had this problem before or know how to lead me in the right direction?

The following versions were used:

OS: Windows 10/Ubuntu 18.04 LTS
Homestead: 9.0.1
laravel/framework: 5.8.*/5.7.*
 \ symfony/finder: ^4.2/^4.1,

EDIT

Downgraded my Homestead to v8.0.1 and everything works. However still no explanation about why this happened on v9.0.1.

6
  • Have you upgraded Laravel by any chance? Commented Jul 2, 2019 at 18:37
  • Yeah I tested out both 5.7 and 5.8 that come with 4.1 and 4.2 of symfony/finder. Commented Jul 2, 2019 at 21:45
  • I got the same issue 2 days ago when I updated my Homestead vagrant box to v8.0.0 and updated my Homestead source code to v9.0.1 and I've been struggling ever since. This is on Windows 10 / Ubuntu 18.04.2 LTS / Laravel 5.6.26 / Finder 4.3.2. @ThomasVanderVeen what version is your Homestead box (vagrant box list)? Also, did you downgrade your Homestead source code by running git fetch --all then git checkout tags/v8.0.1 -b release? Commented Jul 5, 2019 at 8:42
  • 1
    @w5m Currently running box version 7.0.1 with virtual box. I indeed ran git checkout v8.0.1 Commented Jul 5, 2019 at 19:59
  • Maybe it's related to case-sensitive. Please check the case of files as well. Commented Jul 6, 2019 at 6:46

2 Answers 2

1
+50

Try updating VirtualBox to v6. See this GitHub issue for more help.

Sign up to request clarification or add additional context in comments.

1 Comment

Many thanks for posting the link @ncla - you're a life-saver. I uninstalled Vagrant & restarted, uninstalled VirtualBox 5.2 & restarted, installed VirtualBox 6.0.8 & restarted, installed Vagrant 2.2.5 & restarted, had to fiddle with the VirtualBox network adapters (following item 2 of this comment: virtualbox.org/ticket/14832#comment:14) and then all was well when using Homestead v9.0.0 and Settler v8.0.0.
0

I don't have an answer for why this happened, but I did code up an alternative to using Finder in the LoadConfiguration::getConfigurationFiles function (within \vendor\laravel\framework\src\Illuminate\Foundation\Bootstrap\LoadConfiguration.php) which allows me to run php artisan commands without any issues...

protected function getConfigurationFiles(Application $app)
{
    $files = [];

    $configPath = realpath($app->configPath());

    $file = new \DirectoryIterator($configPath);
    while($file->valid()) {
        if(!$file->isDot() && ($file->getExtension() == 'php')) {
            $directory = $this->getNestedDirectory($file, $configPath);
            $files[$directory.basename($file->getRealPath(), '.php')] = $file->getRealPath();
        }
        $file->next();
    }

    ksort($files, SORT_NATURAL);

    return $files;
}

Hope that helps someone.

2 Comments

Thanks for the answer. Ofc you know it would not be nice to have to change source code.
Thomas, the code modification in my answer is not needed thankfully - see my comment on the answer from @ncla. Everything is happy once on VirtualBox 6.0.8.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.