[Resolved] Bugs/conflicts between Masonry and Views 1.11.1

[Author]

Posts

[kasiaG]

I have several websites with custom themes built on Bootstrap and the Toolset plugin suite (typically Types/Views/Layouts). I have been using the Masonry jQuery script with the Bootstrap grid in Views and it has been working really well until the most recent Views update. After updating to Views 1.11.1, dynamic rendering of the columns in the masonry grid became very buggy. Rolling back to version 1.10.1 seems to resolve these display rendering issues, so I have rolled back all my sites until this can be resolved. I know this probably isn't enough information for you to go on, because the description is kind of vague. I will try to follow up with a screen recording video to demonstrate what I mean. This is probably a lower priority for your team, but I thought it was worth mentioning.

[Minesh Supporter Languages: English (English ) Timezone: Asia/Kolkata (GMT+05:30)]

Hello. Thank you for contacting the Toolset support.

*** Please make full backup of your database and website. ***
Would you mind to try solution I've offered here:
=> https://toolset.com/forums/topic/why-is-my-views-wrapped-in-new-div/#post-349168

If your issue still persist:
Yes, you are right. Could you please provide me more information showing exactly what issue you are facing. Few screenshots or brief description would be helpful or as you suggested a video showing your exact issue.

[kasiaG]

Hi,

I'm not able to use the solution offered in the above linked topic because I still do need to use features like pagination and parametric searches.

Here is a video I made demonstrating the issue and the difference in behaviour between verison 1.10.1 and 1.11.1. Any insight would be appreciated.

hidden link

[Minesh Supporter Languages: English (English ) Timezone: Asia/Kolkata (GMT+05:30)]

OK. I understand your issue.

Would you mind to send me access details of your site as well as a link where I can reproduce your issue?

*** Please make a FULL BACKUP of your database and website.***
I would also eventually need to request temporary access (WP-Admin and FTP) to your site. Preferably to a test site where the problem has been replicated if possible in order to be of better help and check if some configurations might need to be changed.

I would additionally need your permission to de- and re-activate Plugins and the Theme, and to change configurations on the site. This is also a reason the backup is really important. If you agree to this, please use the form fields I have enabled below to provide temporary access details (wp-admin and FTP).

I have set the next reply to private which means only you and I have access to it.

[Minesh Supporter Languages: English (English ) Timezone: Asia/Kolkata (GMT+05:30)]

I've escalated your ticket to our next level support. Please be patient, wait for a reply from them and they will get in touch with you as soon as possible.

[Adriano]

Hello,

I'm Adriano, Toolset support lead and I've been escalated to this thread. WordPress by default loads a masonry library 3.1.2 natively and the theme of the client loads a 4.3.1 version. The very strange thing here is that the problem can't be reproduced in the previous version of Views, just in the 1.11.1.

I've noticed that in (wp-views/embedded/toolset/toolset-common/toolset-forms/classes/class.file.php), we set jquery-masonry as dependent of a Toolset script. This can be the reason, I'm not sure about it. I'll contact our developers and will update you. Thank you for your understanding.

[Adriano]

Hi Kasia,

This is being caused by some HTML tags we've added in the View from 1.11 version, it was needed to execute a couple of new actions. In order to fix that by removing those tags you just need to add the code below in functions.php:

add_filter( 'wpv_filter_wpv_view_shortcode_output', 'prefix_clean_view_output', 5, 2 );

function prefix_clean_view_output( $out, $id ) {
    if ( $id == '375' ) {
        $start = strpos( $out, '<!-- wpv-loop-start -->' );
        if ( 
            $start !== false
            && strrpos( $out, '<!-- wpv-loop-end -->', $start ) !== false
        ) {
            $start = $start + strlen( '<!-- wpv-loop-start -->' );
            $out = substr( $out , $start );
            $end = strrpos( $out, '<!-- wpv-loop-end -->' );
            $out = substr( $out, 0, $end );
        }
    }
    return $out;
}

Of course replace 375 with the View's ID.

Please let me know if you are satisfied with my reply and any other questions you may have.

Regards,

Adriano Ferreira

[kasiaG]

Hi,

Unfortunately this solution doesn't work for me, as implementing the filter breaks the masonry script altogether. The columns no longer automatically fit within the available vertical space. See the attached screenshot for what I mean.

[kasiaG]

Hi again,

I tinkered around this this a bit and once I realized that the filter was stripping out all code above the <!-- wpv-loop-start --> and below the <!-- wpv-loop-end -->, I was able to fiddle with my code and use this solution.

[kasiaG]

Sorry, one more thing. This solution appears to disable pagination. Is there a way to fix that?

[Adriano]

Unfortunately not, the pagination needs that part we've removed. The best thing we can do is to understand why masonry is conflicting with Views, not simply remove that wrapper. Could you open another ticket? You can mention I'll help you directly, since I'm aware about the problem.

[kasiaG]

As you requested, I have started a new thread on this topic here:

https://toolset.com/forums/topic/conflicts-between-views-1-11-1-and-masonry-jquery-script/