gábor hojtsy → credited warped → .
hestenet → credited Warped → .
Aren't you adding a bunch of packages when you add the dependencies?
At some point, it must have what is going to be done. Jumping to a display, and then returning to the point where it evaluates, if there are any changes, sounds like minimal intrusion. But I don't know the process is.
In Linux, when you install a new package, it shows you the dependencies that will be added to the install, and optional modules that would enhance your experience. Those would require additional install commands later.
I have aborted installs just because I didn't realize how many additional packages would be installed. Having a preview page would definitely give new to Drupal the confidence that they are more in control. More information makes it understandable, rather than wondering what it is going to do. Think about someone that sees a module for credit card processing and doesn't realize this will install commerce.
On the preview page, it could also indicate if it was going to download the module, upgrade an existing module, that maybe wasn't enabled, or just enable a module. After all, a module could have been uninstalled previously and not removed, but they didn't know or remember. Or one of the dependencies might be to enable a core module.
This adds to the idea that the button can just be a "Install" button, instead of a "Download & Install", or "Add and Install", because the exact procedure is detailed in the status and you don't have to know up front.
I also like @lostcarpark 's idea of a post install display. Not only can it include setup/config links, but if an upgrade had change notes, or requirements to manually make changes because of an update, that would be a great time to inform them, rather than leaving them to wonder why it isn't working. And a great confirmation page for a screen print to document their setup, and steps they used to get there.
While project browser is a feature all may use, the intent is to make it easier and more comfortable for those with little knowledge of Drupal. Maybe an opt-out config would help those more knowledgeable to disable features they don't want.
brianperry → credited Warped → .
It might be overwhelming, when you enable them, if you have many debug messages. I like the debug message function, but maybe a checkbox on each one to enable, and a button to disable all. Maybe as an option on a "save" dialog, to remind you to disable when you save the setup.
At the Alpha stage I can see wanting to keep parts required in core at a minimum. Just thinking that for general release, it would be good to support beginners by reducing problems they may initially encounter.
I agree that hosting features are not likely to be removed, but if they aren't there in the first place, are unlikely to be added by cheap hosters. I had difficulty getting PHP 8 added a year ago by a client's cheap hoster. They said they had no plans for it, and only when i asked if we would need to Seek hosting somewhere else, did they grudgingly install it in our shared environment. Only later did they install it where it was available in CPanel. And dropping Drupal ad a 1-click install sounds like the path of least resistance for them, if customers run into, and report any problems with using Drupal, that point to them needing to change hosting configuration and requirements.
I understand trying to keep core minimal and less stress/work to keep it maintained. Maybe if there is a default "Recipe" that can pull in all the basic contrib needed to create a workable website, one that can conditionally check hosting services, that would make entry level easier to start, while allowing many core modules to be removed to contrib.
Just a few thoughts.
1. Are you thinking that most sights will use AU? If not, then are the likely users less likely to be using local development to update and test, more likely to set and forget, assume that a core service will just work, and have more difficulty when it doesn't.
2. Should new users be presented with options that just work, instead of needing to immediately jump into the Drupal contrib system. Core Drupal allows a pretty good basic website, before venturing into contrib.
3. If cheap hosting doesn't have rsync, will they remove Drupal as a 1-click install option? I have seen cheap hosting with WP, but not Drupal. Since they are often very slow to update Drupal, this seems like a great opportunity to improve using Drupal in those circumstances.
4. Is there no other tool or method, besides trying to duplicate rsync in PHP, that would require less maintenance?
5. Are we improving the experience for those new to Drupal, or for those that don't even know what Drupal is, and are just trying it out of several options.
hestenet → credited Warped → .
It is nice to have a page of recommended versions of PHP and database versions, but historical information must also be available. Just because D8 and D9 are EOL doesn't mean the info isn't needed anymore. People are still getting old websites to update and are being wrongly informed that D8 can be changed to PHP 8.1 before upgrading to D9. To minimize the impact of changes, it is easier to upgrade D8 at PHP 7.4 to the latest of everything, then upgrade to D9.0.latest, then D9.1.latest, etc, until D9.5.latest at PHP 7.4 unless some module requires it. Junk hosting is notorious for not updating, and some have just provided PHP 8 versions, while others are still at PHP 7.4 and still running latest D9 versions. Upgrading D9 latest to PHP 8.1 is probably the best time, when all other problems have been solved, before possibly adding several more PHP issues. There is still a D7 PHP requirements page, probably because it is still supported, but there should still be a D8 and D9 page with complete information. As in when certain versions of PHP started being supported. Supplying this archival info will result in fewer questions in support channels as well as making it easier to point people to the correct information, instead of hopefully getting someone that actually knows, instead of misinformation.
Something that may create an issue with a few sites is LibreSSL, a fork of OpenSSL that removes older, insecure protocols, is lighter weight,and is preferred in some Linux distributions. Below is a link on configuring PHP7 for LibreSSL. IDK if it has gotten any easier in recent times.
Another problem to check is that certificate validation often doesn't check if it has been revoked.
https://stackoverflow.com/questions/43942717/build-php-7-using-libressl#...
hestenet → credited Warped → .
Chris McGrath → credited Warped → .
Chris McGrath → credited Warped → .
Chris McGrath → credited Warped → .
hotwebmatter → credited Warped → .
hotwebmatter → credited Warped → .
hotwebmatter → credited Warped → .