Problem/Motivation
Currently, file and image field's field formatter doesn't have support to render/display absolute URL.
ImageUrlFormatter
and UrlPlainFormatter
classes doesn't have flexibility to display absolute url.
Steps to reproduce
Configure the field formatter and check that we don't have flexibility to render absolute url.
Proposed resolution
- Add an option to both the field formatters.
- Validate option value in viewElements() method and display URL accordingly.
- Add test cases to validate newly added options.
Remaining tasks
Contact Usability for wording of new text in the UI.
- Review MR https://git.drupalcode.org/project/drupal/-/merge_requests/5882 which represents further changes since patch #122
User interface changes
- New option is added on both the field formatters.
File field:
Image field
API changes
- N/A
Data model changes
- N/A
Release notes snippet
Comment | File | Size | Author |
---|---|---|---|
#122 | 2811043-122.patch | 24.33 KB | mohit_aghera |
#120 | 2811043-120.patch | 24.08 KB | smustgrave |
#120 | diff-119-120.txt | 572 bytes | smustgrave |
#119 | interdiff-2811043-117-119.txt | 2.74 KB | mohit_aghera |
#119 | 2811043-119.patch | 24.07 KB | mohit_aghera |
Issue fork drupal-2811043
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #2
StijnStroobantsComment #3
StijnStroobantsComment #4
StijnStroobantsUpdated the settingsSummary
Comment #5
StijnStroobantsComment #7
StijnStroobantsAdded settings to schema.yml
Comment #8
StijnStroobantsComment #10
StijnStroobantsUpdated test file field formatter settings
Comment #11
StijnStroobantsComment #12
dawehnerSo wait, we make it absolute by default?
The indentation is a little bit off.
Its a boolean, I think
$this->getSeting('absolute_url')
should be enough.Comment #13
StijnStroobantsThanks for the reply!
Yes, I'm testing the absolute as TRUE by default, is that not the right way to do it?
There was indeed a gap in the indentation.
Oops indeed, a boolean is just true or false :-) Don't need to check the value of the boolean again...
I'm pretty new to D8-coding, so still a lot to learn! :-)
Comment #14
StijnStroobantsComment #18
StijnStroobantsComment #19
StijnStroobantsComment #20
StijnStroobantsComment #23
StijnStroobantsComment #24
StijnStroobantsComment #26
StijnStroobantsComment #27
StijnStroobantsComment #28
StijnStroobantsComment #30
StijnStroobantsComment #31
StijnStroobantsComment #33
StijnStroobantsComment #34
StijnStroobantsComment #35
StijnStroobantsComment #36
StijnStroobantsComment #37
tstoecklerI think that now that #2517030: Add a URL formatter for the image field is in, we should also update the new
image_url
formatter to have the same option. Also we could use some tests here and we definitely need an upgrade path.Comment #38
StijnStroobantsComment #39
StijnStroobantsHi, thanks for the reply.
I think for the image_url formatter we should create another issue, because it's a seperate component.
In the patch there are tests.
Why we need an upgrade path if this formatter was not by default available in D6/D7 core?
Thanks!
Comment #41
StijnStroobantsComment #42
StijnStroobantsComment #44
heddnI agree we need tests. But I'm not sure we need an upgrade path.
Nit: short array syntax.
Comment #45
heddnAnd here's a re-roll with the array stuff fixed. No interdiff as its just a re-roll (with array short syntax fixes).
Comment #46
StijnStroobantsThanks for the short array syntax fix. Makes sense!
Comment #48
edysmpreroll to 8.6.x
Comment #49
heddnIt looks like from #37 we should to this for image_url formatter as well. This is small enough, let's just do it all in one place.
So, NW for that and tests.
Comment #50
jyoti.singh CreditAttribution: jyoti.singh as a volunteer and commentedPatch for the #37. Adding the absolute url for the Image Url field formatter.
Comment #51
jyoti.singh CreditAttribution: jyoti.singh as a volunteer and commentedComment #52
msankhala CreditAttribution: msankhala as a volunteer and at Srijan | A Material+ Company commentedThis can be shorten as:
This empty line is not required.
This can be shorten as:
This empty line is not required.
Here are some of the feedback. @jyoti.singh Can you please provide interdiff as well. We need tests for this patch as well.
Comment #53
jyoti.singh CreditAttribution: jyoti.singh as a volunteer and commentedThank you @msankhala for the feedback , updating the patch for the same.
Comment #54
jyoti.singh CreditAttribution: jyoti.singh as a volunteer and commentedComment #56
jyoti.singh CreditAttribution: jyoti.singh as a volunteer and commentedAttaching another patch for the comment #52
Comment #57
msankhala CreditAttribution: msankhala as a volunteer and at Srijan | A Material+ Company commentedThese empty lines can be removed. @jyoti.singh Can you please provide the interdiff as well? https://www.drupal.org/documentation/git/interdiff
so it makes it easy to review what you have modified since the last patch.
This patch requires test cases as well. I think the test for these should go inside
FileFieldDisplayTest
andImageFieldDisplayTest
.Comment #60
e.escribano CreditAttribution: e.escribano at Youwe commentedFor Core 8.7 the last patch didn't work so I remade it.
Comment #61
e.escribano CreditAttribution: e.escribano at Youwe commentedSorry, got bad name for the patch, re-uploading it.
Comment #62
hctomIs there a special reason why you do not use the
$relative
parameter ofcreateFileUrl()
directly? This method already has all the logic to return a relative or absolute URL.Comment #63
BerdirBecause that's new and didn't exist when this code was written, agree that it should be used now.
I'm also wondering about the use case from the issue summary:
> When sending the values in a mail (contact form), it should render the absolute url so you can click directly to the file from within a received mail.
Drupal core should now automatically convert relative URL's in e-mails to absolute, are there other reasons for this? We've worked hard in Drupal 8 to avoid absolute urls whenever possible.
Comment #66
HLopes CreditAttribution: HLopes commentedRSS Feeds
Applies cleanly on 8.9, tested with views formatter, works fine.
Comment #67
Berdir> RSS Feeds
Yeah, covered: \Drupal\Core\EventSubscriber\RssResponseRelativeUrlFilter
Comment #68
hctom@berdir: Uh nice... didn't knew about that one. That looks very promising... But apart from that I still think it is a good idea to let the site builder decide if for whatever reason there is an absolute URL output required.
Maybe there should be some sort of short description on the checkbox field explaining why absolute URLs may lead to trouble in certain cases.
...so if this feature should still get in, my finding in comment #62 should still be implemented - let me know if I should change the patch for it, or if this issue will more likely to be closed?!
Comment #69
HLopes CreditAttribution: HLopes commentedI see, this works but for description field only. My use case also has html in other rss item field (don't ask), hence why.
Still I tend to agree with #68.
Comment #71
mohit_aghera CreditAttribution: mohit_aghera as a volunteer and at QED42 commentedAdding three test cases to validate field formatter changes and configuration.
Comment #72
mohit_aghera CreditAttribution: mohit_aghera as a volunteer and at QED42 commentedReuploading the above patch with relevant fixes.
- It contains three test cases to validate field formatter changes and configuration.
- PHPCs error fixes in the above patch.
I've intentionally kept diff against comment #61 so we can easily see the diff between those.
Update:
Accidentally added interdiff with .patch extension instead of .txt
Comment #75
Berdirthe assert() needs to move up before a method on $file is called, and we can still use createFileUrl(TRUE/FALSE) here. In fact, you can just use $file->createFileUrl(!$this->getSetting('absolute_url'))
Also, if we do make it absolute, we need to add the url.site cache context and should assert that as well.
Comment #76
mohit_aghera CreditAttribution: mohit_aghera as a volunteer and at QED42 commented@Berdir, thanks for the suggestions.
I've included those in the current patch. I've also updated test cases accordingly.
Comment #78
mohit_aghera CreditAttribution: mohit_aghera as a volunteer and at QED42 commentedResolving issues in
testImageFieldFormattersPrivate()
test case.@berdir, somehow functional javascript tests are failing on DrupalCI. Is there any way to identify which is causing issues?
Comment #79
BerdirI'm.. not sure what this is testing exactly. You're asserting the response, but you're not actually visiting a page here, at least for the public case, so your assertion has nothing to do with what you are rendering, the url.site cache context just happens to be on the page the test last visited. And it doesn't work for private, because a few lines above, access denied is tested for private and that page doesn't have it.
But we don't actually need to do that, instead, lets just assert the render array directly, you're already looking at #markup, just assert ...['#cache']['contexts'] directly, with an assertContains(). And then also ensure that it's not there if you set absolute_url to FALSE.
Comment #80
mohit_aghera CreditAttribution: mohit_aghera at QED42 commentedUpdating test cases as per the above comment.
Comment #82
Anas_maw CreditAttribution: Anas_maw at Coders Enterprise Web & Mobile Solutions commentedReroll the patch to work on the latest version
Comment #83
sokru CreditAttribution: sokru as a volunteer commentedPatch on #82 failed to apply, here's a reroll.
Comment #85
ankithashettyUpdated deprecated code in #83.
file_create_url() is deprecated in drupal:9.3.0 and is removed from drupal:10.0.0. Use the appropriate method on \Drupal\Core\File\FileUrlGeneratorInterface instead. See https://www.drupal.org/node/2940031
file_url_transform_relative() is deprecated in drupal:9.3.0 and is removed from drupal:10.0.0. Use \Drupal\Core\File\FileUrlGenerator::transformRelative() instead. See https://www.drupal.org/node/2940031
Thanks!
Comment #87
anweshasinha CreditAttribution: anweshasinha at Valuebound commentedI am working in it.
Comment #88
anweshasinha CreditAttribution: anweshasinha at Valuebound commentedHi,
I have created a patch for the absolute url for image. Please review it.
Comment #90
heddnComment #92
Anas_maw CreditAttribution: Anas_maw at Coders Enterprise Web & Mobile Solutions commentedReroll the patch to work on 9.4.x
Comment #93
Munavijayalakshmi CreditAttribution: Munavijayalakshmi at Valuebound for Valuebound commentedpatch #85 re-rolled (9.5.x).
Comment #94
Munavijayalakshmi CreditAttribution: Munavijayalakshmi at Valuebound for Valuebound commentedComment #97
ddiestra CreditAttribution: ddiestra as a volunteer commentedMake it work for 9.4.8
Comment #99
AshM CreditAttribution: AshM commentedMake it work for 9.5.0
Comment #100
_utsavsharma CreditAttribution: _utsavsharma at OpenSense Labs for DrupalFit commentedFixed CCF for #99.
Please review.
Comment #101
_utsavsharma CreditAttribution: _utsavsharma at OpenSense Labs for DrupalFit commentedComment #103
mohit_aghera CreditAttribution: mohit_aghera at PreviousNext commentedAttempt to fix the test case failures.
Both the failing test cases are passing on local now.
It seems that older instance of
file_create_url($uri)
should be replaced with$file_url_generator->generateAbsoluteString($image_uri)
.It was set as
$file_url_generator->generateString($image_uri)
.Comment #104
smustgrave CreditAttribution: smustgrave at Mobomo commentedSeems in all the reroll starting in #93 some files were add/removed from the original patch.
Was there a reason why?
Comment #105
HitchShockHi @smustgrave Not sure what do you mean about "original patch"? Which one is original? The first one? Then it's normal that other people have expanded it, improved it and added tests.
If you're talking about another patch, why do you consider it original?
I looked at the patch development trend and concluded that #103 is a logical result of the current patch evolution.
I installed and tested the patch for two Drupal sites: 9.4 and 9.5.
The patch works perfectly for me.
FYI. for 9.4 I used #97, but I had to update that patch a bit. Fixed the same URL issue as in #103
Added my patch to the issue but hid it, because 9.4 is already outdated.
Comment #106
smustgrave CreditAttribution: smustgrave at Mobomo commentedWill let someone else review. #88 attempted a change that had a few files more then in #85.
Then #93 rerolled #85, so skipping #88 was that change not needed? No one seems to answer that.
Lack of interdiffs and comments don't explain why things are added or removed.
To me this needs an issue summary update now.
Comment #107
mohit_aghera CreditAttribution: mohit_aghera at PreviousNext commentedI have reviewed both the patches closely. #85 and #88
The changes in #88 seems completely in wrong direction.
Basically, key thing i.e. field formatter
ImageUrlFormatter.php
itself is missing from the patch.I am hiding the patch given in #88 so we can have proper sequence.
Adding issue summary for clear direction.
Comment #108
quietone CreditAttribution: quietone at PreviousNext commentedThanks to everyone for getting this older issue close to commit.
It appears that this is a self RTBC, #105. So this, at least, needs another review.
This is a feature request so we need a patch on 10.1.x. I am changing the version. Refer to the allowed changes policy for details.
I was going to look at the patch but, honestly, I do not know which one I should review. Hopefully, that will be clear when there is a patch for 10.1.x.
This also needs a title that better explains the change.
Thanks.
Comment #109
mohit_aghera CreditAttribution: mohit_aghera at PreviousNext commentedThis is turning out to be somewhat confusing.
It seems that the patch in #93 is re-rolled against #85 because #92 and #88 contains the diff related to quick edit module.
So #88 and #92 seems somewhat incorrect to me.
#105 seems against 9.4.x, so we can ignore the patch.
Coming to conclusion:
@quietone, I noticed that the patch in #103 is getting applied on latest 10.1.x head.
I have triggered re-test of #103 to see how it goes.
Comment #110
quietone CreditAttribution: quietone at PreviousNext commented@mohit_aghera, thanks! I was really quite lost and spending too much time trying to figure this out. So, the patch to work with is #103.
As best I can tell, the last review of the patch was in #79, and we have a confirmation that it works in #103. So, we still need a fresh review. I am changing the status to NR for that.
The next step is to review the patch in #103.
Comment #111
smustgrave CreditAttribution: smustgrave at Mobomo commentedReviewing #103
Appears to be adding a new field option, so probably needs a change record.
Also will need an upgrade path for existing sites.
Comment #112
mohit_aghera CreditAttribution: mohit_aghera at PreviousNext commented- Added a post update hook to change the field formatter settings.
- Add a test case to validate the post update hook.
Comment #113
smustgrave CreditAttribution: smustgrave at Mobomo commentedThink the only thing left would be the change record! Almost there!
Comment #115
pnagornyak CreditAttribution: pnagornyak commentedthis solution does not work with image styles, absolute URL is generated for original image only :(
Comment #116
mohit_aghera CreditAttribution: mohit_aghera at PreviousNext commentedChange record added here https://www.drupal.org/node/3368703
Keeping this in needs work as I'm yet to check #115
Comment #117
mohit_aghera CreditAttribution: mohit_aghera at PreviousNext commentedI was able to reproduce the issue mentioned in #115
Attached a patch and test case for the same.
Comment #119
mohit_aghera CreditAttribution: mohit_aghera at PreviousNext commentedFixing test case failures.
Comment #120
smustgrave CreditAttribution: smustgrave at Mobomo commentedPatch no longer applies cleanly to 11.x
but it was such a small change I just went ahead and did it.
With the patch applied verified the update hook ran without issue
Verified the view display setting on an Image field.
Created a node with the field setting set to absolute.
Verified the URL rendered as absolute.
Comment #122
mohit_aghera CreditAttribution: mohit_aghera at PreviousNext commented- Patch is not getting applied to latest 11.x head. I did the rebase of the patch.
- Fixing test case failures. Test cases are passing on local now.
Let's see how it goes for CI pipeline.
I'm not quite sure why it was working previously and suddenly stopped working.
Comment #123
mohit_aghera CreditAttribution: mohit_aghera at PreviousNext commentedComment #124
smustgrave CreditAttribution: smustgrave at Mobomo commentedSeeing all green so restoring status. Thanks @mohit_aghera!
Comment #125
quietone CreditAttribution: quietone at PreviousNext commentedI'm triaging RTBC issues. I read the IS and the comments. I didn't find any unanswered questions.
Thanks for getting this 7 year old issue to RTBC!
This is making a change to the UI, adding the usability tag. There should be a screenshot for the change in the issue summary, or linked to from there.
That made me think of the change record so I read that. It does needs updating to provide the reader with the information needed to use this new feature. It should be explicit about where the new setting is found, which form and the url. Also it would help to have a screen shot. I've added the tag for an update to the change record.
I then read the patch, noting the following points.
Why is there no corresponding change in the same test for migration from Drupal 7 sources?
nit: should be added alphabetically
I am all for comments but this seems unnecessary as the if block is clear.
This is really testing the update of the value. I think this is an improvement.
" * Tests update of the 'absolute_url' file and image field formatter setting."
This should use 'assertFalse'
No quite meeting the standard, also is should be 'absolute_url'. Drupal API documentation standards for functions
I suggest, "Tests the 'absolute_url' setting on the field display setting form."
Similar to above. I suggest, "Tests the absolute_url setting with the image style setting."
These need work, there is a common assert to each if/else.
The same code is executed for public and private.
Finally, the comments are inconsistent when referring to the new setting. Sometimes 'option' is used instead of 'setting' it would be helpful to be consistent on that.
So, nothing major just a few things to tidy up.
Comment #126
angrytoast CreditAttribution: angrytoast as a volunteer and at Tableau commentedAdding an updated patch + interdiff with changes based on most of the feedback in #125. Specific points:
1. The D7
MigrateFieldFormatterSettingsTest
does not have any cases offile_url_plain
which differs from the D6 version. Not sure on how to proceed here as it seems like it'd be a bigger change in the test migration?8 + 9. It seems like the
public
vsprivate
paths ultimately ended up with the same assertions so that the only difference came down toprivate
triggering a logout in the test. That didn't seem necessary as the tests were asserting on the existence of theurl.site
cache context which should exist regardless of auth state. Ended up removing theif
paths.Also updated the Change Record with more descriptions and Issue Summary to include screenshots.
Comment #130
smustgrave CreditAttribution: smustgrave at Mobomo commented#3041402: Add option absolute url in formatter URL to image closed as a duplicate and moved over credit.
Comment #132
angrytoast CreditAttribution: angrytoast as a volunteer and at Tableau commentedUpdated to use a MR because the patch triggered DrupalCI process looks to be failing consistently due to disk space issues in the Jenkins based builds.
Same changes as patch in #126, the interdiff between 122 and 126 is represented in this commit
Comment #133
smustgrave CreditAttribution: smustgrave at Mobomo commentedLeft some feedback, all minor stuff.
Comment #134
angrytoast CreditAttribution: angrytoast as a volunteer and at Tableau commentedAddressed feedback from #133. Not sure about MR resolving policy, setting this back to Needs Review to get eyes on it.
Comment #135
angrytoast CreditAttribution: angrytoast as a volunteer and at Tableau commentedComment #136
smustgrave CreditAttribution: smustgrave at Mobomo commentedMy feedback has been addressed.
Comment #137
quietone CreditAttribution: quietone at PreviousNext commentedI'm triaging RTBC issues. I see I have been here before and this is steadily making progress. I read the IS, which appears to be up to date, and the comments. I didn't find any unanswered questions.
This is adding a new string to the UI and I see from the screenshots that there is inconsistent capitalization of URL. Also, I don't think that 'render' is used in the Drupal UI. So, this needs input from usability for the correct wording. I don't know why I didn't see this before. I am setting this to needs work for getting feedback from the usability team. I'll tag it as well, for visibility.
Although, someone here can ask in #usability for advice. If you do, add who responded to your comment. Thanks.
I did not review the MR or consider if this deprecation can occur in 10.3.
Comment #138
rkollerUsability review
We discussed this issue at #3411359: Drupal Usability Meeting 2024-01-05. That issue will have a link to a recording of the meeting.
For the record, the attendees at the usability meeting were @benjifisher, @Emma Horrell, @rkoller, @shaal, and @simohell.
If you want more feedback from the usability team, a good way to reach out is in the #ux channel in Slack.
At first thanks on working on the issue as well as that the issue summary was in good shape. That saved a lot of time and left more time to focus on the issue itself. We've based our explorations and discussions on the latest state of MR5882 on a Drupal 11.x-dev install with a content type which had a file, image and media field added. At first a few points we've noticed:
Manage display
page of a content type, per default, the summary for those three fields showsRendered as relative url
. When you edit the field you are only presented with theRender as absolute url
checkbox - no signs of a setting for the relative url which was shown and referred to in the summary overview. The state of "relative url" is hidden or better is just communicated indirectly. If the checkbox is unchecked you get the relative url, if the checkbox is checked you get the absolute url - that fact adds a cognitive load to the user.render
in this context. The group agreed that it is probably not quite the right word. The termrender
would probably be more appropriate for example in the context of rendering templates.If checked, links will be rendered as absolute urls.
in context with the checkbox labelRender as absolute url
isn't really explaining anything or adding any extra information. It is mostly repeating the checkbox label prepending the constraintIf checked, links will be
. At the same time things become tricky if you want to actually cover and explain all the dos and don'ts when a checkbox is checked. The description would become lengthy and hard to read.url
is only lower case. According to https://www.drupal.org/docs/develop/user-interface-standards/interface-t... acronyms likeURL
should be capitalized.There was a clear consensus in the group about the following recommendations:
Render as relative url
andRender as absolute url
toRelative URL
andAbsolute URL
. Ideally the details of interest,Relative URL
andAbsolute URL
, should be front-loaded (currently the user has to scan past 10 characters before the detail of interest is reached). For this context we also agreed on less is more and simply removed the "Render as ".Show link as
and for the radio button labels go withRelative URL
andAbsolute URL
.For one by using radio buttons the relative URL option would become explicit in the UI and the case that each option would start redundant with
Render as
as well as the term "render" would be avoided by moving to the more neutral wordShow
in the legend. We were only a bit uncertain at first about adding a radio button group with just two options. But while writing up the comment I've revisited the user interface standards for radio buttons on d.o: https://www.drupal.org/docs/develop/user-interface-standards/radio-buttons and having a list of two is a legitimate case https://www.drupal.org/docs/develop/user-interface-standards/radio-butto.... Avoiding redundancy by moving parts of the radio button labels to the legend is also in line and recommended in https://www.drupal.org/docs/develop/user-interface-standards/radio-butto....Relative URL
is selected the suggestion would beExample: /sites/default/files/image.png
, whenAbsolute URL
is selected the suggestion would beExample: https://www.example.com/sites/default/files/image.png
instead. We've just slightly shortened the examples used on https://www.drupal.org/node/3368703. But by using radio buttons and a description that adjusts dynamically to the selected radio button, things would become completely self-explanatory and clear. In case the dynamic description is out of the scope for this issue it could be also moved to a follow up issue?At the end one additional detail that was noted during the discussion - not a recommendation or suggestion but more of question. It was asked if the functionality was tested on a site that utilizes for example the
Domain
module or any other similar module and if there might be potential problems?I'll remove the
Needs usability review
tag again.Comment #139
rkollerAnd one additional note i've noticed when i've looked at the change record before the meeting (@angrytoast pointed me to it helping me to understand the scope and problem space of the issue). I've already commented on Slack in the #ux channel that the current state of the change record is potentially misleading in the context of the views based REST export json responses.
In the first section (
Example screenshots for site builders:
) you have screenshots with the UI before the patch and the changes after the patch is applied. The second section (Example to illustrate the change with a views based REST export json response
) is applying the exact samebefore
and afterpattern
. That way a user might assume thatbefore
shows the response without the patch applied whileafter
shows the response with the patch applied. Instead thebefore
is the response for theRelative URL
option whileafter
is the response for theAbsolut URL
option. Maybe the easiest fix might be to simply replacebefore
andafter
withRelative URL
andAbsolute URL
? The headline could be left as is even and I've used the slightly shortened example URLs from #138.Example to illustrate the change with a views based REST export json response:
Relative URL:
/sites/default/files/image.png
Absolute URL:
https://www.example.com/sites/default/files/image.png