Desarrollo Armonioso con Symfony 6

no one can ;) stay tuned!

Hey Ruslan!

Thank you for your interest in SymfonyCasts tutorials! We don't have any certain plans to cover Codeception in the nearest future unfortunately, but I add this topic to ours idea pool, thanks! Also, we're planning to brush up our tutorials about testing, i.e. PHPUnit, PhpSpec and Behat - most probably it will happen in 2022, but no any possible release date yet too. Meanwhile, in case you're interested in Testing tools, I'd recommend you to take a look at Testing track: https://symfonycasts.com/tr...

Cheers!

Thank you.
But if you will update "Testing tutorials", don't forget about Stimulus too, please.

Hey @Ruslan!

We’re definitely planning by on a big testing update - we need it!

About Stimulus - no update is needed there. Stimulus 3 is out, but other than a renamed package name and a few minor features, it is identical to v2. But if the tutorial is not making this fact obvious enough, please let me know!

Cheers!

I mean tests for App with Stimulus.

We will definitely be talking about that in those tutorials :)

Hey Yangzhi,

Yes, you can override templates in third-party bundles, please take a look at Symfony docs: https://symfony.com/doc/current/bundles/override.html#templates - you just need to create a correct path in a specific dir that will match the path of the template from the 3rd-party bundle you want to override.

Cheers!

Hey Azahari,

Well done! Thank you for your kind words about this course :) We're actively working on a new Symfony 7 intro course, it will be available shortly, stay tuned ;)

Cheers!

Yo pasquale_pellicani!

The simple answer: yes! The longer answer: yes, but based on some things, you may want to make some changes.

SO, on a high level, unlike older versions, Symfony almost never cares about your directory structure anymore. For example, a command is not a command because it lives in the src/Controller/ directory / App\Controller\ namespace. You can put a controller anywhere, because it's the autowiring + autoregistration that tells Symfony this is a command. So, from a namespacing perspective, if you have a bunch of different namespaces for different bundles inside of your src/ directory, instead of App\, Symfony won't care at all. Probably the biggest difference (I'm guessing) is that a modern app will use service auto-registration. So your bundles will all need to explicitly wire the services, while a newer app won't. So, if you were creating a Controller, it can live anywhere, but you would need to manually register it as a service and give it the tag (which, again I'm guessing, you have been doing all along on that app).

The complication happens if you want to start using service auto-registration (and you weren't previously using it) and you want to have the same directory structure as a modern Symfony app. Then you DO need to make changes. But these are both optional things.

Anyway, I talked a lot about this in this tutorial - https://symfonycasts.com/screencast/symfony4-upgrade - including the (rather big) steps to take if you DO want to fully upgrade your app and make it look like a modern app. But, again that's up to you :). One potentially important point is this: when we changed the directory structure & added service autowiring & autoregistration, we didn't actually remove any code or any functionality. If you previously had an app full of bundles... whne going from symfony 3 -> symfony 4, that all kept working exactly like before.

If you do decide to update, you can always ask questions here :).

Cheers!

Hi @Juan-S!

Apologies for my uncharacteristically SUPER slow reply. Busy time of year!

I've been developing on Symfoni for three months, and your tutorials have been a great help

Fantastic! Welcome to the community :)

However, now I am working on setting up user sessions and I am stuck on how to send a message to the user when the session is about to expire, and how to manage a maximum number of sessions per user.

Hmm. Typically, a session will "stay alive" as long as the user is active - e.g. if they continue to refresh the page, the session will stay alive forever. But, my guess is that you are setting a session.gc_maxlifetime to some finite value? Is it critical that the user is logged out right at 30 minutes of inactivity (using 30 minutes as an example)? Or are you just trying to give them a warning to be nice?

and how to manage a maximum number of sessions per user

This is also interesting. First, you'll definitely want to store sessions in the database. Then, I might create a UserSession table to track the relationship - it would have a ManyToOne to User and... perhaps a sessionId string column. To be honest, I'm struggling a bit because PHP sessions can be a bit of a pain to work with manually in this way. Ideally, you'd store your sessions in the database via a Session entity (an uncommon thing, but I believe I've seen people do it). Then it would be easy to have a UserSession entity that links to User and Session.

