Fixed Possible bug issue in message_macros (itemprop="name" appears twice)

Affected version
2.2.5

ForumGeek

Member
Hi,

I just updated one of our forums to 2.2.5 and did a standard W3C Validator check afterwards this which reported an error message concerning the message_macros template:

The corresponding code line is
Code:
<div class="message-userDetails">
<h4 class="message-name"><xf:username user="$user" rich="true" defaultname="{$fallbackName}" itemprop="name" /></h4>

If I have a look at the source code rendered by this in the browser I see
HTML:
<div class="message-userDetails">
<h4 class="message-name"><a href="/members/someuser.123/" class="username " dir="auto" itemprop="name" data-user-id="123" data-xf-init="member-tooltip" itemprop="name">SomeUser</a></h4>

Note that itemprop="name" appears twice in the <a> tag which is also the error message of the W3C validator.
 

smozgur

Active member
Same here.

fnUsernameLink() function in Templater.php returns itemprop attribute as hardcoded, so the template probably shouldn't have that.
 

XF Bug Bot

XenForo bug fixer bot
Staff member
Thank you for reporting this issue, it has now been resolved. We are aiming to include any changes that have been made in a future XF release (2.2.6).

Change log:
Remove duplicate itemprop attribute on a post's username link
There may be a delay before changes are rolled out to the XenForo Community.
 

pegasus

Well-known member
This should be reopened, as there are still problems with this in 2.2.7.

The appropriate fix is to have itemprop="name" in the template, and remove the hardcoded itemprop="name" from fnUsernameLink(). (The "fix" did the opposite). The reason is that fnUsernameLink() may sometimes be used in a context that is not in an itemscope, and if so, the current design results in an orphaned itemprop="name", or one that gets added to an unexpected parent.

The itemprop should only be added if it's needed. In the message_macros it's needed, so it should be added explicitly by message_macros. In other contexts it's not needed, so fnUsernameLink() should not include it by default.
 
Top