<p>I did a little digging in the source, and here's what's going on:</p>

<p>When Craft builds an element index, it pulls all available element attributes from the <a href="https://craftcms.com/classreference/services/ElementIndexesService" rel="nofollow">ElementIndexesService</a>, where the method <a href="https://github.com/pixelandtonic/Craft-Release/blob/master/app/services/ElementIndexesService.php#L250" rel="nofollow"><code>getAvailableTableAttributes</code></a> adds all custom fields to the available attributes, with keys <code>'field:'.$field-&gt;id</code>.</p>

<p>The ElementIndexesService class was <a href="https://github.com/pixelandtonic/Craft-Release/commits/master/app/services/ElementIndexesService.php" rel="nofollow">added in Craft 2.5.2750</a>, when a lot of things changed related to element indexes (this is when the <a href="https://pixelandtonic.com/blog/craft-2.5-beta" rel="nofollow">Customizable Element Indexes</a> feature was added).</p>

<p>Before 2.5, things worked differently – custom attributes weren't "pre-fetched" by Craft, but had to be added manually using the <code>modifyEntryTableAttributes</code> hook, where the <code>$attribute</code> variable passed to <code>getEntryTableAttributeHtml</code> would be a custom field handle, not the current <code>field:{fieldId}</code> value.</p>

<p>It's unfortunate that <a href="https://craftcms.com/docs/plugins/hooks-reference#getEntryTableAttributeHtml" rel="nofollow">the official docs</a> for <code>getEntryTableAttributeHtml</code> appear to not having been updated since Craft 2.4, as its current example code won't actually work (for custom fields) since 2.5.</p>

<p>Either way, here's a workaround which should make things a little bit easier in customizing the HTML for custom field attributes:</p>

<pre><code>public function getEntryTableAttributeHtml(EntryModel $entry, $attribute)
{

    // If custom field, get field handle
    if (strncmp($attribute, 'field:', 6) === 0)
    {
        $fieldId = substr($attribute, 6);
        $field = craft()-&gt;fields-&gt;getFieldById($fieldId);
        $attribute = $field-&gt;handle;
    }

    // Get html by attribute (field handle)
    switch ($attribute)
    {
        case 'customFieldHandle' :
            return '&lt;span&gt;'.$entry-&gt;$attribute.'&lt;/span&gt;';
            break;
    }

}
</code></pre>

CC BY-SA 3.0
2016-03-14T18:38:27.550Z
Is this working as documented in Craft CMS 2.6.2776?
a-am
CC BY-SA 3.0
2016-03-20T09:46:45.297Z
@aran Nope – neither the docs nor the relevant source code appears to have changed with 2.6.2776.
Mats Mikkel Rummelhoff
CC BY-SA 3.0
2016-03-12T13:37:01.313Z
2016-03-12T13:57:07.907Z
2016-03-12T13:57:07.907Z
Mats Mikkel Rummelhoff
<p>I have <code>getEntryTableAttributeHtml(EntryModel $entry, $attribute)</code> setup in my plugin file.  I have attributes defined in <code>defineAdditionalEntryTableAttributes()</code>.  However when the page loads <code>$attribute</code> returns <code>field:85</code> instead of one of the expected labels. Why might this occur?</p>

CC BY-SA 3.0
2016-03-11T22:13:49.637Z
I've been wondering about this, too. I believe it changed when the Customizable Element Indexes were introduced with 2.5, but [the docs](https://craftcms.com/docs/plugins/hooks-reference#getEntryTableAttributeHtml) don't mention it and still use the handle-based syntax in the example.
Mats Mikkel Rummelhoff
<plugin-development>
Why would getEntryTableAttributeHtml(EntryModel $entry, $attribute) not return proper labels?
# Why would getEntryTableAttributeHtml(EntryModel $entry, $attribute) not return proper labels?

(Asked by: username_0 on 2016-03-11)

I have `getEntryTableAttributeHtml(EntryModel $entry, $attribute)` setup in my plugin file. I have attributes defined in `defineAdditionalEntryTableAttributes()`. However when the page loads `$attribute` returns `field:85` instead of one of the expected labels. Why might this occur?

**Tags:** plugin-development
> **Comments:**
> **username_1**: I've been wondering about this, too. I believe it changed when the Customizable Element Indexes were introduced with 2.5, but [the docs](https://craftcms.com/docs/plugins/hooks-reference#getEntryTableAttributeHtml) don't mention it and still use the handle-based syntax in the example.  

---

## 1 answers

### Answer by username_1 on 2016-03-12. Score: 2 | Accepted answer

I did a little digging in the source, and here's what's going on:
When Craft builds an element index, it pulls all available element attributes from the ElementIndexesService, where the method getAvailableTableAttributes adds all custom fields to the available attributes, with keys 'field:'.$field->id.
The ElementIndexesService class was added in Craft 2.5.2750, when a lot of things changed related to element indexes (this is when the Customizable Element Indexes feature was added).
Before 2.5, things worked differently – custom attributes weren't "pre-fetched" by Craft, but had to be added manually using the modifyEntryTableAttributes hook, where the $attribute variable passed to getEntryTableAttributeHtml would be a custom field handle, not the current field:{fieldId} value.
It's unfortunate that the official docs for getEntryTableAttributeHtml appear to not having been updated since Craft 2.4, as its current example code won't actually work (for custom fields) since 2.5.
Either way, here's a workaround which should make things a little bit easier in customizing the HTML for custom field attributes:
public function getEntryTableAttributeHtml(EntryModel $entry, $attribute)
{

    // If custom field, get field handle
    if (strncmp($attribute, 'field:', 6) === 0)
    {
        $fieldId = substr($attribute, 6);
        $field = craft()->fields->getFieldById($fieldId);
        $attribute = $field->handle;
    }

    // Get html by attribute (field handle)
    switch ($attribute)
    {
        case 'customFieldHandle' :
            return ''.$entry->$attribute.'';
            break;
    }

}

> **Comments:**
> **username_0**: Is this working as documented in Craft CMS 2.6.2776?  
> **username_1**: @aran Nope – neither the docs nor the relevant source code appears to have changed with 2.6.2776.  

---

