Free tagging entity reference to a vocabulary does not create the term, only allows existing terms

Yes, that's by design. Entity Reference doesn't create entities.

@dgtlmoon,
It would be great if you can provide a patch with some text for the README.txt to let people know that ER can be used only for referencing.

Yes, that's by design. Entity Reference doesn't create entities.

As part of porting Og-vocab to D7, I was able to create terms using ER. I think it can be a nice feature, for each entity type to say if it's auto-creatable. Patch will land in a couple of days.

Damz, any objections?

Completely un-tested.

@Amitaibu: I tried your patch but it does not validate against newest changes. From my position of having low experience comapred to what you have I still dare to ask:

1. Is it a mistake that you name some functions and keys of arrays "entityreferene" instead of "entityreference"? (the "c" is missing")
2. The best reply I ever got from Drupal was that the handler was broken; except for that no change in taxonomy terms and I have not had any luck with debugging as it seems to be far from my knowledge of Drupal

Other than that I wish I was able to take a look at this functionality because this is what I have been after.

Closed #1791206: autocomplete(tags style) errors on validation if term is new and says: There are no entities matching "test" as a duplicate of this issue.

btw, OG-vocab already has code that does it for terms.

I wish someone with the required skills have the time to take a look at the code in OG-vocab and replicate it in this module.

Are there any plans to support this? Would have really helped me out.

Taxonomy Term Reference Filter by Views is an alternative, but it puts the term ID in brackets after the name, which is totally undesirable for me. Entity reference doesn't do that, but it won't let people add terms.

Amitaibu says the required code is already in the og_vocab module. I am guessing, It shouldn't be too much work for someone who has some coding skills.

@DamZ
I don't wanna sound rude but either that option is mis-named, or this is a bug/missing feature for the module. It's very hard to accept that "it works as designed". I have no doubt; 9 out of 10 site builders would expect the new term to be created if that "Autocomplete, Tag Style" option is used.

Thanks...

So am I correct, if the Entity Reference module is still not replacing previous modules like Term References? I thought that was the purpose of ER, to integrate that all by using entities. It is indeed confusing that 'Autocomplete Tag Style' can be selected, because tagging should create tags automatically.

Here's a patch based on the og_vocab code. It adds references in autocomplete tags style widgets by checking for "(id)" suffix, or searching existing terms by name (matching first vocab sorted by order in field target bundles settings), or creating new term if no existing term found.

@bgilhome

Thanks for taking the time. I am testing this patch. As long as I can see, it works great when a single new term is used. I have tried many different combinations that works.
NEWterm
existingterm1, NEWterm
NEWterm, existingterm1
existingterm1, existingterm2, NEWterm
existingterm1, NEWterm, existingterm2
NEWterm, existingterm1, existingterm2

These all works fine. However, there is a problem when 2 new terms are used.
NEWterm1, NEWterm2

Notice: Trying to get property of non-object in _entityreference_autocomplete_tags_validate() (line 934 of /var/www/oraturk.tk/public_html/sites/all/modules/entityreference/entityreference.module).
Warning: array_flip(): Can only flip STRING and INTEGER values! in DrupalDefaultEntityController->load() (line 178 of /var/www/oraturk.tk/public_html/includes/entity.inc).
Warning: array_flip(): Can only flip STRING and INTEGER values! in DrupalDefaultEntityController->cacheGet() (line 355 of /var/www/oraturk.tk/public_html/includes/entity.inc).
Notice: Trying to get property of non-object in taxonomy_term_save() (line 626 of /var/www/oraturk.tk/public_html/modules/taxonomy/taxonomy.module).
EntityMalformedException: Missing bundle property on entity of type taxonomy_term. in entity_extract_ids() (line 7663 of /var/www/oraturk.tk/public_html/includes/common.inc).

For me, its not a big deal but I can't speak for others.

Hi i've been working on this too and I was considering create a separate module for it. That depends on entity reference maintainers but if this is going to be added I think it should let you chose wether to allow free tagging or not at a field level. I will try to make a patch from the code I have if you want. BR

I say; It makes a lot more sense to have it as a part of this module, rather than having it on a separate one.

Test this one.

Seems to be working for me, nice one!

@galindus_olidop

1- When I create my new field with ER, first I am at the "field settings" page, where I check the "Create terms if no matches." and I hit save. Now I am at the "my new field settings" page which is has more detailed options. The same check box for creating new terms is now uncheched. I have to re-check it again on this page. Either my previous selection should be carried over here or maybe its better to have that option on only one page, not two.

2- All single term tests works without a problem. I tried all combinations like I mentioned at #15.

3- There is a problem while trying to create multiple terms, which I can not place my finger on top of it. First, it doesnt happen all the time. Second, even if I get that Ajax error message, I see that the terms are created correctly after I click ok on the error message. I dont know what causes the error. First I thought it is related with the placement of the new terms since I try mixing the new terms with the existing ones in different orders. Then I thought it happens while editing an existing content rather than when creating a new one. But still I couldnt pin-point when it exactly happens. Please see the attachement for the error message. And it would be great if someone else tests this with multiple terms, it might have something to do with my own setup.

Thanks...

I needed to add a line after 473 of entityreference.module:

        '#title' => 'Create terms if no matches.',
		'#default_value' => isset($settings['handler_settings']['add_to_target']) ? $settings['handler_settings']['add_to_target'] : 0, //added line

in order to save the checkbox setting. I haven't encountered the error message from above comment.

Hi,
@bgilhome
I have clean a bit the code and added #21, thanks.
@hgurol
I have test it with a clean install and I can't reproduce your error, but due the fact the error is thrown on the ajax call it can't be (or shouldn't) the changes done by that patch.

Tested patch in dev branch and works ok.

Alright, I have tested the patch in #22 on a different (fresh) setup.

Now the selection about creating new terms carries over to the 2nd config page.
And I don't get any weird Ajax errors I have mentioned earlier.

All looks good and I feel safe to change the status.

Thank you guys...

I have reworked the patch to match Drupal coding standards and cleaned it up a little (reduced bloat). Tested it and it's working.

Related to this is #1959624: Autocomplete widgets not referencing the single entity result. Perhaps a maintainer can now guide both of these towards commit.

I've incorporated the changes from #1959624: Autocomplete widgets not referencing the single entity result and marked that issue as a duplicate of this one. Patch attached. Changing this to a feature request since this was not in the module original design.

I've moved part of the patch into another existing issue: #1389238: Autocomplete widget improvements

So, here are two patches. The first patch includes the functionality provided by the aforementioned issue. The second will work once you have applied the patch in the aforementioned issue.

This patch has overhauled the previous way this was done. Entity creation is no longer term specific and the EntityReference_SelectionHandler interface has been extended to support entity creation and field settings form validation. I have supplied a generic entityCreate() implementation and one for terms. There are likely to be problems with other entities but further testing will iron those out.

Views selection does not have creation support at this point. We shouldn't add that until this patch gets committed.

Please test this patch with your weird and wonderful entity references and let's get this into the codebase! :)

#28: 1472596-28.patch queued for re-testing.

Hi Sammys, first of all thanks for fixing the patch. I have tried to apply the patches , first #1389238 and then #1472596 but this one fails.
Anyway thinking about this there are some things that are not clear to me. If final solution will not allow us to use views I think this is not an improvement since core taxonomy already has free tag with autocomplete widget and we would replicate the same behavior, the second one is if allowing entity creation with free tags widget wouldn't be the same behavior as entityconnect offers.

Best regards

I did the same tests I did before with patch 1472596-28.patch
It applies well, works well. I did not encounter any problems.

What kind of a test should I do for views integration?

I gave the patches a try, and they look solid. I was able to create new terms without any issues.

Hi all,
@hgurol
I don't have much time right now to test but the views integration you should use a view to select the entities (though it is not working according to sammys) it is not a big problem though if someone wants to display a custom dropdown list it will not be possible to add terms. I think the fix goes in the right direction, adding views support would be the next action IMO.

BR!

Is this patch included in the latest release? I am using og_vocab in Open Atrium 2 and I am not able to free tag. I have the latest release of the entity reference extension.

Greg

@grpenner: As you're relatively new to d.o I'll explain how the issue status works.

When an issue is being discussed it will have the status "Active".

When someone writes a patch and uploads it the status will be changed to "Needs review".

After people review it, if there are problems with the patch, or it otherwise needs further work, the status will be changed to "Needs work", which will then loop back to "Needs review" when a new patch is uploaded.

After (hopefully) several people review the patch and believe it works well, the status will be changed to "Reviewed & tested by the community", which is how we tell the maintainer that we believe it's ready to be committed. Note, however, that the maintainer may test out the patch themselves and skip this step.

When the maintainer commits the patch the status will be changed to "Fixed". At this point the change will be available from the project's -dev release, there is no automatic process of creating a new stable release just because someone commits a change. Note that the status will be automatically changed to "Closed (fixed)" by the system two weeks after the issue is changed to "Fixed".

Because this issue's status is "Needs review" it indicates that the fix has not been committed, therefore it is not in the -dev release nor is it in the most recent stable release. It would be really great if you could take a bit of time to test out the patch and report back whether it works for you.

Thanks for contributing!

FYI https://drupal.org/project/entityconnect was mentioned as a possible temporary work-around.

Hiding all but the most recent patch.

I was only able to reproduce this problem with a fresh taxonomy. After that, I am unable to reproduce the issue.

I confirm that patch #28 works.
Not related to this issue probably, but tags that are found in the field, show the term ID behind it. Don't think that is needed.
By the way, I'm using this in combination with Active Tags module and this patch https://drupal.org/node/1912156..works great!

The development snapshot of Entityreference_autocreate works like a charm and looks like it is exactly what is needed.

@mvdve, thanks! Entityreference_autocreate works for me too.

So it sounds like we have several options here.

* Patch #28
* Entityreference Autocreate
* Entity Connect
* References Dialog

Was looking high and low to find this. We thought entity reference was also a drop in replacement for term reference. (guess again ;-))

For getting back the free tagging functionality of terms/basic taxonomy with no additional mandatory fields the
Entityreference Autocreate path is the best solution.
We use this now

For nodes and more complex content
Entity Connect is the better solution. But we have some issues with disappearing add buttons and so on.

Reroll to the HEAD of 7.x-1.x

Adjust tests: fix $element mock in entityreference.handlers.test

The patch from #46 is working form me since a few weeks without issues.

RTBC ?

I confirm that patch #46 works with last dev 7.x-1.2+20-dev

Thanks @julia.klimovsky

Hello

The patch keeps working with 7.x-1.4, but this

--- tests/entityreference.handlers.test
+++ tests/entityreference.handlers.test
@@ -199,6 +199,7 @@
$handler = entityreference_get_selection_handler($field);
$element = array(
'#parents' => array('element_name'),
+ '#field_name' => $field['field_name']
);
$form_state = array();
$form = array();

Thanks for the patch @julia.klimovsky

I cannot apply patch #46 in branch 1.x-dev, that's why I changed its status.

$ git apply -v entityreference-term_autocreate-1472596-45.patch
Checking patch entityreference.module...
Hunk #1 succeeded at 554 (offset 16 lines).
Hunk #2 succeeded at 945 (offset 18 lines).
Hunk #3 succeeded at 968 (offset 18 lines).
error: while searching for:
// Get an array of matching entities.
$entity_labels = $handler->getReferencableEntities($tag_last, $instance['widget']['settings']['match_operator'], 10);

// Loop through the products and convert them into autocomplete output.
foreach ($entity_labels as $values) {
foreach ($values as $entity_id => $label) {
$key = "$label ($entity_id)";

error: patch failed: entityreference.module:1091
error: entityreference.module: patch does not apply
Checking patch plugins/selection/EntityReference_SelectionHandler_Generic.class.php...
Checking patch plugins/selection/EntityReference_SelectionHandler_Views.class.php...
Checking patch plugins/selection/abstract.inc...
Checking patch tests/entityreference.handlers.test..

I'm not sure if anybody else is in the same boat, but because of the entityreference security update in 7.x-1.5 I've re-rolled the patch to work against that specific tag.

see attached.

(this also works against current 7.x-1.x dev)

Looks good to me, I've successfully applied this patch above.

Thanks @thtas, patch #51 works perfect in 7.x-1.5

I think this patch has been tested enough and it is a very needed feature. Thanks all for the work :)

Are there any plans to incorporate the working patch into stable release?

@candelas: I don't disagree with you; but the patch will still need work to match the code style checks the maintainer has activated, per #53.

I looked over the style issues that Coder flagged above in #53, and many were pre-existing issues in this module, with the exception of a couple dozen that were new. As the primary focus of this issue was to address the limitation that terms could not be created on-the-fly, I took a stab at correcting only the low-hanging fruit -- code style issues introduced in areas of code that #53 already touched.

Attached is a revised version of the patch from #51 with the style issues that patch introduced (hopefully) addressed. I've also attached an interdiff to make the changes more obvious.

Hopefully this makes the code sniffer happy :)

Here's the interdiff.

Thanks @GuyPaddock
Your patch in #59 works with 7.x-1.9

triggered tests on all supported versions of PHP

fuzz cleaning

@candelas , what version of PHP are you using?

This patch needs fixing for PHP >=7.4+

Needs work.