Opened 11 years ago
Closed 11 years ago
#25351 closed enhancement (fixed)
Updating the 'jquery-masonry' to a latest version
Reported by: | rohitink | Owned by: | nacin |
---|---|---|---|
Milestone: | 3.9 | Priority: | normal |
Severity: | normal | Version: | 3.6.1 |
Component: | External Libraries | Keywords: | needs-testing has-patch |
Focuses: | Cc: |
Description
Wordpress currently has the version 2.1.05 of the jquery-masonry bundled with the core. This version of the script is currently outdated, and not very useful.
The latest version of the Script is 3.1.2 which is a great enhancement, and has more features as compared to the WordPress core bundled version.
Latest Version: http://masonry.desandro.com/masonry.pkgd.min.js
So, I request that script be updated to the latest version.
Attachments (7)
Change History (29)
#1
follow-up:
↓ 2
@
11 years ago
Seems that v3 introduced breaking (not backwards compatible) changes?
#2
in reply to:
↑ 1
@
11 years ago
Replying to helen:
Seems that v3 introduced breaking (not backwards compatible) changes?
Correct. Grumble.
WordPress should introduce a wp.masonry
wrapper (or something to that effect) that can attempt to offer backwards compatibility for future breaking changes. We might even be able to hijack the Masonry object and make it an instance of our object. It should be fairly easy to ensure back compat, all that changed were some options: http://masonry.desandro.com/appendix.html#upgrading-from-v2.
Another alternative is forking it and making our own backwards compatible build. I haven't asked the maintainer yet if he would be willing to help support such a build, but I doubt it.
The final alternative is just upgrading it and ignoring the back compat issues. We will have to update core for isRTL => isOriginLeft, but I don't think that would affect any others. I would suggest, as I did above, we build our own wrapper for future plugin and theme use. We could also ask the maintainer if he plans for version 4 to contain so many backwards incompatible changes, and whether there is anything we could do to prepare.
#3
@
11 years ago
Yes, the changes are too many. This does indeed create the problem of backwards compatibility. Since, the changes are too many, so it wouldn't be efficient to create a custom build. As newer themes/plugins would prefer to use the latest version of this script.
But, to offer compatibility to older themes/plugins, we can include the 2 versions, and give access to the older(2.1.05) version by default. And the developers who would like to use the latest version, should use something like 'jquery-masonry3' in the wp_enqueue_script('jquery-masonry3')
function call.
This update is important, as it has been backed by a lot of theme reviewers at our mailing list.
And we can remove the older version in any of the coming updates.
#4
@
11 years ago
If there was a different handle for Masonry 3 than Masonry 2, as @rohitink wisely suggests, wouldn't that make it as easy as having core deregister masonry3 if ( is_admin() ) just in case theme/plugin developer didn't only register Masonry 3 if ( ! is_admin() )?
#7
@
11 years ago
I have uploaded a new patch that upgrades Masonry to the latest version and fixes the issues this caused in the footer widget areas in TwentyThirteen and TwentyFourteen, which use Masonry for layout.
According to my detective work, which may be incomplete, the only places in core that use Masonry are the custom handler admin page, and the two places mentioned above. I tested the custom header admin page after uploading a variety of custom headers of different sizes and they rearranged just as they had before without making any changes to the Masonry JS in wp-admin/js/custom-header.js.
Upgrading Masonry did break the footer widget areas in TwentyThirteen and TwentyFourteen do to the way that Masonry 3 handles column widths differently then version 2. Please see the diff for how I handled this and if you are better with javascript then I am please suggest or make improvements to my changes.
If anyone knows of or finds a place that core uses Masonry that I missed, please comment and I will look into it.
#8
@
11 years ago
I reviewed the changes you made. The Twnety Thirteen theme seems to be running Perfectly Fine. However, There is one change you still need to make in wp-content/themes/twentythirteen/js/functions.js
on line no. 77.
The Parameter: gutterWidth
is no longer valid. It has been renamed to gutter
http://masonry.desandro.com/appendix.html#upgrading-from-v2
#9
@
11 years ago
You Also need to change, the following:
isRTL
to isOriginLeft: false
isResizable
to isResizeBound
Reference: http://masonry.desandro.com/appendix.html#upgrading-from-v2
I think that's it. Couldn't find any more issues.
#10
@
11 years ago
I made the changes suggested by @rohitink and tested with RTL tester that everything worked fine in RTL mode.
#12
@
11 years ago
David DeSandro wrote a shim in response to an issue I posted in the Github repo for Masonry:)
https://github.com/desandro/masonry/blob/master/examples/js/masonry-v2-shim.js
I'm not sure what the best way to implement this is and would appreciate guidance or a patch that makes this work.
#13
@
11 years ago
This new patch 25351.3.diff updates to Masonry 3. I modified wp-includes/script-loader.php using a strategy suggested by Otto in the theme review team discussion list. The handle 'jquery-masonry' now enqueues the shim and has a dependency of 'jquery-masonry3' which is the file with the actual Masonry v3 code.
This patch does not modify js/functions.js in TwentyThirteen or TwentyFourteen. But, thanks to the backwards compatibility shim they're footer widgets work just fine:) If this patch is accepted then someone who has better Javascript skills should update the relevant code to Masonry 3 syntax, though that is not urgent, since they will work as-is with this patch.
This ticket was mentioned in IRC in #wordpress-dev by shelob9. View the logs.
11 years ago
#16
@
11 years ago
- Owner set to nacin
- Resolution set to fixed
- Status changed from new to closed
In 27271:
#17
@
11 years ago
- Keywords has-patch removed
- Resolution fixed deleted
- Status changed from closed to reopened
Just wanted to re-open this to address the issue of broken jshint tests that this commit introduced.
See: https://travis-ci.org/tierra/wordpress/jobs/19603866
Also related: #26446
#19
@
11 years ago
If it wasn't clear from the commit message for [27271], after studying this I realized Masonry dropped the jQuery dependency, which meant the juggling that shelob9 did in the latest patch could be taken a step further. In the end, it's a bit cleaner and it provides a solid path for themes and plugins.
I also decided to include imagesLoaded directly in masonry.min.js, at least for now. They happen to be separate libraries upstream, but it's tough to use Masonry without it. In the future we could always spin it off into its own file.
#20
@
11 years ago
- Keywords has-patch added
- Resolution fixed deleted
- Status changed from closed to reopened
Looks like r27271 assumes the existence of jquery.masonry.min.js, but we never added our new shim to Grunt. See 25351.4.diff. Using static mapping, otherwise Grunt will treat ".masonry.js" as an extension.
Latest Version of the jQuery Masonry