Dave

Can you check your Developer Tools Console (Chrome)? Do you see any error? If you click on Screen Options (top of the Media Library), do you see the Renamer column there? Is it checked?

No column in Media Library, nor is there an error in the console, nor is there a checkbox for Renamer under the ‘Screen options’ panel. I’m using Firefox 79.0.

I’ve checked the manual mode option in the settings but it doesn’t seem to honour this option.

Do you mean that the image wasn’t renamed in the post, even though it should have? Is the post broken?

Correct, the image didn’t rename. I suspect that might have something to do with the missing option though.

I think you are talking about hacking the Select or Upload Media modal…

I am! My thought was that if the image could be renamed prior to selecting the image within the post, it would stop the images from being broken in the post (once they are renamed but the post references aren’t updated). It may well be that v5 fixes this issue once I can get the manual rename option back again.

@tigroumeow I’ll turn on the log to see if anything gets caught by that to give further clues as to what’s going on.

@tigroumeow Thanks for your speedy response. I can sympathise with your comments on Gutenberg. It’s a right old pain to work with compared to the classic editor.

I’ve just installed v5. The settings UI looks much better now.

I can’t see the rename option in the Media Library any more in list view 😭 The column with the rename button has vanished. I’ve enabled ‘Manual Rename’ in the options but the buttons don’t appear.

Separately, I uploaded an image to the post, edited the image alt/title in Media Library from within the post, saved the post, and exited. Neither the image URL nor the post have been updated with the clean URLs.

I disabled ‘rename on post save’ to test and it made no difference.

Thanks for your speedy reply. I’ve enabled the last option but it doesn’t seem to do anything.

So the code I have in header.php is:

<img src="<?php bloginfo(template_directory); ?>/images/logo.jpg" />

Looking at the Wiki, the ‘WebP Attribute To Replace’ in this instance should be img.src (or img.data-src as lazy loading is also enabled). Both of these are in the list.

‘WebP For Extra srcset’ is set to on.

I’ve uploaded logo.webp to the images directory right next to logo.jpg. But in Chrome, it still favours the jpg, even though the article body is now loading webp images instead. So WebP looks to work fine for anything in the content loop, but doesn’t seem to be picking up anything else hardcoded into the template.

So my question really is should it be automatically changing the hardcoded URLs in my template, or will it only do this for images that come from the media library?

@cliqueradar – Sadly not. I took a look at the Google docs, and the existing plugin code. I had hoped it was a case of moving some stuff around to make it work. Alas not.

The invisible Captcha requires JavaScript to be triggered at the time the form is submitted to populate a Captcha field. This is then processes as it is in the existing plugin.

I don’t know enough about Mailster’s architecture to know if there’s a hook to trigger a JavaScript function on submit. I haven’t had a chance to dig any deeper, although I’d love to find a solution as the ReCaptcha design (even the compact version) is awful on newsletter forms, and I’m pretty sure it’s costing me subscribers. Removing it opens me up to way more spam than I need, so it’s a necessary evil right now.

@everpress – Do you know if there’s a hook for triggering a JavaScript function on submit of a Mailster form? Furthermore, is there a set of developer docs available for Mailster than you know about?

Thought this might be of use from the System Info tab:

Delivery Method               sparkpost
SMTP Port check               no smtp
Send at once                  5
Send limit                    1000
Send period                   24

Test Mail                     OK

Port 110                      (pop3) open.
Port 995                      (pop3s) open.
Port 993                      (imaps) open.
Port 25                       (smtp) open.
Port 465                      (urd) open.
Port 587                      (submission) open.

I’m also running:

                              Mailster - Email Newsletter Plugin for WordPress: 2.2.9
                              Mailster Contact Form 7: 1.0.1
                              Mailster Google Analytics: 1.0
                              Mailster reCaptcha: 1.1
                              Mailster SparkPost: 1.0

Looking at the database, the verification setting in the array is 0, so presumably the Mailster interface cannot handshake with Sparkpost to verify the URL. However, the API key has all privileges granted, and when I send a test message, it routes through Sparkpost.

That’s a shame. I’ll have a look through the code later on and see if I can add it in myself as a temporary measure until it is officially supported.

Either that, or an admin option to redirect non-registered visitors to the login page, bypassing the modal form altogether.