HackerOne users: Testing against this community violates our program's Terms of Service and will result in your bounty being denied.

Headmodule outputs huge json stuff when not needed at all ... json_encode($this->jsonLD)

Is there a reason this code is not on conditional, as per discussion format type?

When Rich Editor is not in use (I am supposing it is for the editor) the entire discussion no matter how very much long is duplicated in JSON in a script tag.

This I find odd.

And upon removal, nothing seems to break. What am I missing?

//applications/dashboard/modules/class.headmodule.php
$this->addTag('script', ['type' => 'application/ld+json'], json_encode($this->jsonLD));

Cheers.

Comments

  • charrondevcharrondev Vanilla Staff

    My understanding is it is entirely unrelated to Rich Editor. It’s there for search engines.


  • edited September 2019

    I figured as much now. Thanks.

    I was/am on a radical hunt to slim down the things included when a page is rendered.

  • For this discussion it is

    <script type="application/ld+json">
    {
     "headline": "Headmodule outputs huge json stuff when not needed at all ... json_encode($this->jsonLD)",
     "description": "Is there a reason this code is not on conditional, as per discussion format type? When Rich Editor is not in use (I am supposing it is for the editor) the entire discussion no matter how very much long is duplicated in JSON in a script tag. This I find odd. And upon removal, nothing seems to break. What am I missing?\\u2026",
     "discussionUrl": "https:\\/\\/open.vanillaforums.com\\/discussion\\/37548\\/headmodule-outputs-huge-json-stuff-when-not-needed-at-all-json-encode-this-jsonld",
     "dateCreated": "2019-09-01 00:51:29",
     "author": {
       "@context": "https:\\/\\/schema.org",
       "@type": "Person",
       "name": "donshakespeare",
       "image": "https:\\/\\/secure.gravatar.com\\/avatar\\/03b46d43c7e8960eee0795d810976e7f\\/?default=https%3A%2F%2Fvanillicon.com%2F03b46d43c7e8960eee0795d810976e7f_100.png&rating=g&size=100",
       "url": "https:\\/\\/open.vanillaforums.com\\/profile\\/donshakespeare"
     },
     "@context": "https:\\/\\/schema.org",
     "@type": "DiscussionForumPosting"
    }
    </script>   
    

    (Not that pretty, but I wanted to make it more readable.

    Without much effort most of the above could be replaced by adding some property="" attributes like that:

    <main
     class="Content MainContent"
      vocab="http://schema.org/"
     typeof="DiscussionForumPosting"
      resource="https://open.vanillaforums.com/discussion/37548/headmodule-outputs-huge-json-stuff-when-not-needed-at-all-json-encode-this-jsonld"
    >
    
    <h1 property="headline">Headmodule outputs huge json stuff when not needed at all ... json_encode($this-&gt;jsonLD)</h1>
    
    <div class="AuthorWrap">
       <span class="Author" property="author" typeof="Person">
          <a title="donshakespeare" href="/profile/donshakespeare" class="PhotoWrap Offline">
                <img src="https://secure.gravatar.com/avatar/03b46d43c7e8960eee0795d810976e7f/?default=https%3A%2F%2Fvanillicon.com%2F03b46d43c7e8960eee0795d810976e7f_100.png&amp;rating=g&amp;size=100" alt="donshakespeare" class="ProfilePhoto ProfilePhotoMedium"  property="image"/>
          </a>
          <a href="/profile/donshakespeare" class="Username" property="url">donshakespeare</a> 
       </span>
       <span class="AuthorInfo">
          <span class="Rank MItem" title="Level 1">✭</span> 
       </span>
    </div>
       <span class="MItem DateCreated" property="dateCreated">
    <div class="Message userContent" property="description">
    

    The author name and the dateCreated might be a problem with this quick approach, but you spare that json-ld block... Although Google recommends JSON-LD, RDFa is a valid option, too. From my perspective JSON-LD has been a bad choice.

  • charrondevcharrondev Vanilla Staff

    @R_J 1 reason we went with JSON-LD is that it was easier to add in an isolated way. Adding micro-data to the HTML markup is a little less clear from a page level meta-data perspective, and also presented some compatibility options with themes/plugins that override various views.

    For example if we added microdata to our discussion view, many themes that override that view would not get the SEO benefits without needing to re-implement the changes. We've tried to decouple the SEO from the actual UI as much as possible here.

    That said I'd support a PR adding some configuration flag to disable this.


  • Thanks for the insights!

    If someone wants to remove that block he should take care for providing the SEO benefit in another way. That other way would include being able to insert this snippet in the themehooks or the plugin file:

       public function headModule_beforeToString_handler($sender) {
           $sender->clearTag('script', 'type', 'application/ld+json');
        }
    

    Because it is that easy to remove this block and in more than 99% the current setting is absolutely okay for the forum owner, I don't think changing anything makes sense.

Sign In or Register to comment.