Rulatir

Meanwhile check out https://novo-media.ch/en/wordpress-site/best-wordpress-gallery-plugin/ which contains demos of Meow Gallery / Lightbox and clearly reproduces the issue in Firefox and Chrome on my end.

(This comment used to say that the problem was limited to Firefox, but I was mistaken; I was testing in Chrome too hastily and didn’t click the right spot to clearly demonstrate issue)

• This reply was modified 3 years, 7 months ago by Rulatir.
• This reply was modified 3 years, 7 months ago by Rulatir.

IMO there are two alternatives each “making sense”:

1. zooming out of the point of interest, so that it stays in the same spot on the screen
2. attempting to center the point of interest, BUT if the point of interest is close to the edge of the image, the translation component of the transform should be adjusted so that no edge is actually pulled towards the center of the screen from its original position

In addition to that, I still think the current zooming geometry calculation is simply broken. It’s not just that it doesn’t do what I expected it to do. It does things that couldn’t possibly have been intended. It behaves asymmetrically. If you open a portrait picture (i.e. taller than wider) in the lightbox and try to zoom into different details, you will see that:

• if you click the center of the image, the image is not zoomed centrally, and instead it gets shifted way to the left of what you’d expect
• if you click near the middle of the right edge of the image, the image gets shifted so much to the left that the right edge ends up left of center
• if you click near the middle of the left edge, the behavior is not a mirror image of the behavior when you click near the middle of the right edge; there is a huge “left bias” ??

• This reply was modified 3 years, 7 months ago by Rulatir.
• This reply was modified 3 years, 7 months ago by Rulatir.
• This reply was modified 3 years, 7 months ago by Rulatir.
• This reply was modified 3 years, 7 months ago by Rulatir.

The offness * sorry, redaction slip (I don’t seem to be able to edit the post after it was accepted?)

Thanks!

This can be worked around, but the workaround is on the much-work side.

First, you need to add Polylang translations to the actual Media Library entries you want to be able to display in a Foo Gallery in other languages than default. Don’t bother doing it with the bare-bones Media Library; you wil lose hours. Instead install the excellent and free Media Library Assistant plugin (no affiliation, I’m just a happy user), and it will provide an alternative media listing with a Translate bulk action. Heed the warning not to upload new media through MLA when Polylang is in All Languages mode!

Once you are done translating media, then for each collection of images you want to display as a Foo Gallery you must create a separate Foo Gallery instance for each relevant language. Then to each gallery you add attachments in the correct language. The last step is to use the right gallery on the right translation of the page.

For example if you want to make a gallery of early 20th century poscards from Zache?mie, Poland (then Saalberg, Germany), and you want to show it both on the English page and on the German page, then you need to add German translations to all the postcards attachments. Then you create a Foo gallery titled “Zache?mie in Old Postcards”, populate it with English attachments and insert it on the English page, and then you must also create a Foo gallery titled “Saalberg am alten Ansichtskarten”, populate it with the corresponding German attachments and insert it on the German page.

Phew!

Another update:

It turns out that the WP Performance Pack plugin is the culprit, but there was an additional confounding factor in that the incompatibility only manifests in my production environment and not in my development environment, despite the identical set of plugins and identical configuration.

The specific functionality of WP Performance Pack that conflicts with Polylang is of course the l10n accelaration. Both “Use gettext” and “Use alternative .mo reader” must be disabled for Polylang compatibility. Caching can be enabled though. Polylang vs. WPPP loading order makes no difference.

Could you look into this incompatibility?

Update: I switched to the path method (i.e. /de/ ), and it didn’t help. The logic that decides which .mo file to load is fragile. Once it works, then it doesn’t, then it works again. Making just about any change to the setup involving rewrites, permalinks or permastructs has a big chance of randomly breaking it or equally randomly fixing it.

This is nearly hopeless.

OK, I had the admin language switcher set to a language instead of “Show all languages”.

This is a problem though. Content should not disappear from listings like that. I think that a rule could perhaps be implemented to show a warning?

IF we are showing a post type listing in the admin

AND the post type is “virgin” with respect to Polylang (i.e. NO posts of that type have an association with a Polylang language taxonomy term)

AND a specific language is selected with Polylang’s admin language switcher

THEN show a transient warning explaining why the listing appears empty.

Dimskiy, thank you for the warning. If I hadn’t seen your single one-star rating, I would install this plugin and be disappointed. The ability to filter by categories when actually using the media library, as opposed to just being able to sort media into categories that do nothing productivity wise, is the single raison d’etre of media category plugins. Without it, they are useless. Your downvote is fully justified.

I am looking for a method to change the type (e.g. “page”, “category”, “tag”, “arbitrary URL”) of an existing menu item, without having to delete and recreate it, and so that its database ID remains unchanged.

The very specific use case is converting a “page” item that points to https://mywordpress.example.com/mypage/ to an “arbitrary URL” item that points to https://mywordpress.example.com/mypage/#myjumplink. Alternatively, is there a plugin that enables adding jumplinks to “page” menu items?

[deleted by author]

… and since the damn thing won’t allow me to correct formatting mistakes in the original post now, I will have to create another support topic…

Found the cause of this. I actually put those <code></code> tags in the page when I pasted the shortcode I had copied from the form definition screen. It is wrapped in code tags there, and Firefox duly pasted all copied HTML in the WYSIWYG editor.

Well I figured it out, but it’s a hack and I haven’t tested it on the front yet.

Each field definition in the admin screen is wrapped in a single HTML <fieldset> element. Just remove that fieldset from DOM using your browser’s debugger (e.g. Firebug) and then Save Changes. Done.

I suspend my downvote because I believe at this point that this is a simple omission bug that will be fixed soon. The developer apparently planned to include [X] buttons in the fieldsets but forgot to do it.

Seconded! I need to delete a field I have added myself, and frankly, an instant one-star review will follow if I fail to locate this absolutely elementary functionality either in the UI or in the docs within next 10 minutes.