Remove user signature and move it to contrib

I agree we should convert it first.

But since you already started the owner discussion ;) I actually think that user signatures are only ever used for forums (and the utter ugly code for it pretty much dates all the way back to the introduction of forum). However, forum is use-case specific already, and I could see potential other use-cases for user signatures. What matters is that user signatures are not simply text fields -- they additionally have business logic applied to them. Thus, I'd almost go with a user_signature field module.

When you do start worrying about ownership, I suggest not putting it in comment module considering adding a signature to a node is a perfectly valid use case. :)

Field-ifying signatures sounds like a pretty good idea. Then it can be applied to nodes, comments whatever.

I'm going to assign this to me to have a look over the next couple of weeks.

Clarifying issue title. This goes hand in hand with #569434: Remove taxonomy term description field; provide description field for forum taxonomy

I'm currently trying to make Drupal 8 use an alternative user storage under the hood, and all of these additional + unnecessary user-preference-alike settings in the {users} table really get in my way. :-/

Really, anything would be more appropriate than the currently hard-coded table column... even UserData would be more appropriate.

However, a text field attached to the User entity would be the most appropriate approach, as it contains all the necessary logic and plumbing already.

It also removes a fairly obscure checkbox/setting from the administrative Account settings page, which happens to be the trigger for the entire functionality (and only god knows what happens when you enable or disable that checkbox).

Like #1292470: Convert user pictures to Image Field, this will result in the removal of quite some legacy code and is a much needed API clean-up.

Related: #1934772: Filter module is not required, but is marked as required

I've followed the example of #1292470: Convert user pictures to Image Field to make signatures their own field. I've decided to give 'ownership' to the user module as the signatures are fields on the user entity.

Hopefully I've gone down the right track with this - any tests relying on the old signature system will not work as I've not altered them so we'll call this a first attempt.

I would probably include a caveat that signature fields should be displayed as 'trimmed' by default rather than free text for however long the user wants.

