Cant comment on the code but it appears to fix the issue for me

On 6 January 2015 at 22:14, Robert Deutz notifications@github.com wrote:

It seems that removing code fixes the problem #5554
#5554 this PR it is more or
less the same as in #5601 #5601.
I have tested tags where I have found them and anything is working. But

this needs more tests, because it feels strange :-)

You can merge this Pull Request by running

git pull https://github.com/rdeutz/joomla-cms fix-adding-tags

Or view, comment on, or merge it at:

#5630
Commit Summary

• removing a part of the code seems to be the fix

File Changes

• M libraries/cms/form/field/tag.php https://github.com/joomla/joomla-cms/pull/5630/files#diff-0 (9)

Patch Links:

• https://github.com/joomla/joomla-cms/pull/5630.patch
• https://github.com/joomla/joomla-cms/pull/5630.diff

—
Reply to this email directly or view it on GitHub
#5630.

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

@test success. :)

I was not able to reproduce #5554 issue on the latest staging.

Steps done:

1. Installed Joomla without any test data
2. Created Tag1, Tag2, Tag3 from tags management
3. Created a new article and assigned it Tag1 & Tag2 tags. Save
4. Edited the same article and added Tag3 without issues.

In fact the real issue is that we should never load the full list of tags (done when the article has no tags). That's bad for performance when you have a lot of tags. The tag field should show only the found tags matching what has been typed.

I just retested on current staging as of 5 minutes ago and I still have the
issue

1. Created Tag1, Tag2, Tag3 from tags management
2. Created a new article and assigned it Tag1 & Tag2 tags. Save
3. Edited the same article and only the existing tags are displayed in the select

the confusing part is that you see a select with options but there are only the already chosen ones, that doesn't makes so much sense.

Yes. The field only has to load the assigned tags and ideally never all the available tags (which is now done when no tags are found because the IN () clause is not executed). Loading all the tags can cause the performance issues.

So the correct way in my opinion is to to do something like this in the getOptions method:

if (empty($this->value))
{
    return array();
}

Just to illustrate that is how it looks like

And the SQL queries.

Without patch (loading only the assigned tags):

SELECT DISTINCT a.id AS value, a.path, a.title AS text, a.level, a.published, a.lft
FROM jml_tags AS a
LEFT JOIN `jml_tags` AS b ON a.lft > b.lft AND a.rgt < b.rgt
WHERE a.id IN (2) AND `a`.`lft` > 0 AND a.published IN (0,1)
ORDER BY a.lft ASC

With patch or when no tags are assigned (loading all the tags):

SELECT DISTINCT a.id AS value, a.path, a.title AS text, a.level, a.published, a.lft
FROM jml_tags AS a
LEFT JOIN `jml_tags` AS b ON a.lft > b.lft AND a.rgt < b.rgt
WHERE `a`.`lft` > 0 AND a.published IN (0,1)
ORDER BY a.lft ASC

@phproberto
i agree, behavior must be the same on create new article (show tags after typing),
that will not confuse users.

I would prefer the following approach:

If an article with tags is loaded, then only the selected tags are loaded. If the user clicks on the tags field, then all available tags are loaded. So, the extensive tags loading is triggered by the user and not automatically in the normal loading process.

@test Success
I would prefer this PR instead of current confusing behaviour until a specialist found a way to load tags at the earliest on click or on focus like Kubik-Rubik advised. I gave up after several hours because of conflicting events.
At the moment you have to know how a tag is named to find it. If there is already a "good" synonym saved that a user doesn't find he/she will create a new tag for the same "thing".

RTC based on testing. maybe @Kubik-Rubik can propose a better fix later?