Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Try Vanilla Forums Cloud product
Vanilla 2.6 is here! It includes security fixes and requires PHP 7.0. We have therefore ALSO released Vanilla 2.5.2 with security patches if you are still on PHP 5.6 to give you additional time to upgrade.

Limit the amount of words used in titles

R_JR_J Cheerleader & TroubleshooterMunich Moderator

@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!'));
        }
    }
keeshadata66

Comments

  • 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_JR_J Cheerleader & Troubleshooter Munich Moderator

    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 =)

    data66
  • Allright, i'll try my best :)

    R_J
  • K17K17 Unlosk · Français / French ✭✭✭

    @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_Jvrijvlinderkeeshadata66
  • R_JR_J Cheerleader & Troubleshooter Munich Moderator

    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.
    rbrahmsonhgtonight
  • K17K17 Unlosk · Français / French ✭✭✭

    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)

  • RiverRiver MVP
    edited August 2016

    @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.

    Pragmatism is all I have to offer. Avoiding the sidelines and providing centerline pro-tips.

    K17
  • R_JR_J Cheerleader & Troubleshooter Munich Moderator

    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

    K17data66
  • @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 :pleased:

    K17
  • K17K17 Unlosk · Français / French ✭✭✭

    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

  • vrijvlindervrijvlinder Papillon-Sauvage MVP

    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…

  • K17K17 Unlosk · Français / French ✭✭✭

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

    vrijvlinder
  • R_JR_J Cheerleader & Troubleshooter Munich Moderator

    @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.

  • K17K17 Unlosk · Français / French ✭✭✭
    edited August 2016

    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_JR_J Cheerleader & Troubleshooter Munich Moderator

    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

  • K17K17 Unlosk · Français / French ✭✭✭

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

    River
  • RiverRiver MVP
    edited August 2016

    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

    Pragmatism is all I have to offer. Avoiding the sidelines and providing centerline pro-tips.

    vrijvlinderK17Terminator
Sign In or Register to comment.