It's perfectly possible to run Laravel Valet (standalone) and Laravel
Herd side-by-side or mix usage, but it's not recommended and/or
supported (especially since Herd recommends migrating away from regular
Valet and may terminate Valet's services).
To avoid issues, PHP Monitor won't work if Herd is currently running.
It's totally fine to relaunch Herd after PHP Monitor's done starting
up, since the check only happens at launch.
Also, PHP Monitor warns about the PATH changes in `~/.zshrc` after
installing Laravel Herd, because that may impact the usage of
PHP aliases/global PHP version in terminal provided by PHP Monitor.
Dictionary key order in Swift isn't a thing, so the process is
now a two-pronged approach: 1) check for specific apps, 2) check for
specific broad frameworks after no other matches were made.
Previously, detection would only work correctly some of the time.
Also cleaned up the `getNotableDependencies()` method.
- Adds a fallback for missing keys
- Make type column resizable on domains
- Localized "Open with" text in context menu
- Updated some Dutch translations
- Fixed issue with Version Manager
- Separate behaviour for previews for Version Manager
- Remove verbose logging when previews are in use
(Note: The latter change may break various other previews. Will need to
investigate this particular issue.)
It was necessary to do some summer cleaning. Here's what's changed:
* First, I'm taking a new modular approach to Swift-based components
that are part of PHP Monitor.
* I've fixed the naming of various parts of the app. I plan on doing
an even deeper check in the future. The following are affected:
- "PHP Formulae Status" is now known as "PHP Version Manager".
- "Warnings List" is now known as "PHP Doctor".
- The associated window controllers have also been updated.
(I've also added a new module: "PHP Config Editor". We'll see what that
brings in the future... but the main purpose will be to edit key PHP
configuration values without needing to go to the .ini files.)
Whenever PHP Guard is used to reset the PHP version when a different PHP
version is installed using the PHP Version Manager, it would previously
kick its version switching process off asynchronously as a separate task
which meant that the app would go into "ready" state too soon. Now this
is considered a blocking task that the app will wait for (async) before
turning the app back into its "ready" state again.
For this to work, Homebrew cannot be installed in /usr/local, which
means that the /usr/local/Cellar folder will be missing and the folder
/usr/local/homebrew will exist.
- A warning has been added if you are not running Homebrew 4.0, since
running older (or newer) versions of Homebrew are not officially
supported. This check is only displayed once per cold app boot.
- The PHP Version Manager now shows the full version number for
up-to-date PHP installations (mostly important for patch version).
- You must now confirm the deletion of an installed version of PHP
before PHP Monitor will uninstall that version.
- It is no longer possible to press the refresh button if the app
is already busy checking for updated PHP versions
This fixes#247, which can be caused when certain folders are not
accessible for some reason. This can occur due to network reasons,
but also because the linked folder in question is iCloud Drive.
- This fixes an issue with PHP Doctor's "Scan Again" button not working.
- This also adds a new check which verifies if "php.ini", "php-fpm.conf"
and "php-fpm.d/valet-fpm.conf" exist (all required files).
- This fixes an issue with PHP Doctor's "Scan Again" button not working.
- This also adds a new check which verifies if "php.ini", "php-fpm.conf"
and "php-fpm.d/valet-fpm.conf" exist (all required files).
If you want to see the source code to the updater, you can find it here:
https://github.com/nicoverbruggen/phpmon-updater
Starting with version 6.0, the code of the updater will be included
in this repository.
After the last merge, there was one file I accidentally included that
doesn't need to be here: the legacy ServicesManager class! In order to
ensure that 5.7, 6.0 and `main` branches are somewhat in order and
easy to merge, I have now removed this file.
This merge brings all of the changes from 5.7 into the 6.0 branch,
while avoiding the need for cherry picking now that the conflicts
have been resolved.
You can start extra verbose logging by running: `touch ~/.config/phpmon/verbose`
Once this file exists, you can find the latest log in: `~/.config/phpmon/last_session.log`.
You can start extra verbose logging by running: `touch ~/.config/phpmon/verbose`
Once this file exists, you can find the latest log in: `~/.config/phpmon/last_session.log`.
This commit ensures that PHP Monitor knows about which versions of
PHP are supported by the upcoming Valet 4.0: PHP 7.1 and higher.
Ensures compatibility with https://github.com/laravel/valet/pull/1318
This commit ensures that PHP Monitor knows about which versions of
PHP are supported by the upcoming Valet 4.0: PHP 7.1 and higher.
Ensures compatibility with https://github.com/laravel/valet/pull/1318
- Fixed `brewPhpAlias` (must be configurable later)
- Added TODOs for where the filesystem abstraction is required
- Set `Homebrew.fake` early on when applying testable configuration
- Evaluate `FakeValetSite` compatibility again
- Never display sponsor alert when running tests
- Upgrade TestableConfiguration.working to use PHP 8.2
A site can be either insecure or unsecured. Insecure has a rather
negative connotation and is also a human trait. Unsecured is a better
term in this particular case.
- Fixes issue with `scanApps` being non-optional in custom configuration
- Fixes issue with position of separator if Xdebug is not detected
- Ensure that `isRunningSwiftUIPreview` modifier always return false for debug builds
In previous builds, PHP Monitor would use interactive mode when opening
a /bin/zsh shell, in order to be able to load the full PATH.
This is a problem because when launching PHP Monitor via the command
line or when you have some interactivity in an actual interactive
shell, it is possible to get stuck waiting for a particular input
which will effectively 'freeze' PHP Monitor's shell.
There are two options to fix this:
1) work with a timeout, which may or may not return a PATH
2) use a non-interactive shell and source .zshrc
I chose option 2, which is the more robust choice. If no .zshrc file
exists, it is also not sourced to avoid warnings or errors from ending
up in the PATH.
I am entirely unsure why one would need these, but I figured I'd get
these in the app before I start the work on PHP Monitor 6.0.
This ensures all common version constraints can now be parsed correctly.
I am entirely unsure why one would need these, but I figured I'd get
these in the app before I start the work on PHP Monitor 6.0.
This ensures all common version constraints can now be parsed correctly.
Also added a few new preferences related to toggling specific menu items
based on your personal choices.
(These new settings still need to be added to the UI.)
- This commit replaces the usage of `whoami` with `id -un`.
- This also changes all `~` replacements with the result of calling
the `NSHomeDirectory()` which may differ from `id -un` (#189)
- This commit replaces the usage of `whoami` with `id -un`.
- This also changes all `~` replacements with the result of calling
the `NSHomeDirectory()` which may differ from `id -un` (#189)
- Add 'Welcome Tour' to First Aid menu
- Updated 'Welcome Tour'
- Helpers are now always written to ~/.config/phpmon/bin
- Updated helpers (now symlinked)
- Updated checks for when to symlink helpers
- Renamed `ProgressWC` to `TerminalProgressWindowController` so it
better reflects the functionality of the class.
- Renamed all `-WC` suffixed classes to `-WindowController`. This is
cleaner because it avoids referencing water closets. 🚽
- Fixed some instances where the copyright notice used the wrong
filename. All window controller classes are now accurate.
This commit adds support for custom environment variables, which can be
set in PHP Monitor's custom configuration file.
Let's say you wish to customize the `COMPOSER_HOME` env variable, like
in #183. You can fix this like so:
```json
{
"scan_apps": [],
"services": [],
"presets": []
"export": {
"COMPOSER_HOME": "/absolute/path/to/composer/folder"
}
}
```
Please note that while it is possible to set the `PATH` this way, you
WILL MOST CERTAINLY break PHP Monitor in the process. Setting other
environment variables should generally not pose an issue, unless said
environment variable affects the output of the shell that PHP Monitor
uses internally.
* Differentiate between services running as root and current user
* Support for custom services (via config.json)
* Renamed "Restart All Services" to "Restart Valet Services"
* Use SwiftUI for Stats, Services and Header view
* Added Color extension for debugging (PAINT_PHPMON_SWIFTUI_VIEWS)
For any given preset, we need to be able to determine what we'd need to
do in order to revert the preset. That means figuring out what the diff
is between the current PHP setup and what the preset would change.
We'll persist that to its own preset, which can be reapplied if needed.
The "revertable" preset is persisted to the following file:
~/.config/phpmon/preset_revert.json
If that file is present and valid, the app should enable the 'revert'
option. (That still needs to be implemented.)
The way .ini files are loaded is changing with this commit. Instead of
directly saving which extensions were found, the extensions loaded are
now determined by reading the .ini file.
However, there are some performance concerns here. Perhaps it is worth
*not* reloading the contents of these files unless absolutely necessary.
- Renaming the configuration files from `www.conf` to the backup
(`disabled-by-phpmon`) will now succeed if the `disabled-by-phpmon`
file already exists. This would fail if the `disabled-by-phpmon` file
already existed in previous builds.
- The PHP-FPM alert when there's an issue with a missing socket
configuration file has been tweaked and now contains a workaround if
you want to run a newer version of PHP (e.g. PHP 8.2) that is not
officially supported by Valet yet.
- When attempting to list the PHP version numbers, the `parse()` method
is now used, as opposed to `PhpVersionNumber.make()`, which couldn't
correctly handle pre-release versions of PHP.
- Updated tests to reflect these changes to `PhpVersionNumber`.
- Up to 50 sites are now preloaded (up from 30)
- No longer crash when invalid config.json is found (only at launch)
- Added `evaluateFeatureSupport` to Valet.swift
- Load configuration during launch checks instead
This change introduces binary detection to the app. PHP Monitor does not
rely on the user's PATH because the output of a user's terminal can
cause issues, so we will scan the two common locations for the Composer
binary file. The text in the alert has been modified to accommodate the
change (you could still not have Composer installed).
Now missing labels will come up as Compiler Errors. This, along with the
deprecations in the previous alert should allow me to replace all the
alerts everywhere.
A quick 5-minute fix.
As raised in #135, it is not super obvious why Fix My Valet might be
disabled. From now on, Fix My Valet is now always enabled, but it might
throw up an alert if the required formula is missing.
It'll be a while before a new release candidate is available, but this
bug has now been resolved.
A new `PhpVersionNumber.parse` method has been added which can throw.
The `VersionExtractor` class is now capable of extracting version
numbers from all strings now too, and isn't just used to determine
the Valet version number.
New tests have been added to handle these scenarios.
This commit also removes the phpmon-cli component, which wasn't being
updated or maintained (it was an experiment).
- PHP next to icon (default)
- PHP Elephant
- No icon
If you chose "no PHP text next to icon" earlier, that preference is
remembered and migrated over.
This change allows for errors to be thrown during the `asyncExecution`
initial callback, and if one is thrown, allows a `failure` callback to
be used. Existing instances of `waitAndExecute` have been replaced.
I also added the ability to tweak the behaviours of the actions that are
always performed when the asyncExecution method is called: you can now
specify limited behaviours (e.g. only set busy icon). For that use case
I have already created a new method: `asyncWithBusyUI`.
With this change, the handling of the Homebrew Permissions flow has also
been modified: when the user does not get administrative permissions
an error is now thrown which results in an alert being presented to
the user once the error occurs.
There is now an opportunity to further refactor other parts of the app
to more gracefully handle failure states using the Error and
AlertableError protocols.
- Properly draw the menu bar icon
(now with extra documentation)
- Resolve Paths via FileManager.default
- Updated DEV readme
- Add PHP Elephant icon (TBD)
- Moved DonationUrl to Constants
- Added additional menu items (visible if window is open)
- Fixed capitalisation of "WordPress" in PhpFrameworks
- Cleanup Stats
- Add new translation strings for menu items
Some users might not reboot their computer and in that situation they
will never see the message in bba961269c.
This has been remedied by also checking how many times the version
switch has occurred.
The thresholds for the alert are now:
- Must have launched the app at least 7 times
OR
- Must have switched PHP versions at least 40 times
If the alert has been seen, it'll never be shown again. For more info
please consult the linked commit for the rationale behind this change.
Okay, so this commit adds a sponsor alert. I wanted to elaborate.
Why? At this point I've invested so much of my free time in the app that
any and all donations would be incredibly welcome. Of course, phpmon
as it exists today must always remain free and open source.
(I dislike it when an app goes open source and then becomes paid.)
Obviously, I don't want to take useful features away from users:
1) usage of the old version is the only option for those who won't pay
2) piracy is an alternative and I don't want to deal with that
3) the positive sentiment around the app disappears ("sellout!")
Instead, I will nicely ask for donations once the app has been
successfully launched 7 times or more. This alert should only
appear once.
Fun fact: PHP Monitor started as a single menu item with only
options to switch between version numbers.
Thanks to all the support, it has now become so much more.
To those who have already contributed: thank you very much.
I hope you continue to use and enjoy the app.
Cheers!
This is much faster than checking the actual driver, which might take
a while if you have many sites. If we're just checking the actual
composer file (which is already parsed) this should be much faster.
This means that the user cannot tell we swapped out the view for another
view. The services are re-fetched upon creating the new view, but there
is a slight delay. This change conveniently "hides" this delay.
BEFORE
- Upon creating ServicesView2, ServicesView is deinitialized
- ServicesView2 shows question marks (no services data persisted)
- ServicesView2 async loads services, when done question marks removed
AFTER
- Upon creating ServicesView2, ServicesView is deinitialized
- ServicesView2 loads stale data (services data was persisted)
- ServicesView2 async loads services, when done stale data replaced
The version constraint checks will also be used in the future to
evaluate whether any given site's PHP constraint (if set) is
valid for the currently linked version of PHP.
For example, assuming you have PHP 8.1.2 linked, we could evaluate:
* A site requires "8.0" -> invalid
* A site requires "^8.0" -> valid
* A site requires "^8.0.0" -> valid
* A site requires "~8.0" -> valid
* A site requires "~8.0.0" -> invalid
Currently, this constraint check is used to determine which versions
that are currently installed are good suggestions to switch to.
If you have a site with constraint "^8.0" for example, and you have
PHP 8.0 and 8.1 installed (with 8.1 linked), then you will get a
suggestion to switch back to 8.0.
- Only works with dynamic icon enabled
- Preference defaults to true on new or existing installs
(because we want to display PHP next to the version number by default)
For those who love a minimal menu bar setup but still want to see what
PHP version is currently enabled, this is perfect.
- Ensure composer global update cannot run twice (#71)
- Set busy status when updating dependencies (#71)
- Further reorganized menu items (#69)
- Use consistent capitals in menu items
- Fix preferences screen layout (auto newlines due to fixed width)
As part of the boot procedure, recommend upgrading Valet if the version
seems to be too old. For version 4.1 of PHP Monitor, the version has
been hard-coded to 2.16.2 (for PHP 8.1 compatibility).
- Avoid preloading list of sites twice
- Avoid loading Valet info twice
- Preload list of sites if <= 10 sites linked + parked
- Added fallback for missing instructions
- Improved description
In rare cases, the version corresponding to the `php` formula might not
be installed, but another alias is linked correctly. That means that the
PHP binary is found, but the core formula is not. PHP Monitor will
incorrectly report that it exists, which means the user can break their
PHP installation. Oops.
This quick fix handles that situation:
- Checks if the PHP binary for the `php` aliased version exists
(located in $optdir/php/bin/php)
- Disables the force load option if the aliased version is missing
(including a tweaked label if the version is missing)
Now correctly detects the following apps that can open a directory:
- PhpStorm (installed via Toolbox)
- Sublime Text
- Sublime Merge
This in addition to:
- PhpStorm (manual installation)
- Visual Studio Code
These need to be installed in the default location.
For VS Code to work, you need to have added `code` to your PATH.
description:Do you have a great idea for an enhancement that could improve PHP Monitor?
title:"[Feature] <title>"
labels:[enhancement]
assignees:nicoverbruggen
body:
- type:checkboxes
attributes:
label:Is there an existing issue for this?
description:Please search to see if an issue already exists for the bug you encountered. Please make sure you've checked the discussions tab as well. Enhancement requests that are not immediately approved will be moved to a discussion instead, so you will find some there.
options:
- label:I have searched the existing issues and discussions
required:true
- type:textarea
attributes:
label:Is this feature request related to a problem?
description:"A clear and concise description of what the problem is. For example: 'I am always frustrated when...'"
validations:
required:true
- type:textarea
attributes:
label:Describe the solution you'd like to see
description:What would be a user-friendly way of resolving this particular issue?
validations:
required:true
- type:textarea
attributes:
label:Additional information or context
description:Add any other context or screenshots about the feature request here.
Thank you for your interest in contributing to PHP Monitor.
I consider this project a bit of a nice side-project to my daily gig, so it is very much a personal affair where I love to tinker around.
**While the code of the latest PHP Monitor release is public, many things are constantly in flux that may not be pushed to this repository yet.**
I don't mean to be rude, but I don't want other people involved with the project beyond simply contributing a few small things here and there, as has been the case in the past.
The extra mental overhead of having additional contributors to report to, whose code will need to be reviewed... it's a lot and it makes working on PHP Monitor less enjoyable for me.
Plus, at this point, the majority of PHP Monitor's main functionality is also done.
As a result, I may refer you to this file at some point. Again, I don't wish to be rude, but this general rule stands:
**Making any changes in a fork and opening a pull request without opening an issue first will most likely result in your PR being closed without mercy.**
To repeat, I am **not opposed** to small contributions and fixes, if they are **meaningful or insightful**.
To learn more, please check out the [pull request template](/.github/pull_request_template.md) which contains more information about my contribution requirements. (This will also show up when you open a new PR.)
Hello there! Thank you for considering a pull request for PHP Monitor.
Please read the text below first before you submit your PR.
## Do not PR unless...
In order to make development and maintenance of PHP Monitor easier, I ask that you _avoid_ making a pull request in the following situations:
* No issue has been associated with the changes you‘d like to merge
* You have not announced you will be addressing a particular issue
* The PR is a low effort change: e.g. commits that only fix typos or phrasing may not be accepted
(If you believe the phrasing of particular text in the app is unclear or incorrect, please open an issue first.)
In short: It is usually best to *get in touch first* if you are making substantial changes.
## About destination branches
Please keep in mind that `main` is reserved for the current code state of the latest release and should *never* be the destination branch unless a new release is happening. **Pull requests that target `main` will be closed without mercy.**
Usually, the best target is the stable `dev/x.x` branch that corresponds with the latest major version that is released.
There may be a newer branch available, which is an appropriate place for bigger changes, but please keep in mind that it is usually best to announce you‘ll be working on such a change before you spend the time, since as the lead contributor I might not even want said change in the app. Thank you.
## Your changes
(feel free to remove the disclaimer above)
* Affected parts of the app: shared code / UI code / CLI (remove what does not apply)
* Estimated impact on performance: none / low / high (remove what does not apply)
* Made a new build with Xcode and tested this: yes / no (remove what does not apply)
* Tested on macOS version + architecture: (e.g. "Monterey on M1" or "Big Sur on Intel")
* References issue(s): (please reference the issue here, using # and the number of the issue)
This project uses the [SwiftLint](https://github.com/realm/SwiftLint) linter. You must install it and can run it like so:
```
swiftlint
```
It also automatically runs when you try to build the project. You'll get a warning if `swiftlint` is not installed, though. You can attempt to automatically fix issues:
```
swiftlint --fix
```
## ⚙️ Preferences
You can find the persisted configuration file in `~/Library/Preferences/com.nicoverbruggen.phpmon.plist`
These values are cached by the OS. You can clear this cache by running:
<imgsrc="./docs/build.png"width="404px"alt="build button in Xcode"/>
### PHP Monitor
If you'd like to build PHP Monitor yourself, you need:
* Xcode (usually the latest version)
* *PHP Monitor Self-Updater.app* in the `phpmon-updater` directory (You can build it yourself, it is included as a target OR copy the signed app so it is included w/ PHP Monitor)
* The contents of this repository
Once you have downloaded this repository, open `PHP Monitor.xcodeproj`, and you should be able to build the app for your system by pressing Cmd-R. This will create a debug build. (If Xcode complains about code signing, you can turn it off.)
If you'd like to create a production build, choose "Any Mac" as the target and select Product > Archive.
### PHP Monitor Updater
Select the separate target and build. You can then copy the product to the `phpmon-updater` directory. The binary will be re-signed when distributing the main build.
## 🚀 Release procedure
1. Merge into `main`
2. Create tag
3. Add changes to changelog + update security document
You can enable marketing mode by setting the `PHPMON_MARKETING_MODE` environment variable. It preloads a list of (fake) domains in the domain window list for screenshot & marketing purposes.
launchctl setenv PHPMON_MARKETING_MODE true
## 🐛 Symbolication of crashes
If you have an archived build of the app and exported the DSYM, it is possible to symbolicate .ips crash logs.
For example, given the following crash (from an .ips file):
> If this software has been useful to you, I ask that you **please star the repository**, that way I know that the software is being used. Also, please consider [sponsoring](https://nicoverbruggen.be/sponsor) to support the project, as this is something I make in my free time. **Thank you!** ⭐️
> If this software has been useful to you, all I ask is that you **please star the repository**, so I know that the software is being used.
> You can also send me [feedback](https://twitter.com/nicoverbruggen) if the app came in handy.<br>**Thank you!** ⭐️
**PHP Monitor** (or *phpmon*) is a lightweight macOS utility app that runs on your Mac and displays the active PHP version in your status bar. It's tightly integrated with [Laravel Valet](https://github.com/laravel/valet), so <u>you need to have it set up if you want to use all of the functionality of the app</u> (consult the FAQ below with info about how to set up your environment).
**PHP Monitor** (or phpmon) is a lightweight macOS utility app that runs on your Mac and displays the active PHP version in your status bar. It's tightly integrated with [Laravel Valet](https://github.com/laravel/valet), so you need to have it set up before you can use this.
<imgsrc="./docs/screenshot.jpg" width="1280px"alt="phpmon screenshot (menu bar app)"/>
<imgsrc="./docs/screenshot34.png"width="412px"alt="phpmon screenshot (menu bar app)"/>
<small><i>Screenshot: A menu showing all of the functionality of PHP Monitor.</i></small>
<small><i>Screenshot: Showing the key functionality of PHP Monitor.</i></small>
It's super convenient to switch between different versions of PHP. You'll even get notifications (only if you choose to opt-in, of course)!
@ -17,31 +15,66 @@ It's super convenient to switch between different versions of PHP. You'll even g
PHP Monitor also gives you quick access to various useful functionality (like accessing configuration files, restarting services, and more).
You can also add new domains as links, isolate sites, manage various services, and perform First Aid to fix all kinds of common PHP link issues.
## 🖥 System requirements
PHP Monitor is a universal application that runs on Apple Silicon **and** Intel-based Macs.
PHP Monitor is a universal application that runs natively on Apple Silicon **and** Intel-based Macs.
*macOS 10.14 Mojave or higher (works on macOS 11 Big Sur and macOS 12 Monterey)
*Homebrew is installed in `/usr/local/homebrew` or `/opt/homebrew`
*The brew formula `php` has to be installed (which version is detected)
*Laravel Valet 2.13 or higher
*Your user account can administer your computer (required for some functionality, e.g. certificate generation)
*macOS 12.4 or later (Monterey, Ventura and Sonoma are supported)
*Homebrew is installed in the default location (`/usr/local/homebrew` or `/opt/homebrew`)
*Homebrew `php` formula is installed
* Optional but recommended: Laravel Valet
_You may need to update your Valet installation to keep everything working if a major version update of PHP has been released._
_Starting with PHP Monitor 6.0, you do not need to have Laravel Valet installed for PHP Monitor to work. To get access to all features of PHP Monitor however, installing Valet is **recommended**._
For more information, please see [SECURITY.md](./SECURITY.md) to find out which version of the app is currently supported.
## 🚀 How to install
You can install via Homebrew (recommended), or may download the latest release on GitHub.
Again, if you want to have access to *all features* of PHP Monitor, I recommend installing **[Laravel Valet](https://laravel.com/docs/master/valet)** first:
To install via Homebrew, run:
```sh
composer global require laravel/valet
valet install
valet trust
```
brew tap nicoverbruggen/homebrew-cask
brew install --cask phpmon
Currently, PHP Monitor is compatible with Laravel Valet v2, v3 and v4. Each of these versions of Valet support slightly different PHP versions, which is why legacy versions remain supported. Please note that some features are not available in older versions of Valet, like site isolation.
To upgrade your existing installation, run:
#### Manual installation (recommended, first time only)
brew upgrade phpmon
Once that's done, you can [download the latest release](https://github.com/nicoverbruggen/phpmon/releases/latest), unzip it and place it in `/Applications`.
_The app is signed and notarized, meaning all you have to do is approve its first launch._
#### Installation via Homebrew
*Prior to version 5.8, this was the recommended way of installing PHP Monitor.*
If you prefer to install the app via Homebrew, you can also run the following:
```sh
brew tap nicoverbruggen/homebrew-cask
brew install --cask phpmon
```
## ⬆️ How to update
The recommended method of updating the app to the latest version is to use **the built-in updater**.
If you have a very slow internet connection, the updater may report that the download has timed out. In that case, you may wish to manually update by [downloading the latest release](https://github.com/nicoverbruggen/phpmon/releases/latest) and placing the app in `/Applications`.
(You may also use Homebrew to update PHP Monitor, but this will require you to approve the app every time an update is installed. If you use the built-in updater, this won't be necessary.)
## ⚡️ Launchers (Alfred, Raycast)
If you would like to integrate with your launcher of choice, you can also download an [Alfred workflow](https://github.com/nicoverbruggen/phpmon/raw/main/integrations/phpmon.alfredworkflow) or [Raycast extension](https://www.raycast.com/nicoverbruggen/php-monitor) that works with PHP Monitor.
The app must be running in the background for these to work, and the _Allow third-party integrations_ checkbox must be enabled in Preferences (it is by default).
## 🔑 Is the app signed & notarized?
Yes, the app is signed and notarized, meaning all you have to do is approve its first launch (or whenever it updates).
## 👨💻 Why build this?
@ -49,12 +82,20 @@ I wanted to be able to **see at a glance** which version of PHP was linked, and
Initially, I had an Alfred workflow for this — but it has now been replaced with this utility, which also does a good job at displaying additional information at a glance, like the current PHP version, memory limits, and more.
## 🐘 Why not use Laravel Herd?
If you don't need to customize your local PHP setup and just want an easy and ready-to-go environment to start coding, [Laravel Herd](https://herd.laravel.com) is probably more than sufficient for many use cases.
If you need more customization and flexibility I encourage you to consider PHP Monitor in combination with Laravel Valet or some other solution like Docker (with Laravel Sail, for example).
## 🤬 The app won't start?!
PHP Monitor performs some integrity checks to ensure a good experience when using the app. You'll get a message telling you that PHP Monitor won't work correctly in a variety of scenarios.
PHP Monitor performs some integrity checks to ensure a good experience when using the app. You'll get a message telling you that PHP Monitor won't work correctly in a variety of scenarios.
**Follow instructions as specified in the alert in order to resolve any issues.**
(If the app crashes at launch without showing you any of these messages, you might have a non-standard Homebrew and Valet setup. Those are not supported.)
## 🙋♂️ FAQ & Troubleshooting
> If you are having issues, the first thing you should be doing is installing the latest version of PHP Monitor _and_ Laravel Valet. This can resolve a variety of issues. To upgrade Valet, run `composer global update`. Don't forget to run `valet install` after upgrading.
@ -64,41 +105,61 @@ If you're still having issues, here's a few common questions & answers, as well
<details>
<summary><strong>Which versions of PHP are supported?</strong></summary>
<ul>
<li>PHP 5.6</li>
<li>PHP 7.0</li>
<li>PHP 7.1</li>
<li>PHP 7.2</li>
<li>PHP 7.3</li>
<li>PHP 7.4</li>
<li>PHP 8.0</li>
<li>PHP 8.1</li>
<li>PHP 8.2 (experimental)</li>
</ul>
All stable and supported PHP versions are also supported by PHP Monitor. However, depending on which version of Valet you have installed, which versions of PHP that are made available for switching purposes may differ.
For more details, consult the [constants file](https://github.com/nicoverbruggen/phpmon/blob/main/phpmon/Constants.swift#L16) file to see which versions are supported.
> **Note**
> If you have versions of PHP installed that can be detected by PHP Monitor but is *not* supported by the currently active version of Valet, you will be alerted by an item in the menu with an exclamation mark emoji. (⚠️)
Backports that are installable via PHP Monitor's **PHP Version Manager** functionality are subject to availability via [this tap](https://github.com/shivammathur/homebrew-php).
For maximum compatibility with older PHP versions, you may wish to keep using Valet 2 or 3. For more information, please see [SECURITY.md](./SECURITY.md) to find out which versions of PHP are supported with different versions of Valet.
</details>
<details>
<summary><strong>How do I install additional versions of PHP, including legacy versions?</strong></summary>
Assuming you have installed the `php` formula, the latest stable version of PHP is installed. At the time of writing, this is PHP 8.2.
You can install other supported versions of PHP via PHP Monitor's **PHP Version Manager**. (You can manually install or upgrade PHP versions too, but this is not recommended.)
Please keep in mind that installing or updating PHP versions, even when done via PHP Monitor's **PHP Version Manager**, may cause other required formula dependencies (required software needed to keep those PHP versions functional) to be upgraded. It might not be very transparent when this happens, but this is likely the cause if installing a PHP version takes longer than expected: usually other dependencies are also being installed.
Additionally, upgrading one specific version of PHP may also cause other installed versions of PHP to *also* be updated in one go, if the dependencies for that one version also apply to the other (newer) version(s) of PHP. It's a bit tricky to manage PHP versions via Homebrew, and even PHP Monitor may encounter some difficulties.
If you encounter a strange scenario or a malfunction, please open an issue on the issue tracker and get in touch. I'd like to keep enhancing this process to make it as foolproof as possible.
> *Note*: Using PHP Monitor when managing PHP versions may cause [temporary alias conflicts](https://github.com/nicoverbruggen/phpmon/issues/54#issuecomment-979789724) while the core tap alias and the tap's alias refer to a different version of PHP, but this is generally speaking a minor inconvenience, since this normally only applies when a new PHP version releases.
</details>
<details>
<summary><strong>I want PHP Monitor to start up when I boot my Mac!</strong></summary>
You can do this by dragging *PHP Monitor.app* into the **Login Items** section in **System Preferences > Users & Groups** for your account.
If you are running macOS Ventura or newer, there's an option in the Settings menu that you can select: "Start PHP Monitor at login".
If you are on an older version of macOS, you can do this by dragging *PHP Monitor.app* into the **Login Items** section in **System Preferences > Users & Groups** for your account.
Super convenient!
</details>
<details>
<summary><strong>What features are unavailable in Standalone Mode?</strong></summary>
The services manager is disabled, and all other obvious Laravel Valet integrations (configuration finder, domains list, Fix My Valet) are also disabled.
(Most other features remain available.)
</details>
<details>
<summary><strong>I want to set up PHP Monitor from scratch! I don't have Homebrew installed either, where do I begin?</strong></summary>
If you want to set up your computer for the very first time with PHP Monitor, here's how I do it:
If you want to set up your computer for the very first time with PHP Monitor, here's how I do it.
Install [Homebrew](https://brew.sh) first.
**I have also created [a video tutorial](https://www.youtube.com/watch?v=fO3hVhkvm3w) which may be easier to follow. If you just want the terminal commands, keep reading.**
Install PHP, composer, add to path:
Install [Homebrew](https://brew.sh) first. Follow the instructions there first!
Then, you'll need to set up your PATH.
brew install php
brew install composer
nano .zshrc
Make sure the following line is not in the comments:
@ -111,24 +172,96 @@ If you're on an Apple Silicon-based Mac, you'll need to add:
# on an M1 Mac
export PATH=$HOME/bin:/opt/homebrew/bin:$PATH
and add the following to your .zshrc:
and add the following to your `.zshrc` file, but add this BEFORE the homebrew PATH additions:
If you're adding `composer` and Homebrew binaries, ensure that Homebrew binaries are preferred by adding these to the path last. On my system, that looks like this:
If you are *not* on Apple Silicon, you should remove the third line.
Install the `php` and `composer` formulae:
brew install php composer
Make sure PHP is linked correctly:
which php
should return: `/usr/local/bin/php` (or `/opt/homebrew/bin/php`)
should return: `/usr/local/bin/php` (or `/opt/homebrew/bin/php` if you are on Apple Silicon)
**If you don't need Laravel Valet, you can stop here. PHP Monitor will work like this in Standalone Mode.**
If you'd like to have Valet as well, continue and install Valet with Composer, like this.
composer global require laravel/valet
For optimal results, you should lock your PHP platform for global dependencies to the oldest version of PHP you intend to run. If that version is PHP 7.0, your `~/.composer/composer.json` file could look like this (please adjust the version accordingly!):
```
{
"require": {
"laravel/valet": "^3.0",
},
"config": {
"platform": {
"php": "7.0"
}
}
}
```
Run `composer global update` again. This ensures that when you switch to a different global PHP version, [Valet won't break](https://github.com/nicoverbruggen/phpmon/issues/178). If it does, PHP Monitor will let you know what you can do about this.
Then, install Valet:
valet install
This should install `dnsmasq` and set up Valet. Great, almost there!
valet trust
Finally, run PHP Monitor. Since the app is notarized and signed with a developer ID, it should work.
Finally, run PHP Monitor. Since the app is notarized and signed with a developer ID, it should work. You will need to approve the initial launch of the app, but you should be ready to go now.
</details>
<details>
<summary><strong>How frequently does PHP Monitor check for updates?</strong></summary>
PHP Monitor will check if an update is available every time you start the app.
You can disable this behaviour by going to Preferences (via the PHP Monitor icon in the menu bar) and unchecking "Automatically check for updates". (You can always check for updates manually.)
</details>
<details>
<summary><strong>I have PHP Monitor installed, and it works. I want to upgrade my PHP installations to the latest version, what's the best way to do this?</strong></summary>
The easiest way is to simply use the built-in **PHP Version Manager**, which will allow you to upgrade your PHP versions with one click.
If you want to do this manually, you can follow the instructions below.
It's easy to make a mistake here, and end up with an unlinked version of PHP or have versions missing from PHP Monitor.
Here's what I usually do:
* Open PHP Monitor and select **First Aid & Services** > **Restore Homebrew Permissions**.
* Close PHP Monitor after the pop-up tells you the permissions were restored.
* Run `brew update-reset`
* Run `brew upgrade`
If after this, any PHP versions are missing in PHP Monitor, please run the following for the versions that are missing:
* Run `brew uninstall php@x.x` (where `x.x` is the version)
* Run `brew cleanup` (if you get any permission issues you may need to manually clean up the folder)
* Run `brew install php@x.x` (where `x.x` is the version)
You may still need to run `brew link php` after upgrading, too.
That's it. Now start up PHP Monitor again and you should be golden!
</details>
<details>
@ -140,7 +273,7 @@ This should resolve the issue! If that does not fix the issue, run `brew link ph
brew install php
brew link php --force
</details>
<details>
@ -152,6 +285,8 @@ This problem is usually resolved by upgrading Valet and running `valet install`
composer global update
valet install
If you are seeing a 502 (Bad Gateway) error after about 30 seconds or so, your request is likely timing out. You may need to solve a performance issue with your own code.
</details>
@ -183,16 +318,24 @@ You should see an error or a warning here in the output.
Usually this is a duplicate extension declaration causing issues, or an extension that couldn't be loaded. You'll have to solve that issue yourself (usually by removing the offending extension or reinstalling).
</details>
<details>
<summary><strong>The option to isolate a site is disabled! What's going on?</strong></summary>
Make sure you have at least **Valet 3.0** installed, since support for isolation was added in this version of Valet. (Please note that this version of Valet drops support for PHP 5.6.)
</details>
<details>
<summary><strong>One of the limits (memory limit, max POST size, max upload size) shows an exclamation mark!</strong></summary>
The value you provided in your INI file is invalid. If that is the case, PHP will attempt to parse your value as bytes, which is usually unintended. (`1GB` will resolve to merely a few bytes, and all of your applications will run out of memory!)
The value you provided in your `.ini` file is invalid. If that is the case, PHP will attempt to parse your value as bytes, which is usually unintended. (`1GB` will resolve to merely a few bytes, and all of your applications will run out of memory!)
You must a provide a value like so: `1024K`, `256M`, `1G`. Alternatively, `-1` is also allowed, or just an integer (which will result in N amount of bytes being the limit).
**Example**: Trying to use `1GB` as the memory limit, for example, will result in this exclamation mark. The correct way to set a 1GB limit is by using `1G` as the value. (Note: The displayed value will append `B` for clarity, so if you set `1G`, the value reported by PHP Monitor will be 1 GB.)
(If you are using Valet, you can adjust these limits in the `.conf.d/php-memory-limits.ini` file. Otherwise, you may need to adjust `php.ini`.)
</details>
<details>
@ -217,32 +360,221 @@ Since v3.4 all of the loaded .ini files are sourced to determine which extension
<details>
<summary><strong>I've got two Homebrew installations on my Apple Silicon Mac, can I choose which installation to use with PHP Monitor?</strong></summary>
Not at this time, no. PHP Monitor will prefer the `/opt/homebrew` installation over the classic installation directory.
If you are using PHP Monitor on an Intel machine or on an Apple Silicon machine with Rosetta enabled, PHP Monitor expects the main Homebrew binary in `/usr/local/bin/brew`.
If you are using PHP Monitor on Apple Silicon without Rosetta, PHP Monitor expects the main Homebrew binary in `/opt/homebrew/bin/brew`.
If there's an issue here, you'll get an alert at launch.
Make sure that the version of Homebrew that you are running normally is the same as the one that PHP Monitor expects. If you are on M1 hardware for example, but still using Rosetta for Homebrew, you'll need to run PHP Monitor under Rosetta as well.
PHP Monitor is a universal app and supports both architectures, so [find out here](https://support.apple.com/en-us/HT211861) how to enable Rosetta with PHP Monitor.
</details>
<details>
<summary><strong>Why is the app doing network requests?</strong></summary>
It's Homebrew. I can't prevent `brew` from doing things via the network when I invoke it.
The app will automatically check for updates, which is the most likely culprit.
PHP Monitor itself doesn't do any network requests. Feel free to check the source code or intercept the traffic, if you don't believe me.
This happens at launch (unless disabled), and the app directly checks the Caskfile hosted on GitHub. This data is not, and will not be used for analytics (and, as far as I can tell, cannot).
I also can't prevent `brew` from doing things via the network when PHP Monitor uses the binary.
The app includes an Internet Access Policy file, so if you're using something like Little Snitch there should be a description why these calls occur.
</details>
<details>
<summary><strong>After running PHP Monitor, Homebrew sometimes has issues with `brew upgrade`!</strong></summary>
<summary><strong>How do I various presets to show up?</strong></summary>
This is a security feature of Brew. When you start a service as an administrator, the root user becomes the owner of relevant binaries.
You must set these presets up in a JSON file, located in `~/.config/phpmon/config.json`.
You will need to manually clean up those folders yourself using `rm -rf` (or by manually removing those folders via Finder).
You must have set up at least one valid preset for this presets to work in PHP Monitor.
Here's an example of a working preset:
<pre>
{
"scan_apps": [],
"services": [],
"presets": [
{
"name": "Legacy Project",
"php": "8.0",
"extensions": {
"xdebug": false
},
"configuration": {
"memory_limit": "128M",
"upload_max_filesize": "128M",
"post_max_size": "128M"
}
}
],
"export": {}
}
</pre>
You can omit the `php` key in the preset if you do not wish for the preset to switch to a given PHP version.
> **Warning**
> You must restart PHP Monitor for these changes to be detected.
</details>
<details>
<summary><strong>How do I ensure additional Homebrew services are shown in the app?</strong></summary>
> **Info**
> Homebrew services aren't displayed if you are using Valet in Standalone Mode.
You must set these services up in a JSON file, located in `~/.config/phpmon/config.json`.
You can specify custom services in the configuration file for Homebrew services that run as your own user (not root).
> **Info**
> If your service must run as root, it cannot currently be added to PHP Monitor.
You can find out which services are available by running `brew services list`.
Here's an example where we add the `mailhog` and `mysql` services to PHP Monitor:
<pre>
{
"scan_apps": [],
"services": ["mailhog", "mysql"],
"presets": [],
"export": {}
}
</pre>
> **Warning**
> You must restart PHP Monitor for these changes to be detected.
</details>
<details>
<summary><strong>How do I set custom environment variables?</strong></summary>
You must configure these custom environment variables up in a JSON file, located in `~/.config/phpmon/config.json`.
PHP Monitor uses a default Shell environment, with no custom environment variables. You need to set custom environment variables manually. These are then used for e.g. Composer.
Here's an example of a working `COMPOSER_HOME` environment variable which is respected:
> You must restart PHP Monitor for these changes to be detected.
</details>
<details>
<summary><strong>How do I get various applications to show up in the domain list's right-click menu?</strong></summary>
When you select and right-click on a domain, you can open these directories with various applications. This can help speed up your workflow. However, for these apps to show up, they must be detected first.
The supported apps are: <i>PhpStorm, Visual Studio Code, Sublime Text, Sublime Merge, iTerm</i>.
All of these apps should just be detected correctly, no matter their location on your system. If you can open it using `open -a "appname"`, the app should be detected and work. If you have renamed the app, there might be an issue getting it detected.
To see which files are checked to determine availability, see [this file](./phpmon/Domain/Helpers/Application.swift).
You can add your own apps by creating and editing a `~/.config/phpmon/config.json` file, and make sure the `scan_apps` key is set:
<pre>
{
"scan_apps": ["Xcode", "Kraken"]
}
</pre>
You can put as many apps as you'd like in the `scan_apps` array, and PHP Monitor will check for the existence of these apps. You do not need to set the full path, just the name of the app should work. Not all apps support opening a folder, though, so your success might vary.
> **Warning**
> You must restart PHP Monitor for these changes to be detected.
</details>
<details>
<summary><strong>How can the app integrate with third party tools, like Alfred or Raycast?</strong></summary>
PHP Monitor supports third party app integrations by default, and this feature is enabled in Preferences unless you disable it.
You can grab the official [Alfred workflow](https://github.com/nicoverbruggen/phpmon/raw/main/integrations/phpmon.alfredworkflow) or [Raycast extension](https://www.raycast.com/nicoverbruggen/php-monitor).
If you'd like to integrate something yourself, all you need to to is use the `phpmon://` protocol and ensure that third party app integrations are enabled in Preferences (in PHP Monitor).
Using app callbacks, macOS and PHP Monitor allow for the following to be called:
* phpmon://list
* phpmon://services/stop
* phpmon://services/restart/all
* phpmon://services/restart/nginx
* phpmon://services/restart/php
* phpmon://services/restart/dnsmasq
* phpmon://locate/config
* phpmon://locate/composer
* phpmon://locate/valet
* phpmon://phpinfo
* phpmon://switch/php/{version}
</details>
<details>
<summary><strong>How does the app know what PHP version is required for my app?</strong></summary>
The `composer.json` file in the root of the folder (if it exists) is scanned and interpreted.
If the version is set in `platform`, it takes precendence.
If the version is not set in `platform` but it is in `require` (most common) then that version is used.
</details>
<details>
<summary><strong>What do the checkmarks next to the PHP version mean in the site list?</strong></summary>
You'll see a checkmark next to the version number if the currently enabled PHP version is compatible with the version required to run the site.
This is determined by evaluating the PHP requirement constraint (e.g. `^8.0`, `~8.0` or a specific version: `8.0`).
</details>
<details>
<summary><strong>Why can't I see the driver type any more? It says "Project Type" now.</strong></summary>
PHP Monitor currently checks your `composer.json` file to try to figure out what project you are running.
This approach is a lot faster than asking for a driver when you have many sites linked, but is slightly less reliable since the framework or type of project inferred via `composer.json` might not be 100% accurate.
You can always still ask Valet using the command line, should it be necessary. In my experience fetching the drivers slowed down the app unnecessarily.
</details>
<details>
<summary><strong>After running PHP Monitor, Homebrew sometimes has issues with `brew upgrade` or `brew cleanup`!</strong></summary>
You can now use **First Aid & Services > Restore Homebrew Permissions** to (temporarily) resolve this issue and allow for a clean and painless `brew upgrade` or `brew cleanup` process.
If you would like to know more, consult [this issue](https://github.com/nicoverbruggen/phpmon/issues/85) for more information about why this is needed.
</details>
<details>
<summary><strong>The app has crashed!</strong></summary>
Please get in touch and open an issue. PHP Monitor shouldn't crash :)
Please get in touch and open an issue. PHP Monitor shouldn't crash... (unless you are actually removing PHP *while* the app is running, that’s considered normal behaviour!)
If you would like to report a crash, please include the associated **log files** so I can find out what exactly went wrong.
To find the logs, take a look in `~/Library/Logs/DiagnosticReports` (in Finder) and see if there's any (log) files that start with "PHP Monitor".
Additionally, you can help me figure out even more information by sending me your verbose log for your latest session of PHP Monitor. Logging is disabled by default.
You can start extra verbose logging by running: `touch ~/.config/phpmon/verbose` and restarting PHP Monitor. You can find the latest log in: `~/.config/phpmon/last_session.log`. Please attach it to the relevant bug report.
</details>
@ -260,14 +592,14 @@ Donations really help with the Apple Developer Program cost, and keep me motivat
## 😎 Acknowledgements
While I did make this application during my own free time, I have been lucky enough to do various experiments during work hours at [DIVE](https://dive.be). I'd also like to shout out the following folks:
Special thanks go out to:
*My colleagues at [DIVE](https://dive.be)
*The [Homebrew](https://brew.sh/) team who maintain
* The [developers & maintainers of Valet](https://github.com/laravel/valet/graphs/contributors)
*Everyone in the Laravel community who shared the app (thanks!)
*Various folks who [reached](https://twitter.com/stauffermatt) [out](https://twitter.com/marcelpociot)
* Everyone who left feedback via issues
*Everyone supporting me via [GitHub Sponsors](https://github.com/sponsors/nicoverbruggen)
*Everyone who has donated via [my sponsor page](https://nicoverbruggen.be/sponsor)
* The [Homebrew](https://brew.sh/) team & [Valet maintainers](https://github.com/laravel/valet/graphs/contributors)
*Various folks who [reached](https://twitter.com/stauffermatt) [out](https://twitter.com/marcelpociot) when PHP Monitor was still very much a small app with a handful of stars or so
*Everyone who has left feedback and reported bugs
* Everyone in the Laravel community who shared the app, especially on Twitter
Thank you very much for your contributions, kind words and support.
@ -275,40 +607,41 @@ Thank you very much for your contributions, kind words and support.
### Loading info about PHP in the background
This utility runs `php-config --version` in the background periodically. It also checks your `.ini` files for extensions and loads more information about your limits (memory limit, POST limit, upload limit).
This app runs `php-config --version` in the background periodically, usually whenever your Homebrew configuration is modified. A filesystem watcher is used to determine if anything changes in your Homebrew's `bin` directory.
In order to save power, this only happens once every 60 seconds.
PHP Monitor also checks your `.ini` files for extensions and loads more information about your limits (memory limit, POST limit, upload limit). See also the section on *Config change detection* below.
### Switching PHP versions
This utility will detect which PHP versions you have installed via Homebrew, and then allows you to switch between them.
This means:
The switcher will disable all PHP-FPM services not belonging to the version you wish to use, and link the desired version of PHP. Then, it'll restart your desired PHP version's FPM process. This all happens in parallel, so this should be a bit faster than Valet’s switcher.
- You have at least the latest version of PHP installed (`php`)
- You have installed Laravel Valet (`which valet` returns `/usr/local/bin/valet`)
- You ran `valet trust`, which means Valet commands can be run without using sudo
If you're using Valet 3 or newer, versions of PHP-FPM required to keep isolated sites up and running will also be started or stopped as needed.
The utility runs the following commands:
### Config change detection
- Unlink all detected PHP versions & stop the respective `php@X.X` services
- Link the desired version of PHP, and start the associated service
PHP Monitor watches your filesystem in the relevant `conf.d` directory for the currently linked PHP version.
Whenever an .ini file is modified, PHP Monitor will attempt to reload the current information about the active PHP installation.
If an extension or other process writes to a single file a bunch of times in a short span of time (< 1 sec), PHP Monitor will only reload the active configuration information after a while (with a slight delay).
### Site detection
1.**Location of your sites**: PHP Monitor uses the Valet configuration file to determine which folders to look into. Each folder is scanned and then PHP Monitor will validate if a composer.json file exists to determine the desired PHP version.
1.**Sites secured or not secured**: Whether the directory has been secured is determined by checking if a matching certificate exists under Valet's `Certificates` directory for that site name.
1.**Project type**: PHP Monitor checks your `composer.json` file for "notable dependencies". If you have `laravel/framework` in your `require`, there's a good chance the project type is `Laravel`, after all.
> **Note**
> If you have linked a folder in Documents, Desktop or Downloads you might need to grant PHP Monitor access to those directories for PHP Monitor to work correctly.
### Want to know more?
If you want to know more about how this works, I recommend you check out the source code.
If you want to know more about how this works, I recommend you check out the source code.
This app isn't very complicated after all. In the end, this just (conveniently) executes some shell commands.
I have done my best to annotate as much as humanly possible, and have avoided using an overly complicated architecture to keep the code as easy to maintain as possible. The code isn't perfect by a long shot (lots of cleanup can still happen!) but the application works well.
## 🔧 Build instructions
I also have a few tests for key parts of the application that I found needed to be tested. In the future, I would like to add even more tests for some of the UI stuff, but for now the tests are more unit tests than feature tests.
<imgsrc="./docs/build.png"width="404px"alt="build button in Xcode"/>
If you'd like to build PHP Monitor yourself, you need:
* Xcode (usually the latest version)
* The contents of this repository
Once you have downloaded this repository, open `PHP Monitor.xcodeproj`, and you should be able to immediately build the app for your system by pressing Cmd-R. This will create a debug build. (If Xcode complains about code signing, you can turn it off.)
If you'd like to create a production build, choose "Any Mac" as the target and select Product > Archive.
For more detailed information for developers, please see [the documentation file for developers](./DEVELOPER.md).
Generally speaking, only the latest version of **PHP Monitor** is supported:
Generally speaking, only the latest version of **PHP Monitor** is supported, except during transition periods (for example, when particular system requirements go up):
| Version | Apple silicon | Supported | Supported macOS | Deployment Target | Detected PHP Versions |
These versions of PHP Monitor are no longer supported, but if you’re using an older computer with an older version of Homebrew, Valet or macOS, you might want to use one of these versions.
| Version | Apple Silicon | Supported | Supported macOS | Deployment Target | Detected PHP Versions | Minimum Required Valet Version |
| 2.5 | ✴️ Universal binary<br/>`/usr/local/homebrew` installations only | ❌ | Big Sur (11.0)<br/>Catalina (10.15) | macOS 10.14+ | not applicable | not applicable |
| 2.4 | ✴️ Universal binary<br/>`/usr/local/homebrew` installations only | ❌ | Big Sur (11.0)<br/>Catalina (10.15) | macOS 10.14+ | not applicable | not applicable |
| <2.4|❌Intelbinary<br/>`/usr/local/homebrew` installations only | ❌ | Catalina (10.15) | macOS 10.14+ | not applicable | not applicable |
"caveats":"To enable PHP in Apache add the following to httpd.conf and restart Apache:\n LoadModule php_module $(brew --prefix)/opt/php/lib/httpd/modules/libphp.so\n\n <FilesMatch \\.php$>\n SetHandler application/x-httpd-php\n </FilesMatch>\n\nFinally, check DirectoryIndex includes index.php\n DirectoryIndex index.php index.html\n\nThe php.ini and php-fpm.ini file can be found in:\n $(brew --prefix)/etc/php/8.0/\n",
letfilename=system("cd \"\(updaterDirectory)\" && ls | grep .zip")
.trimmingCharacters(in:.whitespacesAndNewlines)
//Ensurethezipexists
iffilename.isEmpty{
print("The update has not been downloaded. Sadly, that means that PHP Monitor cannot not updated!")
awaitAlert.show(description:"The update could not be downloaded, or the file was not correctly written to disk. \n\nPlease try again. \n\n(Note that the download will time-out after 20 seconds, so for slow connections it is recommended to manually download the update.)")
print("The checksums failed to match. Cancelling!")
awaitAlert.show(description:"The downloaded update failed checksum validation. Please try again. If this issue persists, there may be an issue with the server and I do not recommend upgrading.")
awaitAlert.show(description:"The updater directory is missing. The automatic updater will quit. Make sure that ` ~/.config/phpmon/updater` is writeable.")
awaitAlert.show(description:"The downloaded file could not be extracted. The automatic updater will quit. Make sure that ` ~/.config/phpmon/updater` is writeable.")
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.