@cilefen Thanks for your help, I think this can be closed
It may be related to "#2664632: Add Auto orientation image effect"
What I have discovered, particularly after reading all of the comments
- My guess is it is related to iphone images or something like that
- I'm still in an early dev phase and am using images from various random sources to test and develop
- I now see many are correct, and many show the error I reported
- Often (but not always) in MS-Word and Libra, when inserting images taken from my iphone, they are turned 90 , 180 or 270 degrees, eventhough they appear correct in mac's Preview app
- To fix this in those cases, I have to open them again in mac's Preview app, turn them left and back right again, and save the change. Then when inserting in Word or Libra they will be correct (strange!!)
- So I guess the real bug is buried deep inside iphone images somewhere :-|
@cilefen
graphql is not involved, but that is where I first became aware of the issue.
Steps to reproduce
On a fresh drupal install v10.2.3
- create a content type with an image field
- ensure in "Manage display" for the contentType Image is not hidden and set to "Image" (not "Url to Image")
- create 2 examples of this content, one with a jpeg image in landscape format and another with an image in portrait format.
- Portrait is an image where its height is greater then its width
- Landscape is an image where its width is greater then its height
- go to "view" page for each of these (portrait and landscape) and using the browser developer tools inspect the DOM img tag for the image
- what you should see:
- For images with Portrait format, the img tag's width and height attributes are wrong, height is where width should be and visa versa:
<img ... width="imageHeight" height="imageWidth" />
- My screenshot in my original post shows what you will see in the Browser DOM inspector
- You can only see the error with the browser DOM inspector, but it is a major problem for me in my react graphql implementation
- The example with a Landscape format image is correct and as expected
- you can repeat this for other image styles created using the "Scale" effect, be sure to alter "Manage display" accordingly, the result will be the same. Images with a portrait format will have the width and height values in the img tag swapped :-(
My guess is something like Drupal::service('image.factory')
is incorrectly always setting width and height as if width is always the greater of the 2 values, which it is for landscape but not portrait formates.
bird-cage → created an issue.
I spent a lot of painful hours before seeing what I did wrong. Somewhere I read that www.somedomain.com and www.somedomain.com/ (with and without trailing slash) are treated as 2 different origins in CORS, and therefore you should add both to your list of origins. That is not correct!
If you do, the origin sent to the browser will have the www.somedomain.com duplicated in the allowed-origins header, which will make it reject your origin (www.somedomain.com). This particularly late in the evening after a long days work is a hard bug to spot in your browsers console and Network tab. The next morning I did spot that the orgin was duplicated, went to my services.yml, removed the one(s) with the trailing slash, and presto it work perfect. Here is my cors bit from my services.yml (domain is changed of course):
cors.config:
enabled: true
# Specify allowed headers, like 'x-allowed-header'.
allowedHeaders:
- x-csrf-token
- authorization
- content-type
- accept
- origin
- x-requested-with
# Specify allowed request methods, specify ['*'] to allow all possible ones.
allowedMethods: ["*"]
# Configure requests allowed from specific origins. Do not include trailing
# slashes with URLs.
allowedOrigins:
- https://production.somedomain.de
- https://www.somedomain.de
# Configure requests allowed from origins, matching against regex patterns.
allowedOriginsPatterns: []
# Sets the Access-Control-Expose-Headers header.
exposedHeaders: false
# Sets the Access-Control-Max-Age header.
maxAge: false
# Sets the Access-Control-Allow-Credentials header.
supportsCredentials: true
NB: I have both production and www as sub-domains, because until the new app is ready to launch, I am able to test the production API and app at production.xxxx.de and when the time comes, just point the server for www.xxxx.de to the correct folder.