Since Laravel 9 is requiring voku/portable-ascii:^2.0 and this repo is requiring voku/portable-ascii:^1.4 it causes a conflict when trying to update composer.

The verdict is out our cool feature was just too cool =)

They suggest we use classmap instead.

Included the URLify.php as a classmap for autoloader instead of psr-0.

If $language is not one for which there's a key in the $maps array, the $chars is not reset and the regular expression becomes longer and longer every time init() is called

I was rather sceptical at first not wanting to over complicate this simple class with namespace and 30 levels deep library/src/package folders I just bit my lip and tried:

        "autoload": {
                "psr-0": {
                        "": ""
                }
        }

and it worked =) so "" is PSR-0 capable and we have all the nyummy goodness of autoloading.

Added an INSTALL file to explain installation. Added bootstrap.php to strap the vendor/autoloader Added phpunit.xml Removed the require_once from the test

In test folder just run phpunit no arguments if bootstrap can't strap it will display the INSTALL file else the test will run as if no one cares.

Enjoy!

This change fixes a language exception that occurs when a character that is used as a regular expression delimiter ("/" by default) is included as a key in the array argument passed into the add_chars() method, and then downcode() is called.

Note that the existing tests do not cover this scenario.

Hi, I found a strange bug, look at the below code (local ENV: php 5.6 on mac os, dev-prod ENV: php 5.6 on ubuntu 16):

• var_dump(\URLify::filter('Text sample A')); // text-sample
• var_dump(\URLify::filter('Text sample B')); // text-sample-b
• var_dump(\URLify::filter('Text sample AA')); // text-sample-aa

Where is, in the first var_dump, the last "a" char?

Is this package still maintained?

Hi,

currently, the removal of words can only be influenced by setting the public static $remove_list property (as seen in #35).

When using URLify in multiple places in a project, this has to be multiple times which seems error-prone. Also, using the remove_list feature in some calls to URLify::filter while disabling it in other calls isn't possible currently.

This pull request adds an additional parameter to the URLify::filter() method to toggle the usage of the remove list feature.

Thx! :)

Hi there,

I've been trying to urlify a very simple string but the last part is being dropped. It's probably a wanted behaviour but it could be useful if there may be an option to avoid that.

My string is "Brazilian Série A" and I want it to become "brazilian-serie-a". It becomes "brazilian-serie" instead without the final "-a" part. Any way I can do this?

Below my code:

\URLify::filter('Brazilian Série A') // produces "brazilian-serie"

Tried also with:

\URLify::filter('Brazilian Série A', 120, 'en') // produces "brazilian-serie"

This is useful if languages have different rules for the same character. e.g. German: "ü"=>"ue" Turkish "ü" => "u"

reference: https://github.com/jbroadway/urlify/issues/51

Here I added "voku/portable-ascii" which is for example used in the "dev-master" version of laravel and it's also based on this project. :smile:

I know it's not that easy to pick a minimal php version to support, but most systems has already upgraded to > 7.0 (https://blog.packagist.com/php-versions-stats-2019-1-edition/) so maybe it's time to move forward?

Linux Distro | Version | End of Life | Default PHP -- | -- | -- | -- | Ubuntu | 14.04 (Trusty) | April 2019 (EOL) | 5.5.9 |   |   Ubuntu | 16.04 (Xenial) | April 2024 | 7.0 |   |   Ubuntu | 18.04 (Bionic) | April 2028 | 7.2 |   |   Debian | 8 (Jessie) | June 30, 2020 | 5.6.29 |   |   Debian | 9 (Stretch) | ~2022 | 7.0 |   |   Fedora | 29 | October 30, 2018 | 7.2.10 |   |   Fedora | 30 | April 30, 2019 | 7.3.4 |   |   OpenSUSE | Leap 15.1 | November 22, 2020 | 7.2.5 |   |   CentOS | 6 | November 30, 2020 | 5.3.3 |   |   CentOS | 7 | June 30, 2024 | 5.4.16 |   |   RHEL | 6 | November 30, 2020 | 5.3.3 |   |   RHEL | 7 | June 30, 2024 | 5.4.16 |   |   RHEL | 8 | May 2029 | 7.2 |   |   OEL | 6 | March 2021 | 7.0 (min) |   |   OEL | 7 | July 2024 | 7.0 (min) |   |  

