KarenWallace

I’m getting the same thing. Downgrading to 2.1.2 made the PHP notices go away, and I’ll try updating again in a month to see if it’s fixed.

@noshiro In my case, someone changed the account password without telling me. It would be nice if the plugin could indicate this, but deleting the account from the plugin settings and then adding it back fixed the issue. Good luck!

Thank you, @kimball31! Your CSS works beautifully.

That fixed it for me, thank you!

I’m using port 587. I looked at the session transcript from the plugin’s test email feature, and I noticed that the domain name in the message ID (which is the WordPress URL) is different from the domain name of the sender email address. Could that be why Google is rejecting the message, in my case?

Mailer: postsmtp
HostName: karenwallaceglass.com
cURL Version: 7.66.0
OpenSSL Version: OpenSSL/1.1.1q-fips
OS: Linux giowm1073.siteground.biz 3.12.18-clouder0 #3 SMP PREEMPT Wed May 25 12:13:20 EEST 2022 x86_64
PHP: Linux 7.4.30 C
PHP Dependencies: iconv=Yes, spl_autoload=Yes, openssl=Yes, sockets=Yes, allow_url_fopen=Yes, mcrypt=No, zlib_encode=Yes
WordPress: 6.0.1 en_US UTF-8
WordPress Theme: Kadence Child (Artist’ Gallery of Ellicott City)
WordPress Plugins: Advanced Custom Fields: Component Field, Advanced Custom Fields PRO, Artists Gallery of Ellicott City, Block Visibility, Calculated fields for ACF, Custom Post Type UI, Enhanced Media Library, Folders, Formidable Forms, Google Apps Login, LoginWP (Formerly Peter’s Login Redirect), Post SMTP, SiteGround Optimizer, SiteGround Security, User Role Editor
WordPress wp_mail Owner: /home/customer/www/karenwallaceglass.com/public_html/agec/wp-content/plugins/post-smtp/Postman/PostmanWpMailBinder.php
WordPress wp_mail Filter(s): wp_staticize_emoji_for_email, PostsmtpMailer->get_mail_args
WordPress phpmailer_init Action(s): PostsmtpMailer->phpmailer_smtp_init
Postman: 2.1.4
Postman Sender Domain (Envelope|Message): artistsgalleryec.com | artistsgalleryec.com
Postman Prevent Message Sender Override (Email|Name): Yes | Yes
Postman Active Transport: SMTP (smtp:tls:plain://chimail.westhost.com:587)
Postman Active Transport Status (Ready|Connected): Yes | Yes
Postman Deliveries (Success|Fail): 127 | 24

The version is 2.1.4.

Thanks for the quick reply! Just to close the loop, it’s working as expected in Safari today. Yesterday was when I installed the plugin and it was behaving oddly. Maybe a cache expired? At any rate, all good now.

I found the problem and a solution.

In inc/product-thumbnail.php on line 35, the code reads passes ‘shop_thumbnail’ as the image size to wp_get_attachment_image(). If you pass $thumbnail_size instead, it fixes the display issue.

With or without my code, the woocommerce_gallery_thumbnail is 100×100, so my theme must be setting it to 100×100, which would explain why the PHP snippet had no effect:

woocommerce_gallery_thumbnail: 100×100 pixels (cropped to fit)

I disabled the slider plugin and verified that the first thumbnail image correctly uses the 100×100 size when the plugin is disabled, but with the slider enabled, the first thumbnail becomes rectangular and doesn’t use the small thumbnail image.

I awoke to the same issue.

I had to rename the plugin folder to get the website accessible at all. After renaming the folder back to the original name, I no longer have a White Screen of Death, but warning messages were still displayed. One more round of renaming the folder, restoring its original name, and activating it fixed the warning display issue, although the WordPress plugins manager still warns me that ‘The plugin generated 258 characters of unexpected output during activation. If you notice “headers already sent” messages, problems with syndication feeds or other issues, try deactivating or removing this plugin.’

This is not the first time this plugin has broken this website with an update.

Me too. Using the Auberge theme on 5.3.2.

The update works great, thanks for the quick turnaround!

I experienced the same. I fixed the errors temporarily by changing line 39 in includes/Permissions.class.php in that plugin’s directory to simply:

$this->permission_level = 1;

Hopefully the plugin author can supply a fix so it doesn’t break again on the next update.

Thanks for the CSS tip to hide the unavailable times, @pothound! That’s a nice improvement to the usability of the plugin.

I puzzled out the problem — it’s not Grimp’s fault, but this might help others.

I have my own database connection library and was opening my own database connection rather than trying to use the WP database code. I have the database where I’m storing the data that I’m manipulating on the same server as the WordPress database. mysql_connect() sneakily reuses connections when the hostname and username/password are the same, so I was unknowingly hijacking the database connection being used by the WordPress framework. Throwing in “true” as the third parameter to mysql_connect() to force it to give me my own connection fixed everything.