Skip to content
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

Rename drowl-init(-from-existing) into drowl-dev-init(-from-existing) and document its purpose #121

Closed
JPustkuchen opened this issue Feb 10, 2023 · 2 comments
Labels
plan A general plan

Comments

@JPustkuchen
Copy link
Member

JPustkuchen commented Feb 10, 2023

Problem:

Having a running online project which you'd like to copy and run locally, you may think drowl-init... is the right choice for a 1:1 copy, but it's not and it's not simply possible.

We have to make this clear and should try to find a solution as simple as possible for this requirement, while it may be technically hard without the user knowing what he's doing. In some parts it's even impossible.

Proposed solution:

1.) Be clearer
The most important point in this issue is to ensure the user clearly knows what happens (before he's doing it)!

To be more clear in naming, we should add a "dev" into drowl-init => drowl-dev-init to be more self-explaning.

Furthermore, we should document, that it's a modified environment focused on development and debugging purpose. Not a live copy!
To point that out, we should also show a short (yellow) information about this, when executing the command and let the user confirm that. He has to know that once imported, the result can not simply be put online again, as things changed irriversibly.

2.) Provide an alternative for a simple copy
Still one may need an environment that reflects the prod environment 1:1, but while that sounds easy, there are very difficult points which can't be automated that simple in all aspects.

Things like:

  • Online settings.php (with real DB credentials!) which can't be used local and may never be changed. It may contain important secrets for the functionality. But if we add a local.settings.php file, this would mean, we're also changing the project!
  • Different Drupal CMS configurations, folder structure, vhost, ... can't be simply assumed like in our environment. This may include folders which are outside of the regular structures (private files)
  • Proxying files and such things can't be done, as we'd need a custom module and that would also change the installation!
  • ...
    so, it's NOT trivial!

We first need a clear plan and concept here, before changing the implementation in large parts!
Things should be clear and easy from the end-user perspective.

And we have to decide, what's worth it, based on regular usage! Things evolve fast... and time is the currency.

@JPustkuchen JPustkuchen added the plan A general plan label Feb 10, 2023
@joshsedl
Copy link
Collaborator

I am unsure about the renaming here, as the main purpose for this repo is, to provide a Drupal development container.
From the README:

Spin up a ready-to-code Drupal 10 CMS DDEV based development container [...]

Although I agree, that there should be coloured text warning the user about the development nature. At least for drowl-init-from-existing. We could also add the warning for "drowl-init", but not as a confirmable prompt, as it would slow down the initialization process.

If at some point, we have time to realize "2.)", we can think about the renaimng of the commands, adjusting the README and anything else. But until then, I will only realize the colorized prompting for now.

@joshsedl
Copy link
Collaborator

Alright. Overhauled the drowl-init-from-existing command.

Closing this issue in favour of #124

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
plan A general plan
Projects
None yet
Development

No branches or pull requests

2 participants