Unable to create gallery with polylang

  • Resolved alfredino

    (@alfredino)


    2 weeks, 1 day ago

    Hi,

    I’m using the free version of your plugin on two personal, private websites. It’s been working well since August 2025, when I first started using it. Today I decided to update some images by replacing them with more recent ones, but it didn’t work (I tried the grid, slider and masonry layouts). I then deactivated all the plugins one by one and discovered that the problem was caused by Polylang. I then tried doing the same on the other website, which also uses Polylang, and everything worked correctly (I can rule out the problem being linked to other plugins, as I deactivated them all). The only difference between the two websites is the theme (the one with the problem uses Twenty Fourteen, the other uses Ocean WP). Both are running the same version of PHP and MySQL and are hosted on the same hosting.

    What could be the problem?

    Thank you

Viewing 7 replies - 1 through 7 (of 7 total)
  • Plugin Support Nadiya – SG Support

    (@wpdexterity)

    2 weeks, 1 day ago

    Hello,

    Since the same version of Polylang works correctly on your other website, Polylang alone is probably not the cause. The issue may be related to a compatibility problem between Polylang and the Twenty Fourteen theme, or to a Polylang setting that affects media handling on this site.

    Could you please check the following?

    1. Go to Languages → Settings → Media and check whether media translation or duplicated media is enabled. Please let me know which options are selected there.
    2. Try creating a completely new gallery on the affected website and add a few newly uploaded images. Then try replacing one of those images. This will help determine whether the issue affects only existing galleries or all galleries.
    3. Please clarify what “didn’t work” means in this case:
      • Does the replacement image fail to appear in the gallery editor?
      • Does it appear in the editor but the old image remains on the frontend?
      • Does the gallery fail to save or show an error?
    4. Open the browser console while replacing and saving an image, then check whether any JavaScript errors appear. A screenshot or copied error text would be very helpful.

    It would also be useful to know the WordPress version, SimpLy Gallery version, Polylang version, and whether the affected page/gallery is assigned to a specific language or is shared between languages.

    Thread Starter alfredino

    (@alfredino)

    2 weeks, 1 day ago

    Hi,

    I’m using the latest version of wordpress 7, polylang 3.8.5, simpLy gallery block & lightbox 3.3.3.3 and twenty fourteen 4.5. Languages → Settings → Media enabled and media are not duplicated.

    I solved, but I’m not sure how. The last thing I did: Languages → Settings → Permalinks and saved again.

    Thank you

    P.S. sorry, the problem is still there. However, I was able to update the pictures.

    • This reply was modified 2 weeks, 1 day ago by alfredino.
    Plugin Support Nadiya – SG Support

    (@wpdexterity)

    2 weeks, 1 day ago

    Thank you for the additional details.

    Saving the permalink settings may have refreshed WordPress rewrite rules, but it would not normally affect how gallery images are replaced. Since you were able to update the images, the remaining issue may be happening only on the frontend rather than inside the gallery editor.

    Could you please clarify what is still not working?

    For example:

    • Do the new images appear correctly in the gallery editor, but the old images are still shown on the public page?
    • Does the gallery display incorrectly after the update?
    • Does it happen in every language or only on one translated page?

    If the problem is visible on the frontend, please share a direct link to a page containing an affected gallery. That would allow me to inspect the publicly available HTML, JavaScript errors, and gallery output without needing access to the website.

    Thread Starter alfredino

    (@alfredino)

    2 weeks, 1 day ago

    The console output. The first problem will be solved with next version of the plugin. The other problem I am not sure if it is related to All-In-One Security (AIOS), 2FA is disabled. Not sure about the last one too: is it related to twenty fourteen theme?

    load-scripts.php?c=0&load%5Bchunk_0%5D=jquery-core,jquery-migrate,hoverIntent,utils,wp-dom-ready,wp-hooks&ver=7.0:5 JQMIGRATE: Migrate is installed, version 3.4.1
    pgc_sgb.min.js?ver=3.3.3.3:1 SimpLy Gallery Block v.3.3.3.3
    deprecated.min.js?ver=990e85f234fee8f7d446:1 Block with API version 2 or lower is deprecated since version 6.9. See: https://developer.wordpress.org/block-editor/reference-guides/block-api/block-api-versions/block-migration-for-iframe-editor-compatibility/ Note: The block "pressidium/cookies" is registered with API version 2. This means that the post editor may work as a non-iframe editor. Since all editors are planned to work as iframes in the future, set the apiVersion field to 3 and test the block inside the iframe editor.
    S @ deprecated.min.js?ver=990e85f234fee8f7d446:1
    (anonymous) @ blocks.min.js?ver=ef38e42500165bfda301:130
    (anonymous) @ data.min.js?ver=1756b6a2676c1b3369ab:1
    (anonymous) @ redux-routine.min.js?ver=64f9f5001aabc046c605:1
    (anonymous) @ data.min.js?ver=1756b6a2676c1b3369ab:1
    (anonymous) @ data.min.js?ver=1756b6a2676c1b3369ab:1
    Proxy.get @ data.min.js?ver=1756b6a2676c1b3369ab:1
    (anonymous) @ blocks.min.js?ver=ef38e42500165bfda301:130
    (anonymous) @ data.min.js?ver=1756b6a2676c1b3369ab:1
    (anonymous) @ redux-routine.min.js?ver=64f9f5001aabc046c605:1
    (anonymous) @ data.min.js?ver=1756b6a2676c1b3369ab:1
    (anonymous) @ data.min.js?ver=1756b6a2676c1b3369ab:1
    (anonymous) @ data.min.js?ver=1756b6a2676c1b3369ab:1
    Yn @ blocks.min.js?ver=ef38e42500165bfda301:130
    106 @ cookies-block.js?ver=a226793d2bf07a8fa7e1:1
    n @ cookies-block.js?ver=a226793d2bf07a8fa7e1:1
    (anonymous) @ cookies-block.js?ver=a226793d2bf07a8fa7e1:1
    n.O @ cookies-block.js?ver=a226793d2bf07a8fa7e1:1
    (anonymous) @ cookies-block.js?ver=a226793d2bf07a8fa7e1:1
    (anonymous) @ cookies-block.js?ver=a226793d2bf07a8fa7e1:1
    deprecated.min.js?ver=990e85f234fee8f7d446:1 Block with API version 2 or lower is deprecated since version 6.9. See: https://developer.wordpress.org/block-editor/reference-guides/block-api/block-api-versions/block-migration-for-iframe-editor-compatibility/ Note: The block "twofactor/user-settings" is registered with API version 1. This means that the post editor may work as a non-iframe editor. Since all editors are planned to work as iframes in the future, set the apiVersion field to 3 and test the block inside the iframe editor.
    S @ deprecated.min.js?ver=990e85f234fee8f7d446:1
    (anonymous) @ blocks.min.js?ver=ef38e42500165bfda301:130
    (anonymous) @ data.min.js?ver=1756b6a2676c1b3369ab:1
    (anonymous) @ redux-routine.min.js?ver=64f9f5001aabc046c605:1
    (anonymous) @ data.min.js?ver=1756b6a2676c1b3369ab:1
    (anonymous) @ data.min.js?ver=1756b6a2676c1b3369ab:1
    Proxy.get @ data.min.js?ver=1756b6a2676c1b3369ab:1
    (anonymous) @ blocks.min.js?ver=ef38e42500165bfda301:130
    (anonymous) @ data.min.js?ver=1756b6a2676c1b3369ab:1
    (anonymous) @ redux-routine.min.js?ver=64f9f5001aabc046c605:1
    (anonymous) @ data.min.js?ver=1756b6a2676c1b3369ab:1
    (anonymous) @ data.min.js?ver=1756b6a2676c1b3369ab:1
    (anonymous) @ data.min.js?ver=1756b6a2676c1b3369ab:1
    Yn @ blocks.min.js?ver=ef38e42500165bfda301:130
    (anonymous) @ gutenberg-blocks.js?ver=1780652408:5
    deprecated.min.js?ver=990e85f234fee8f7d446:1 wp.editPost.PluginDocumentSettingPanel is deprecated since version 6.6. Please use wp.editor.PluginDocumentSettingPanel instead.
    S @ deprecated.min.js?ver=990e85f234fee8f7d446:1
    me @ edit-post.min.js?ver=28ef50b859708963e197:1
    rn @ edit-post.min.js?ver=28ef50b859708963e197:1
    mf @ react-dom.min.js?ver=18.3.1.1:105
    Qk @ react-dom.min.js?ver=18.3.1.1:250
    Ri @ react-dom.min.js?ver=18.3.1.1:195
    Ok @ react-dom.min.js?ver=18.3.1.1:195
    Nd @ react-dom.min.js?ver=18.3.1.1:194
    Li @ react-dom.min.js?ver=18.3.1.1:189
    db @ react-dom.min.js?ver=18.3.1.1:79
    (anonymous) @ react-dom.min.js?ver=18.3.1.1:184
    pgc_sgb_masonry.js?ver=3.3.3.3:1 SGB MASONRY v.3.3.3.3
    load-scripts.php?c=0&load%5Bchunk_0%5D=react,react-jsx-runtime,wp-autop,wp-blob,wp-block-serialization-default-parser,wp-hooks,wp-deprecated,wp-dom,react-dom,wp-escape&load%5Bchunk_1%5D=-html,wp-element,wp-is-shallow-equal&ver=7.0:101 Block with API version 2 or lower is deprecated since version 6.9. See: https://developer.wordpress.org/block-editor/reference-guides/block-api/block-api-versions/block-migration-for-iframe-editor-compatibility/ Note: The block "twofactor/user-settings" is registered with API version 1. This means that the post editor may work as a non-iframe editor. Since all editors are planned to work as iframes in the future, set the apiVersion field to 3 and test the block inside the iframe editor.
    S @ load-scripts.php?c=0&load%5Bchunk_0%5D=react,react-jsx-runtime,wp-autop,wp-blob,wp-block-serialization-default-parser,wp-hooks,wp-deprecated,wp-dom,react-dom,wp-escape&load%5Bchunk_1%5D=-html,wp-element,wp-is-shallow-equal&ver=7.0:101
    (anonymous) @ blocks.min.js?ver=ef38e42500165bfda301:130
    (anonymous) @ data.min.js?ver=1756b6a2676c1b3369ab:1
    (anonymous) @ redux-routine.min.js?ver=64f9f5001aabc046c605:1
    (anonymous) @ data.min.js?ver=1756b6a2676c1b3369ab:1
    (anonymous) @ data.min.js?ver=1756b6a2676c1b3369ab:1
    Proxy.get @ data.min.js?ver=1756b6a2676c1b3369ab:1
    (anonymous) @ blocks.min.js?ver=ef38e42500165bfda301:130
    (anonymous) @ data.min.js?ver=1756b6a2676c1b3369ab:1
    (anonymous) @ redux-routine.min.js?ver=64f9f5001aabc046c605:1
    (anonymous) @ data.min.js?ver=1756b6a2676c1b3369ab:1
    (anonymous) @ data.min.js?ver=1756b6a2676c1b3369ab:1
    (anonymous) @ data.min.js?ver=1756b6a2676c1b3369ab:1
    Yn @ blocks.min.js?ver=ef38e42500165bfda301:130
    (anonymous) @ gutenberg-blocks.js?ver=1780652408:5
    jquery-migrate.min.js?ver=3.4.1:2 JQMIGRATE: Migrate is installed, version 3.4.1
    block-editor.min.js?ver=93c3566b7f24c15b7e17:76 twentyfourteen-block-editor-style-css was added to the iframe incorrectly. Please use block.json or enqueue_block_assets to add styles to the iframe. ​
    j @ block-editor.min.js?ver=93c3566b7f24c15b7e17:76
    • This reply was modified 2 weeks, 1 day ago by alfredino.
    Thread Starter alfredino

    (@alfredino)

    2 weeks, 1 day ago

    • Do the new images appear correctly in the gallery editor, but the old images are still shown on the public page? No, the new images are not loaded.
    • Does the gallery display incorrectly after the update? No, they are fine. I cannot neither modify them nor add a new gallery (I can add it without images).
    • Does it happen in every language or only on one translated page? Every language
    Plugin Support Nadiya – SG Support

    (@wpdexterity)

    2 weeks, 1 day ago

    Thank you, this clarifies the issue.

    The problem is not related to the gallery layout or to images already displayed on the frontend. The Media Library is not loading images inside the editor, so SimpLy Gallery cannot add or replace them. This is why you can insert a new gallery block, but cannot add images to it.

    Could you please test one thing: add a standard WordPress Image block and click Media Library. Does the media popup load your images there?

    If images also do not load in the standard WordPress Image block, the issue is outside SimpLy Gallery. It is likely related to the Media Library request itself, such as a blocked REST API or admin AJAX request.

    Please then open your browser Developer Tools → Network, try opening the Media Library, and look for failed requests shown in red. In particular, please check for requests containing:

    • wp-json
    • wp/v2/media
    • admin-ajax.php

    A screenshot of the failed request, including its response or status code, would be very helpful.

    The All-In-One Security plugin could still be relevant if it blocks REST API or AJAX requests, even with 2FA disabled.

    Thread Starter alfredino

    (@alfredino)

    2 weeks, 1 day ago

    Hi,

    the standard wordpress image block works correctly. There are no errors in Developer Tools → Network (I tried both to upload and already uploaded images).

    I asked to All-In-One Security for clarification.

    Thank you

Viewing 7 replies - 1 through 7 (of 7 total)

You must be logged in to reply to this topic.