Statamic is not being detected correctly

[SRWieZ]

Is there an existing issue for this?

• [X] I have searched the existing issues and discussions

Is this feature request related to a problem?

Nope !

Describe the solution you'd like to see

Hi! Not important, but it will be nice to see which valet driver is used in this view:

Thanks for your app, hope you the best!

Additional information or context

No response

[nicoverbruggen]

Unfortunately valet which is a slow operation, which is why this doesn't happen this way right now. Originally this is how earlier versions of PHP Monitor worked, but in order to make the app faster I decided to do away with running valet which for every domain, since it became a performance issue when a certain amount of domains were registered with Valet. If you have like 50 sites... this takes forever to run for all sites in the list!

The only solution for this problem is to run the command asynchronously (and in parallel) and I'd rather avoid having to do that because there's also an energy impact (i.e. CPU spike) if I try to run that command for too many sites at the same time.

Instead, I came up with a workaround: I maintain a list of dependencies that will map your project from Composer to a predefined value in PHP Monitor: https://github.com/nicoverbruggen/phpmon/blob/d5888c1c7aea01db1c6452ad2c971101515c47f5/phpmon/Domain/Integrations/Composer/PhpFrameworks.swift#L36

If Statamic isn't being detected correctly then I may need to update this code. What does your project's Composer require section look like? I'd be happy to update this to correctly reflect the current Valet drivers.

[SRWieZ]

Thanks for the explanation, totally make sense ! So I suppose it's now a bug report then 😄

I read your code but I'm barely a Swift developer, just started learning it. If I had to guess, I think the problem is that Statamic is a package of Laravel and that it should take precedence over Laravel when searching in the dependencies. It wasn't always the case as you can see here in the documentation

Statamic v3 is built as a Laravel package instead of a "siloed" application like v2.

Here is the require part of my composer.json, containing both Laravel and Statamic:

    "require": {
        "php": "^8.1",
        "guzzlehttp/guzzle": "^7.2",
        "jacksleight/statamic-lazy-logo": "^1.1",
        "laravel/framework": "^10.8",
        "laravel/sanctum": "^3.2",
        "laravel/tinker": "^2.8",
        "league/flysystem-aws-s3-v3": "^3.0",
        "mitydigital/sitemapamic": "^2.3",
        "ohdearapp/ohdear-php-sdk": "^3.6",
        "spatie/cpu-load-health-check": "*",
        "spatie/laravel-health": "^1.23",
        "spatie/laravel-schedule-monitor": "^3.4",
        "spatie/statamic-responsive-images": "^4.1",
        "statamic/cms": "^4.0",
        "symfony/http-client": "^6.3",
        "symfony/mailgun-mailer": "^6.3",
        "torchlight/torchlight-commonmark": "^0.5.5"
    },

[nicoverbruggen]

Strange, if statamic/cms is included then PHP Monitor should resolve this correctly. I can't reproduce this with a brand new Statamic 4.x project (followed these instructions).

When the actual check occurs, the dependency order is already inverted so that if statamic/cms is found, it takes precedence over laravel/framework.

If you click on the "PHP 8.2" button (in the list, next to the green checkmark), what does it say? If PHP Monitor was able to read the Composer file, it should say:

[SRWieZ]

I remember following these same instructions, so weird.

In case it helps, I'm using version 6.1 (1306) of PHP Monitor installed with brew. I'm available for any other tests of information about my machine.

[nicoverbruggen]

@SRWieZ This should now be fixed in the next update.

Please try the following DEV build and let me know if it resolves the problem: phpmon-dev-62.zip

[SRWieZ]

All good ! It works 🙂