exmosis

I’ve had a similar issue with a second plugin on the same site, which seems to be caused by the tag being removed from the source – see https://www.ads-software.com/support/topic/version-3-2-1-missing/

We’re running Wordfence for security, which apparently takes a copy of plugins for running against integrity checks and I wonder if versioning issues are causing problems here.

I’m trying to compare readme.txt between our site, plugin downloads, and the plugin info screen, but it’s a bit confusing:

readme.txt on our site:

• Tested up to: 6.2
• Stable tag: 1.6.3

readme.txt downloading 1.6.3 package from the plugin page:

• Tested up to: 6.2
• Stable tag: 1.6.3

readme.txt downloading dev version from the plugin page:

• Tested up to: 6.5
• Stable tag: 1.6.3

I’m not familiar with how plugin versions work under the hood though. Would updating the tag version help Wordfence see the expected change? Wordfence notes that “If you install that new version and run a scan then you may get a scan result that a file or files have been modified because our mirror copy of the plugin for that same version number differs due to the changes the plugin author made without committing a new tag version number.“

@stevenjc What do you see in your readme.txt now that you’ve reinstalled the plugin, out of interest?

• This reply was modified 6 months, 3 weeks ago by exmosis. Reason: Added Wordfence link and info for reference

Having a look into something related I think – WordFence reports a file difference, but shows “Unable to read file contents” when I try to view the differences. The file exists on our server, but I assume it’s trying to locate the canonical file, which may be missing for the same reason.

Not sure if this is related, but we have v1.6.3 installed, dating back to March 30th 2023. The latest repo version indicates readme.txt has been updated to increase Tested Up To to 6.5, but no obvious changes to classic-editor.php. There’s no corresponding version tag update for the change to readme.txt, but I’m not sure how plugin updates work.

Will keep an eye on this thread.

• This reply was modified 7 months ago by exmosis. Reason: Hit enter too soon

Have also hit this recently, which blocked out non-admin editors and users on the site.

As an immediate workaround we could promote trusted users to be admins, which bypasses the capability checks and the error.

As a second workaround, I modified the class-gfp-drip.php file to remove the arrays. Lines 129-131 now look like this instead:

‘capabilities_settings_page' => 'gravityforms_drip_plugin_settings',
'capabilities_form_settings' => 'gravityforms_drip_form_settings',
'capabilities_uninstall' => 'gravityforms_drip_uninstall'

I’ve tried to get in touch with the plugin’s developer through various means (email, slack request, mastodon), but no luck so far.

Would be very interested to know if this plugin is still being supported, and/or whether there any alternatives that provide the same functionality.

• This reply was modified 7 months, 3 weeks ago by exmosis.

@wayneallen-1 Thanks for confirming. I figure, theoretically, that you could do something like “caption1: …” for all emails, in the same way you use #img1# for plain text ones? But maybe allowing for both attachments and inline images does muddy the water.

Replying to myself in case anyone else looks into this.

From what I can see, attaching images using HTML formatted emails always replaces alt=”{CAPTION}” with alt=”” – there doesn’t seem to be an easy way to hook anything to change that.

But as an alternative I’ve switched to the Preferred Text Type config to Plain Text, and can set alt text using the “#img1 caption=’my alt text’# approach as documented. This will do me for now, anyway.

@voltronik Thanks, I think I see ?? So if I tick “Send notification to Author”, and the Author comments on their own post, they should get a notification of their pwn comment?

The other notifications do usually hide the second box for me too, actually. Bu for some reason it only seems to be the options “New Comment” and “Post comment approved” options under “Posts”, and “Comment approved” under any of the custom post types. That might make sense – you can then block notifications to the original comment poster. But not sure why “New comment” would only do it for non-custom posts.

Sorry, hope that makes sense!

One last quick question @voltronik – when I set up a notification for a custom post type, the option “Do not send this Notification to the User that triggered it” disappears if I tick “Send this notification to the Author”. Is that expected behaviour, and if so, is there a reason for it? This doesn’t happen for normal Post notifications.

Great, thanks for the quick reply! That’s what I thought, but wanted to just confirm.