Closed (fixed)
Project:
Drupal core
Version:
9.4.x-dev
Component:
quickedit.module
Priority:
Major
Category:
Task
Assigned:
Unassigned
Reporter:
Created:
18 Feb 2022 at 04:06 UTC
Updated:
10 Jun 2022 at 09:59 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #2
mstrelan commentedThere doesn't seem to be any references in PHP code to the image.info or image.upload routes that use this controller. I checked where these routes came from, see #2421427: Improve the UX of Quick Editing single-valued image fields. The path to the routes is referenced in image.js which appears to be entirely quickedit related, so hopefully an easy move. There are a bunch of related styles as well.
Comment #4
mstrelan commentedRough initial commit. Added some todo items, in code and in the MR. Not sure about deprecating the route or the library either.
Comment #7
spokjeAdded draft CR
Comment #9
spokjeComment #10
murilohp commentedThe D10 branch looks good to me! Just reviewed and there's nothing to add, the D9 branch I just added some minor comments. About the CR, do you think we need to add anything related to the JS files? I mean the library has been moved into the quickedit module, is it something that can affect the developers?
Comment #11
quietone commentedChanging parent to the issue tracking the steps to deprecate quickedit.
Comment #12
catchWith the library changing namespace..
If modules have an explicit dependency on the library, I think we should probably leave the old library in image module + deprecated and unused in 9.4.x. This would trigger a deprecation message for an un-updated stable equivalent in contrib.
If modules/themes are altering the library via hook_library_info_alter() / library overrides, then just a change record is fine because we explicitly tell people that what gets passed to alter hooks is subject to change in between minor releases. If we know of specific modules it's likely to break, then nice to also open an issue against them.
Comment #14
bnjmnmNot assuming there isn't more to do here, but providing patches since the commits are frequent enough today that I wanted to provide an option that wasn't saying "unable to apply" within moments of its addition.
Comment #15
daffie commentedMy review of the patch file for D9.4:
I think we are missing a deprecation message test for this deprecation.
Can we remove these 2 routes in 9.4? If somebody is using them in contrib or custom, than there site will break if we remove the routes.
I am very sure that this does not work. Which QuickEditImageController class are we using here?
This is not how we style this in Drupal core. Please put it on a single line. If you would like to change this then please create a followup issue for it.
Just a question: I think a git rename would be better here. Less to review and less that could go wrong.
@bnjmnm: Do you have in the file .gitconfig, the setting:
Renaming in the patch file makes it a much smaller file.
Comment #16
catchI don't think we need a test for this - we have generic test for the libraries deprecation API, which this uses.
Routes count as data structure/@internal, so they're generally fair game for removing/changing in a minor, although in practice we don't for high traffic routes like node add and similar. On the other hand it would not hurt to leave them in duplicated in 9.4
Comment #18
bnjmnmAdding patch for convenience. Interdiff is basically this commit.
RE #15 1-2 Looks like catch is OK with them as-is
RE #15 3-4 Good call, in general it looks like there's quite a few changes happening in a class that is getting deprecated in this very issue, and it seems like the chances this class even being used after this leans much closer to theoretical than possible. I reverted pretty much everything outside of adding the deprecation. It looks like these changes were made based on this feedback in the MR, which are clever suggestions, but it seems like this ultimately adds more overhead to getting this completed that isn't required by the scope of this issue.
No changes to the 10 patch, so the one in #14 can be considered active.
Comment #19
wim leers🤔 What does this do? AFAICT that's a thing for
@FieldTypeplugins only.Nit:
(Because it used to be a sole in-place editor in the Image module, now it's a specific in-place editor in the Quick Edit module.)
🐛 Needs to be updated now 😅
🤔 Why reformat this? Isn't the current formatting in line with what core does?
🤔 Why change the signature?
🤔 Why reflow these? Seems like a nice-to-have out-of-scope change?
Comment #20
dww@bnjmnm: Thanks for running with this! 🙏
@Wim Leers: Thanks for the reviews and keeping us honest. 😉
💯 agree on keeping this the minimum possible change to move this code and deprecate it. The whole point is we want to stop having to maintain this code in core. The smaller the diff, the faster this will land and we can unblock actually deprecating the whole module.
Thanks again!
-Derek
Comment #22
bnjmnmAddresses #19 as well as addressing image assets that were not copied over. I did a round of comparing in hopes of trying to undo any additional out of scope changes and hopefully they're all addressed now.
Comment #23
wim leersOnly one remark remains, then this will be perfect!
Sorry, but: s/field/in-place editor/ 🙈
Comment #24
bnjmnmAddressing #23 and updating the 10x patch to incorporate the feedback provided to the 9x patch that was also applicable to it.
Comment #25
dwwThanks! Sounds great. Queued the 10 patch for 10.0.x. Will try to give this a thorough review sometime today...
Comment #26
wim leers10.0.xtests failed only on Nightwatch toolbar tests, which are 100% unrelated. And … it's the same kind of failure we see on PHP 7.3 environments with Drupal 9.4/9.5, which #3281863: Nightwatch tests failing >50% of test runs on PHP 7.3 in 9.4.x and 9.5.x, as well as PHP 8.1 on 10.0.x is fixing.Re-testing.
Comment #27
lauriiiWe probably should update the CR to mention that we are no longer loading
image/quickedit.inPlaceEditor.image. We should also document the code change we expect people extending that library to make.We also need a draft release note.
I'm wondering if there would be benefit in updating
image/quickedit.inPlaceEditor.imageto reference the files from Quickedit? That way there would not be as much of a risk of loading the same file twice, and we wouldn't have to keep the files in sync.Comment #28
lauriiiFor #27.
Comment #29
lauriiiImplemented #27.
Comment #30
lauriiiUpdated CR and added release note.
Comment #31
bnjmnmI did not do any changes since the last RTBC, and all those changes appear to sufficiently bring this back to RTBC worthiness.
Comment #33
catchCommitted/pushed to 10.0.x, then the respective patch to 9.5.x and cherry-picked to 9.4.x, thanks!