Problem/Motivation
When I upgraded from rc4 to rc5 the initial zoom level sitewide changed from "fit" to 1x, which is way too large in my case. I found the global config for initial zoom level and it only accepts a number, not the strings "fit" or "fill". This leaves me no way (that I'm aware of) to define the initial zoom level to "fit".
Proposed resolution
Change the field type for the initial zoom level config to accept number or string. Or add the ability to define the initial zoom level (with text field) in the views setting for a PhotoSwipe gallery.
Issue fork photoswipe-3414849
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
anybodyLooking at https://photoswipe.com/adjusting-zoom-level/
I totally agree! This should be changed to accept any of the allowed values!
@nickbn could you prepare a MR? I think we should validate the acceptable values then.
Comment #3
anybodyPS: Default zoom level should be "fit"!
We should reset this regression in an update hook! Thanks for the report!
Comment #4
nickbn commented@anybody I'm building my first Drupal project in 10 years and I'm a little embarrassed to admit I don't know what an MR is. I'm happy to do anything in my skillset, but my skillset is small (so far). What's an MR?
Comment #5
nickbn commented@anybody also I see you moved this do dev and somehow I accidentally moved it back to rc5. Not my intention, my apologies.
Comment #6
nickbn commentedComment #7
anybody@nickbn sorry. MR means merge-request. You can do it here as alternative to providing a patch. Do you think you'll be able to give it a try? Or aren't you a developer?
Otherwise we'll have to wait until someone has the time to fix this.
Comment #8
yospyn commentedFound same thing as nickbn when I upgraded to rc4 > rc5. So I reverted back to rc4. The images were loading full size with rc5, regardless of the width of the browser window.
Comment #9
anybodyI prepared a MR to fix the issue. Could you please try if it solves the issue for you?
Comment #10
anybodyComment #12
anybodyOkay seems to work fine in my tests, let's wait for further feedback.
Comment #13
hephaestus commentedCan confirm that is working here.
Comment #14
anybodyThanks @Hephaestus, so let's set this RTBC!
Comment #16
anybodyMerged into dev!
I'll tag a new release.
Comment #17
grevil commentedThis broke tests. Unfortunately, the new test indicator is quite small. Please adjust the tests accordingly in a follow-up issue and reclose this issue.
Comment #18
grevil commentedOh wow, it didn't actually.... sorry!!
Comment #19
grevil commentedOk, it did break tests. :P
Furthermore, we are changing the schema definition of "initialZoomLevel", "secondaryZoomLevel" and "maxZoomLevel", but only update the "initialZoomLevel" in our update hook? Does this even work? Will do we not need to cast the other options to string?
And lastly, I don't really like forcing "initialZoomLevel" to be "fit". The original setting should've simply be cast to string, as numbers are valid values as well, see https://photoswipe.com/adjusting-zoom-level/#supported-values.
But we tagged a new release already, so if the module still works all fine! :)
Comment #20
anybody@Grevil: The settings are stored in yml anyway, I don't think it's as strict as in databases.
Re "fit": What should be the numeric representation of fit and fill?
The output was miserably broken using the number before, so setting this back to original PS value was urgent.
Comment #21
grevil commentedThere is none, but numeric values are also allowed, so if somebody wanted to have 2x Original Size for the "initialZoomLevel" (value: 2), this update will overwrite this setting with "fit" instead.
And if an allowed value would make the formatter "miserably broken", then we should create an issue in https://github.com/dimsemenov/PhotoSwipe. And disallow numeric strings.
Comment #22
anybodyOk perhaps I got you wrong.
If someone enters an invalid value, it's his problem ;D String is fine in this case, as it's what the library accepts and it's JS, not typescript. No need to be over-compliant.
Comment #23
grevil commentedBut the value is stored in config and configuration is heavily typed. And if we allow both strings like "fit" and numbers like 1 or 2, that should be reflected in the schema definition, where it currently isn't. But there is no way to add multiple schema types for one config entry.
And number are NOT invalid! If that is what you are referring to.
Comment #24
anybody"2" == 2 in JavaScript in the end, so I still don't see the problem here. Beside being precise of course, but that's real world vs. perfection. I'm also a fan of perfection! :D
I think I just didn't get the point, we'll talk tomorrow :)
Comment #25
grevil commentedYea, thought the settings form might throw some schema errors or something. But seems all fine! :)