Integration with token (new branch request) [#318443]

It would very nice to have integration with token module
I mentioned it in #318438: Support for other kind of default subjects but there I proposed the code to provide other kind of default values to subject without integration with token, so I'm opening this issue to follow up a different feature request.
previous issue #231245: Support tokenization for comment pattern ended with a translatable request for "Re: " (also it was for version 5.x), so this is not a duplicate, also use cases are requested, well there are provided in #318438: Support for other kind of default subjects
Certainly being more flexible won't harm as long as default configuration be naturally the most common.
Also, integration with token won't make this module dependent, only optionally detect if token is available.

Comment	File	Size	Author
#21	2009-09-15 token_support.patch	17.98 KB	arhak
#21	2009-09-15 comment_subject 6.x-2.5.zip	11.12 KB	arhak
#15	2009-09-14 comment_subjects 6.x-0.3.zip	3.86 KB	arhak
#11	2009-09-13 comment_subjects.zip	3.65 KB	arhak

Comments

Comment #1

ahoeben commented 8 October 2008 at 09:23

Status:

Active

» Closed (won't fix)

Still fail to see the use cases.

Comment #2

ahoeben commented 8 October 2008 at 13:55

Status:

Closed (won't fix)

» Active

Reconsidering...

Comment #3

arhak commented 8 October 2008 at 19:22

I'm glad to hear about it

Comment #4

juroon commented 29 January 2009 at 09:10

Is it possible to add the user's name to the end of the generated subject by customizing something somewhere? Tokens would do it, but any way would help. I need this on a multi-user blog where /blogs/posts is the main page, and recent comments show up in a block on the side so the user doesn't have to go fishing to see if there's anything new on any of the blog posts. I'm using Comment subjects to force some consistent information to show up in the recent comments block, but I still need to see who posted in the block as well. (Users don't need to have any control over the subject, in fact I'd prefer they didn't.)

I've looked at the related threads, and I hope this is the right place to post this. Apologies if it's not.

Comment #5

mpaler commented 5 February 2009 at 18:32

This might be the same user case a jaroon is suggesting...but it would be great to include the username of the user whos comment/node is being replied to...

For example:

User1 posts a topic: "Here's my topic"

User2 replies: "Re:[User1] Here's my topic"

User3 replies to User 2: "Re:[User2] Here's my topic"

User4 replies to User 1: "Re:[User1] Here's my topic"

My specific use case if for a forum. I realize a threaded comment listing can solve this, however, for a flat list, this could be really useful...

I'm going to go ahead and attempt to hack this in, however I'll be following along here as well.

Mike

Comment #6

mpaler commented 5 February 2009 at 22:28

Here's what I did, just in case any body is interested...for version 5.x



// $Id: comment_subject.module,v 1.3.2.6 2008/11/06 08:49:37 ahoeben Exp $

/**
 * Implementation of hook_form_alter().
 */
function comment_subject_form_alter($form_id, &$form) {
  if ($form_id == 'comment_form' && $form['subject']['#default_value']=='') {
    switch (arg(0)) {
      case 'node':
        $node = node_load(array('nid' => arg(1)));
        $subject = $node->title;
	    $to = $node->name;
        break;
      case 'comment':
        if (arg(1)=='reply') {
          if (is_numeric(arg(3))) {
            $comment = _comment_load(arg(3));
            $subject = $comment->subject;
                $to = $comment->name;
          } else {
            $node = node_load(arg(2));
            $subject = $node->title;
	        $to = $node->name;
          }
        } else if (arg(1)=='edit' && is_numeric(arg(2))) {
          $comment = _comment_load(arg(2));
          $subject = $comment->subject;
	      $to = $comment->name;
        }
        break;
    }
    if (!preg_match('/^' . preg_quote(t('Re:')) . '/i', $subject))  { // no "Re:" so add one
      $subject = t('Re:') . ' ['. $to .'] ' . $subject;
    } else if  (!preg_match('/\[.*\]/i', $subject)) { // Re: but no username, so add it
      $subject = preg_replace( '/^' . preg_quote(t('Re:')) . '/i' , t('Re:') . ' ['. $to .'] ', $subject);
    } else { //Re: and username, so replace username
      $subject = preg_replace( '/\[.*\]/i' , '['. $to .']' , $subject);
    }

    // comment subjects can not be longer than 64 characters
    $subject = truncate_utf8($subject, 60, TRUE, TRUE);

    if (variable_get('comment_subject_field', 1) == 1) {
      $form['subject']['#default_value'] = $subject;
    } else {
      // comment subject disabled in comment settings
      $form['subject'] = array('#type' => 'hidden', '#default_value' => $subject);
    }
  }
}

Comment #7

skizzo commented 24 February 2009 at 19:26

While you are at it... would it be very hard to include the comment number?
That's what they use in drupal.org. I have no programming skill, so I can't tell
whether this is feasible or not. Alternative suggestions are welcomed. Thank you.

Comment #8

arhak commented 20 March 2009 at 14:48

@skizzo
I made a version of comment_subject which does it, check it over here
It also solve another issue
BUT bare in mind it was just a demo, not a clean solution, it works fine, I used it on a live Intranet issue tracker
I'm still waiting for comment_subject to have token integration

Comment #9

skizzo commented 20 March 2009 at 17:39

Thank you so much arhak, that's exactly what I needed.
Even without token integration it is very handy.

Comment #10

arhak commented 15 June 2009 at 15:35

Version:

6.x-1.3

» 6.x-1.4

Comment #11

arhak commented 14 September 2009 at 03:54

Status	File	Size
new	2009-09-13 comment_subjects.zip	3.65 KB

a first draft of how token integration might be provided
I kept token as an optional module instead of a required dependency
nevertheless, even without token module a couple of replacements will be available i.e. [parent-title] & [auto-increment]

the uploaded module is named comment_subjects to allow co-existence with current release of comment_subject (for testing just enable one or the other)

Comment #12

arhak commented 14 September 2009 at 03:55

Status:

Active

» Needs review

by the way, lets change it to "needs review"

Comment #13

skizzo commented 14 September 2009 at 07:19

is the [comment-cid] token the equivalent of [auto-increment]? Indeed, I do have the token module enabled, but when using [comment-cid] I get an empty field (instead of the expected auto-increment counter). Thank you.

Comment #14

arhak commented 14 September 2009 at 08:03

@#13 no, they are not the same
actually [comment-cid] shouldn't be available as a token replacement at all, since the comment doesn't exists yet and can't have any cid by that time

I think it should also support [comment-cid] but it will need some work to handle it
If the big picture of this revamp gets committed I should attend that issue

actually [auto-increment] was thought for "#[auto-increment]" like this issue queue, but unique sequence numbering will be guaranteed for concurrent posts only if users aren't allowed to edit the subject field in comments

Comment #15

arhak commented 14 September 2009 at 08:52

Status	File	Size
new	2009-09-14 comment_subjects 6.x-0.3.zip	3.86 KB

- added support for [comment-cid]
- renamed token [auto-increment] in favor of [auto-numbering]
- enforce validation: using [comment-cid] and/or [auto-numbering] requires Comment subject field to be disabled

Comment #16

arhak commented 15 September 2009 at 04:10

I have improved the proposed draft for token integration,
but won't provide updates here since this issue hasn't been attended but the maintainer yet

If the maintainer ask for updates I will provide them
or else, a new module would need to be created, in that case refer to the forum post Looking for a CVS committer

new fixes include:
-- support for all [comment-*] tokens
-- uniformity for new provided tokens (make them comment- prefixed)
-- providing more tokens like [comment-pid], [comment-parent-title-raw], ..
-- improved validation enforcement and validation error reporting
-- ...

Comment #17

skizzo commented 15 September 2009 at 08:52

@#14. Thanks. I missed [auto-numbering] at first, as it was way down in the list of allowed tokens. Using flatcomments and having disabled subject editing, one thing I would like to see would be something like #17 (Re:14) when replying to #14 (and simply #N for add new comment). I tried with #[auto-numbering] (Re:[parent-title]) but I get #17 (Re:), possibly because of flatcomments module. Even if it worked, I wouldn't know ho to avoid recursion in subject...

Comment #18

arhak commented 15 September 2009 at 09:40

recursion won't be a problem, setting Default subject's prefix to Re: will avoid repeating the "Re:" prefix whenever it is already present

... mmm .. sorry, that isn't your case, you wan't more complicated stuff

interesting, I think it should also be supported

but we are talking about feature requests on top of pending acceptance of the proposed draft
help me out to encourage the maintainer of this module to commit token support
or help me find a CVS committer (explained in previous comment #16)

then we can go farther

Comment #19

arhak commented 15 September 2009 at 11:20

Title:

Integration with token

» Integration with token (new branch request)

@#17 I figure it out, instead of having a fixed "non repetitive prefix" and a default subject with token replacements I will provide (next release will have to wait for the maintainer to open a new branch) a [comment-subject-prefix] token which will be configured the same way but gains capability of being placed wherever you want

for example, suppose bellow is the comment settings form

Non repetitive prefix:
Re:
Default subject:
#[comment-auto-numbering] [comment-subject-prefix][comment-parent-title]

then the [comment-subject-prefix] will get replaced with "Re:" for that content type's comments according to configurable "Non repetitive prefix" textfield
[comment-parent-title] will get replaced with the parent's title
BUT the replacement of [comment-subject-prefix] will also watch out that the following resulting substring doesn't contains the prefix already

just a pending problem for which I request your help:
how to describe such behavior?

I need a synthetic sentence to describe what [comment-subject-prefix] does
any suggestion?

Comment #20

arhak commented 15 September 2009 at 11:34

marked #569828: Add support for replacement patterns to prevent repetitive subject lines as a duplicate of this issue

Comment #21

arhak commented 15 September 2009 at 17:16

Status	File	Size
new	2009-09-15 comment_subject 6.x-2.5.zip	11.12 KB
new	2009-09-15 token_support.patch	17.98 KB

Note: the attached patch (and the zipped module as well) have comment_subject version 2.5 which DOES NOT exists

this is JUST for testing purposes, the maintainer of this module hasn't opened a 2.x branch yet

NOTE that previously attached module was named slightly different, but was discouraged by other developers, therefore now it has the same name as the existing module

remember that token support implied a total revamp of the whole module

Comment #22

arhak commented 15 September 2009 at 17:42

use cases

-- for comment #17 of this thread: after considering other use cases I change it a little
Non repetitive prefix:
#[comment-auto-numbering] Re:
Default subject:
[comment-parent-title]
Non repetitive suffix:
leave it empty

resulting "#1 Re: title", "#2 Re: title", etc

-- for issue #569828: Add support for replacement patterns to prevent repetitive subject lines
Non repetitive prefix:
Re:
Default subject:
[comment-parent-title]
Non repetitive suffix:
- [comment-author-name]

resulting "Re: title - UserA", "Re: title - UserB", etc

-- for current functionality of comment_subject 1.4 (the default configuration which is)
Non repetitive prefix:
Re:
Default subject:
[comment-parent-title]
Non repetitive suffix:
leave it empty

resulting "Re: title", "Re: title", "changed title", "Re: changed title", etc

-- for issue tracker comments
Non repetitive prefix:
leave it empty
Default subject:
#[comment-auto-numbering]
Non repetitive suffix:
leave it empty

resulting "#1", "#2", "#3", etc

-- mailing lists like
Non repetitive prefix:
[[site-name]] Re:
Default subject:
[comment-parent-title]
Non repetitive suffix:
leave it empty

resulting "[Site Name] Re: title", "[Site Name] Re: title", "changed title", "[Site Name] Re: changed title", etc

Comment #23

skizzo commented 16 September 2009 at 15:02

I surely would like to see token support included in comment_subject rather than branching off a new module (http://drupal.org/node/23789). It would allow to use flat display (see http://www.lullabot.com/articles/drupal_usability_comment_configuration) while retaining some referencing info, in titles rather than through indentation. If it is not possible to include token support in the current module, then I would rather keep providing it as a patch; but I am not a developer, so I am not sure about the implications (in anyway, couldn't you gain CVS access through a proxy?).

Finding a concise and clear wording for token description is not easy: I would rather provide few examples (in content type configuration page) and let the users find their way

Re: #17, after installing the latest zip file, I have not managed to achieve the intended pattern, i.e.:

#17 Re:#14
#18 Re:#17
#19                (or #19 Re: Node Title , in response to original post)
#20 Re:#12

maybe [comment-parent-number] is needed? I guess that it could only be "extracted" from parent title (when applicable), right? Thank you.

Comment #24

arhak commented 16 September 2009 at 18:39

@#23

in anyway, couldn't you gain CVS access through a proxy?

haven't tried using yourfreedom, but that would be painful
I currently surf behind several proxies, my current bandwidth is too tight, adding yourfreedom on top of it would kill me

I was thinking about another develper with a CVS account that would be able to publish a repository through http, kind of Git/Mercurial, then I would be able to commit to that repo (out of drupal.org) and the developer would commit major branches to drupal.org on my behalf
am I asking too much? It might be painful for that developer

Comment #25

arhak commented 16 September 2009 at 18:46

@#23

If it is not possible to include token support in the current module, then I would rather keep providing it as a patch; but I am not a developer, so I am not sure about the implications

if at least the maintainer of this module opens a branch for it then it would make sense
otherwise, providing a patch which totally revamps current release would be non-sense

I already tried to contact the maintainer of this module through his contact form, but got no response at all
I can't request become co-maintainer since I wouldn't be able to commit through CVS
I'm trapped

PS: in spite of the above, maintaining another patch without being really necessary... phew

Comment #26

arhak commented 16 September 2009 at 18:54

@#23

maybe [comment-parent-number] is needed? I guess that it could only be "extracted" from parent title (when applicable), right?

right, I already added support for [comment-pid] (the cid of the parent comment if there is such), but I didn't thought about [comment-parent-auto-numbering] which makes a lot of sense

now
how am I supposed to attend isses (either bug report or features requests) through a patch
it would be untraceable!

it would be really necessary to open a new branch to go on with this

by now I will prioritize bug reports, then If I find the time I would add requested features

PS: please, help me out in finding a way to get a new branch opened
better if it comes with a new co-maintainer who be able to listen to the proposed patches,
otherwise, help me find a CVS committer with the will to commit on my behalf

Comment #27

arhak commented 16 September 2009 at 19:37

I'm asking for a developer available to become a co-maintainer of this module http://groups.drupal.org/node/26952
who's only tasks would be:
- open a new branch 2.x
- commit patches marked RTBC

Comment #28

arhak commented 18 November 2009 at 16:00

Version:	6.x-1.4	» 6.x-2.0-alpha1
Status:	Needs review	» Fixed

all bug reports and feature requests go now to 6.x-2.x branch

Comment #29

arhak commented 1 December 2009 at 05:43

Status:

Fixed

» Closed (fixed)

almost two weeks now, I'm closing it to clean up the issue queue

Integration with token (new branch request)

Comments

Comment #1

Comment #2

Comment #3

Comment #4

Comment #5

Comment #6

Comment #7

Comment #8

Comment #9

Comment #10

Comment #11

Comment #12

Comment #13

Comment #14

Comment #15

Comment #16

Comment #17

Comment #18

Comment #19

Comment #20

Comment #21

Comment #22

Comment #23

Comment #24

Comment #25

Comment #26

Comment #27

Comment #28

Comment #29

News items

Our community

Documentation

Drupal code base

Governance of community