Slugging service?

[Daniel Leech]

Hi,

In the BlogBundle I have created a PostUtil class with a single method,
slugify(), which I am now reusing in another bundle.

In both cases it is to generate change a Title into a URL slug for routing,
which would incidentally be solved by
https://github.com/symfony-cmf/RoutingExtraBundle/issues/68 and I guess
would be useful for that.

It seems to me that this is a pretty useful thing to have, especially
for routing, and that it should probably also be a service
(like https://github.com/FabienPennequin/FPNTagBundle/blob/master/Util/Slugifier.php)

Should this be in the CMF? Should it be in CoreBundle (or routing
component / bundle)? and what is the aim of core bundle anyways? at the moment
it could well be called PublishWorkflowBundle :)

Cheers

Dan

[David Buchmann]

hi,

> In the BlogBundle I have created a PostUtil class with a single method,
> slugify(), which I am now reusing in another bundle.
>
> In both cases it is to generate change a Title into a URL slug for routing,
> which would incidentally be solved by
> https://github.com/symfony-cmf/RoutingExtraBundle/issues/68 and I guess
> would be useful for that.

(see also my other email to this list about the work by sjopet)

> It seems to me that this is a pretty useful thing to have, especially
> for routing, and that it should probably also be a service
> (like https://github.com/FabienPennequin/FPNTagBundle/blob/master/Util/Slugifier.php)
>
> Should this be in the CMF? Should it be in CoreBundle (or routing
> component / bundle)? and what is the aim of core bundle anyways? at the moment
> it could well be called PublishWorkflowBundle :)

the core bundle was initially intended to contain things that are needed
by many different other bundles. as it turns out we seem to not need a
lot of that. if we can we should put things into the bundle they fit
most. for slugify that could be phpcr-odm or maybe we should start a
phpcr-odm-extra to not clutter up phpcr-odm with optional things too much.

cheers,david

[Ally Burns]

I've seen a few other Symfony bundles with bundles containing slugify e.g.

https://packagist.org/packages/deruwe/slugify-bundle

Which is really just a wrapper for:

https://github.com/cocur/slugify/blob/master/src/Cocur/Slugify/Slugify.php

I'm sure there was another bundle with a number of string tools including slugify. The others looks useful to a cms too.

What are peoples thoughts on a 3rd party for such things like slugify? Is it too basic a function to introduce more 3rd party bundles?

At what point do we think it's best to keep code "in house" o avoud introducing more requirements for a few lines of code?

Cheers,

Ally

[rmsint]

Hi,

The DoctrineExtensions bundle also has a slugify method:
https://github.com/l3pp4rd/DoctrineExtensions/blob/master/lib/Gedmo/Sluggable/Util/Urlizer.php#L261

