Limit the amount of words used in titles

R_J

@keesha said:
How high are the chances for 2.3x that a "limit the amount of words used in titles" feature in the Dashboard/Advanced tab gets implemented?

I hope it will not be implemented because as I understand Vanilla, it offers not many config settings, but makes it really easy to do small changes. Wrap the below in a plugin, change "yourPluginName" accordingly and you have a plugin which does exactly what you need with just a very few lines of code.

    public function discussionModel_beforeSaveDiscussion_handler($sender, $args) {
        if (str_word_count($args['FormPostValues']['Name']) > c('yourPluginName.MaxTitleWords', 4)) {
            $sender->Validation->addValidationResult('Title', t('Don\'t be so expressive!'));
        }
    }

keesha

Uh wow thank's for the code, but why don't you just upload this plugin to the database? I'm kinda sure that a lot of people are going to love you for this one.

But anyway thank you for your help i appreciate it a lot.

R_J

Writing those few lines takes me 5-10 minutes. If I make it a plugin, I would create a GitHub repository, add some description and commenting and it would take me 30 - 45 minutes.

If you make it a plugin because you need it, it would be great if you would publish it! Those are just two lines of code, so I do not claim any rights on that at all. Make it your first plugin!
I somewhere have a HowTo plugin showing how to create a simple setting screen. Add this to the plugin to make it "complete". You will see that this is really easy

keesha

Allright, i'll try my best

K17

@R_J a dit :
Writing those few lines takes me 5-10 minutes. If I make it a plugin, I would create a GitHub repository, add some description and commenting and it would take me 30 - 45 minutes.

If you make it a plugin because you need it, it would be great if you would publish it! Those are just two lines of code, so I do not claim any rights on that at all. Make it your first plugin!
I somewhere have a HowTo plugin showing how to create a simple setting screen. Add this to the plugin to make it "complete". You will see that this is really easy

Done here ^^ https://vanillaforums.org/addon/titlelimit-plugin-1.0 with a settings page.
But @keesha you're free to do a new one ^^

R_J

That was fast, @K17!

I do not see any errors in there only some things I would solve in other ways and old coding standard: function names should start with a lower case letter, bools should be lowercase, config settings do not need a "Plugins." start any more, plugins folder/name in PluginInfo array should start with a lower case

• The plugin file should be all lower case
• The plugin class should be named TitleLimitPlugin => class TitleLimitPlugin extends Gdn_Plugin { (if you do so, you need to deactivate the old plugin before you upload the new version and enable it)
• You could spare some keystrokes in the setup() with the function touchConfig
• Instead of using two strings in a validation result (line 51 in your plugin), you should consider using sprintf
• Consider using Vanillas ConfigurationModule instead of building the config form by yourself.
• Although there is no standard and there really is no difference, I would use settingsController_titleLimit_create instead of pluginController_titleLimit_create. I prefer using SettingsController for the settings of a plugin and if the plugin has a functionality that needs "an endpoint" I use PluginsController, but that's really up to you.

K17

Thanks for feedback @R_J
I'm not à Good dev but I'll try this after ^^
But why put all of this lower case ? (It's a real question ^^ in dev I'm a newbie)

River

@K17 said:
Thanks for feedback @R_J
I'm not à Good dev but I'll try this after ^^
But why put all of this lower case ? (It's a real question ^^ in dev I'm a newbie)

https://vanillaforums.org/discussion/30598/coding-standards

http://docs.vanillaforums.com/developers/contributing/coding-standard

http://docs.vanillaforums.com/developer/plugins/quickstart/

I was going to refer you to the Example plugin referenced in the quickstart documentation, but it looks like it does not follow coding standards. Some of the other plugins follow coding standards but some also don't support the current version of php that is required for the stable version of vanilla, so you have to weave around, and use your best judgement.

R_J

I was going to refer you to the Example plugin referenced in the quickstart documentation, but it looks like it does not follow coding standards.

Here is an official example plugin with the current coding standards: https://github.com/vanilla/addons/blob/master/plugins/example/class.example.plugin.php

keesha

@K17 said:

@R_J a dit :
Writing those few lines takes me 5-10 minutes. If I make it a plugin, I would create a GitHub repository, add some description and commenting and it would take me 30 - 45 minutes.

If you make it a plugin because you need it, it would be great if you would publish it! Those are just two lines of code, so I do not claim any rights on that at all. Make it your first plugin!
I somewhere have a HowTo plugin showing how to create a simple setting screen. Add this to the plugin to make it "complete". You will see that this is really easy

Done here ^^ https://vanillaforums.org/addon/titlelimit-plugin-1.0 with a settings page.
But @keesha you're free to do a new one ^^

Alrighty

K17

Oh, I just see that I've post the TitleLilit link of 1.0 version only X) Here is the one who target the last version https://vanillaforums.org/addon/titlelimit-plugin

vrijvlinder

if there are any moderators here that can make this discussion appear under K17 plugin it would be helpful … because otherwise this discussion is less useful than it should be…

K17

@vrijvlinder True I'm sorry for this I "forget" what was the main topic here

R_J

@K17: I see you have problems with the title in the settings screen. There is a bug and you can only see the title after you have saved your settings. It should be translatable when you name your translation file /plugins/titleLimit/locale/fr.php (I've already used "titleLimit" here which should be the name following the current naming scheme.

K17

The bug with the title is here with plugins using the configuration module for me And when I tried to translate it, nothing happend.

@R_J

EDIT: I've just fixed the title problem. I'll upload a new version later.

R_J

It is a bug in configuration module which is already known and fixed in version 2.3: https://github.com/vanilla/vanilla/blob/release/2.3/applications/dashboard/modules/class.configurationmodule.php#L149

The most easiest way to avoid that bug is to use the code for the config module in that order:

$conf = new ConfigurationModule($sender);
$conf->initialize(...);
// Set title _after_ you have used $conf->initialize()!
$sender->setData('Title', t('...'));
$conf->renderAll();

Set the title after the initialize() and before the renderAll() method

K17

@R_J Yes, I've seen this I do this correction on the 1.4

River

R_J said:The plugin class should be named TitleLimitPlugin => class TitleLimitPlugin extends Gdn_Plugin { (if you do so, you need to deactivate the old plugin before you upload the new version and enable it)

this may be a good idea, and perhaps the most important to make plugin compatible with more versions of vanilla (past and perhaps future).

@K17
You did a nice job at following suggestions to improve your plugin, much easier to read, no clutter with debug statements, locale correct, and consistent syntax, good screenshots. Excellent.

At one time it was better to use and probably still better to use

class TitleLimitPlugin extends Gdn_Plugin {

class TitleLimitPlugin extends Gdn_Plugin { // more compatible and follows staff defacto conventions,

and NOT:

class TitleLimit extends Gdn_Plugin {     // causes issues with themehooks in older versions and does not follow conventions.

in some versions of vanilla not adding Plugin in the ClassName caused problems with mobile and themehooks,

it looks like Vanilla Staff still use this convention and although it might not cause a problem with your version of vanilla, you get a greater lifetime of plugin if you follow the defacto conventions even if the underlying reason in the plugincontroller has corrected the issue that was the cause of problems with mobile themehooks, testing for mobile etc.

that doesn't mean conventions won't change in the future, but it will be easier to notice if you follow the staff conventions, because it will be easier to notice changes, and you won't be left guessing what cause the issue, because you can see what the latest conventions is, even if they are not announced by looking at the changes at staff plugins as the versions increment.

whenever you change or add classes or locales or setup or structure in a plugin, or update an addon you should always disable and re-enable the plugin via the dashboard