Skip to content

Bug with camelCase and all caps inputs. #39

@jacobrussell

Description

@jacobrussell

What is this feature about (expected vs actual behaviour)?

The camel case filter, in this used via a Craft CMS filter that I'm told (by the CMS developer) directly uses Stringy, appears to return unexpected results in the case of an all caps input. The CMS appears to provide no additional processing to Stringy's return, so it appears to be a transparent layer in this issue.

Input - 'FOO BAR'
Expected Output - 'fooBar'
Actual Output - 'fOOBAR'

I haven't been able to find a strict definition for how came case should behave when applied to an all caps source, but in testing with several web-based tools (found in a 'camel case text' google search) all return my expected output. Stringy (again via a Craft CMS filter) returns the output in 'Actual Output'.

How can I reproduce it?

Add a case to your test suite with an all caps input.

Does it take minutes, hours or days to fix?

Probably minutes, easy answer would be to push all letters to lower case before camel casing (this was the workaround I used in my implementation).

Any additional information?

I could be wrong about the 'correct' implementation of camel case, but anecdotal evidence makes me believe I'm not.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions