Word Counter for D7

I've made some modifications to create a word counter.

It isn't perfect, by any means. The JS doesn't have a good way to prevent you from typing more words, so it just relies on the form validation when you submit to complain. Also the word count is occasionally off by 1.

Hi cthos, i am looking for this too to limit by number of words not characters on my formulaires. How can i apply this patch you ve created to the Maxlength module?

When you're setting up the maxlength area for a field, a new dropdown will appear called "Maxlength Type". Set that to "Word", and you're good to go. (Though you will have to manually change the text for the countdown).

I've attached a screenshot showing the elements.

Also, "Force Text Truncate" and "Truncate html" don't do anything in word mode.

Hi @cthos i apply your patch and it shows the new option to select Word maxlegnth type, i enable it and i see that the counter goes counting by word on my text area field while a user types, but, it stops letting user to write more words at 300 characters, not words. For example i need that the user submit in a form a resume of no more than 300 words, i set up in the limit 300 and select "Word" in maxlegnth type. i paste in the text area a dummy example text of exactly 300 words for test it, but it only paste like 50 words not letting me to write more than this. So as i see it is limiting the text area to 300 characters, not 300 words as i setup using your patch.

Is this way how it works for you?

I attach my text area field setup with maxlength.

No, I haven't seen any issues with that on my patch (screenshot). You'll want to make sure your browser is not caching the javascript.

Are you using CKEditor for your editor? That and plain text are the only ones I've tested.

I had the same problem as elvismdev. Fixed it and created a patch.

Thanks @mikespence, i got tested and this patch works pretty good. While typing and it arrives to the words limit specified (300 words in my case) it blocks me to type more words than that, leaving an offset of -1. At this point all good.

Making more tests: If i copy and paste a text of more than 300 words, for example 600, it allows to paste all the 600 words giving me the bottom warning that i am out of words left. This makes sense for me so i think is OK. But if i anyway try to submit this form with the 600 words skipping the warning, the popup message that appears ("Please shorten this text to 3990 characters or less (you are currently using 3990 characters).") counts it by characters as you can see.

This is just a tip for debugging if you want to improve more this patch. For me works good but it can be still better. hope the developers apply it. :)

Agreed, thanks to @mikespence.

@elvismdev - It's weird that it's still telling you characters on the submit flow, since it is supposed to remove the #maxlength param from the element it's validating (which is the thing that's giving you the character warnings).

What editor are you using? I'll see if I can make it a bit better.

I am using this field as plaint text only, no need of editor. I update the experience cause now seeing your post i have tested more. The results for me is that this only happens in Google Chrome and when is forcedly pasted a text of 2 paragraphs exceeding between the two of them the size of words allowed. In Mozilla Firefox this test run just ok and the patch works as expected.

Screenshot of the warning after pasting only one paragraph of 600 words it self (limit=300) and trying to submit the form with oversized words: (this way works in firefox and chrome ok)

Now try this in Firefox and Google Chrome after:
Set a word limit to 300 for example and paste 2 paragraphs within 300 words in each one (total 600 words). Then submit the form. In Firefox it will just show the warning red message as above image, but in chrome it displays this popup

That's very interesting, I'll see if I can find out why it's doing that.

Just a quick note on your patch, @mikespence.

$wordArray = explode(' ', trim($value));

The reason I did preg_split in the original patch is to account for multiple spaces in the middle of the string. Trim only strips off whitespace from the beginning and the end of the string. Example:

bash-3.2$ php -r "var_dump(explode(' ', trim(' a   d    e ')));"
array(8) {
  [0]=>
  string(1) "a"
  [1]=>
  string(0) ""
  [2]=>
  string(0) ""
  [3]=>
  string(1) "d"
  [4]=>
  string(0) ""
  [5]=>
  string(0) ""
  [6]=>
  string(0) ""
  [7]=>
  string(1) "e"
}

Second thing:

textarea.attr("maxlength", len);

That's pretty genius as a way to prevent further submission, but it's probably leading to what @elvismdev is seeing in Chrome. I'll tinker a bit and see what I can do to get that working.
For more info on that problem: http://tjvantoll.com/2012/10/17/maxlength-constraint-validation-oddities/

Okay, so I made some modifications to @mikespence's patch which should make it a little bit cleaner.

1. There's nothing I can do about chrome trying to validate when maxlength is on, so I changed the message to use "words" instead of "characters", and wrapped it in Drupal.t
2. Reinstated preg_match in the php side of things for reason listed above.
3. Made the #maxlength solution pay attention to options.enforce (which is the "force truncate" option in the field's settings. If it's not on, it shouldn't force you to stop typing.

