search

helhum / TYPO3-Distribution

A distribution package for TYPO3 CMS with added typo3_console support
81 stars 19 forks source link

README #18

Closed infabo closed 6 years ago

infabo commented 6 years ago

Hi,

how does the new release 8.3.0 work? Seems like there are database user/password hardcoded somewhere, because on composer create-project they are not prompted on the CLI wizard (In the install.settings.yaml I only found admin/password for backend).

best regards, ingo

helhum commented 6 years ago

The database credentials are not hardcoded. The only thing that changed here is that the environment variables are taken into account TYPO3_INSTALL_DB_USER, TYPO3_INSTALL_DB_PASSWORD ...

How exactly did you test?

infabo commented 6 years ago

tried to migrate my distribution based on 8.2.1 to 8.3.0 - but did fail on the install step (though I removed any .env files). So, when you say nothing big changed - going to give it a fresh try soon.

infabo commented 6 years ago

OK, got it working by now. But the setup changed a lot it seems. LocalConfiguration.php is not dynamically anymore on DEV-context. Setting up a local dev is a pain, because even when all variables in .env are set, the auto-setup insists on a "empty" database. or the autosetup wizard gets into a infinite loop on e.g. Check environment and create folders, when there are symlinked upload folder and/or fileadmin. etc. The new typo3 console wizard has some glitches it seems.

helhum commented 6 years ago

OK, got it working by now

What exactly is working? Do you use exactly this repo without modifications? If you have modifications, where can I have a look at those?

But the setup changed a lot it seems.

That is true.

LocalConfiguration.php is not dynamically anymore on DEV-context

What do you mean by that? The following works as expected for me:

composer create-project helhum/typo3-distribution

The result is a set up TYPO3 instance with configuration values populated from conf/* files.

Setting up a local dev is a pain, because even when all variables in .env are set, the auto-setup insists on a "empty" database.

Since this distribution changed to not pull in env vars any more, it seems you have your own distribution where this happens. Without knowing how exactly this distribution looks like, I cannot help much. Can you put it somewhere in a public repo so I can have a look?

or the autosetup wizard gets into a infinite loop on e.g. Check environment and create folders, when there are symlinked upload folder and/or fileadmin. etc.

Here again. It would be helpful to see what exact code you have and the error messages resulting from that as well.

The new typo3 console wizard has some glitches it seems

It may be that there are glitches. It might be though, that there is documentation missing, thus you have expectations on how things should work, which do not match how it actually works.

Here it would be helpful to also see what exactly you are trying, how your expectations are and what the result actually is.

infabo commented 6 years ago

Is local.settings.yaml a mandatory file - even in development context?

edit: Oh yes, seems so - as DB-settings are not pulled dynamically from ENV-variables anymore?

infabo commented 6 years ago

It may be that there are glitches. It might be though, that there is documentation missing, thus you have expectations on how things should work, which do not match how it actually works.

This may be the case. But without proper README, nobody will ever know.

helhum commented 6 years ago

To be clear with that: Thanks for trying out my work and for your time you put into this already. I'm always happy to see people using stuff I do.

However, judging from the issues you face and the questions you ask, this project here lacks some decent documentation. However writing that would consume quite some time, which I'm currently not able to contribute on a voluntary basis.

I invested a lot of time (roughly 2 weeks of work) for the conceptual work and the implementation (for the latest release only) and pushed everything out publicly for investigation and demonstration purposes.

I'm aware that using this work is harder without proper documentation, but this is the current state we all have to live with for now.

Nevertheless you have multiple options to overcome this limitation:

  1. Push the code your questions are related to into a public repository along with a step by step description of what you are doing (like suggested above), so that I don't waste time trying to figure out how things might look like on your end
  2. Sponsor me to write documentation for every bits an pieces of this distribution
  3. Hire me for 1on1 support or a workshop where we can go into all details
  4. Invest time to reverse engineer how things are supposed to work
  5. Abstain from using the latest version which you seem to have trouble with

I'm fine with any of these options. I'm looking forward hearing from you which one you choose. Thanks.

infabo commented 6 years ago

I'm fine with this too.

helhum commented 6 years ago

I'm fine with this too.

Fine with option 5? Or what exactly?

Please don't get me wrong. I'm really happy to help. But you need to allow me helping you, by providing more information about what you are trying to do (option 1)

helhum commented 6 years ago

In case you choose option 1, feel free to post the link to the repo here and I will have a look and re-open this ticket (or rather create new ones)

infabo commented 6 years ago

I'm fine with 1,2 and 4. ;)

I will try to push my setup into a public repo in github today. But it is really a 90% fork of your current 8.3.x. I just removed auto-install now and added a local.settings.yaml because there are no ENV variables anymore. Seems like, local.settings.yaml is only written on a FRESH clone of the distribution and is not generated on a existing setup. Now I have the "dynamic" AdditionalConfiguration and LocalConfiguration files back again.

helhum commented 6 years ago

I'm fine with 1,2 and 4.

Sounds great

But it is really a 90% fork

Sometimes the 10% matter ;)

I will try to push my setup into a public repo in github today

Looking forward to that

I just removed auto-install now and added a local.settings.yaml

That very likely is what causes the troubles you are seeing, because both are very much embedded into the current way everything works.

there are no ENV variables anymore

Yes. I removed that concept in favor of only having local.settings.yaml, with the idea to make it easier to use as now there is only one file, while there were two files (.env and conf/env.yml) before to adapt when using the "pull settings from environment" approach