Sluggable: Doctrine Extensions

Hi!

Just an update - this should not be a problem anymore - we've been waiting for 2 new releases (from doctrine/extensions and stof-doctrine-extensions-bundle) and both have now been released. 🎉

Cheers!

This fails due to data fixtures when I try it.

Hey Aaron, could you tell me what error you got?

Hey Diego, sure here's the full composer output:

`./composer.json has been updated
Loading composer repositories with package information
Updating dependencies (including require-dev)
Restricting packages listed in "symfony/symfony" to "5.1.*"
Your requirements could not be resolved to an installable set of packages.

Problem 1

- doctrine/data-fixtures 1.4.4 requires doctrine/common ^2.13|^3.0 -> satisfiable by doctrine/common[2.13.0, 2.13.1, 2.13.2, 2.13.3, 2.13.x-dev, 3.0.0, 3.0.1, 3.0.2, 3.0.x-dev, 3.1.x-dev] but these conflict with your requirements or minimum-stability.
- doctrine/data-fixtures 1.4.4 requires doctrine/common ^2.13|^3.0 -> satisfiable by doctrine/common[2.13.0, 2.13.1, 2.13.2, 2.13.3, 2.13.x-dev, 3.0.0, 3.0.1, 3.0.2, 3.0.x-dev, 3.1.x-dev] but these conflict with your requirements or minimum-stability.
- doctrine/data-fixtures 1.4.4 requires doctrine/common ^2.13|^3.0 -> satisfiable by doctrine/common[2.13.0, 2.13.1, 2.13.2, 2.13.3, 2.13.x-dev, 3.0.0, 3.0.1, 3.0.2, 3.0.x-dev, 3.1.x-dev] but these conflict with your requirements or minimum-stability.
- Installation request for doctrine/data-fixtures (locked at 1.4.4) -> satisfiable by doctrine/data-fixtures[1.4.4].

Installation failed, reverting ./composer.json to its original content.
exit status 2`

Oh, I think you only have to update the "doctrine/data-fixtures" library and it should do the trick

I did composer update but data-fixtures didn't have any updates. Trying again resulted in the same error.

Hmm, interesting... have you tried this composer require doctrine/common --update-with-dependencies

Just got time to test this morning and it looks like the issue with the extensions bundle has been addressed.

those are excellent news! Let's keep rocking

Hi Marcus S.!

Yes, thanks for sharing! Doctrine recently released a few new major versions (doctrine/common 3 and doctrine/persistence 2) and it's temporarily wreaking a small bit of havoc on things :p.You described it very well and the solution.

Thanks!

Hey Leszek C.!

Hmm! I'm not sure this is easily possible. There is a system in this called slug handlers - https://github.com/doctrine-extensions/DoctrineExtensions/blob/main/doc/sluggable.md#slug-handlers - but i've never used them and I'm not sure if they will accomplish what you're looking for. But, it's worth a try. It looks like you need to:

A) make a class that implements SlugHandlerInterface: https://github.com/doctrine-extensions/DoctrineExtensions/blob/main/src/Sluggable/Handler/SlugHandlerInterface.php
B) Configure this on your slug field - https://github.com/doctrine-extensions/DoctrineExtensions/blob/main/doc/sluggable.md#slug-handlers
C) Finally, in your "slug handler" class, I think you need to do nothing in each method EXCEPT for onSlugCompletion. In this method, use the $object variable - which will be your entity object - and check $slugManual. If you do NOT want a slug generated, set the $slug argument to null. That argument is passed "by reference" so simply setting it to null will change that variable where it's used... and I think that it will cause the $slug to be set to null.

So... give it a try and let me know if it works!

Cheers!

Hey Jayant,

Did you try to the solution from the error message? I.e. try to run that command with --with-all-dependencies option:

$ composer require stof/doctrine-extensions-bundle --with-all-dependencies

This should help. Otherwise, requiring a lower version of stof/doctrine-extensions-bundle may help to, you can specify a specific version like this:

$ composer require "stof/doctrine-extensions-bundle:^1.5"

Btw, we use v1.5.0 in this course, so this should definitely work :)

Cheers!

Hey Sherri,

Yeah, the latest v1.6.0 of the bundle requires Symfony 5.2, but you can install the previous one v1.5.0 instead that fits for ^5.0. You can do it:

$ composer require "stof/doctrine-extensions-bundle:^1.5.0"

Cheers!

Hey Monoranjan,

Yeah, that's because your Symfony version is 5.1... you should upgrade it to 5.2 first and then you should be able to install that latest 1.6 version of stof/doctrine-extensions-bundle . For Symfony 5.1 you can only install v1.5.0 of stof/doctrine-extensions-bundle that allows ^5.0 for Symfony components, but if you want the latest v1.6 - the only way to install it - upgrade Symfony to 5.2. Thankfully, it should be a minor easy upgrade.

Cheers!

Hey Jorg,

Hm, looks like you have doctrine/orm installed that is locked on 2.8.3 and that requires to have doctrine/common 3.0.3 or higher. To install the doctrine/common:^2.7 you should either downgrade the doctrine/orm to ^2.7... or require "doctrine/common^2.8.3" at least that will fit doctrine/orm version you have installed.

I hope this helps!

Cheers!

Hello Victor,

yes help so that I have an new error :-D

Your requirements could not be resolved to an installable set of packages.
Problem 1
- Root composer.json requires stof/doctrine-extensions-bundle ^1.6 -> satisfiable by stof/doctrine-extensions-bundle[v1.6.0].
- stof/doctrine-extensions-bundle v1.6.0 requires symfony/config ^4.4 || ^5.2 -> found symfony/config[v4.4.0, ..., v4.4.20, v5.2.0, ..., v5.2.4] but these were not loaded, likely because it conflicts with another require.
Installation failed, reverting ./composer.json and ./composer.lock to their original content.

