Rick Hellewell

Been working on the update to remove all of those warnings by making the code PHP 8x compatible. Getting close to finishing – just testing all of the options.

But then suddenly wondered if there were any new features or other enhancements that might be useful?

If you (or anyone) think of any possible new features/enhancements, create a new topic here and put ‘feature request’ in the title.

Thanks. I suspect you are using PHP version 8.x, which gives warnings about trying to check a variable that doesn’t exist. PHP 7.x didn’t care.

That version number on the wp_register_style is just there to add a version number to the style call to help ‘bust’ CSS caching. Only really useful during my debugging the code.

I probably should go through all the code to get rid of the checking of undeclared variables to keep PHP 8.x happy (there’s probably others). Since those are ‘warnings’, they shouldn’t ‘kill’ your site unless you have non-standard debug/error logging enabled

Error has been fixed. after applying update Thanks for the efforts.

Looks to me to be related to PHP version – the plugin is causing warning errors on my site, which is running PHP 8.1.9.

Use of undefined variables – you need to put an isset() around all array elements that may not be defined (like server variables for IP address, etc).

You are correct, of course. Found the error in my code, which was hiding from the error logs for some reason.

Thanks.

Took a quick look at the video. I may have to try that on my test site.

But thinking that it might be interesting to see the HTML code block that is generated – in the block editor screen and the ‘public’ page.

The plugin just looks for HREF codes, and then loops through all HREF codes looking for an amazon link. If an amazon link is found, it take the query string and looks for any ‘tag’ query parameter. If one is found, it is replaced with your link code. If not found, it adds one.

So the plugin only looks at any “<a href=’somelink’ …” . If the link is not an HREF, then it doesn’t do anything.

That’s why a comparison of the generated code in the editor and on the ‘live’ page might be interesting.

I can’t duplicate the problem – or understand your issue. Is the issue with the public-facing site not showing the links properly, or with editing the post (as an admin) using the block editor and the links break?

please provide exact steps i can use to duplicate this issue. Thanks.

In regards to your last reply:

This is a honeypot field that is used in protecting forms against bot attacks. Since this field is only for bots, it is set off-screen so that site’s normal users don’t feel it.

Putting a field off screen does not protect against bot attacks. Bots don’t ‘read’ the screen, they look at the source code of the screen. Putting a field off-screen doesn’t do anything to block a bot. It’s a waste of time. (As are hidden fields, whether they have a ‘hidden’ type or CSS that is set to display:none. )

None of those techniques block bots. And some browsers may ignore that offscreen display attempt.

— We checked this issue on our end but could not replicate it. Also by default, the plugin doesn’t wrap the form inside <code class=”es-code”> tag. Can you let us know the steps that you are following on your end? That would be helpful in replicating the issue.

I see the ‘code’ tag on multiple sites, with multiple themes, including the ‘twenty’ theme. There is no reason to use a ‘code’ tag around your form. You should be using a unique class to do stuff like that.

I’ve had to put this CSS to get around the issue. But your ‘honeypot’ technique of putting things off screen is just not a valid way to block bots.

input[name="esfpx_es_hp_email"] {
	display: none;
}

This will get rid of that useless off-screen field.

Further investigation, using a different site, with different themes. The extra field seems to be coming from this code just before the submit button:

<label style="position:absolute;top:-99999px;left:-99999px;z-index:-99;"><input type="email" name="esfpx_es_hp_email" class="es_required_field" tabindex="-1" autocomplete="-1" value="" /></label>

In addition, the form is wrapped in a block, so any theme CSS that has defined will cause issues with the form. Example:

<code class="es-code">

So, two issues: why is there a field that has an absolute position off screen? And why is there a tag wrapped around the form?

Those two issues are causing problems in some themes.

Assuming that when an email has images attached, each image has a file name or name of some sort. Those names would be unique to that specific email.

So processing an email would grab those image file names, place them in a temp array for use when that email is processed. Once the email subject and text is processed, any pictures are processed.

Each email has several things that would be processed. THe message ID would be used as a key to the other parts of the same message. Message ID 12, for example, would have subject and text things that would be stored in a temp record. That record would also have the array of image file name (image1.jpg, image2.jpg, etc).

That ‘hunk’ of info (subject, text, array of image file names) would be used to process the email. As eash hunk of info (subject/text/immage item) was processed, that item is flagged as ‘done’. If the entire message is not fully processed, then the next CRON for processing would see that record as not completely processed, and would pick up where it was interrupted.

Only when a single message is fully processed, would that temp record row be deleted, so the next message could be processed.

(Sort of late here, and I just got home from driving 13 hours, so not very lucid, perhaps.)

Cogitating on this issue, I note:

1. Image file names in an email do not change.
2. So, grab the image emails into an array. Copy the image files into a temporary folder.
3. Grab the text in the email and convert it into a new post. Set the post status to draft.
4. Grab the subject line in the email and use it as the new post name.
5. Store the image file name array, and the post ID into a temporary setting (in the options table, or wherever)
6. Process each image file in the array. When processing is complete, add the image to the post, and remove the image file name from the array in that settings table row.
7. Repeat step 6 until all images are processed. If all images posted (no more files in the settings array), delete that row, and set the new post status to publish.
8. If the processing is stopped for any reason, the unprocessed image file names will remain in the table. The next CRON processing will look at the table for any unprocessed files, and process those into the post ID (post ID stored in the settings table temp row.
9. Repeat step 8 as needed to process all images in that message to the post. If done, set post to ‘publish’.

This process will ensure that there are not multiple images processed into the media area, nor will there be multiple ‘tmp titles’ cluttering up the Post list. This would be a great improvement, and would eliminate all of the support messages about excess images and tmp_titles, and mailings that don’t make it into the blog.

Huzzah !! Thanks! Your solution works, but I decided to do this instead (which also worked):

* {transition:none;}

Thanks for the great (and speedy) support!

Still no response after 5 months. So not hopeful that this will get a response.

What filter could be used to let this plugin use the default/current comment box editor?

Or is there a better after-submittal comment editor than this one – perhaps with better support?

Well, I thought that manual copy of the plugin files from a ‘good’ site to the problem site would fix things. And it did. For a day.

The next day, the plugin files in that problem site have reverted back to the previous version. Without any actions on my part. It’s a test site, but I’ve left it alone for a few days.

What would be causing the plugin files to revert back to a previous version? There are no plugins on the site that have that ‘feature’. I see nothing anywhere on the site that would revert files to a previous version.

The only thing that appears to revert the files is the manual ‘check for updates’ in IWP admin. And the revert files only happens on the first time I run the update check that day. Subsequent update checks on the same day don’t cause the file reverts.

One one of the sites that keeps complaining about the 1.9.9 update (even after it gets updated), I looked at the plugin files. The init.php file had a version number of 1.9.8, even after doing the client update.

The sites that are ‘not complaining’ have an init.php file with version of 1.9.9.

So I copied a ‘good site’ (uncomplaining) plugin files to the complaining site, therefore doing a manual update. A IWP rescan of all the sites fixed that complaining site. The other complaining site (where I didn’t do a manual update) is still complaining about the 1.9.9 version being needed.

So, the init.php file was not getting updated during, and causing the continual ‘complaining’ about the 1.9.8 version. Perhaps your client update process (via the IWP control panel) is not updating properly.

Note that I set all plugins on the formerly complaining site to ‘no auto updates’. That did not change the complaining site. Only a manual copy of all files from a ‘non-complaining’ site to the complaining site fixed the complaining site.