Noindex based on min word count?



  • R_JR_J Cheerleader & Troubleshooter Munich Moderator

    Normally simple things like that either work or they don't. Is it possible that "this little hack/plugin is no longer working consistently" is based on a misunderstanding on what the plugin should do/can do?

    hgtonight adviced you to "passing the bodies through the format class like @x00 did". The difference of counting the words in the body and counting the words in the body formatted to text might be enormous if a discussion contains a lot of links and text formattings. That would be counted as words although you cannot see them when they are displayed.

    Furthermore you simply added the code snippet to a plugin template without reading or understanding what is in there. One of the more intersting lines in the plugin is this: 'MobileFriendly' => FALSE, // Should this plugin be run on mobile devices?. You can read it like that:
    Question: Should this plugin be run on mobile devices?
    Answer: No.

    Therefore that optimization wouldn't work for all clients. Not sure how search engines do their crawling but I would always consider that they also might crawl you mobile pages. Since you haven't changed that line, this optimization has never been effective for mobile agents.

    But coming back to your question: change this

        $threshold = C('AutoNoIndex.Threshold', 300);
    $discussion = val('Discussion', $sender, false); if($discussion === false) {   return; } $wordCount = str_word_count($discussion->Body);
        if($wordCount >= $threshold) {

    to that

        $threshold = C('AutoNoIndex.Threshold', 300);
        $discussion = val('Discussion', $sender, false);
        if($discussion === false) {
        $wordCount = str_word_count(Gdn_Format::text($discussion->Body));
        if($wordCount >= $threshold) {

    and this

            $wordCount += str_word_count($comment->Body);

    to that

            $wordCount += str_word_count(Gdn_Format::text($comment->Body));

  • edited July 2017

    Thank you and I had no idea about the mobile exclusion. Very important!

  • phreakphreak VanillaAPP - White label iOS and Android App MVP

    A little bit input from my experience for others interested in no-index (not misunderstanding the issue that was asked here, automatization). About a manual approach.

    Google is pretty strict on user generated content when it comes to SEO. Especially if you have two or more discussions with similar content (which is likely in communities, and merging two or more topics can confuse things pretty hard) it makes sense to look up with a SEO tool which is ranking better in the SERPs and no-index the other discussions which performs lower (Google could balance them to each other sometimes not clear which one to choose which weakens both discussions).

    There is a manual no-index plugin by the Vanilla Team which seemed to be broken ever since:

    It has a permission issue (which is also in action on this forum) and also didn't add no-index to the discussion when I tried it.

  • R_JR_J Cheerleader & Troubleshooter Munich Moderator

    @phreak said:
    There is a manual no-index plugin by the Vanilla Team which seemed to be broken ever since:

    It has a permission issue (which is also in action on this forum) and also didn't add no-index to the discussion when I tried it.

    The plugin looks good to me. I've just tested it on my Vanilla 2.3.1 test installation.

    As long as a role either has Garden.Moderation.Manage or Garden.Curation.Manage rights, users of that role have the right to "Add NoIndex"/"Remove NoIndex"

    A discussion which is marked with "NoIndex" has the following line added to the head <meta name="robots" content="noindex,noarchive" />

    So from what I can tell, it works exactly as intended.

    If you are facing problems, I could think of two scenarios:
    1. if you add NoIndex and don't see any difference, you might have seen an outdated version of your page and a refresh might solve that problem (which only exists in your browser)
    2. users permissions get cached for a while. So if your users had one of the above mentioned rights, they might still see the option in the discussion options (but they normally should not, maybe they are looking at an outdated version of the page, too). But when they try to use that option, they will be presented with a permission error

  • edited February 2018

    @R_J This plugin no longer works with 2.5 upgrade. It shows as enabled in dashboard but has no effect. Any ideas?

    This is the log with debug mode enabled:

    The addon in /plugins/Noindex has 1 issue(s).
    #0 [internal function]: gdn_ErrorHandler(1024, 'The addon in /p...', 'S:\\htdocs\\...', 795, Array)
    #1 S:\htdocs\public_html\forum\library\Vanilla\Addon.php(795): trigger_error('The addon in /p...', 1024)
    #2 S:\htdocs\public_html\forum\library\Vanilla\Addon.php(829): Vanilla\Addon-&gt;triggerIssues()
    #3 S:\htdocs\public_html\forum\cache\addon.php(3435): Vanilla\Addon::__set_state(Array)
    #4 S:\htdocs\public_html\forum\library\Vanilla\AddonManager.php(319): require('S:\\htdocs\\...')
    #5 S:\htdocs\public_html\forum\library\Vanilla\AddonManager.php(740): Vanilla\AddonManager-&gt;ensureMultiCache()
    #6 S:\htdocs\public_html\forum\library\Vanilla\AddonManager.php(1094): Vanilla\AddonManager-&gt;lookupAddon('stubcontent')
    #7 S:\htdocs\public_html\forum\library\Vanilla\AddonManager.php(1074): Vanilla\AddonManager-&gt;lookupByType('stubcontent', 'addon')
    #8 S:\htdocs\public_html\forum\bootstrap.php(247): Vanilla\AddonManager-&gt;startAddonsByKey(Array, 'addon')
    #9 [internal function]: {closure}(Object(Garden\Container\Container), Object(Gdn_Configuration), Object(Vanilla\AddonManager), Object(Garden\EventManager), Object(Gdn_Request))
    #10 S:\htdocs\public_html\forum\vendor\vanilla\garden-container\src\Container.php(723): call_user_func_array(Object(Closure), Array)
    #11 S:\htdocs\public_html\forum\bootstrap.php(308): Garden\Container\Container-&gt;call(Object(Closure))
    #12 S:\htdocs\public_html\forum\index.php(22): require_once('S:\\htdocs\\...')
    #13 {main}
  • edited February 2018

    I just made a post (awaiting moderation for some strange reason) asking why this plugin stopped working with 2.5 but have since found that you just need to change the following:

    Before: class TestingGround extends Gdn_Plugin {
    After: class TestingGroundPlugin extends Gdn_Plugin {

  • whu606whu606 I'm not a SuperHero; I just like wearing tights... Moderator


    That post got caught in the spam queue.

Sign In or Register to comment.