You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
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:
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.
The text was updated successfully, but these errors were encountered: