-
-
Notifications
You must be signed in to change notification settings - Fork 366
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Possibly replace CheckEnvironment with a nimbler set of exceptions and handlers #630
Comments
Can we list on the first post what needs to be done so it's easier to plan / split? |
I agree with @lcharette, should make it much easier to keep track of progress on this. Also sounds like an opportunity to use GitHub tasks.
|
FYI, while most check will be made by the CLI in |
Same goes for folder permission apparently. Checking them via the CLI will return the permission of the user running the cli command, which might be different from the apache user. And using |
Whatever solution is landed on, it needs to support Nginx and IIS as well. Might be an idea to have specialised classes for each web server. Such an approach might make it possible to eliminate the need for checkenvironment, provided the CLI tools are decent for Apache and Nginx. (I know IIS is already fully controllable via CLI). |
Do we still need a single page with all the checks? Or could we move to a one exception at a time solution? For example, Apache and permission fails. Right now both would be displayed on the same page. Do we need to do that, or could be display Apache exception, then, when it's fixed, display the permission exception? |
I feel like that Apache check could be converted to a behaviour driven test. Something that would work with more than just Apache. |
At the same time it would be more useful to tell the (new) dev "you need mod rewrite" than "This don't work. It may be mod_rewrite, or ISS thing, or nginx thing" |
True, but we can always strike a balance. |
CheckEnvrionement is gone in UF5 :) |
As we discussed in #dev, we should consider replacing the monolithic
CheckEnvironment
with appropriate exceptions and exception handlers in the portions of the code where they are relevant. For example, the check to see ifcache/
is writable could happen the first time something actually tries to write to that directory (so, maybe the locator service could do this check and throw the exception).This would also allow us to preserve the easy toggling between "dev" mode (sending errors to the response) and "production" mode (sending errors to a log and showing the client a generic message).
The text was updated successfully, but these errors were encountered: