Gutenberg: Tags disappear on entry

Here are my 50 cents: looking at the database tables, if I enter the tags normally, only the term row is created in table ‘wp_terms’. So, the accompanying row “pll_…..” is not created. You can notice this also in table ‘wp_term_taxonomy’, where the row “term_translations ….” is missing. If you enter the tags via quick edit, the missing rows are created.

I encounter the same problem on my production server (live) but can’t reproduce in my local machine (which is worse ?? )

• This reply was modified 5 years, 4 months ago by korayloker. Reason: email notification update

Same issue here, WordPress 5.2.2. It’s very disappointing to see that this serious issue has been around for so many months.

I also have issues with Tags in Gutenberg 5.2.2

If I have a post with a tag and edit it, the tag does not show up in the Document’s tag section. So if I just make a minor edit and save, I lose my tags unless I enter them again.

I also use the Revisionize plug-in to schedule updates to existing posts and it will not save the tags on the update. My home page has a section that includes articles with a certain tag, so this is a problem.

Same problem here, but I have one solution:

You can solve this: press first key of the tag, wait one moment (1 second), press second key and wait, continue and the tag appear, click and will run ok.

Another solution is use the fast edit in the posts section.

I hope this help

Hallo,
A part for the Quick Edit option which was already mentioned above I noticed than it works just fine if the TAG was already inserted in the POST-TAG page from scratch.
Apparently when you edit a NEW TAG in the post itself it saves the NEW TAG in some sort of cache but it DOES NOTupdate the TAG DB list.
So if you even try to recover the previous NEW TAG typing it from the “Add New Tag” field and you can find it but even if you select with keyboard or mouse It will not be saved. It seems that is recovered from some temporary cache. Use save option to verify it (CTRL-S).
The only way is to create it from scratch from the POST-TAG page and then recall it from the “Add New Tag” field.
I think this solution is quicker then the Quick Edit solution even is not a on-the-fly method to create and save a TAG within a post.

WP Version 5.2.3

• This reply was modified 5 years, 1 month ago by zionthelion73. Reason: minor editing, syntax errors... not found :)

mee too i have this problem in the past i write like 4 tags: tags 1, tags 2, tags 3, tags 4 and when i copy all tags and i puth paste i don’t have problem. now when i puth all tags, all tags disappear

@vdtonline
does my workaround works for you?

Hi @otto42, do WordPress developers know this problem?

I think this problem is only for servers with high latency responses.

Thanks to @vdtonline, @zionthelion73 and @scrumptiousreading for sharing ways to face this.

• This reply was modified 5 years, 1 month ago by harrinsonmb.

@harrinsonmb No, I’ve never seen this problem before. It’s not a known issue.

I can confirm that this is related to SQL latency. I upgraded MariaDB 10.2 to 10.3, which brought with it some fairly significant performance improvements on my server. I still see the problem, but not nearly to the extent I did. CPU load shot up after adding about 10 tags but the responsiveness was quicker, I didn’t lose any tags and it didn’t shoot up nearly as high as previously.

I don’t see these issues doing literally anything else with Gutenberg. The block editor works fine and is light on the CPU, I can save and edit posts without problems, it’s JUST the tags.

Still, maybe another piece in the puzzle.

(@plagiarismtoday)
Thanks dude!

I wanted to provide some additional info on the problem. I took this screenshot from my WHM while I was in the middle of editing a lengthy post in Gutenberg.

https://www.plagiarismtoday.com/wp-content/uploads/2019/10/shot1.png

As you can see, not a lot going on, the site plagiarismtoday is eating some resources but nothing crazy. Showing a very light overall load.

Then I added about a dozen tags and it turned into this.

https://www.plagiarismtoday.com/wp-content/uploads/2019/10/shot2.png

As you can see, it opened up a SLEW of php-fpm pools and each of them gobbling up an insane amount of CPU. This is actually LESS bad than it was before I upgrade to MariaDB 10.3 where it would be even worse, possibly fatal to the server.

Hope this provides some insight.

Thanks. I hope some developer are reading us!

Going to tag @otto42 since he was on the thread earlier and, maybe, my new info cna help.