Maybe this will also get support for PHPCR. For ORM projects I
experienced that this bundle (together with https://github.com/stof/StofDoctrineExtensionsBundle)
is almost always installed, and then the slugify tool is also
available.

Cheers,

Roel

On 17 feb, 18:14, Daniel Leech <dan...@dantleech.com> wrote:
> Hi,
>
> In the BlogBundle I have created a PostUtil class with a single method,
> slugify(), which I am now reusing in another bundle.
>
> In both cases it is to generate change a Title into a URL slug for routing,

> which would incidentally be solved byhttps://github.com/symfony-cmf/RoutingExtraBundle/issues/68and I guess

> would be useful for that.
>
> It seems to me that this is a pretty useful thing to have, especially
> for routing, and that it should probably also be a service

> (likehttps://github.com/FabienPennequin/FPNTagBundle/blob/master/Util/Slug...)

[Daniel Leech]

On Tue, Feb 19, 2013 at 06:40:42AM -0800, Ally Burns wrote:
> I've seen a few other Symfony bundles with bundles containing slugify e.g.
>
> https://packagist.org/packages/deruwe/slugify-bundle
>
> Which is really just a wrapper for:
> https://github.com/cocur/slugify/blob/master/src/Cocur/Slugify/Slugify.php
>
>
> I'm sure there was another bundle with a number of string tools including
> slugify. The others looks useful to a cms too.
>
> What are peoples thoughts on a 3rd party for such things like slugify? Is it
> too basic a function to introduce more 3rd party bundles?
>
> At what point do we think it's best to keep code "in house" o avoud introducing
> more requirements for a few lines of code?
>
> Cheers,
>
> Ally

I think one of the difficult things with a Urlizer/Slugifier is that
there seem to be lots of different ways of implementing it, and I'm not
sure all slugifiers support, for e.g., russian characters. So I think it
is important to allow the end-user to choose. Rather than assume that we
cover all the cases.

Another thing I notice is that at least one of the available slugifiers
removes words like "and, is, this" etc. which I wouldn't do, but it goes
to show that there are different needs.

In this PR I have added a SlugifierInterface and a CallbackSlugifier,
which effectively allows you to use any third party slugifier:

https://github.com/symfony-cmf/RoutingExtraBundle/pull/69

Probably not the ideal solution, or place for it to go.

>
>
>
>
>
>
>
>
>
>
> On Sunday, February 17, 2013 5:14:22 PM UTC, dantleech wrote:
>
> Hi,
>
> In the BlogBundle I have created a PostUtil class with a single method,
> slugify(), which I am now reusing in another bundle.
>
> In both cases it is to generate change a Title into a URL slug for routing,
> which would incidentally be solved by
> https://github.com/symfony-cmf/RoutingExtraBundle/issues/68 and I guess
> would be useful for that.
>
> It seems to me that this is a pretty useful thing to have, especially
> for routing, and that it should probably also be a service
> (like https://github.com/FabienPennequin/FPNTagBundle/blob/master/Util/
> Slugifier.php)
>
> Should this be in the CMF? Should it be in CoreBundle (or routing
> component / bundle)? and what is the aim of core bundle anyways? at the
> moment
> it could well be called PublishWorkflowBundle :)
>
> Cheers
>
> Dan
>

> --
> You received this message because you are subscribed to the Google Groups
> "symfony-cmf-devs" group.
> To unsubscribe from this group and stop receiving emails from it, send an email
> to symfony-cmf-de...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Lukas Smith]

On Feb 20, 2013, at 19:28 , Daniel Leech <dan...@dantleech.com> wrote:

> On Tue, Feb 19, 2013 at 06:40:42AM -0800, Ally Burns wrote:
>> I've seen a few other Symfony bundles with bundles containing slugify e.g.
>>
>> https://packagist.org/packages/deruwe/slugify-bundle
>>
>> Which is really just a wrapper for:
>> https://github.com/cocur/slugify/blob/master/src/Cocur/Slugify/Slugify.php
>>
>>
>> I'm sure there was another bundle with a number of string tools including
>> slugify. The others looks useful to a cms too.
>>
>> What are peoples thoughts on a 3rd party for such things like slugify? Is it
>> too basic a function to introduce more 3rd party bundles?
>>
>> At what point do we think it's best to keep code "in house" o avoud introducing
>> more requirements for a few lines of code?
>>
>> Cheers,
>>
>> Ally
>
> I think one of the difficult things with a Urlizer/Slugifier is that
> there seem to be lots of different ways of implementing it, and I'm not
> sure all slugifiers support, for e.g., russian characters. So I think it
> is important to allow the end-user to choose. Rather than assume that we
> cover all the cases.
>
> Another thing I notice is that at least one of the available slugifiers
> removes words like "and, is, this" etc. which I wouldn't do, but it goes
> to show that there are different needs.

agreed.

> In this PR I have added a SlugifierInterface and a CallbackSlugifier,
> which effectively allows you to use any third party slugifier:
>
> https://github.com/symfony-cmf/RoutingExtraBundle/pull/69
>
> Probably not the ideal solution, or place for it to go.

it seems like there is a general need for this. now the question is where to put this code.
i would generally lean more towards putting it into the CoreBundle. i guess the functionality you are working on is quite dependent on PHPCR, which means there is a high probability that people that want this functionality will be fine with also adding CoreBundle.

regards,
Lukas

[Daniel Leech]

Hi,

Just to update, the SlugifierInterface and a CallbackSlugifier
implementation have been added to CoreBundle some time ago.

https://github.com/symfony-cmf/CoreBundle/tree/master/Slugifier

And I have knocked together a very quick branch for a PSR standard
on a SlugifierInterface, I havn't made the PR yet as I have done it
very quickly:

https://github.com/dantleech/fig-standards/blob/slugifier/proposed/slugifier.md

All comments and fixes welcome :)

[David Buchmann]

thanks for the update.

> Just to update, the SlugifierInterface and a CallbackSlugifier
> implementation have been added to CoreBundle some time ago.
>
> https://github.com/symfony-cmf/CoreBundle/tree/master/Slugifier

