Char counter for text/textarea fields

[bfncs]

Hi Matthew,

this shouldn't have anythind to do with the module itself, but you might try the following:

1. Delete everything related to the module from your /site/modules folder.
   
2. Use PHPMyAdmin or something similiar to look in the "modules" table of the database. Delete the entries named "TextareaCounter" or "TextAreaCounter".
   
3. Delete all files starting with "Modules." from your /site/assets/cache folder (ah, forgot this at first post...)
   
4. Install again as usual.
   

I haven't tested this in any way, but his hopefully helps.

Edit: Sorry to cause you problems with the rename, I just thought it would make more sense with the lowercase "a"...

[MatthewSchenker]

Hi boundaryfunctions,

I'll try that.

Another thing is that, sometimes, for whatever reason, when I do an update to my JQuery/JS elements, they stop working for a little while, then work properly again at some point. It might be a cache thing, I don't know.

Thanks,

Matthew

EDIT: I cleared out the entry from my file server. Then in PHPMyAdmin I discovered that -- yes, in fact, there was an entry for "TextAreaCounter" in the "Modules" table. I deleted that, then installed the module as normal and it is working great now.

EDIT EDIT: I think this one can be moved from "wish list" to "done list."

[ryan]

Tested here and works great! Thanks for making this Boundaryfunctions and Soma! I look forward to seeing this in the modules directory. This is a very useful module for sure.

Minor point, but longer term, I wonder about the hooking method and whether that might present problems for future InputfieldTextarea derivatives. This one specifically excludes TinyMCE, but feasibly there are future others it might need to as well. It makes me wonder if this module might better exist as an Inputfield itself (InputfieldTextareaCounter) or perhaps as a module config setting where you check boxes for which Inputfields it should apply to. Or perhaps as a core addition to existing InputfieldTextarea. These are just ideas for the future, but seems like what you've got here now is working great and I look forward to using it!

[bfncs]

Ryan, thanks a lot for looking into this, your feedback is very much appreciated!

You're raising a really valid point there, I didn't really think about problems with other derivates, but you're completely right. I think this should be approached before submitting to the modules directory because depending on the solution, it might block the easy update path for some users later.

I'm not so shure which of your proposed solutions, that all sound reasonable, is the way to go here. Thus my question about the module as an input field itself: would there be any problems for a user to change from a normal InputfieldTextarea to a InputfieldTextareaCounter and back? If this is trivial (as it looks to me), I think this might be the cleanest solution to do it. Otherwise I like the checkbox solution second best, but it requires more configuration knowledge (I already see the "Why is my InputfieldXY behaving strangely?" thread in front of my mental eye).

[Soma]

Tested here and works great! Thanks for making this Boundaryfunctions and Soma! I look forward to seeing this in the modules directory. This is a very useful module for sure.

Minor point, but longer term, I wonder about the hooking method and whether that might present problems for future InputfieldTextarea derivatives. This one specifically excludes TinyMCE, but feasibly there are future others it might need to as well.

if($field != "InputfieldTextarea") return;

I'm not completely getting it about derivates. But of course I wasn't thinking about all consequences and what would be best way to go. But Ryan think makes some valid points here.

Extending InputfieldText or Textarea and just create a field for having counters versus a module only with options to chose which text field has the counter might work, but would need to also be able to make counter settings for each individual. Damn so many options it's hard to see through

[bfncs]

