Loop Using .hentry, Not .entry

[Porter]

The home page loop for a client is using .entry, and the formatting is great. I'm using ajax to pull in posts, using the a copy / paste of the original front-page loop they were using. For some reason, the ajax returned loop is using .hentry, not .entry, and the formatting is broke. To be clear, the default loop shows the same exact structure, but .entry, not .hentry. I changed .hentry to .entry in the inspector, and it fixed everything.

I'm completely losing it trying to figure out how to fix this, any ideas?

I've isolated the "issue" to this line, printf( '<article %s>', genesis_attr( 'entry' ) );
If I change 'entry' to 'entryaaaaa', all of these classes aren't pulled in:

post-14 type-post status-publish format-standard has-post-thumbnail hentry category-culture

So that line, is pulling in all of the classes, but something is telling it to use hentry, not entry.

if( $the_query->have_posts() ) :

    do_action( 'genesis_before_while' );
    while ( $the_query->have_posts() ) : $the_query->the_post();

      do_action( 'genesis_before_entry' );
      echo '<div class="article-bootstrap col-xs-6 col-sm-4">';
        printf( '<article %s>', genesis_attr( 'entry' ) );
          echo '<div class="entry-wrapper">';
            do_action( 'genesis_entry_header' );
            do_action( 'genesis_before_entry_content' );
            printf( '<div %s>', genesis_attr( 'entry-content' ) );
              do_action( 'genesis_entry_content' );
            echo '</div>';
            do_action( 'genesis_after_entry_content' );
            do_action( 'genesis_entry_footer' );
          echo '</div>';
        echo '</article>';
      echo '</div>';
      do_action( 'genesis_after_entry' );

    endwhile; //* end of one post
    do_action( 'genesis_after_endwhile' );

  else : //* if no posts exist
    do_action( 'genesis_loop_else' );
  endif; //* end loop

---

Buy me a beer? | Try DigitalOcean VPS Hosting

[Victor Font]

For whatever reason, your code is bypassing the HTML5 check. Hentry is removed in the genesis_entry_post_class function located in genesis/lib/structure/post.php. The function checks for HTML5 support and removes hentry if true. What happens if you remove the ajax call and use the standard loop?

---

Regards,

Victor
https://victorfont.com/
Call us toll free: 844-VIC-FONT (842-3668)
Have you requested your free website audit yet?

[Porter]

The code from the standard loop is simply copy / pasted into functions.php, with slight alterations to wrap certain elements in div tags (not ideal, but I didn't write it). That being said, I found the cause! Line 84 of genesis/lib/structure/post.php

if ( is_admin() ) {
		return $classes;
	}

The is_admin function is returning true, because all ajax calls in Worpdress (at least, from the learning I've done this last week), go through the admin area, via admin-ajax.php. Since it's going through the admin, this check is exiting before reaching the rest of the function that displays the posts as I'd like them too.

Now I'm sick, and a bit out of my comfort zone, but isn't that somewhat of a bug on the end of Genesis? If this is indeed the standard behavior for an ajax call (going through admin), we don't want to tamper with the formatting as if we're in the admin panel. I can't think of a better check off the top of my head, but surely that boolean check can be expanded to exclude when an ajax call is happening, or add an && like so:

if ( is_admin() && current_user_can( $capability ) ) {
		return $classes;
	}

Perhaps with the lowest common privilege, that check would suffice to know if you're on the admin dashboard, vs doing ajax? (list of privileges)

Again, I'm just kind of thinking out loud here, so please correct me / let me know what you think.

PS - I "fixed" my issue with this javascript, but it's obviously a hack-job, and I'd like to continue the dialogue above.

$('.status-publish').toggleClass('hentry entry');

---

Buy me a beer? | Try DigitalOcean VPS Hosting

[Victor Font]

I could be wrong, but I don't think Genesis was updated to work with WordPress Ajax calls yet, so no, it wouldn't be a bug if it doesn't support the feature.

---

Regards,

Victor
https://victorfont.com/
Call us toll free: 844-VIC-FONT (842-3668)
Have you requested your free website audit yet?

[Porter]

There are "how to" articles pertaining to WordPress and Ajax dating back to 2011 and very likely long before, if it hasn't been updated to "support" it, it never will be (unless they overhaul completely to help with the REST API).

I'm still leaning towards it being an overlooked case, as I've see a few in WordPress core pertaining to these kinds of checks (images being returned with size modifications that weren't meant for the dashboard).

What's the best way to contact StudioPress to get an official response?

---

Buy me a beer? | Try DigitalOcean VPS Hosting

[Porter]

I did a bit of digging around, and while there may be a more elegant solution, this seems to the accepted way to circumvent the issue. Simply change the sole is_admin() function call, to:

if ( is_admin() && defined('DOING_AJAX') && !DOING_AJAX )

I'm not 100% sure where in the admin area this check shows up, or what id does, but I think this works. I'm going to edit my Genesis framework files to include this change, unless someone can tell me what it might break. I put in a ticket to support, hopefully they take a peak, and even better consider patching the next minor release.

---

Buy me a beer? | Try DigitalOcean VPS Hosting

[Author]

Posts