PS: in my fork I also added different "stop-words" (https://github.com/voku/stop-words/tree/master/src/voku/helper/stopwords) for different languages and some other specials like support for currencies (https://github.com/voku/urlify/blob/master/src/voku/helper/URLify.php#L484). I don't know if this is also interesting for you?

This change is 

Consider the following:

URLify::add_chars(['/' => '']);

This causes a language exception, preg_match_all(): Unknown modifier ']', because the / character is used as the regular expression delimiter within the URLify library.

The above example derives from a fairly common and reasonable use-case: I want to remove all illegal characters from a file name, and on UNIX and Windows, / is illegal.

To fix this, PHP's preg_quote() function must be called on the keys in the array argument passed to add_chars().

I'll submit a PR shortly that seeks to fix the issue.

Upgrading from 1.2.3 to 1.2.4 broke our test suite, in particular some characters are transliterated differently, breaking assertions and semver.

E.g. we test that това е текст на бълрагски за тест becomes tova-e-tekst-na-blragski-za-test which is true in 1.2.3 and false in 1.2.4.

In 1.2.4 it instead transliterates to tova-e-tekst-na-bielragski-za-test.

| urlify version | in | out | |----------------|-----------|------------| | 1.2.3 | бълрагски | blragski | | 1.2.4 | бълрагски | bielragski |

I'm sure the dependency has its reasons for doing this, but composer pulled in 1.2.4 automatically and broke out test suites, this should have been a 1.3.0 or a 2.0.0 release.

Hi,

Why is $underscoreToSpace removed from the filter ? It was pretty handy to make underscores hypens of you wanted, or spaces ofcourse.

I hope there is a good reason for it!

Thanks

It will fix the issue when trimming a text:

From : -test- to test

With this option the "-" won't be removed.

By default it works as usual.

Had to add the following chars for our transliteration test to pass:

        URLify::add_chars(
            array(
                'Ÿ' => 'Y',
                'µ' => 'u',
                '¥' => 'Y',
                'Ĉ' => 'C',
                'ĉ' => 'c',
                'Ċ' => 'C',
                'ċ' => 'c',
                'Ĝ' => 'G',
                'ĝ' => 'g',
                'Ġ' => 'G',
                'ġ' => 'g',
                'Ĥ' => 'H',
                'ĥ' => 'h',
                'Ħ' => 'H',
                'ħ' => 'h',
                'Ĕ' => 'E',
                'ĕ' => 'e',
                'Ĭ' => 'I',
                'ĭ' => 'i',
                'Ĵ' => 'J',
                'ĵ' => 'j',
                'Ĺ' => 'L',
                'ĺ' => 'l',
                'Ľ' => 'L',
                'ľ' => 'l',
                'Ŀ' => 'L',
                'ŀ' => 'l',
                'ʼn' => 'n',
                'Ō' => 'O',
                'ō' => 'o',
                'Ŏ' => 'O',
                'ŏ' => 'o',
                'Ŕ' => 'R',
                'ŕ' => 'r',
                'Ŗ' => 'R',
                'ŗ' => 'r',
                'Ŝ' => 'S',
                'ŝ' => 's',
                'Ŧ' => 'T',
                'ŧ' => 't',
                'Ŭ' => 'U',
                'ŭ' => 'u',
                'Ŵ' => 'W',
                'ŵ' => 'w',
                'Ŷ' => 'Y',
                'ŷ' => 'y',
                'ſ' => 'i',
                'ƒ' => 'f',
                'O' => 'O',
                'o' => 'o',
                'U' => 'U',
                'u' => 'u',
                'Ǎ' => 'A',
                'ǎ' => 'a',
                'Ǐ' => 'I',
                'ǐ' => 'i',
                'Ǒ' => 'O',
                'ǒ' => 'o',
                'Ǔ' => 'U',
                'ǔ' => 'u',
                'Ǖ' => 'U',
                'ǖ' => 'u',
                'Ǘ' => 'U',
                'ǘ' => 'u',
                'Ǚ' => 'U',
                'ǚ' => 'u',
                'Ǜ' => 'U',
                'ǜ' => 'u',
                'Ǻ' => 'A',
                'ǻ' => 'a',
                'Ǿ' => 'O',
                'ǿ' => 'o',
                'Ǽ' => 'Ae',
                'ǽ' => 'ae',
                'IJ' => 'IJ',
                'ij' => 'ij',
                'J' => 'J',
                'ĸ' => 'k',
                'Ŋ' => 'N',
                'ŋ' => 'n',
                'Ẁ' => 'W',
                'ẁ' => 'w',
                'Ẃ' => 'W',
                'ẃ' => 'w',
                'Ẅ' => 'W',
                'ẅ' => 'w',
            )
        );

Unfortunately, since I do not know what language they belong to, I find it difficult to provide a PR when the code is structured based on language.