The problem with derivates will occur, if someone adds another module where the counter doesn't fit in to InputfieldTextarea (like with TinyMCE). This won't break anything directly, because the counter only comes to action if you enter limits in the field configuration, but still this is something making it possible to do something wrong (and maybe don't get why).

The simplicity of if($field != "InputfieldTextarea") return; is a good idea to prevent this. On the other hand this will also prevent adding the counter to derivates of InputfieldTextarea where it actually would make sense.

The same is true for making it as a distinct field, because it wouldn't allow to add functionality with modules working with InputfieldTextarea hooks only, even if it makes sense.

Ryans proposed solution with a config setting to select on which variants of Inputsfields this should act would be the most flexible solution, but on the other hand, Soma, you're right about options everythere, this is really overcomplicating things for the clueless user.

I think all different methods mentioned here have their pros and cons, I'm not really sure, which one would be the best way to go. Maybe there are even more options?

[MatthewSchenker]

Greetings,

I've been using the counter developed in this thread, and it's terrific. I'm just digging into the code in recent days.

It does seem, as boundaryfunctions explains, that any solution has its limits. But for the sake of being straightforward so the client has no confusion, I think the current solution works well. Here's my thinking, based on the current project I am working on for an arts organization...

As the developer, I am always the one determining which fields are placed into the template: I have yet to have a client ask me if they can add a core field to their templates on their own! Therefore, I can figure out ahead of time whether or not I'm including a field that needs character/word limits, and I make sure that the type of field I include is correct for that purpose.

In those cases where the client is more sophisticated and wants to add fields themselves, they would be sophisticated enough to know which fields are capable of character limits.

One of the things I love about ProcessWire is that it keeps everything as clean as possible. Following this philosophy, I think the current use of the character limits element works best. It simply requires reasonable understanding from the developer or the client. (Extrapolating, I think the character limits element is a good example for other elements.)

Thanks,

Matthew

[bfncs]

Hey Matthew,

first, thanks a lot for testing and using it, I'm always glad if something is helpful to other and to get back feedback from it!

What you're pointing out there is something that I had in mind, too: the one activating the functionality for a field is usually a dev and should know what he or her is doing (i.e. don't add the counter for WYSIWYG textareas). Since you literally have to enter limits for every single field you want to use this with either way, the practical implications of the current behaviour shouldn't be too critical.

On the other hands: minimizing the chance for something to go wrong is always something to go for, assuming that the user will know what to do is never an execuse. Also it's tedious, to have to look up things in the documentation of each single module you use, even for the simplest things (reminds me of MODX the bad way...).

The discussion is also interesting, as this is a pattern that might be used by others modules, too. It would be great to have a working example for building this kind of field modification module (with validation and interactivity) using best practices that can be used in other places afterwards.

Just thinking out loud here, wouldn't it be possible for the Inputfield class to have a function isPlaintext() or even better to add an interface InputfieldHasPlaintextValue that modules with plain text values (no markup, no WYSIWYG, etc) would implement? On the one hand, this would make it easy in this case to check, whether the module is applyable and might be useful for others. On the other hand, I like that Pw isn't bloated with stuff like that myself, starting with this, where would you stop...

I'm leaning towards implementing Ryans proposal to have a module setting for this now. This should provide sensible defaults for all core module Inputfields and make it possible, to add the functionality to all derivates of InputfieldTextarea later. Tinkering with it when you're only using the basic functionality and nothing else wouldn't be necessary that way, but it still would be possible to add the functionality for all super custom fields you add later. In the module settings, this should be hidden enough for good I think.

[ryan]

Another factor to consider with the current solution is that it depends on an autoload module (executed on every request). That's a little less efficient than a solution that is specifically called upon when needed, as an Inputfield would be. From that respect, it would probably make sense for this to be InputfieldTextareaCounter. It would also be the simplest and most straightforward to implement and maintain. The drawback would be that you couldn't apply the counter functionality to other types of unknown future textarea derivative inputfields. But if someone is making a new text inputfield, chances are it's like TinyMCE, ACE editor or some other type of thing that wouldn't be compatible with the counter anyway. Ultimately the functionality provided here is pretty darn useful regardless of how it's implemented. But if I were implementing it myself, I'd probably make it an Inputfield rather than an autoload module. As a bonus, this would also guarantee compatibility with non-admin Inputfield forms, like those from FormBuilder, FormTemplateProcessor or API generated Inputfield forms.

[Raul]

Hi , 

I have tested this modul, but it doesnt work if the textarea is into a repeater field.

Is there some patch to apply for this?.

Thank you in advance.

Raul

[bfncs]

Hi Raul,

