Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Backwards Compatibility Wrapper? #446

Closed
Shelob9 opened this issue Nov 23, 2013 · 7 comments
Closed

Backwards Compatibility Wrapper? #446

Shelob9 opened this issue Nov 23, 2013 · 7 comments

Comments

@Shelob9
Copy link

Shelob9 commented Nov 23, 2013

Does a backwards compatibility wrapper of any sorts for using Masonry 2 initialization code with Masonry 3 exist? I can't seem to find one.

The need for one is blocking the upgrade from Masonry 2 to Masonry 3 in WordPress core: http://core.trac.wordpress.org/ticket/25351

desandro added a commit that referenced this issue Nov 24, 2013
@desandro
Copy link
Owner

Let's try this out: masonry-v2-shim.js

It's designed to re-map the v2 options to the v3 equivalents. I did a couple basic tests and it seems to do the job.

  • gutterWidth -> gutter
  • isAnimated sets transitionDuration to 0 or default value
  • isRTL: true -> isOriginLeft: false
  • isResizable -> isResizeBound
  • animationOptions.duration -> transitionDuration

This allows users with v2 options to use v3, and not have to change any options.

There were some other functional changes with how Masonry was packaged. imagesLoaded and smartresize are no longer included, so any code specific to that can still work, so long as the necessary separate files are included.

@Shelob9
Copy link
Author

Shelob9 commented Nov 24, 2013

@desandro Thanks. I will see if this satisfies the backwards compatibility concern once I figure out the best way to implement it. Do you recommend that I push for inclusion of imagesLoaded and smartresize as well? In my experience, imagesLoaded is generally, but not always needed to get Masonry to work properly in WordPress.

@desandro
Copy link
Owner

Yes, that sounds reasonable. I'd leave off smartresize and imagesLoaded.

@Shelob9
Copy link
Author

Shelob9 commented Nov 24, 2013

@desandro I implemented this shim and tested it with TwentyThirteen and TwentyFourteen themes. It works like a charm for TwentyFourteen, but fails for TwentyFourteen, due to the way column width is set. This is how Masonry is initialized:

    // Arrange footer widgets vertically.
    if ( $.isFunction( $.fn.masonry ) ) {
        $( '#footer-sidebar' ).masonry( {
            itemSelector: '.widget',
            columnWidth: function( containerWidth ) {
                return containerWidth / 4;
            },
            gutterWidth: 0,
            isResizable: true,
            isRTL: $( 'body' ).is( '.rtl' )
        } );
    }

This is from: https://github.com/WordPress/WordPress/blob/master/wp-content/themes/twentyfourteen/js/functions.js

I fear this sort of column width setup is fairly common. I know that is how I used to do it before upgrading to Masonry 3. Is there anything you can suggest to address this?

And yes, both themes should get their initialization code updated to be version 3 compatible the right way, but if I can prove this shim works with them unmodified that should be the proof I need that this thing works.

Thanks again for your help.

desandro added a commit that referenced this issue Nov 24, 2013
@desandro
Copy link
Owner

Ah! Forgot about that. I've updated the shim to account for columnWidth set as a function.

@Shelob9
Copy link
Author

Shelob9 commented Nov 24, 2013

That worked. Your are very cool for helping out with this. I think my latest patch with your revised shim should do it. Hopefully I can get attention from a lead dev before the code freeze for WP 3.8.

@desandro
Copy link
Owner

Closing as fixed 🚤. Please open a separate issue if you do run into an issue with Masonry v3 and v2, or this shim.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants