-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
Gallery: Duplicate image IDs into easy-to-parse attribute #11540
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm reasonably okay with this direction. If we have the IDs, I'd like to see images
contain as little as possible which is not redundant with the id
. I think that would mainly be captions? May even be possible to change attributes shape to ids
and captions
at that point. Though I suppose we'd probably want to limit such changes at this point in the development cycle.
The mention of a block "constructor" seems very similar to what we'd had early in Gutenberg with the function form of attributes
, eventually removed due to its inability to interoperate with the backend (#1905).
ids: { | ||
type: 'array', | ||
shortcode: ( { named: { ids } } ) => { | ||
return ids.split( ',' ); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ids
is not guaranteed to be assigned, at which point this would throw.
|
||
this.state = { | ||
selectedImage: null, | ||
}; | ||
} | ||
|
||
setAttributes( attributes ) { | ||
if ( attributes.ids ) { | ||
throw new Error( "Don't use this attribute, dangit." ); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note to self: even though this error should never be thrown, let's change the copy to something neutral and descriptive.
542187a
to
3108056
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I did some polishing on this PR; it should be ready. I think this approach is a good tradeoff between providing server access to the ids and using our existing mechanisms.
I agree with @aduth, that removing the id data attribute from the image may even be a better path. But I'm not sure if it is something we can do now, and this path seems "safer."
3108056
to
7efb944
Compare
7efb944
to
063f643
Compare
@jorgefilipecosta seems it is failing tests. Can't see why when comparing your changes to the last success...
|
@antpb This test has been very flakey lately. Trying rebuild.. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suggested a couple of nit-picks, but LGTM
🚫 Actually, this still needs a deprecation for Gallery. |
Co-Authored-By: jorgefilipecosta <jorge.costa@developer.pt>
Co-Authored-By: jorgefilipecosta <jorge.costa@developer.pt>
Co-Authored-By: jorgefilipecosta <jorge.costa@developer.pt>
Co-Authored-By: jorgefilipecosta <jorge.costa@developer.pt>
f30b663
to
1815336
Compare
1815336
to
526b956
Compare
Hi @mcsf, in my tests I did not find any valid gallery created on the previous version that becomes invalid after this changes. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The code looks good to me, and I wasn't able to trigger the deprecation error as well.
I see a lot of green statuses here. 🙂 With @youknowriad last comment I feel good with us moving forward on merging this one. Thank you @mcsf ! Fixes: #1451 and #8193 |
Actually, it was a quick phone-side comment and I didn't think that deeply, but this is great! Thanks for the work, @jorgefilipecosta! |
Sorry, but problem is solved or not? |
@selftripsdotru: Yes, this PR was merged and shipped as part of WordPress 5.0. |
What is PR? |
How to get new IDs for galleries after export/import? |
A PR is a pull request, such as the one on this page. It means that this change has been incorporated in WordPress 5.0.
For general help requests, please post in the support forum at https://wordpress.org/support/forum/how-to-and-troubleshooting/. Technical help requests have their own section of the support forum at https://wordpress.org/support/forum/wp-advanced/. You may also ask for technical support at https://wordpress.stackexchange.com/. Please make sure you have checked the Handbook at https://wordpress.org/gutenberg/handbook before asking your question. |
Description
Fixes #8193.
Would supersede #11212.
Prototyped during a call with @mtias.
Warning: yes, this is quite awful. I mainly want to close this unless I can be convinced this is a trade-off worth making.
This is yet another trade-off to allow easy parsing of galleries on the server. This functionality is expected by many, especially given the possibilities offered by the
[gallery]
shortcode, etc. A comprehensive set of server-side tools for deep block inspection isn't expected until WordPress 5.1, thus in the meantime measures such as this can make third-party developers' lives easier. See parent issue for more.Conceptually, I don't like what this PR does, as it duplicates state. Indeed, Gallery has an attribute
images
, an array of image objects whose properties includeid
. This attribute is sourced in the block's HTML, however, based on elements' data attributes. This PR introduces an attributeids
which is not sourced and contains just the IDs extracted fromimages
.It highlights my concerns about state duplication:
setAttributes
to enforce the unidirectionalimages -> ids
synchronisation;transforms
— but this would have to be replicated in any other block that offers a transform to a Gallery;