thanks for testing and posting! I'm pretty sure that you are right, but there's currently no ready-to-use fix for it. I doubt it would be too hard to do, but I currently don't have enough time. I already filed an issue on Github for it, though, and I hope that there will be a working fix soon.

With kind regards,

Marc

[Alex]

thanks this module is great!

[ceberlin]

The module does not work on my installation (with the latest PW dev installed):

I receive a 404 error

........ /wire/modules/Inputfield/InputfieldTinyMCE/tinymce-3.5.8/plugins/charcount_maxlength/editor_plugin.js

And indeed there is not such a folder charcount_maxlength within that wire directory.

EDIT: Maybe a false alarm. The offending plugin call charcount_maxlength was not anywhere in your code,

but buried in our field's settings for TinyMCE. I will check now how that entry came in there.

[bfncs]

Hi ceberlin,

this plugin is not intended for the use with a RTE editor like TinyMCE. It only works with plain textarea inputs.

[Martijn Geerts]

Great Module !

I just added a setting to truncate the inserted text instead of revert to the old text. I wished to do it the Gig Hub way, but I don't understand how to do that. I've put the changed module on my github account. ( sorry )

If you like it, maybe you can add it to your TextareaCounter module. 

[diogo]

I wished to do it the Gig Hub way, but I don't understand how to do that

You can do it even in the site. Just go to the file you want to change and edit it. They will ask you if you want to fork the whole project, you just have to say yes and edit the page to make a pull-request.

[Martijn Geerts]

Done, Thanks Diogo

[bfncs]

Hi Martin,

thanks a lot for adding this option, very nice!

Because of the Github trouble, I manually created a patch from your changes and commited it:

https://github.com/boundaryfunctions/TextareaCounter/commit/f740d8f8

I recognized that your repository is not actually a fork of mine from a Git point of view, and this is what made it complicated. The normal development model is "Fork and Pull" and should more or less include these steps:

1. Create a fork of the repository you want to work on.
2. Clone your fork to your computer, create a new branch and do all changes on one topic in there.
3. Push that branch to your fork on Github.
4. File a pull request.

With kind regards,

Marc

[Martijn Geerts]

Hi Marc,

Thank you very much adding the truncate option & and the detailed description for the path to follow using git.

Many thanks,

Martijn

[ceberlin]

Hi, the module is only checking the presence of tinyMCE and not of CKeditor, is this correct?

[Joss]

How to get round problems with form builder with this module?

It is throwing errors both on saving a form and when I submit the form on the site - though the form is working.

Notice: Trying to get property of non-object in /home/claysvehiclerepairs/public_html/site/modules/TextareaCounter/TextareaCounter.module on line 50

 

Notice: Trying to get property of non-object in /home/claysvehiclerepairs/public_html/site/modules/TextareaCounter/TextareaCounter.module on line 58

 

Notice: Trying to get property of non-object in /home/claysvehiclerepairs/public_html/site/modules/TextareaCounter/TextareaCounter.module on line 66

 

 

Thanks!

[Soma]

It's simply that the module isn't made for Formbuilder. This module needs a Field to work with. Formbuilder doesn't use Fields, only Inputfields.

It's failing in these here:

$value = $this->fields->get($event->object->name)->maxchars;

https://github.com/boundaryfunctions/TextareaCounter/blob/master/TextareaCounter.module#L50

Hi, the module is only checking the presence of tinyMCE and not of CKeditor, is this correct?

That's correct.

[Joss]

I wasn't sure it had been changed - I noticed a post from Ryan a couple of pages back about making it compatible.

I am not actually trying to use it with formbuilder at all - it is just generating the error all on its own

[Soma]

Whut?

I remember that was about with Textareas Profield not Formbuilder.

Huh? You wrote you try to use it with formbuilder. 

[Joss]

Nope - it is just throwing that error when I use formbuilder. 

It is when debug is on. When you save a form that includes a textarea, you get the error and when you use the form in the front end I also get the error. But this is happening simply because the counter module is installed on the system, not because I have tried to include it in a form.

Ryan's comment is here:

https://processwire.com/talk/topic/2343-char-counter-for-texttextarea-fields/?p=22901