Spaces in usernames mean the username is not linked in the post [#2266187]

Hi,

I've been using at.js in the Harmony project default user at.js listener. I've noticed a small bug and thought it was more an at.js issue than a Harmony one.

In the attached screenshot only usernames without spaces are linked when viewing the post where a user has been tagged.

Cheers

Tom

Comment	File	Size	Author
#4	atjs-spaces_in_results-2266187-4-d7.patch	3.16 KB	imfaber
	at-js.JPG	68.49 KB	blacklabel_tom

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Comment #1

heylookalive CreditAttribution: heylookalive commented 3 June 2014 at 15:32

Hey Tom, good point! I'm open to suggestion on this one. I would say that it's recommended to not allow spaces in usernames.

I can't think of a simple and efficient way to account for spaces without having a list of usernames and checking against it.

Comment #2

blacklabel_tom CreditAttribution: blacklabel_tom commented 12 June 2014 at 16:03

Errrmmmm...... Yeah this is a tricky one.

I don't like the idea of limiting usernames to not have spaces in, it feels a bit wrong!

How does the text filter replace usernames with links currently? I'm assuming regexs?

Cheers

Tom

Comment #3

blacklabel_tom CreditAttribution: blacklabel_tom commented 8 October 2014 at 09:32

Hi Ali,

Thinking about this a bit more, would it be possible to when the post is save replace spaces with a stringlike [ATJS_USERNAME_SPACE] and then when the link is generated on the front end replace that string with spaces keeping the link?

This assumes that someone doesn't put [ATJS_USERNAME_SPACE] in their username though...

Cheers

Tom

Comment #4

imfaber CreditAttribution: imfaber at Edo commented 16 February 2016 at 11:09

Status:

Active

» Needs review

File	Size
atjs-spaces_in_results-2266187-4-d7.patch	3.16 KB

Hi guys,

I followed blacklabel_tom's suggestion but instead of using [ATJS_USERNAME_SPACE] I simply used the '+' sign which is an invalid character in usernames and in the regex pattern, thus I think we can assume it can be used and replaced safely.

If this is not the case I think we could expose an additional field to the listener settings page and let the user choose the sign to use.

In my proposed patch I also wrap the '+' with a span tag and inject some css to the WYSIWYG to display it like an actual space.

Please take a look and let me know your thoughts.

Cheers.
F

Comment #5

lukus

he/him

CreditAttribution: lukus commented 21 September 2016 at 12:43

I can confirm that the patch is working well for us.

Is there a chance this could be committed?

Thanks

Luke

Comment #6

heylookalive CreditAttribution: heylookalive at Cancer Research UK commented 21 September 2016 at 16:37

Hey all, at the moment this patch doesn't apply cleanly to 7.x-1.x dev. Work has also gone into whether or not spaces are allowed so you may want to re-test before trying to fix the patch.

I didn't carry out this work, the co-maintainer david hughes did. Will ping him.

Comment #7

david.hughes

he/him

English

CreditAttribution: david.hughes at Cancer Research UK commented 22 September 2016 at 11:11

Hey,

Sorry, I must have overlooked this issue when I was working on tackling this problem.

As of a few months ago, I'd put in a setting for At.js listeners to allow spaces - this would then wrap the insert template with square brackets so that the entity name can be clearly identified. This does come with the issue that names with the ']' character may not be matched properly (I'll check this later today). This could be addressed by making the square brackets editable, so different boundary defining characters can be used instead.

In hindsight, replacing the space with some other character is probably the preferred solution to this, however there are sites which use & rely on this square brackets fix, making migration a concern.