Anyway, I'm rambling a bit and not being particularly helpful. If you've made some progress but have more questions or problems, let me know and I'll do my best to help. And hopefully faster than 19 days later ;).

Cheers!

Hola @JesusCH

Nos da gusto saber que te ha sido util nuestro tutorial

Saludos!

Hey Anthony,

Yeah, code evolves a lot during the time that leads to new features and updates, i.e. led to continuous maintenance of the project. Well, I'm not aware of WordPress policy too much, but I probably may shed some light on Symfony's development process.

Well, first of all, except Symfony you most probably will have other third-party dependencies, i.e. packages that evolve on their own... I suppose in WordPress it's the same thing, even if we will consider additional plugins that might be installed in your project and also do some updates. So, if we will set aside those 3rd-party libs and focus only on Symfony - here's what we have.

Symfony has a so-called backward compatibility (BC) promise - you can learn more about it here: https://symfony.com/doc/current/contributing/code/bc.html - mostly it means that BC breaks may happen only during the major Symfony upgrades, e.g. from Symfony 5 -> Symfony 6. If you just want to upgrade a minor version, e.g. from Symfony 5.2 -> 5.4 - there should not be any BC breaks and your project should work well after the upgrade without any required changes. Well, in practice, it may not be 100% true, but it mostly depends on how well you're writing your code, or if you're using experimental components or not. So, such minor version updates will bring you new features as also some security fixes, etc, but they should not break your code base in theory.

Now about the Symfony roadmap (schedule of releases) - you can see more here: https://symfony.com/releases . As you can see Symfony has LTS (Long-Term Support) Release which means you don't have to update your major version if you don't want (don't need new features they may give you) and still get those important bugs and security fixes. LTS versions live for 3 years of maintenance + 1 extra year of only security fixes. If you have a big and complex project and don't want to upgrade it too often because it's time-consuming for you or just because you don't need those new features - stick to the LTS version :) The new LTS version is created every 2 years as you can see from the schedule.

So, that's basically it, that's how Symfony works, and that's what its release schedule and promises. Mostly, it's a similar process to the Ubuntu release cycle if you're aware of it. But it's up to you to decide if that fits your needs or not and how much load it will put on you to maintain it.

I hope this helps! :)

Cheers!

Hello @Yukako,

Do you have twig installed? and normal template for testing?

Cheers!

Hey Miracle,

Thank you for your feedback! We're happy to hear you liked it :) See more Symfony 6 related courses in this track: https://symfonycasts.com/tracks/symfony

Cheers!

Hey @Anthony-E!

Sorry for the slow reply! It's something I'd like to do too - I'll add a vote for it on our internal tracker. If you'd like to see an example of a site deployed with platform.sh, you can see https://github.com/symfony/ux/tree/2.x/ux.symfony.com

Cheers!

Woo! Keep up the good work 💪

Hey Tom O. !

Ah, I think I understand. By "sub form", you are referring to the AnimalNameType and other Animal###Type classes, right? If you want to pass options into those, you need to do it manually via the 3rd argument to ->add() For example. Suppose that you need to pass the units option into a sub-form:

public function buildForm(FormBuilderInterface $builder, array $options): void
{
    if ($options['form_1'] === true) {
        $builder->add(
            'name',
            AnimalNameType::class,
            ['units' => $options['units']]
        );
    }

    // ...
}

Of course, you'll need to make sure that AnimalNameType allows a units option in its configureOptions() method, but it sounds like you already have that.

Is that what you were referring to? If I completely missed the point, let me know :).

Cheers!