ramdamnest

Nevermind. After re-activating the plugin, normal behaviour was restored.

Thank you so much for your responsiveness.

Which version is this being added to, my WordPress install is not showing any new update for the plugin?

Warmest,
R

I’m seeing the same problem.
It actually appear as an error in the browser’s console on the homepage (which doesn’t have a QPP form) of my web site with no user logged in. I feel this information leakage like a security risk.

Hi.

I’ve traced the problem down to the premium theme I was using.
It uses a custom post type called “chunk” that’s meant to hold content snippets that can be re-used many times on pages using a shortcode to include them.

When including the [newsletters_subscribe list=”6″] shortcode in one one of these CPT, it results in paragraph tags added to the javascript code.
Using [raw] around the [newsletters_subscribe] shortcode didn’t work as [raw] wasn’t detected as a shortcode.

I moved the [newsletters_subscribe] shortcode on a Page and no paragraph tags were added to the javascript so the error didn’t happen (but [raw] is still not detected as shortcode on a Page).

Hi, thank you for your reply.

I have my web site deployed on a staging environment where wordpress version, newsletter version and theme version are the same but the problem does not occur.
The plugins installed and their version differs, so I think it’s probably another plugin doing it.

Regards
R

The way I got it working is by adding a rule allowing TinyMCE
followed by a rule denying all php files in the wp-includes directory.

The rule for allowing TinyMCE MUST contains directives connecting Nginx to PHP application server (php5-fpm in my case).
Basically i copied over the directives i had under the location ~ \.php$ block.

So for me the solution looked like this:

# Allowing TinyMCE only
location = /wp-includes/js/tinymce/wp-tinymce.php {
        allow all;
        fastcgi_pass unix:/var/run/php5-fpm.sock;
        fastcgi_index index.php;
        include fastcgi_params;
        fastcgi_read_timeout 300s;

}

# Blocking other PHP files in wp-includes
location ~* /wp-includes/.*.php$ {
        deny all;
}

Thank you!
I did raise a support ticket anyway as it’s more a bug than a feature from where I stand.

A related feature enhancement would be the ability to set different SMTP settings for sending the newsletter and for sending system emails and the ability to turn on/off email sending at the level of each notification (or maybe the latter is already there and I didn’t see it).

Also if the graphs could make the distinction between system emails sent and newsletters sent rather than clumping them together, that would be great.

Best regards,
R.

Hi,

Thank you for your reply.

I saw the bulk action for changing subscribers preferences.

It does the job but it’s not practical. For our use case it will be preferable to have the function on the newsletter edit screen which is were this decision is made on a case by case basis.

Thank you for adding it to the roadmap. Looking forward to see it implemented.

Best.

9 months later, I have the same problem.
Has anyone found a fix to this problem?