Field Key's and Database Comment Feeds
Submitted Ryan Ashbrook, Jul 03 2012 05:54 PM | Last updated Aug 23 2012 02:41 PM
This is a specific circumstance, however I wonder if we can't handle this a bit better?
The problem is... if you create a field for a custom database, and assign it a Field Key of "content." Then, create a Feed Block, and select Comments as the Content Type for that specific database, then an issue can appear where $r['content'] for the Feed is actually replaced with the parent records field of the same key. This is because of this code here:
$r[ $fields[ $matches[1] ]['field_key'] ] = $r[ $k . '_value' ]; assigns a new member of the array using the Field Key. if that key happens to be "content" (which is set earlier in the code), then the variable set earlier will display the field value, rather than the actual comment content. I'm pretty certain this can also happen with any fields that have a key of url or date as well, considering those are also set prior to record fields being added.
I'm not... overly sure on how this can be handled, short of one of the following:
1. We change the above to something like this:
So as to avoid conflicts with array keys... I can't think of many instances where Record Fields are used within a Comments Feed block, so... this may work?
2. We simply skip over any Record Fields that have a key of content, date, or url, and not add them to the $r array.
The problem is... if you create a field for a custom database, and assign it a Field Key of "content." Then, create a Feed Block, and select Comments as the Content Type for that specific database, then an issue can appear where $r['content'] for the Feed is actually replaced with the parent records field of the same key. This is because of this code here:
foreach( $r as $k => $v )
{
if( preg_match( "/^field_(\d+)$/", $k, $matches ) )
{
$r[ $k . '_value' ] = $fieldsClass->getFieldValue( $fields[ $matches[1] ], $r, $fields[ $matches[1] ]['field_truncate'] );
$r[ $fields[ $matches[1] ]['field_key'] ] = $r[ $k . '_value' ];
}
}$r[ $fields[ $matches[1] ]['field_key'] ] = $r[ $k . '_value' ]; assigns a new member of the array using the Field Key. if that key happens to be "content" (which is set earlier in the code), then the variable set earlier will display the field value, rather than the actual comment content. I'm pretty certain this can also happen with any fields that have a key of url or date as well, considering those are also set prior to record fields being added.
I'm not... overly sure on how this can be handled, short of one of the following:
1. We change the above to something like this:
$r['record_fields'][ $k . '_value' ] = $fieldsClass->getFieldValue( $fields[ $matches[1] ], $r, $fields[ $matches[1] ]['field_truncate'] ); $r['record_fields'][ $fields[ $matches[1] ]['field_key'] ] = $r['record_fields'][ $k . '_value' ];
So as to avoid conflicts with array keys... I can't think of many instances where Record Fields are used within a Comments Feed block, so... this may work?
2. We simply skip over any Record Fields that have a key of content, date, or url, and not add them to the $r array.
| Status: | Fixed |
| Version: | 2.3.2 |
| Fixed In: | 2.3.3 |
6 Comments
Has anyone really thought about what would happen if the field key is record_approved, record_link, category_id, member_id, primary_id_field, url and so-on? Content would fall apart at the seams in many areas, simply put, the software really needs to protect the stock array keys, if the column exists on the database table or is used as a consistency key, Content for sanities sake should not allow it.
Why is that allowed/saved?
Should have probably opened a new bug report so your comments don't get missed...
k, did so, with a sane list.
http://community.invisionpower.com/resources/bugs.html/_/ip-content/field-keys-user-input-r38708
Since the original issue was fixed and there's a new report, just going to close this one out.