Hey Jorg,

Hm, could you tell me what command exactly do you run? :) Btw, what Symfony version do you have? Looks like the stof/doctrine-extensions-bundle^1.6 requires symfony/config ^4.4 || ^5.2 - if you have a lower version, you would probably need to upgrade symfony/config first.

I hope this helps!

Cheers!

composer require stof/doctrine-extensions-bundle --with-all-dependencies
Using version ^1.6 for stof/doctrine-extensions-bundle
./composer.json has been updated
Running composer update stof/doctrine-extensions-bundle --with-all-dependencies
Loading composer repositories with package information
Restricting packages listed in "symfony/symfony" to "5.1.*"
Updating dependencies
Your requirements could not be resolved to an installable set of packages.
Problem 1
- Root composer.json requires stof/doctrine-extensions-bundle ^1.6 -> satisfiable by stof/doctrine-extensions-bundle[v1.6.0].
- stof/doctrine-extensions-bundle v1.6.0 requires symfony/config ^4.4 || ^5.2 -> found symfony/config[v4.4.0, ..., v4.4.20, v5.2.0, ..., v5.2.4] but it conflicts with your root composer.json require (5.1.*).
Installation failed, reverting ./composer.json and ./composer.lock to their original content.

Hey Jörg daniel F.

I'm afraid that Victor is right and you'll have to upgrade Symfony5.1 to Symfony5.2 in order to install that bundle

Hi Folks,

i solved my problem with this site

https://symfony.com/doc/cur...

with this I make a Symfony upgrade to 5.2 and voila it works.

Thx @ all for your help

Wonderful!

Hey Will T.!

Hmmm. This definitely feels like the feature is simply not working at all. You mentioned that the stof_doctrine_extensions.yaml file was not added for you. This IS part of the recipe for this bundle - https://github.com/symfony/recipes-contrib/blob/master/stof/doctrine-extensions-bundle/1.2/config/packages/stof_doctrine_extensions.yaml

This make me think that the recipe did not execute. Possible reasons are that (A) you've disabled "contrib" recipes in your composer.json file - the extra.symfony.allow-contrib key - or (B) you answered "No" when it asked you if you wanted to install it or (C) you're not using Flex (or D, something weird just happened, that's always possible).

Anyways, good job adding the stof_doctrine_extensions.yaml file manually. But also check that the bundle is enabled inside of config/bundles.php. That is one other possible thing that's going wrong.

Overall, the process "should" be pretty simple:

A) The bundle must be enabled
B) If the sluggable behavior is enabled in your config file - https://symfonycasts.com/screencast/symfony-doctrine/sluggable#codeblock-82cb5aacdb - then the "SluggableListener" will be activated
C) Then, as long as you have the @Gedmo\Slug (which you do), then the magic will happen

If you were missing (A) or (B), then it would silently not work. Any other problems - like types in the annotation, etc - should result in a clear exception.

Let me know if you find out anything! Also, though it's rarely needed, when super weird things happen, you can try to run bin/console cache:clear.

Cheers!

Hey Ryan!

I fixed this myself after looking through the bundles.php directory.
I found that Stof\DoctrineExtensionsBundle\StofDoctrineExtensionsBundle::class => ['all' => true] was missing, so I added it.
Thanks for your thorough answer, though :)

Hey Will T.!

Nice debugging and I'm just glad you got it working :).

Cheers!

Hey Daniel K. !

Hmm, cool suggestion!

DoctrineExtension does a good job. I just think that the parameter converter needs some special tweeking that might be quite interesting!

Yes, I think you're right about this... and I think you would need a custom param converter to do the job. Well, you could add @ParamConverter annotations, but that's annoying ;). Well, actually, I would create a custom "argument resolver" - not a param converter, just because that whole system was written before the "argument resolver" system, which is now much easier. We talk about that topic in general in the deep dive course: https://symfonycasts.com/screencast/deep-dive/global-args#custom-argumentvalueresolver

Making an argument resolver work would be fairly easy - you could, for example, look specifically to see if there is a $request->attributes->get('slug') and, if there is, use $request->getLocale() and that value to query for the entity. The ArgumentMetadata $argument that's passed to your custom argument value resolver contains the type-hinted class name for each argument via ->getType(). You could use that in supports() to know if your argument resolver should operate on an argument (easiest way would be to have a list of classes you want to support, harder would be to check to see if the class is an entity in Doctrine or not) and then use it again in resolve to fetch the repository and make the query.

That's a quick answer to a not-so-easy task. If you're interested, let me know if you need more details :).

Cheers!

In the "resolve" part: you query for the object. What if there is none. e.g. "getOneOrNullResult" returns "null"?

How do you throw a 404?
if the resolver yields a "null" value a 500 server error is thrown, because the controller expects an instance of the entity
So would you throw a NotFoundHttpException right in the Argument Resolver?

Hey Daniel K.

Yes, as far as I know that's what you have to do to trigger a 404 page. It's something similar as when you type-hint for an entity argument in your controller's method, it will query it for you or throw a `NotFoundHttpException` which will trigger a 404 page

Cheers!

Thank you for this hint and the great idea! I tried it and it seems to me that the ParamConverter kicks in before the argumentValueResolver.So the "auto_convert" option of the param converter needs to be set to false. But of course i'd like to use it for other requests :)
Any thoughts on this?