A little love for tags in the entry editor

[yellowled]

See http://board.s9y.org/viewtopic.php?p=10440067#p10440067 etc. for details.

(Move to stable if needed; this should not be a release blocker for the RC.)

[bauigel]

Two things that could be done to make it a little bit more user friendly:

1. move input-fied to top
2. allow to hide #backend_freetag_list (user_admin.css still to available, isn't it?)

[yellowled]

allow to hide #backend_freetag_list (user_admin.css still to available, isn't it?)

It's not even necessary; there is an option for that in the plugin's configuration.

[yellowled]

Related commit: additional_plugins/5f9ffb

[yellowled]

I consider this “done” as far as my ability to develop it is concerned.

If a plugin dev wants to give the possible solution mentioned in the forum a try, feel free to re-open this issue.

[ophian]

Just wanted to say thanks. This is much better now and will serve word artists! :)

[yellowled]

You're welcome.

I'm still not sure this is “perfect”, but it's the best I can do now without having to make too many changes (which would require lengthy discussions).

[ophian]

Ups - I just compared our DEV netzblog with my local checkout and found this, which is for the (mega long) categories far from perfect at all...

.........

[yellowled]

I'm aware of that, but since it's only the fallback for no-overlay users (which I don't expect to be that many) … meh. And besides, it really is like @garvinhicking said in the forums – if you have really MANY categories (or tags, for that matter), there really is no good interface for this.

Have a look at how other blog backends handle this – Ghost doesn't even have categories, Wordpress doesn't list them (in the entry editor). Both only have autocompletion inputs for tags or categories. There's a reason for that.

[ophian]

I'm aware of that, but since it's only the fallback for no-overlay users

Hmm, I didn't think of being a non-overlay user. Is that set as default somehow, since my config there says:

?

[yellowled]

No. Apparently, it's just that the category list is not hidden (like the tags) below the entry editors if overlays are used. Should be easy to fix, but I'm not sure if I'll get to that today.

[yellowled]

Sorry, that was wrong (because it was that way before) – both categories and tags are no longer hidden below the entry editors if overlays are used.

[yellowled]

That should do the trick.

[ophian]

sorry - maybe I just see a bug where there isn't any, but now it looks like my local one

Which is ok. I can tag right as before in 1.7, which I am happy with.

I would now expect the missing cat box being a button on top, pointing into an overlay for the categories.
But there is this

instead, pointing to tag overlay. Is that a mistake?

[yellowled]

Is that a mistake?

If it is, it is a mistake in your local installation (wouldn't be the first) or cache-fu or something in your browser. It works exactly the way it is supposed to work in the dev blog for me now.

[ophian]

Well, apparently not - it were current snips from the DEVnetz Blog.
Ok really! - another hard reload cached away the tags in a box. So sadly I have to revert my happiness about its return to non-overlay. Couldn't we make this granular for tags? ;-)
(Hey! NO personal offence - I really appreciate your work!)

[yellowled]

Couldn't we make this granular for tags?

I already suggested to make that config option more granular in the forums because I think people should be able to i.e. use overlays in the media db, but not for tags/categories if they so desire.

However, I don't think that's necessary for RC, and it definitely is not related to this issue.

[bauigel]

I already suggested to make that config option more granular in the forums
because I think people should be able to i.e. use overlays in the media db,
but not for tags/categories if they so desire.

However, I don't think that's necessary for RC, and it definitely is not
related to this issue.

​It is not possible to solve this through a simpletags-plugin-setting?​

[yellowled]

​It is not possible to solve this through a simpletags-plugin-setting?​

I literally have no idea what you mean by that. So, probably not.

[ophian]

I literally have no idea what you mean by that. So, probably not.

An option in the freetags plugin, eg 'Use overlay: yes no' and then check this in ... whereever it is done.
Sounds like an easy solution for me.

[yellowled]

I don't think it would be a good idea to have that in a plugin (which could be used with a completely different backend theoretically which doesn't even have an overlay).

But again, this is not related to this issue. Please open a seperate issue for this.

[ophian]

@yellowled I just updated my latest native test blog to the RC and installed the freetag plugin.
I now cannot find any place in a backend entry where I can see the tags already tagged to this entry.
The whole block <fieldset id="edit_entry_freetags" class="entryproperties_freetag mfp-hide"> is set to mfp-hide and the overlay only shows the tags which are available to set.

Do I miss something or is that too strict now?

[yellowled]

#239

[yellowled]

the overlay only shows the tags which are available to set

This, by the way, is not true. See the entry “Tag test” in the nbe backend – the input field in the overlay is populated with tags already assigned to that entry (and yes, the nbe blog is on rc-1).

[ophian]

It is, since I used the native lang, non-utf-8 test blog. :)
I just found the issue some minutes ago, which did not display the already tagged tags in the input field.

[yellowled]

Well, in that case, it is not always true. :)

But it is also not an issue with the overlay or a design flaw. (Although I agree that this could maybe be better, see #239).

[ophian]

Hm I don't why it does not reference any more....
see fix and some remaining questions/issues commit s9y/additional_plugins@8a5bf1c

[onli]

Just as a not, I see neither a button nor a list in the backend as well. Seems like you are already on it.