Configuración del Proyecto y el Plan

Hey @Slawomir-B ,

If I understand you correctly, the system is trying to use different credentials from the ones that are written in the .env file, right? If so, there's a few more files that take precedence over the .env file, e.g. .env.local, or Symfony environment specific .env files. Please, double-check all the .env files in your project to make sure you don't override your default DB credentials from the .env file. You may also want to leverage the bin/console debug:dotenv Symfony command which will show you the env vars declared in your system with their values and in which order they are loaded.

Also, you may even want to double-check the same .env file, sometimes you may accidentally declare the same env var twice in that file and the latter definition will override the 1st one.

If still no luck, please, double check your configuration files in the config/ dir - there might be some config changes there that also override your DB config.

I hope that helps!

Cheers!

Yes, it has something to do with symfony cli because both serve and doctrine commands use root database. If I use php81 bin/console doctrine... and laragon it uses the symfony6_upgrade.

Hey Slawomir,

If you use symfony binary - the connection may be different indeed in case you also have some Docker setup. In short, you may want to use plain bin/console if you don't use Docker, or the reverse, it's recommended to use symfony console in case you use Docker, because it will use dynamic ports that Docker reveals.

Cheers!

I'm going to have to counter that with: I'm using docker and it goes to root with symfony cli anyway and works properly with bin/console.

Hey Slawomir,

It's great it works with bin/console for you. Actually, it should work for sure, but you need to specify correct credentials manually. While the symfony console will automatically detect and exposed ports, so it's still recommended to use symfony console especially if you're leveraging Docker. But if using bin/console is more familiar to you - that's a good way too, just keep in mind to set up correct credentials manually.

Cheers!

Hey Mepcuk,

You can see a minimum required PHP version in the composer.json, but you don't even need to download the course code to know it, you can look at the "Versions" tab on this page to know that the project requires PHP "^8.0.2" in this project, as also you can see a list of all dependencies in this course. So, in theory, any PHP version which matches that constraint should be good, i.e. 8.0.2+, 8.1, 8.2. But if you experience any problems with your current PHP version that should work but does not - let us know in the comments and our support team will help :)

P.s. I don't use mysql, Best practicies of Symfony use Postrgres. Why there are mysql? :)))))

You can use whatever you want, of course! :) You just need to configure the DATABASE_URL in your .env.local file, you can see an example of its configuration commented out in .env. Why? Well, it's the most straightforward and widely used DB, so it's easier for newcomers to start with it because many server solutions like XAMP, MAMP, etc usually provide it out of the box.

Cheers!

In which file should I make my changes?

Hey @Atikingbadota

@Ahaaje means you need to add that to your command like:

NODE_OPTIONS=--openssl-legacy-provider yarn watch

No need to edit any files :)

Cheers!

I did not change any file. I just ran the export command before I started yarn

Hey Ahaaje!

Yea, sorry about this! I believe the problem is that in Node 17, there were some BC breaks related to ssl options. Webpack fixed this in version 5.61.0 and babel-loader in 8.2.4, but I believe this course code uses version older than that. We've got a task on our TODO list to check into this and see if we can carefully upgrade the code just a little bit to avoid this problem. Your work around, of course, is also good!

Cheers!

Hey @Dan_M!

Ah, that's not the experience we want! I've recently learned the cause of this issue, and it's interesting and maddening! You're correct that SENTRY_DSN is not included in .env. And yes, if I download the code and run composer install, it works just fine for me :).

Why? Because SENTRY_DSN (this was done in an earlier tutorial) lives in the secrets vault. Anything in the secrets vault become env vars. So, why is this working for me and not for you? Because in order to read the secrets vault, your php install needs the Sodium extension - https://www.php.net/manual/en/sodium.installation.php - and my guess is that your php doesn't have this. What's maddening is that this should be installed by default in php since php 7.2. However, I've found some users with php 8 that don't have it - my guess is Ubuntu may ship with a stripped down version and you need to install it manually.

Anyways, this value isn't actually important for this tutorial. You can set SENTRY_DSN to an empty value in .env or run install the sodium php extension to get things working. I'm going to set SENTRY_DSN to an empty string in .env and update the code download just to avoid the issue for others. Oh, and if I'm TOTALLY wrong about the cause (Sodium), please tell me ;).

Cheers!

Hey @weaverryan!

I am developing on a Windows machine, and when I installed php 7.4, I did not enable the sodium extension in the php.ini file. When I did that, the code worked as expected.

Thanks!

Hey Noel H.

Unfortunately I'm not Ryan but from my point of view I have some advices. First you need to check all your 19 bundles if they can be updated to use with Symfony 6+. Of course I'll recommend to use hybrid upgrade strategy, manually upgrading with wise applying Rector rules. Also it will be awesome if you have good test coverage. Anyways it will be better to have upgrade flow 3.4 -> 4.4 -> 5.4 -> 6.1 and then to keep all up to date I suggest to use 6/12 months upgrade periods.

Chers!

Thanks sadikoff for your response. I will take your advice into consideration.

You are welcome! I just had same situation several times, and even one upgrade from Symfony 2, but there was no rector at that time

Cheers!

Hey David P.!

Yea, this is our bad. The code DOES work in PHP 8, but you have to trick Composer (due to some dependencies being so old) with:

composer install --ignore-platform-reqs

I've just updated our setup README to show this.

Cheers!

Hey David P.

Thanks for reporting it. The first part of this tutorial is not compatible with PHP 8 until the part when it gets upgraded to Symfony 5.4

If you really want to make it work with PHP 8 you'll need to make a few changes to the composer.json. Change all the Symfony libraries constraints "5.0." to "5.2. (including the config extra.symfony.require), then run composer up

I hope it helps. Cheers!