Field machine names don't respect the field title

The field has to be entity-id, because the data is configured as entity id.

The first one is adressed on #973698: Questions about template naming conventions

The problem with this patch is that it will break a lot of things.

a) revisions
b) all existing views
c) all existing d7 templates
d) more

I think we basically can't change this field name anymore without getting big problems.

So here's the thing.

I agree that there is no reason to use entity_id here, and I'm a little startled to see that we have this hardcoded string in there as a field ID, especially considering that this string is used so heavily.

We have to fix this. I realize it's going to cause problems, but this can't stay like this. When you've got almost all entity fields in a view, then your tokens will be all entity_id, entity_id1, entity_id2 with no way to distinguish between them. When we've already got perfectly good IDs to use, and we're just not using them. :/

This is the reason we're releasing alpha versions, btw. We recognize that we may have to fix major design flaws. This is one case we're I think we're better off fixing it and telling people that things are not going to upgrade cleanly.

subscribing

Subscribe.

Here is a patch

* tests views_get_handler:
* test basic functionality
* test the moved to feature
* test override handler feature
* add "moved to" to fieldapi data:
* renamed entity_id to $field_name
* renamed revision_id to $field_name . 'revision_id', because that's the way to take sure of uniqueness.

The tests are working for

@merlinofchaos

    if (isset($data[$field][$key]['moved to'])) {

had to be changed. There was a recursion check in this line which was a duplicate of the later recursion check

      if (!empty($recursion_protection[$moved_table][$moved_field])) {

Minor notes from quick review:

function testviews_get_handler() {
...
$this->assertEqual('views_handler_' . $type . '_broken', get_class($handler), t('Take sure that a broken handler of type: @type are created', array('@type' => $type)));
...

change to

$this->assertEqual('views_handler_' . $type . '_broken', get_class($handler), t('Make sure a broken handler of type: @type is created.', array('@type' => $type)));

Subscribe

Subscribe.

I am using this patch on my website:
http://premsat.co.uk/

(All the http://premsat.co.uk/taxonomy/term/ pages are Views with the patch)

The patch works fine, except I get the 'Ghost' row Blup mentioned.

I have used the patch with tpl.php files and everything is fine.

Please note: When you use the patch, you must re-create all your existing views in order for the entity id to be replaced with the actual field name.

any of these topics anlamamhttp://www.ikinci-el.tk

If you really have to recreate the views this patch fails.

@big_smile

Did you cleared your views cache before trying out this.
admin/structure/views/tools is the url for this.

Sorry. I didn't explain very well. You only have to re-create your view to make existing fields get the correct names. (After further experimentation, I have found that you can also just delete the fields old and re-insert them). All fields created after the patch have the correct names.

Sorry for not explaining too well. I hope I didn't cause any problems.

Can someone post a screenshot of the "ghost fields"?

The patch worked form me when adding a new field, but not for existing fields in views. I did clear the Views cache.
I had a view with an entity "entity_id_1" in it. After the patch this one remained unchanged. However, adding the same field again and it gets "field_image" as name/token.

# [entity_id_1] == Fields: field_image
# [field_image] == Fields: field_image

An upgrade path for any existing views with entities should be available as well.

I didn't see any ghost fields here.

Here is a new version of the patch which fixes this.

Everything checks out, except one small typo:

+++ tests/views_module.test	15 Feb 2011 16:43:12 -0000
@@ -76,4 +89,63 @@ class viewsModuleTest extends ViewsSqlTe
+      $this->assertEqual('views_handler_' . $type . '_broken', get_class($handler), t('Take sure that a broken handler of type: @type are created', array('@type' => $type)));

s/Take/Make

Still marking this as RTBC.

Take sure that a broken handler of type: @type are created

shouldn't that be is created?

Patch in #23 works for me, the UI now shows everything correctly.

One note : In the Views template you still get $fields['entity_id_1'] for the existing field and $fields['field_image'] for the new field. I do get this can't be changed anymore... I'm mentioning it because this can potentially break existing (prepatch) templates that print fields directly by key.

In the Views template you still get $fields['entity_id_1'] for the existing field and $fields['field_image'] for the new field.

This is how it should work.

Why can this break prepatch templates? Just the new fields get's changed.

Image this scenario :

I have a view with a field entity_id
I create a page display
I use a template views-view-fields--myview--page.tpl.php, i use print $fields['entity_id']
Views is updated to a version with patch
I add another page display (overridden fields) with the same field, it uses the same template suggestion

In that scenario print $fields['entity_id'] won't work for my 2nd page display, I have have to create a more specific template or add logic to check on both field names.

On 2nd thought, I rephrase my previous comment. It's not really breaking the existing view template, but the template won't be compatible with the new page display. I admit, it's an unusual scenario... maybe it can just be discarded :)

I was under the assumption that anyone using hardcoded calls to 'entity_id' will have broken code, but that's not the responsibility of this patch.

Commited to cvs and git.