+++ b/core/modules/comment/comment.moduleundefined
@@ -1641,16 +1641,16 @@ function template_preprocess_comment(&$variables) {
+    $variables['user_picture'] = user_view($account, 'compact')['user_picture'];
...
+    $variables['user_signature'] = user_view($account, 'compact')['user_signature'];

Direct array dereferencing depends on PHP 5.4.

Thanks Grayside - wasn't aware of that.

I was trying to think of the best way to accomplish what was desired. If it is just left at
user_view($account, 'compact') then all of the fields in the compact view of the user entity are displayed. This means that picture & signature are displayed twice. (This seems to be a bug from when user picture was fieldified).

Perhaps a better way would be to:

  $user_view = user_view($account, 'compact');
  if (theme_get_setting('toggle_comment_user_picture')) {
    $variables['user_picture'] = $user_view['user_picture'];
  }
  else {
    $variables['user_picture'] = array();
  }
  if (theme_get_setting('toggle_comment_user_signature')) {
    $variables['user_signature'] = $user_view['user_signature'];
  }
  else {
    $variables['user_signature'] = array();
  }

If we keep the field in User module for now, then I think we want to add a new view mode/display 'signature', which only renders that text field.

Please also note that #1853378: Optimize user_view('compact') in template_preprocess_node() is about to change how the compact view mode is processed and rendered.

I can reroll the patch as and when that happens in conjunction with amending to code in #9.

Should also take into account that displaying the user picture via the methods it currently does is sort of broken as it just renders everything in the 'compact' view of the user.

#6: 1548204-6-fieldify_signatures.patch queued for re-testing.

It needs reroll.

In light of #2142549: Support multi-column field types in base tables, the signature can stay as a base field and be a regular 'text' field instead of two string fields stiched together. Here's an initial patch that depends on the above, which means we'll have to wait for that to get in before moving forward here.

#2142549: Support multi-column field types in base tables is in.

Thanks for the alternative approach, @amateescu.

But, hm. One of the secondary goals envisioned here was to get rid of the columns in the {users} table (cf. #4). If you do not need or use user signatures on your site, then you should not see the properties, data, schema columns, etc.

By turning the user signature into a field, the entire storage and data would only exist if you actually use user signatures on your site. Otherwise, they wouldn't appear anywhere.

Thoughts?

The thing is.. I didn't read the comments in this issue before posting. I was told in #2142549: Support multi-column field types in base tables that user signatures would serve as a good testcase, so I just extracted the work from that patch and posted here.

If the goal is to not have the data in {users} anymore, then sure, a configurable text field makes more sense, so feel free to disregard the patch in #16 :)

I suggested this approach because of the way the signature field is used. It's not displayed on users, it's pulled in on comments and displayed there. That is something that requires custom code and doesn't work well in combination with a custom field. We'd need to have that code in the profile or so or some other place where it's conditional.

Converting it to such a field at least means less custom code and standard features, like edit.module's embeded field usage tracking would work for the signature as well.

Needs a re-roll now anyway.

Just to throw another potential wrench in the works... Signatures should ideally be able to optionally be displayed on nodes, too. At least that's how every forum software on the planet works, which is the origin of this feature.

This is the one part of my never-ending quest to fix signatures I never got to. ;( But even if we don't fix this in core, contrib will definitely need to be able to do this, so whatever approach is taken here should factor that in.

@Berdir, I fully agree that the base field approach should be using the new standard field facilities in D8. We can perfectly do that as a first step, although I wonder whether we shouldn't create a separate issue for doing so?

That is, because this issue always was about the hard-coded columns in the {users} table. As mentioned in #4, I attempted to replace the user account storage with an external system (as a quick experiment, I used the {users} datatable of a Drupal 6 site) some time ago.

To do so, I swapped out the user storage controller with my own, which worked like a charm, but having to care for signature* values really came unexpected, since signatures do not really have any business in there.

I agree that a custom field might be hard to maintain in a reliable way. Perhaps we should simply move the functionality into a new [user_]signature.module with corresponding database table, and simply expose it as an extra field?

That approach would inherently resolve @webchick's note on making the signature available for (forum) nodes, too.

Thoughts?

For now, just starting a straight re-roll of the last patch.

Next, I'm going to explore how hard it is to move the functionality into a new user_signature.module.

24: user-signature.24.patch queued for re-testing.

24: user-signature.24.patch queued for re-testing.

Here we go. This is my first more substantial dive into the new Entity Field API of D8, so please don't shoot me in case I missed something big or super-obvious. ;)

As a random benchmark: The proposed changes would have taken me ~20 minutes in D7. The total RTT for this patch was 4h.

I primarily had a lot of DX related problems with (1) learning new entity/form code execution flows, (2) deciphering which classes and services are actually getting invoked, (3) reverse-mapping arbitrary string IDs to plugin/service/class implementations, (4) making sense of entity/property/field/data/definition thingies that seemingly appear to be mixed and mashed and used like crazy :P, and lastly, (5) trying to implement seemingly basic things that do not seem to be cleanly supported yet ;)

All in all, things appear to make sense, but I did not have the impression that the system is prepared for very typical bridge/glue modules like this yet. (?)

I don't know whether this patch is correct in any way, but that's how I'd interpret the current system architecture as a "newbie". Hopefully this helps us to learn some more about how we can improve the Entity/Field API experience for developers. I'd certainly love to learn! :)

What do you think?

Some random feedback on @todo's and questions in the code.

1. +++ b/core/modules/user_signature/user_signature.module
   @@ -0,0 +1,253 @@
   +  }
   +  // @todo There does not appear to be a way to cleanly load the field item
   +  //   values of attached third-party fields within the Entity API or
   +  //   Entity Field API scope? -- hook_entity_load() is too gross (performance),
   +  //   and no lazy-loading in FieldItemBase?
   +  $signature = db_query('SELECT signature__value AS value, signature__format AS format FROM {user_signature} WHERE uid = :uid', array(':uid' => $account->id()))->fetchAssoc();
   +  if ($signature) {
   +    $account->set('user_signature', $signature);
   +  }
   

   Not like you'd expect it to. Use the load hook, that will become part of the cached entity values (not right now in the entity caching patch, but I want to get there), so you shouldn't have to worry about performance too much, It's actually likely faster to get it like that from the cache than setting like like this, because this requires instantiated field objects.

   The alternative is computed properties but I don't think that makes much sense here.