what would you think of adding a straightforward slugifier
implementation as well, as with the callback you still need to implement
the actual slugify?
i found this recently (see first reply, which claims to come from jobeet
which was the symfony 1 tutorial :-)
http://stackoverflow.com/questions/2955251/php-function-to-make-slug-url-string

> And I have knocked together a very quick branch for a PSR standard
> on a SlugifierInterface, I havn't made the PR yet as I have done it
> very quickly:
>
> https://github.com/dantleech/fig-standards/blob/slugifier/proposed/slugifier.md

great, like it.

maybe it would make sense to explain the word "slug" already in the
second sentence, in addition to the definition below. like
"The goal is to provide a simple common interface for classes which
produce a an URL-save string (*slug*) out of any string. Such classes
are commonly known as slugifiers or urlizers."

one question about edge cases? what to return on empty string? empty
string is ok right? in any other cases, is an empty string ok? what
happens on slugify " " or " "? would this need to at least lead to one
character? are "/" in a slug allowed? we might mention them and require
the implementor to clearly state if he does that or not... and what
happens with "/" in the source string?

btw, the link to RFC1738 seems broken.

cheers,david

[Daniel Leech]

On Thu, Mar 21, 2013 at 01:42:30PM +0100, David Buchmann wrote:
> thanks for the update.
>
> > Just to update, the SlugifierInterface and a CallbackSlugifier
> > implementation have been added to CoreBundle some time ago.
> >
> > https://github.com/symfony-cmf/CoreBundle/tree/master/Slugifier
>
> what would you think of adding a straightforward slugifier
> implementation as well, as with the callback you still need to implement
> the actual slugify?
> i found this recently (see first reply, which claims to come from jobeet
> which was the symfony 1 tutorial :-)
> http://stackoverflow.com/questions/2955251/php-function-to-make-slug-url-string

I guess we could. In the auto-route bundle I am currently using a third
-party library, which was basically the first one I found on packagist :)
So it might be nice to contain it in the CMF - but then again there are
lots of implementations out there, why reinvent the wheel? And then
again we could just provide a really basic one to cut down on
dependencies...

>
> > And I have knocked together a very quick branch for a PSR standard
> > on a SlugifierInterface, I havn't made the PR yet as I have done it
> > very quickly:
> >
> > https://github.com/dantleech/fig-standards/blob/slugifier/proposed/slugifier.md
>
> great, like it.
>
> maybe it would make sense to explain the word "slug" already in the
> second sentence, in addition to the definition below. like
> "The goal is to provide a simple common interface for classes which
> produce a an URL-save string (*slug*) out of any string. Such classes
> are commonly known as slugifiers or urlizers."
>
> one question about edge cases? what to return on empty string? empty
> string is ok right? in any other cases, is an empty string ok? what
> happens on slugify " " or " "? would this need to at least lead to one
> character? are "/" in a slug allowed? we might mention them and require
> the implementor to clearly state if he does that or not... and what
> happens with "/" in the source string?
>
> btw, the link to RFC1738 seems broken.
>
> cheers,david
>

Have now made the PR:

https://github.com/php-fig/fig-standards/pull/100

I changed the wording to say that there should not be ANY restrictions
on the source string and that it is OK to return empty strings (but the
return value must be a string, i.e. not a boolean), and that characters
should not assume any special meaning.

The link worked for me ..

[David Buchmann]

> Have now made the PR:
>
> https://github.com/php-fig/fig-standards/pull/100

awesome, lets see what happens :-)

> I changed the wording to say that there should not be ANY restrictions
> on the source string and that it is OK to return empty strings (but the
> return value must be a string, i.e. not a boolean), and that characters
> should not assume any special meaning.

ok. i wonder if we should not say the oposite, that is even if an empty
string is passed in, something must come back, for example noname or a
random hash :-)

> In the auto-route bundle I am currently using a third
> -party library, which was basically the first one I found on packagist :)
> So it might be nice to contain it in the CMF - but then again there are
> lots of implementations out there, why reinvent the wheel? And then
> again we could just provide a really basic one to cut down on
> dependencies...

if this really gets accepted as a Psr standard, then i think we should
try to make existing slugifier libraries adopt the psr interfaces, if
there are any that don't have additional unneeded code. apart from that
i would suggest to move our things to a stand-alone component
Symfony\Cmf\Component\Slugifier that can be used without any other code.

cheers,david
--
Liip AG // Agile Web Development // T +41 26 422 25 11
CH-1700 Fribourg // PGP 0xA581808B // www.liip.ch