Thanks everyone who's working on this! Anyone out there want to see about getting this included into the module? >_> ... <_<

It works like a charm @cthos! this is already a must for this module, ¿{developers}? give a test and apply the patch!

The patch works, but it has one small bug: the remaining word counter starts off at limit - 1, even when no characters have been typed yet. (The character countdown doesn't have this problem.)

To solve it I added a simple character-count check, so if the text area contains no characters, the word count is by definition 0. Around line 164 of js/maxlength.js:

    if (text.length == 0) {
      count = 0;
    }
    else {
     count = words.length; 
    }

The patch supersedes the one at #14.

New patch, just because there was a missing space in the indentation on line 168.

@antiorario - Nice catch!

+++ b/js/maxlength.jsundefined
@@ -113,6 +124,94 @@
+      count = words.length; ¶

extra space on the end of the line.

+++ b/js/maxlength.jsundefined
@@ -113,6 +124,94 @@
+      var len = textarea.val().length;
+        ¶

unnecessary indentation on a blank line.

+++ b/maxlength.moduleundefined
@@ -68,6 +82,21 @@ function maxlength_form_field_ui_field_edit_form_alter(&$form, &$form_state, $fo
+       '#description' => t('The text used in the Javascript message under the input, where "@limit", "@remaining" and "@count" are replaced by the appropriate numbers.'),

This strikes me as odd since t() tries to handle @whatever tokens. Should this not be encoding (or something) the @ sign instead? Maybout that's out of scope for this patch since I see clear removal of a similar line later, but it did give me pause.

I am in no way endorsing the patch save these issues, just trying to review the stuff that I know is wrong still. If the maintainer likes this, there seem to be very few style issues left.

Also, please try to roll interdiff patches with these things. It makes it a TON easier to read what changes from one patch to the next.

Eclipse

+++ b/maxlength.moduleundefined
@@ -68,6 +82,21 @@ function maxlength_form_field_ui_field_edit_form_alter(&$form, &$form_state, $fo
+       '#description' => t('The text used in the Javascript message under the input, where "@limit", "@remaining" and "@count" are replaced by the appropriate numbers.'),

That line exists in the main line, and I believe it is like that because it later runs through t() again to parse out those variables when it renders the actual element, so it's illustrating how you would do the replacements.

I'd guess that t doesn't replace anything it doesn't have in its parameters array so it should be fine?

Thanks for the review @EclipseGC, I'll fix the whitespace issues sometime tonight.

could you attach a .patch file with this last changes?

Here's the full patch with the corrected whitespace. I've included the interdiff at @EclipseGC's request.

Looks good! I think this would be quite useful. +1 and kudos.

Sorry to bother all you lovely people - I have the new code, but can't seem to get the "characters or words" setting to appear... I have run an update and cleared cache, but no love.
Sorry, I know I am a ditz, but could someone help me out? Is it because there is already data in the database? If so, can that be ignored somehow?

Not enough coffee in the world, really...

Thank you so much!

Ok, I am sorry. My bad. I guess I didn't clear enough cache somewhere, because it is showing up now... that is, except for IE9, which may be an entirely different issue. Thanks, everyone! :)

@justkristin - I didn't test IE9 specifically, but there shouldn't be anything weird which is preventing it from showing up. I'll look into it!

Do we need to apply a different patch before the patch in #23? I applied only wordcount-1496570-19.patch and got this error message in my console:

Uncaught TypeError: Object #<Object> has no method 'ckeditorWordChange'

I checked some of the past patches and it looks like the first one declares the ckeditorWordChange function but none of the following ones do...? Did I do something weird?

@drclaw - No, it looks like somewhere along the line it got nuked. I'll make another patch.

Readding the missing CK method.

@drclaw - You should just be able to apply this patch.

Awesome. Thanks!

C'mon, let's get this patch committed.

Just one suggestion to improve the patch.

The maxlength_validate_input() function on L209 of maxlength.module reads:

$wordArray = preg_split('/\s+/', $value);

I would suggest replacing that with:

      $trimmed_value = trim($value);
      $wordArray = preg_split('/\s+/', $trimmed_value);

This will remove any whitespace at the beginning and end of the input. For instance, I have a 500 word limit and I type 500 words, but put a trailing space at the end then the JS counter tells me I have 500 words and 0 words left, but the PHP code counts that space as another word and I get an error when I try to submit.

(Yes, I have a very picky client who insisted this be fixed.)

@dieuwe

Nice catch, I've rolled that into the patch.

Are these patches rolled against the 3.x-dev branch? I haven't been able to get them to apply to a fresh copy.

@mraichelson

Yep, it's 3.x-dev, but it looks like someone updated 3.x-dev a couple of days ago which might have conflicts with this patch. I'll reroll it when I get a chance. In the meantime you should be able to apply it to the HEAD^ commit in that branch.

There are actually tons of conflicts between this patch and the latest dev. I've stopped trying to make sense of them for today. Any volunteers?

Yeah, I've been pretty swamped with other things lately and haven't had a chance to work on it yet. :/

Yeah, I've been pretty swamped with other things lately and haven't had a chance to work on it yet. :/

Hello I have downloaded both 7.x-3.0-beta1 and 7.x-3.x-dev and none seem to have the word count feature. Please advise.thanks

this is definately a good feature to have, looking for this myself.. i was happy to see this was put in place but it seems that the latest --dev does not have it due to it breaking? I have the latest --dev now, but no option to set between character/word count. Any update on this?

Or how would one apply the --dev branch before the commit that takes it away (#34)?

Great,

I dont have much experience in Drupal, but looking at this module as it is now, can someone help or point directions on how to accomplish:
1 - setting up a price per word
2 - pickup the wordcount in real time while the user is typing and display an extra field with the current price
3 - When the user press save send to an ubercart checkout to pay

many thanks in advance

jomadpt, your comment is only tangentially related to this issue, so you should open a new issue with your request. However, since the word-count functionality is not yet officially in the module, and what you need (as far as I understand) sounds more like development advice/support, maybe it would be more at home in a section of the general forum.

Like others I could not successfully apply patch #34 to version '7.x-3.x-dev'. Therefore I manually applied the patch rows to files 'maxlength.js' and 'maxlength.module'. After adding the following line to function '_maxlength_add_maxlength_attributes()' the word counting option seems to work:

  $element['#maxlength_js_type'] = isset($element['#maxlength_js_type']) ? $element['#maxlength_js_type'] : $settings['maxlength_js_type' . $suffix];

Possibly there are other inconsistencies between patch and dev version. But at least I made a step forward (I think). For convenience I attach the versions of 'maxlength.js' and 'maxlength.module' after my manual correction attempt.

Kind regards,
baso.

@baso -- this your comment worked for me!

Rerolled patch based on #44 and a few changes along the way like: there were 2 returns in maxlength_help() like they would be output after each other.

Rerolled patch on #46 to the latest dev and a few changes to acomplish coding standards

The word counter works fine for me - thanks!

(Do note that the patch doesn't apply to the 7.x-3.0 version, but does apply cleanly to the latest dev.)

Please can we get this added into the module?

Thanks for working on and testing this nice improvement to the maxlength module!

Patch #47 removes code related to permission "bypass maxlength", by mistake I assume.

I would also really appreciate if the code styling fixes where moved to a separate patch.

Hi,
when i apply the patch on comment #47 i get this error:
Notice: Undefined index: maxlength_js_type in _maxlength_add_maxlength_attributes() (line 198 of ..maxlength/maxlength.module).

Since #47 wasn't working against the latest dev, here's a new one, which seems to be working well. I restored the missing bypass functionality, as per #49.

#51 works great with the latest version!
Thanks antiorario and people who made this functionality!

Still works with the latest dev. Committing it would be good.

currently throws the following error:
Undefined index: maxlength_js_type in _maxlength_add_maxlength_attributes() (line 245 of /var/aegir/platforms/fv-7.39/profiles/family_violence/modules/contrib/maxlength/maxlength.module).

This module is an alternative if you are using EntityForms...

https://www.drupal.org/project/field_validation

Rerolled patch on #51 to the 3.2.

facine
I have applied your patch to maxlength (version 3.2) I'm able to select the Maxlength Type to "Word" but i'm getting the following error "Notice: Undefined index: maxlength_js_type_summary in _maxlength_add_maxlength_attributes() (line 220 of C:\xampp\htdocs\drupal754\sites\\modules\maxlength\maxlength.module)." I'm using drupal 7.54 version. Is there anything that I've missed? I have also tried with maxlength (version 3.x-dev) but that just doesn't work

Has anyone found a solution for the issue of php notices filling up in the drupal logs.

Notice: Undefined index: maxlength_js_type in _maxlength_add_maxlength_attributes() (line 220 of /var/www/html/sites/all/modules/contrib/maxlength/maxlength.module).

Removing my assignment because I'm not working on this anymore

We are putting a feature freeze on the Drupal 7 version of the module, so I'm marking this Closed, won't fix. I'm also changing the priority from Critical to Normal. I see the appeal of this feature, but keeping the module focused on character counts makes for a lightweight, simple module.

Thank you everyone for working on this issue. If you do want to maintain the Drupal 7 version, do reach out. We'd be happy to bring you on board as a maintainer and work to commit this to the project.