2. +++ b/core/modules/user_signature/user_signature.module
   @@ -0,0 +1,253 @@
   +    // @todo Wasn't #maxlength support for #type 'textarea' committed already?
   +    '#maxlength' => $account->get('user_signature')->getFieldDefinition()->getSetting('max_length'),
   

   You should be able to get to the definition directly with with $account->getPropertyDefinition('user_signature').

   The property/field mismatch will be solved in one of the typed data issues I think.

   Also, the whole form element should just be a text item widget, similar to how node title now works. There are still multiple issues related to make DX better, but that's where it's going afaik.

3. +++ b/core/modules/user_signature/user_signature.module
   @@ -0,0 +1,253 @@
   + *   enforced?
   ...
   + * @todo Why is the TextFieldItem 'max_length' constraint not automatically
   

   Because validations currently only work for configurable fields, see the #2002180: Entity forms skip validation of fields that are edited without widgets.

4. +++ b/core/modules/user_signature/user_signature.module
   @@ -0,0 +1,253 @@
   +    }
   ...
   + *
   + * @todo Move CRUD logic into new user_signature FieldItem extends TextFieldItem?
   + */
   +function user_signature_user_form_submit($form, &$form_state) {
   +  $account = $form_state['controller']->getEntity();
   +  if ($account->id() && isset($form_state['values']['user_signature'])) {
   +    if (!$account->get('user_signature')->isEmpty()) {
   +      db_merge('user_signature')
   +        ->key(array('uid' => $account->id()))
   +        ->fields(array(
   +          'signature__value' => $account->get('user_signature')->value,
   +          'signature__format' => $account->get('user_signature')->format,
   +        ))
   +        ->execute();
   +    }
   +    else {
   +      db_delete('user_signature')
   +        ->condition('uid', $account->id())
   +        ->execute();
   ...
   +  }
   

   You've chosen a rather strange middle path by making it an entity field and still have custom storage/logic.

   Unfortunately, entity storage doesn't support non-configurable fields yet, see #2144263: Decouple entity field storage from configurable fields. With that, it should be able to take care of storing your values.

   For now, you could simply define it as a configurable fields by throwing the necessary config files into your config folder. You'd just need to take care of the entity form display I think.

   Or do it the other way, and don't bother with entity fields at all. Because right now, you get almost nothing from doing so :)

5. +++ b/core/modules/user_signature/user_signature.module
   @@ -0,0 +1,253 @@
   +  // Fetch signatures for all authors, keyed by entity ID.
   +  $uids = array();
   +  foreach ($entities as $entity) {
   +    $uids[$getAuthorId($entity)] = $getAuthorId($entity);
   +  }
   

   I don't really get why using an anonymous function is any better than just defining it as a normal function :)

+ * @todo Why is the TextFieldItem 'max_length' constraint not automatically
Because validations currently only work for configurable fields, see the #2002180: Embrace entity validation in entity forms .

More precisely, field constraints are only validated for fields rendered by Widgets rather by custom FAPI code, because Widgets can map violation back to a FAPI structure, and arbitrary FAPI code can't.
If you don't use widgets, you're on your own for FAPI handling, including validation...

It is currently possible but fairly convoluted to have a base field use a widget, #2144919: Allow widgets and formatters for base fields to be configured in Field UI is the issue about making it simple.

Thanks for the helpful insights and pointers!

Re-implemented user signature as a field type attached to User entity.

The underlying idea: The user signature belongs to the User entity, and content entities like Comment and Node are loading the User entity of the author already for theming.

I wonder that there's a whole module for that? why not just and a few config files to create field?

1. +++ b/core/modules/comment/lib/Drupal/comment/CommentInterface.php
   @@ -26,6 +26,33 @@
   +  public function getAuthor();
   ...
   +  public function getAuthorId();
   ...
   +  public function setAuthorId($uid);
   
   +++ b/core/modules/comment/lib/Drupal/comment/Entity/Comment.php
   @@ -338,6 +338,28 @@ public static function postDelete(EntityStorageControllerInterface $storage_cont
   +  public function getAuthor() {
   ...
   +  public function getAuthorId() {
   ...
   +  public function setAuthorId($uid) {
   

   Happends in #2028025: Expand CommentInterface to provide methods

2. +++ b/core/modules/user_signature/user_signature.install
   @@ -0,0 +1,45 @@
   +/**
   + * Implements hook_uninstall().
   + */
   +function user_signature_uninstall() {
   +}
   +
   

   is not needed

Expanding on #36 I think it would be more consistent with what we do for the user picture. There you just configure the 'compact' view mode however you like. We could add a 'signature' view mode and then add the signature field as simple config.

1. +++ b/core/modules/comment/lib/Drupal/comment/CommentInterface.php
   @@ -26,6 +26,33 @@
   +  public function getAuthor();
   ...
   +  public function getAuthorId();
   ...
   +  public function setAuthorId($uid);
   
   +++ b/core/modules/comment/lib/Drupal/comment/Entity/Comment.php
   @@ -338,6 +338,28 @@ public static function postDelete(EntityStorageControllerInterface $storage_cont
   +  public function getAuthor() {
   ...
   +  public function getAuthorId() {
   ...
   +  public function setAuthorId($uid) {
   

   Let's go with Owner here as per #2078387: Add an EntityOwnerInterface

2. +++ b/core/modules/user_signature/lib/Drupal/user_signature/Plugin/Field/FieldType/UserSignatureItem.php
   @@ -0,0 +1,91 @@
   + *   conditionally define field schema based on field definition properties.
   ...
   + * @todo Consolidate TextItem and TextLongItem into a single field type and
   

   I'm not sure how that could really be done, but it sounds interesting. Let's open an issue for that.

3. +++ b/core/modules/user_signature/user_signature.install
   @@ -0,0 +1,45 @@
   +/**
   + * Implements hook_uninstall().
   + */
   +function user_signature_uninstall() {
   +}
   

   ?

4. +++ b/core/modules/user_signature/user_signature.module
   @@ -0,0 +1,187 @@
   +  // Make sure the signature isn't longer than the size of the database field.
   ...
   +  $maxlength = $schema['fields']['signature__value']['length'];
   ...
   +  $schema = drupal_get_schema('user_signature');
   ...
   +      'max_length' => $maxlength,
   ...
   +    ->setSettings(array(
   ...
   +      'text_processing' => 1,
   +    ));
   

   I don't see a reason for this indirection. Can this not be validation constraint on the field item directly?

I think it is way too late to move it to a separate module (even though that would actually work now, and a lot easier than done here). The only thing we might still have a chance is to convert it to a text field type. That would still mean a storage change, resulting in signature__value and signature__format as column names and a single field. But even that might be too late, can't say.

It is late see #569434-220: Remove taxonomy term description field; provide description field for forum taxonomy

The only thing we might still have a chance is to convert it to a text field type. That would still mean a storage change, resulting in signature__value and signature__format as column names and a single field. But even that might be too late, can't say.

Agreed. That is the least disruptive change right now and does not have to change templates or so (just disable display configuriablity)- but would help us solving #2405943: User entity validation misses form validation logic. At least we could leave the existing getter() in place?

It poses a new problem though: User module would have depend on filter module for the filter format. (Right now, filter format depends on it.)

It blocks #2425193: Convert the signature field in user_field_data to the ordinary views field which is a child issue of critical so should we change this to critical?

I've closed #2425193: Convert the signature field in user_field_data to the ordinary views field as a duplicate of this issue, because (a) this seems to be the Right Way to fix the problem of making the signature field actually translatable and access controlled in Views and (b) it may not only be the Right Way but probably is the Only Way.

This one now becomes a child of #2393339: [META] Make sure Views base fields are using Field API for formatting, and do not lose functionality and becomes critical.

Not convinced about B). As commented above, we have a non-trivial cross-dependency here between user and filter module if we make it a base field.

I'd argue that in the current state, the "right way" is not always the way we can still do...

Right. So what would we do with it exactly? And who would create it?

We already have something like that for the profile picture.. which is configuration, but we also have API functions that assume that *if* it exists, then with a specific name and so on..

There is some kludgy code already in the User module that disables the Signature field if the Filter module is not enabled. See for instance user_modules_uninstalled() in user.module, and I think there's code for this elsewhere as well, just cannot remember where.

Probably we'd need to do something similar with this field, but ... wouldn't a field that depends on Filter just automatically not get its config imported until all the dependencies are present? That seems like a cleaner thing than the kludge that is there now.

You can have optional config like that in HEAD, but #2090115: Don't install a module when its default configuration has unmet dependencies makes that possible.

If we make it either an optional field in user or part of standard.install, then yes, that might work.

The interesting thing is that standard actually doesn't have that feature enabled, so we'd change it to be enabled by default for standard? If not, then we would essentially drop the feature completely? Or make the UI checkbox create the field or something.

Or make the UI checkbox create the field or something

IIRC so far we have avoided "some checkbox somewhere creates a field somewhere else" approaches, because of duplicate UIs and the difficulty of enforcing they stay in sync.
I guess that's easier in a wizard-create UI that you don't ever see again once the "thing" has been created, but having two separate UI screens control the same thing is tricky.

The same way we have #2230177: Without Field UI comment module presents a poor UX unsolved
Also I think that loading user could cause access checks for filter so circular deps too

Back to comment 1 - this seems to be forum specific? Why not make it a field in forum module's default config?

What about exposing the signature field as part of a dedicated module. Forum module could depend on it, but I think signature is really not a common used
feature, compared to the generic usecase of the user module.

doing a reroll for separate module, also I think we need to expose signatures through post render so changing a signature should not invalidate all entities where used.

About settings, there is related issues

also I think we need to expose signatures through post render so changing a signature should not invalidate all entities where used

That might be a really good idea, but I think it's out of scope for this issue. Can we defer that to a noncritical followup?

I like #55 and #56 because I don't want user signatures on my sites. If I really wanted users to have signatures on their posts I'd extend the user entity to provide it.

doing a reroll for separate module, also I think we need to expose signatures through post render so changing a signature should not invalidate all entities where used.

Not convinced by that at all, actually :)

Comments and nodes have the user cache tag anyway, so they will be invalidated anyway when the user entity is saved.

post_render isn't free, it requires additional rendering on every page load.

Not convinced by that at all, actually :)

Comments and nodes have the user cache tag anyway, so they will be invalidated anyway when the user entity is saved.

post_render isn't free, it requires additional rendering on every page load.

Exactly.

Using #post_render_cache for every single user signature would mean that on a forum with e.g. 50 forum posts visible at a time, by 50 different users, we'd be rendering and replacing 50 different placeholders. User signatures usually don't change very often, so I don't see why we'd want to do that.

Just one small note, since we have to do some amount of wrangling either way, it would be amazing if whatever is done here is done in such a way that signatures can be displayed on forum nodes as well as their comments. That is forum functionality 101 and has been a thorn in my side since Drupal 4.6. ;)

#62: Hah! If it's a field, that should be trivial nowadays? Comments and nodes are entities, and they both have authors. So however this works exactly; it'd just be a matter of configuring the user field formatter on both the node bundle and the comment bundle's view displays.
Of course, I don't know anything about how this patch actually works, so that could be total nonsense.

As maintainer of forum, my personal preference is to remove this from core. Wholesale.
The word signature does not appear in forum.module at all, so it's presence would be something provided by user as it stands, which would suggest that a contrib module could easily add it back without much trouble on behalf of forum.
I can't see any situation where we get close to an RC and say 'hey we can't ship 8.0.0-rc1 because user signatures'.
Who's with me?

/me ducks for rain of abuse

Not quite like that, a view mode can't be split up later and be split into multiple places. We can only do that if we render multiple fields explicitly, the way views does that now/soon, but then we lose the configurability.

That said, there's no reason we could do the same for nodes that we do on comments, but not sure if we should that here.

#64: heh! :P

I personally always hated forum signatures, on every forum I've ever been on (at least a dozen), in all the possible implementations I've ever seen (several dozen). Endlessly repeated annoying text? That's what a user *profile* page is for. This is a remnant of e-mail signatures (which are also annoying as hell), and just made it into web forum software because e-mail lists were the original forums.

+1

What prevents a user signature from being a textarea (text, formatted, long) and inform the user reference formatter field how to handle it if present?

Looking at 2 first questions
http://drupal.stackexchange.com/questions/101118/signature-user-field-no...
http://drupal.stackexchange.com/questions/115275/how-to-not-show-user-si...

I'm really +1 to remove signatures to contrib

Also there's a issue to clean-up comment entity templates so at least template_preprocess_comment usage of user_view() could be fixed.

About post render, I'm sure that more often a forum discussions used by only few users, so 50 comments could be done by 5 users with only 2 with signatures.

PS: Still trying to separate signatures to optional module

Removal of mentions, let's see how much broken

Migrate dump and variables still define the source

TODO:
1) \Drupal\Component\Utility\NestedArray doc block uses example about signatures
2) Fix CHANGELOG.txt

Also there's a issue to clean-up comment entity templates so at least template_preprocess_comment usage of user_view() could be fixed.

Can you point to that issue? I'd love to review it.

Remove remains and fix tests, core/modules/user/src/Tests/UserSignatureTest.php is removed also

And more clean-up

Patch is green, so now we need to decide on module name, my +1 to comment_signature

Given that @webchick thought about signatures both on comments and the node itself, I would like to suggest user_signature

I think user_signature is better as well since it is tied to an individual user and could, in theory, be used anywhere.

+1 user_signature

Thank you for updating the hook_help() implementation along with this patch! I have no opinion on the merits of the patch, but updating the help at the same time is much appreciated. :)

So following up on #44 - #45, the case for the meta #2393339: [META] Make sure Views base fields are using Field API for formatting, and do not lose functionality being critical was that we would leave it critical only until such time as we had identified the scope of the critical work for that issue, and made sure that any specific issues were filed. Children are not necessarily critical (and in many cases won't be). This issue by itself is not critical, so downgrading.

and made sure that any specific issues were filed.

                          .'  .
                         .'.'.' .
                        .`.'.`'.
                       ..'..'.`'
                       `,'....`
                      `' ..'`.
                     `'``''`.
                     .'.``'`
                  .'`..'''`.
                    ````.'`
                  xl""``""lx
                 X8Xxx..xxX8X
                 8X8bdX8bd8X8
                dX8Xbd8XbdX8Xb
               dX8Xbd8X8XbdX8Xb
              dX8Xbd8X8X8XbdX8Xb
            .dX8Xbd8X8X8X8XbdX8Xb.
          .d8X8Xbd8X8X8X8X8XbdX8X8b.
      _.-dX8X8Xbd8X8X8X8X8X8XdbX8X8Xb-._
   .-d8X8X8X8bdX8X8X8X8X8X8X8X8db8X8X8X8b-.
.-d8X8X8X8X8bdX8X8X8X8X8X8X8X8X8db8X8X8-RG-b-.

No, there is still tons of unknown work in front of us

Need to be checked to see if they can be removed/replaced.

The patch is looking great for me, lets get better that feature removed earlier than later and make a good contrib module.

A bit more clean-up in migrations
Suppose to get review for the hunks in \Drupal\migrate_drupal\Plugin\migrate\load\LoadEntity::processTextField() - probably that code would be needed for d7 migrations

Let's be real.

Thanks for the updated title. Also needs update in issue summary and change notice, since this is functionality that was in 7 and in 8 until now, and is proposing to be removed.

However... Is anyone actually proposing to do this in a contrib module? And how? Is it even feasible to have it not kludged into the user and comment modules like it is now? And if it is feasible, why can't it be moved to a core module? I mean... This functionality is clearly an ugly kludge, and I agree that removing the code feels good. But if the only way to provide the functionality is through this ugly kludge, I am not sure removing it is the right fix.

re #86: This might be a crazy idea but I was thinking in contrib it could be a field. The field "data" would be any settings that you might want to set per instance rather than the signature itself. Then the display of the field would pull in the signature. That way, it could be easily added to any fieldable entity.

@Michelle: I think the suggestion in #89, if I'm understanding it correctly, is basically:
- Signature is a field on the User entity.
- It gets added to the "compact" view mode for the User.
- This view mode is what is already being shown along with user picture for comments, so signature would be included in that.

I'm not entirely convinced you want the signature placed near the picture and/or user name (picture is often upper left corner, user name across the top, signature at the bottom), but something like this does seem like a reasonable solution other than that detail.

I think I jumped in without thinking it through enough. I was thinking about the _display_ of the signature and making that a field that could be added to comments, nodes, users, whatever. Basically it would take in the author of the entity the field is on and spit out a signature based on settings on the field. I wasn't thinking at all of where the actual signature would be stored. So I guess there would end up being a "signature field" on the user that holds the signature and a "signature display" field that could be put anywhere, which maybe doesn't make a whole lot of sense since that isn't how fields are normally used.

Thanks for assigning to me. This is near and dear to my hearty since this was the whole reason I got into core dev. ;)

Like jhodgdon and Michelle I would feel a lot better about this if a workable direction was given to a prospective contrib module maintainer that met the following requirements:

- field in user profile
- updating it there updates it everywhere it is displayed
- displayed at the *bottom* (under the user picture is definitely not what people would expect and drupal behaved this way for at least 10 years) of both comments and nodes
- you can configure which node/comment types so it's shown on so for example, only forum posts/replies

Right now that direction feels basically like:

¯\_(ツ)_/¯

If lots of smart core devs can't figure this out, I'm doubtful contrib is just going to magically make it happen, and then sites lose data (and in this case highly personal data -- as in "that's part of my identity") when they move to D8.

One question is whether another way to resolve the critical is simply to remove views integration for the field.

So... On #2425193: Convert the signature field in user_field_data to the ordinary views field I attempted to fix the critical part of this by adding a proper formatter to the Signature base field (making it a proper long text field with a format, and then you could just use the Field API formatter in Views for Signature). This failed, because base entity fields can't be long-text-with-format (we don't want them to depend on Filter), and exposed to me the general kludgyness of Signature in the User module (the "field" gets turned off if the Filter module isn't there, to avoid having User depend on Filter, etc.). Plus there's a "use signatures" setting on user accounts, which is really also a kludge.

To me, this says that the Signature field should be a Field UI field, not a base entity field, so that (a) it can really be long-text-with-format, and (b) it can be turned off by removing the field. The kind-of-and-kludgy way it's being done now also probably doesn't properly support translation of user signatures anyway using the Entity Translate stuff. If both User and Filter are turned on, this field config would be imported and you'd have signatures; if Filter is missing you wouldn't get the field config, because it depends on Filter.

But then there's all the other kludgy special stuff that Signature does to make it appear magically at the bottom of forum comments or whatever else it does. I haven't delved into that enough to know how that works, but it's probably magic. I mean, there's a relationship between a comment and the user who created it, but in rendering an entity with an entity relationship, you can't normally render the related entity scattered around the way Comment is doing: user name one place, picture a second place, signature a third place. So this is problematic: both Picture and Signature get special treatment and neither of them is a proper Field.

Anyway. You all probably knew all of this... but it *really* makes me doubt this can go into Contrib easily.

I really don't see a problem with moving this to contrib.

@jhodgdon:
- There is no problem with having a text field as a base field. Taxonomy terms do that for the description, it works fine (although I think that description should be a configurable field, but that's a different problem). The problem is having a text base field on *users*, because user is a required module and text and filter is not.
- There's not as much magic as you think (depends on what you understand as magic). It's built in the comment view builder, added to comment templates and printed there.

What makes it complicated is that user signatures are trying so hard to be implemented in a Drupal 5 way in Drupal 8 ;)

Here's what a contrib field has to do:
- Expose an extra field "User signature" on comments and nodes (or every other entitiy type that you want to, because there's nothing special about that) (Instant and free configurability per bundle and view mode)
- A bit of code that adds *something* into that extra field. It could either be a single text field that the module provides, or it could be the user entity in a given view mode (the existing compact mode doesn't work, it is not possible to render an entity and then split it up due to render caching).

That being in a separate module means:
- No custom configuration required, if you don't want the feature, don't enable the module, and you can configure it to be shown where you want, no custom template/preprocess logic necessary by default. (Unless you want to, which is also possible, of course)
- No overhead for the 99% of the sites that don't want user signatures
- Free and working views integration

We could have done this any time in the last 4 years in D8 development, but we didn't, because no active core developer cares about user signatures. Which makes it a good candidate for contrib IMHO. I'd suggest to revive https://www.drupal.org/project/signature, by the way..

Created a minimal module to display signatures in comments https://github.com/andypost/signature

+1 to use https://www.drupal.org/project/signature that will require some clean-up on names in the module.
Seem only thing is left to find a new maintainer for the module

reroll

Thanks for the explanation Berdir and the minimal module andypost. Can we get all of this stuff into the issue summary and a draft change notice, since there now seems to be (a) agreement that moving to contrib is a good idea and (b) demonstration of it actually working and (c) a patch to remove signature from core?

I was going to add the tags for change record and summary, but they're already present. ;)

Yes, moving to contrib is a good idea. #93 100% right.

Played with andypost's code and though it needs some work, it definitely does the gist of what the core version does. Thanks a lot for that.

Updated the issue summary. Also filed #2457017: Offering to maintain Signature for 8.x, unless there are other people dying to take it over. :P I pinged ultraBoy and jonaswouters via their D.o contact forms as well, per https://www.drupal.org/node/251466.

Marking RTBC, though I'd still love an answer to this:

One question is whether another way to resolve the critical is simply to remove views integration for the field.

...because the parent issue makes me extremely nervous as a critical. If there's any way of downgrading it to major by removing Views integration from these "rogue" fields and adding it back later once "major" fixes for these other issues land, that would be awesome.

Also this issue will open a way for #2031883: Markup for: comment.html.twig and #2002094: Improve performance of comment.html.twig to make comment templates and rendering faster and cleaner. Also this helps to #2428509: Comment links weight should be managed by view display so comment links and other user-defined fields could be reordered through field UI.
Yes, new module needs some love especially in access/translation cos we have no multilingual support for extra fields.

If there's any way of downgrading it to major by removing Views integration from these "rogue" fields and adding it back later once "major" fixes for these other issues land

I see bigger problem with comment templates because I'm sure that people more often will fight with templates/preproces wtf then use signature in views.

Ok, https://www.drupal.org/project/issues/signature is now looking more lively.

This still needs a change record.

I don't think Dries needs to sign off on this, but I'll be talking to him tomorrow so will commit it then, as long as the CR is ready.

Filed https://www.drupal.org/node/2457545
Probably CR to update https://www.drupal.org/node/2116417

Really sorry, yesterday got away from me.

Committed and pushed to 8.0.x. Thanks! So long to 4 years of work, sniff. ;)

looks not pushed

On behalf of @webchick I committed 7d31cc8 and pushed to 8.0.x. Thanks!

Maybe this change record should have been updated instead? (or in addition)
https://www.drupal.org/node/2116417
"Modules and themes removed from core in Drupal 8"

OH, this wasn't a module removed from core.. it was functionality that is to be replaced by contrib. Hm. I dont know if we have a group of things like that.

@YesCT that's why I ask in #101, maybe we just add new section to it with "functionality moved to contrib"? like layout module...

It seems like it would not hurt at all to add a note there!

Done https://www.drupal.org/node/2116417/revisions/view/7031041/8296917