Chris Whitford

OK, I think I’ve worked this out. When an image is inserted it picks up the alt text from the media meta, but if the alt text is added to the media meta later it doesn’t change in any images already inserted. So the two aren’t linked. This does explain something that puzzled me, which is that if the same image is used in several places it may need different alt text. I haven’t completely got my head around the block editor yet – it’s so much more complicated than the classic editor.

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 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”.

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.

This has fixed the problem for align left; I don’t have any align right. Thank you for your prompt reply. I’m impressed by your support.

The image is positioned correctly when on the page. Here are 2 screenshots:
screenshot2: showing the page with the same image+text directly on the page and inside another block
screenshot1: the html and styles in the developer window
Screenshots

Thanks for the tip about using an image block, which I hadn’t figured out, but this has the same problem. I’m using the GenerateBlocks plugin to create a tiled layout, with text and images in container blocks. The image is outside the container to the left. It moves to the correct position when the following CSS rule in main.min.css is disabled:

margin-inline-start: calc(( 100% – min(var(–block-max-width), var(–container-width-base)) )/2);

Perhaps this doesn’t allow for the containing block being a nested block, less than the full page width?

Another bug with this update:
Using a classic edit block with image+text, image left-aligned so that the text flows around the image, the image goes off-screen to the left. The problem is with the CSS rule “.entry-content .alignleft”. This doesn’t seem to be due to browser caching, and I’m not using any server-side caching plugins. I’ve done a temporary fix with custom CSS.

(This seems to be the only way to get text wrapped around an image. If anyone knows of another block which does this, let me know!)

Solved! In setting up the new website I had copied wp-config.php from another site, in which the constant WPCF7_ADMIN_READ_CAPABILITY had been redefined for reasons particular to that site.

This is what I had in wp-config.php:
define (‘WP_CONTENT_DIR’, $_SERVER[‘DOCUMENT_ROOT’] . ‘/files’);
define (‘WP_CONTENT_URL’, ‘//exhibition.landlps.org.uk/files’);
define (‘WP_PLUGIN_DIR’, dirname(__FILE__) . ‘/plugins’);
define (‘WP_PLUGIN_URL’, ‘//exhibition.landlps.org.uk/wp43/plugins’);

but the missing url was something like
https://exhibition.landlps.org.uk/files/plugins/foogallery/&#8230;..

I’m not sure the rationale for my file structure was very sound anyway. The main purpose was to not use default file locations because that’s what hackers target.

Thanks for your reply.
Current advice, to speed up page loading, is to load JS asynchronously or in the footer wherever possible. Loading jquery is triggered by the first script which depends on it. As noted, if the in_footer parameter in wp_enqueue_scripts() is true, it loads the script in the footer but loads dependencies as in the header (if called early enough). If some other script also depended on jquery and had to be in the header, that would cause jquery to be loaded. On my site there are no JS scripts explicitly loaded in the header so there is no benefit having jquery loaded early.

Thanks for your reply. I think I understand now. My main stylesheet is style.css which is for media=’all’ and I’m overriding this in the print stylesheet. VFM is assuming that if the media types are different the stylesheets are alternatives so the relative order doesn’t matter. So it’s a feature, not a bug! The easiest option at the moment is to load the print-style.css in the footer.

Thanks for your reply, but I don’t think this is the explanation. All stylesheets are loaded using wp_enqueue_styles. I’m loading both desktop.css and mobile.css because one of them is marked as ‘alternate’ and JS is used to toggle between them. On a tablet in particular, a user may prefer one or the other, and doing it this way avoids reloading the whole page. So these 2 files are added to the exclusion list in VFM. When I first installed VFM, print.css was loaded separately (presumably because it has media=’print’) in the correct place, after the VFM generated file. It is only after I updated VFM that print-style.css became inlined, and appeared before the VFM generated stylesheet. When it’s excluded from VFM it is loaded in the correct order.
I didn’t understand your last para. I haven’t selected to inline anything. VFM is inlining print-style.css by default.
I should add that VFM is an excellent plugin and this is the only issue I’ve had with it up to now.

The problem was with the Post Types Order plugin. In the settings screen there’s a tick box to apply the custom sort order to admin screens as well as the front-end. This was ticked, which I hadn’t even noticed. When cleared this problem goes away – a very simple fix. When I first installed this plugin a few years ago there were a few issues with it which I fixed myself. As I had modified the code I haven’t been updating it. I must check out the latest version.

Apologies for a false report – as I said, this is a new installation of WordPress, and I found an error in my wp-config file. I haven’t re-installed the latest NGgallery, but I think this was the cause of the problem.