Captions don’t display

I’ve done a bit of hacking and tracked this one down. In src/LightboxPhotoSwipe/LightboxPhotoswipe.php the assumption is that images are below the wp_content folder, which is below the site (WordPress) folder, which it may not be. It would be safer to use home_url() rather than site_url() on lines 260 and 261. But the path part of the url is always based on DOCUMENT_ROOT, so the best approach is to extract just the domain from the url and replace this by $_SERVER[‘DOCUMENT_ROOT’] . ‘/’. The domain can be extracted from the home or site url using preg_match().

Another variation (I don’t know if this can occur) is if the url in the <img> tag doesn’t include any protocol, so it starts with “//mydomain.com/”. This is a legal url and will find the image file so perhaps it needs to be recognised as well.

No, the plugin does not assume, that the content is in “wp_content”. In fact this folder is not used at all. Also I do not use DOCUMENT_ROOT as well.

The relevant part is this:

if (substr($file, 0, strlen($baseurlHttp)) === $baseurlHttp || substr($file, 0, strlen($baseurlHttps)) === $baseurlHttps) {
    $isLocal = true;
    $params = '';
}

This means: if the URL of the file starts identically to the URL of the website then it is considered to be site local and captions may be retrieved from the database if they are not provided as alternative text (ALT tag) or as figure caption in the HTML code.

Why this does not work on your site – I don’t know. The code works on other site which also moved the upload folder to another path. To find out what is going on in detail, I would have to do debugging on your server which is out of scope for free support. But the code is open source and any pull request with a tested fix is welcome: https://github.com/arnowelzel/lightbox-photoswipe/

For your problem I suggest another approach: your images are all missing alternative text (ALT tag). This is not recommended for good accessibility. Every image should have an alternative text added. So I would add the captions to the “Alternative text” of the images and enable using “Alternative text” as a source for captions. Then also impaired users get an image description and there is not database lookup needed which is better for performance anyway.

Edit: about using URLs starting with the scheme “//” – yes this may cause captions to fail if they have to be retrieved from the database since the plugin has to find the exact image URL in WordPress (maybe I will implement a workaround for that in future updates). But this is not the case on your site – your images all start with https://www..

• This reply was modified 1 year, 7 months ago by Arno Welzel.
• This reply was modified 1 year, 7 months ago by Arno Welzel.
• This reply was modified 1 year, 7 months ago by Arno Welzel.

In addition: if you are using any kind of “optimizer” or caching plugins – disable that temporary to check if this changes anything. Often these plugins can cause side effects.

Thanks for your reply. I tried using the alt text but that didn’t work. It turns out that this has to be entered in the block editor; if it’s in the alt text field in the edit media page it doesn’t get put into the html. The two don’t seem to be linked and the block editor overrides the media setting.

The way I set up wordpress sites is to put the wordpress files in one subfolder and wp-content in another subfolder. This is partly for security, to hide the path to the wordpress files, and partly to keep urls clean. In the code referenced above, at lines 260-261, the site url is being used (i.e. the wordpress folder). Images are not below that folder, but they are below the home url folder so get_home_url() is the better function to use. However, as the web server uses the path part of the url as a file path from DOCUMENT_ROOT, that is a more direct way to get the file location.

On the use of alt tags, WordPress states “Leave empty if the image is purely decorative”.

About the meaning of “decorative” in the context of alternativ text for images:

These are images which have no meaning for your site and are only “eye candy”. Any other image is not decorative, especially not if you offer to open it in a lightbox – then it is content and not “decoration”.

Also see https://help.siteimprove.com/support/solutions/articles/80000863904-accessibility-image-alt-text-best-practices

About getting alternative text as ALT tag to the website:

I don’t know what is wrong with your setup – WordPress itself has no problem at all creating ALT tags if the media contains an alternative text, also see this example: https://wordpress-demo.arnowelzel.de/lightbox-with-photoswipe-caption-sources/

About DOCUMENT_ROOT:

$_SERVER['DOCUMENT_ROOT'] has nothing to do with the URL at all. This server variable is the physical path on your server where the files are stored for your webhosting. Also see https://www.php.net/manual/en/reserved.variables.server.php.

I already told you the relevant part in the code – the plugin only compares the URL of image link with URL of the website. Local file paths are completely irrelevant in this case! The local part of the URL (and not the document root!) is then used to identify the metadata record in the database which looks like this, for example if the image is named https://example.org/2023/04/img123.jpg

s:4:"file";s:20:"2023/04/img123.jpg"

This is what my plugin is looking for if it determined that an image belongs to the website and is not “external” from another website.

Also the upload path has no meaning for the caption at all! This is only relevant later when getting the jpeg header data from the image file including the EXIF data. But as you already explained the EXIF works, this is a proof that the path to the image file is correct – because otherwise EXIF could not work at all, since then the file could not be read!

About get_site_url() vs. get_home_url():

Both functions return exactly the same base URL. The only difference is, that get_home_url() will return something different, if you configured a different frontend URL which is not the same domain as your backend. But since the images usually come from the backend and not the frontend I must use get_site_url() to determine if images belong to the website or not.

However feel free to test your ideas about what should be changed in the PHP code – if it works, let me know what you have changed and I can do some more testing here as well. I may also provide a hook for this in a future update, so one can override the key which is used for querying the image meta data with a custom function if needed for the local site setup. However then you still need to be aware exactly what meta key your site uses for the images in the database records.

Conclusion

I believe you use some kind of alternative media gallery plugin or non standard way to organize the media, so the meta records in the database are not handled by the WordPress core as expected. But further investigation is completely impossible without knowing any detail about your website (plugins, theme, site configuration etc.) and doing such support is beyond the scope of free support – sorry!

• This reply was modified 1 year, 7 months ago by Arno Welzel.

I looked at several lightbox plugins and liked this one, except that it wasn’t displaying any titles. I’ve offered a fix that works for me, which is to change lines 260 and 261 in the file src/LightboxPhotoSwipe/LightboxPhotoswipe.php, changing get_site_url() to get_home_url(). I think this is because the site url is something like //mydomain/wordpress and the wp-content url is //mydomain/files/ which isn’t below the site url. I do this partly for security, as it hides the path to the wordpress files, and partly to give cleaner urls.

On the separate issue of alt tags, I’m using the Generate Blocks plugin for layout, as it is more flexible than the Media and Text block. It seems that when an Image block is inside a Generate Blocks container, it doesn’t pick up the alt tag from the image metadata. This obviously is nothing to do with the lightbox plugin. Just another quirk to work around.

I’ll mark this as resolved as I know how to work round it, but if it is corrected in the plugin that will avoid having to edit the code.

Thanks for the feedback and the suggestion for the change. I’ll have a look into that and provide an update if needede.

About the alt tags: if you can give me a specific example with the generated HTML code I may add a parser for this. The frontend script already contains a number of parsers for certain structures based on Elementor, Gutenberg and some different plugins and image blocks. Adding one more is not a big deal.

Sorry… forget what I said about the alt tags – I confused the missing output of the alt tag in the HTML code with using it in the lightbox.

Release 5.0.32 contains the suggested change. Thanks for the hint.