Please vote - Should DDEV create the local.xml file?

[addison74]

DDEV is definitely a real, fast and efficient solution for anyone who wants to create a test/development environment based on Docker and PHPStorm. In Windows, WSL2 must be used, but for better performance, I recommend using a Linux distribution. Even in an Ubuntu 22.04 installed in a VM everything runs faster than in Windows 10 Pro + WSL.

I recently discovered an issue in DDEV and I reported it here ddev/ddev#4259. In short, when the ddev start command is run, if there is no /app/etc/local.xml file, DDEV will create one, but this will immediately cause a problem. The Backend is inaccessible because there is no admin account that is created during the installation process of OpenMage. I have identified two solutions, but there may be others (I am not an expert in Docker/DDEV).

If these two solutions are the only ones that solve the problem, then we should choose the first one, DDEV should not create the /app/etc/local.xml file. The author of DDEV agrees with the amendment proposed by me, but he wants to know the opinion of other people in the community. Therefore, please express your opinion in the survey below.

[colinmollenhour]

Ideally there would be two ways to start an environment: one with an existing user-supplied database and one that starts a fresh install.

For the fresh install this should use install.php, but this script has a lot of parameters so it is nice if the user doesn't have to populate these all by hand/memory.

If nothing else we could write a script like dev/ddev/init.sh which checks/assumes you have a running ddev environment and execs the install.php with some sane defaults.

[addison74]

From what I read in the documentation, DDEV offers the possibility to create our own commands to run in certain containers. I will check how it could be done concretely. For example, if a user finds that he cannot access the Backend, it is no longer necessary to delete the file to start the installation from scratch or to access the database, but to execute this command. It can also be useful if he forgets the password.

[fballiano]

I think the install should be manual

[sreichel]

Ideally there would be two ways to start an environment: one with an existing user-supplied database and one that starts a fresh install.

Note to myself ... test hooks https://github.com/drud/ddev-contrib/tree/master/hook-examples/import-db-if-empty

[addison74]

The goal is for the test environment to be created quickly in a few simple, easy-to-remember steps (ddev config/start/launch). The existence of the local.xml file as created by DDEV is good because we no longer go through the installation stage, accessing the Frontend will load the store immediately. To solve the issue related to the administrator account there would be several options:

• Hooks to the post-config to check if the admin_user table has no records (select count = 0) and if it is empty then add an admin account as simple as possible, for example admin:admin. It seems the best option because it will only be run in the configuration procedure, which is done only once. If we do not have the possibility to list the account information with the ddev describe command, then we will have to mention it in a README file.

• Custom commands that are added in .ddev/commands/db/command directory. Thus, a script can be run in the database container that adds a record in the admin_user table if the table is empty We can even reset the table if the password does not work. These commands must be mentioned in a README file.

If we agree on these solutions, we could propose PR's in the DDEV project. I am sure it could be solved by adding commands directly in DDEV or modifying the stages in the case of OpenMage, but I can't express my opinion because I don't know the Go programming language. What I showed above as possible solutions were identified by me after reading the documentation.

[addison74]

This issue is solved in the following PRs #3256 and #3248. There is no need to change the DDEV default behavior.

Unfortunately, the fist one more needs one more approval to be integrated.

[addison74]

I appreciate your help, the two commands are really useful and I say this from the position of someone who uses them periodically.

When I will get more free time I will present a tutorial about DDEV and OpenMage in Windows. Most likely it is only used by a few. As long as the advantages have not been shown, there is no way to be adopted. I discovered it based on the fact that Sven kept mentioning it in his posts and I discovered its real advantages, not only for OpenMage, but also with Magento 2, Typo3, Wordpress.

[colinmollenhour]

Agreed, no harm in merging. I think the change to ddev mysql will improve the compatibility for more users so will be happy to approve it after that is fixed (assuming it is correct).

[fballiano]

I tested ddev in the past but I prefer other environments, at least on mac :-) but hey, the world it's nice because it has many different colors ;-)

[fballiano]

@addison74 would you be able to check the "ddev mysql" thing, then we merge after that?

[addison74]

DDEV allows us to create commands to be run in containers. In the case of that command created by me, it will be executed in the web container. There is the cli mysql command available. It is not necessary to use ddev mysql which is wrong in my opinion. According to the documentation this command allows getting the MySQL prompt to enter commands as in the terminal. Only someone who has used DDEV so far will understand what I have created there. Sven proposed n98, I wanted not to depend on it. The command is useful precisely because ddev config command does not create an administrator account and this is where it comes to solve the issue. In addition, if you forgot the password, it can be reset to any desired size, because it no longer depends on OpenMage limitations. In the development environment I use short passwords of 3 - 4 characters, not 14 as minimum required by OpenMage.

[addison74]

Thank you all for your feedback. This PR solved the issue #3256.