Aaron Brown

Same for me. XLSM will not upload, using WP Add Mime Types 2.1.0 and WordPress 4.7.1. Adding the following code to wp-config.php file makes it work, but creates a security hole–as you know.

define( ‘ALLOW_UNFILTERED_UPLOADS’, true );

I’m getting the same error.

Thanks for the solid plugin Stephen.

I’m also seeing this behavior. No customers are being added in Stripe. Neither new customers who create an account, nor current customers who try to save credit card details for later are being created in Stripe.

This also means the functions that go along with “Save credit card details for later” are not working (not able to select from saved credit cards, not able to manage cards, saved cards not showing on account page).

Hello all,

We were able to sort out that the issue was because our host had changed our server that did not have PHP’s mail() function enabled.

Calling to instantiate a new Mail() object causes a fatal error if mail() has not been enabled on the server.

So, no fault of the plugin, just our server set up.

I am also getting suddenly getting this error sitewide, causing the whole site to be down.

Parse error: syntax error, unexpected T_STRING in \wp-content\plugins\sendgrid-email-delivery-simplified\wpsendgrid.php on line 60

I receive this message for versions 1.3.2, 1.3, 1.2, 1.1 (line 57), and 1.0. Oddly, I have several other sites on the same server using 1.3.2 with no issues. Additionally, until yesterday, the site with an issue was using 1.3.2 with no problems.

I’m trying to figure out what changed yesterday to cause the problem on just this one setup. All my sites using SendGrid are on WP 3.9.2. Perhaps even more oddly, I tried to install the Big Mailer SendGrid plugin as a stop gap and it creates the same error, at the same piece of code as yours:

$mail = new SendGrid\Mail();

This leads me to think it’s not an issue with either plugin, but with something else.

You are correct. Sorry about that! I’ll mark this as resolved.

Hi @raj

Yes, I tried the php mail() function both with and without headers. Both tests returned true. The test without headers was received. The test with headers was never received.

I don’t want to make changes to the class.phpmailer.php file because I’d have to make them each time WordPress has an update. And, in general I need a solution that can be done without editing the WordPress core.

Other possibilities?

Thank You

I’m having the same issue on a customer site hosted at GoDaddy with Linux hosting. Their support has been unable to resolve the issue.

I created a simple test file that used PHP’s standard mail() function and it was sent successfully and received. However, adding any headers into the test cause the send to be successful, but the email was never received.

The headers I set for the test were a from name and from address that was an active email account with the same domain name.

I tried the WP-Mail-SMTP plugin with several variations of from name, from address, and return path, all using PHP mail() to send the emails. None of these worked.

Any other suggestions?

Thanks for finding that Greg. We’ll take a look.

Hello @boobymonster. To apply a font to a specific div tag, the div tag must have an id or a class, or a way to specify it through other CSS selectors.

First select the font in the Google Fonts settings page. Then, in the Custom CSS text area, write in the appropriate CSS.

For example, if you want to apply the font “Acme” to a div tag with an id of “#container”, you would enter the following in the Custom CSS box:

#container{
   font-family: acme;
}

Thanks @itsmeka. These notices have been corrected as of v3.1.1

Thanks for seeing that JPecsenyicki. We’ll correct that in an upcoming update.

Great, thanks @mlmjr. That means it is a stylesheet issue. To confirm further, you could click on the ‘<div class=”variant-Roboto variant-items”>’ element in your developer tools, and then uncheck the display:none rule in its matched CSS rules. You should then see the options boxes.

We will be providing an update (v3.1.1) today that will add a version number to the stylesheet that may help correct this issue.

@mlmjr and @pjv, if either of you have developer tools for Chrome or Firefox, can you please inspect the “Choose the font styles you want” element and tell me what content is in the <div class=”webfonts-variants”> element?

If it is indeed a stylesheet issue, you should see something like this (although the font name will be different):

<h3>1. Choose the font styles you want:*</h3>
<div class="variant-Adamina variant-items">...</div>

If it is not a stylesheet issue, you will see only the <h3> element and nothing else. Please let me know what you find.

A stylesheet item changed in this release that makes the areas you’re talking about visible instead of invisible. I’m wondering if perhaps your browser is showing you the old stylesheet (a cached version).

Can you please try to do a “hard refresh” two or three times and let me know if that solves it. On a Windows computer, you do a hard refresh by holding down the shift key while clicking your browser’s refresh button. On an Apple computer it’s Command+Shift+R.