SB Welcome Email Editor

[James]

Hi there,

I just updated to BPS Pro 5.8

I never had this issue previously until after updating to 5.8

The plugin in question is ‘SB Welcome Email Editor’ seen here:  http: //wordpress.org/extend/plugins/welcome-email-editor/

I’m guessing you updated the emailing alert feature and now there’s a conflict (or more likely the plugin I’m using is terribly coded)

What do you suggest?

[AITpro Admin]

What is the actual issue/problem?  Please explain with full exact/specific details.  Are there any errors in your BPS Security Log related to this plugin?

[James]

This happened directly after updating to 5.8,

There were no other errors, log entries, plugin updates.. literally just updating BPS

 

There is just a WP notice saying that there’s a conflict.

There are no Security Logs or PHP Errors in the Log.

Like this: http://d.pr/i/Honz/4EnYec6s

[AITpro Admin]

BPS Pro uses that standard WordPress wp_mail function and has been using this WordPress function in previous versions of BPS Pro so I would be very surprised if this had anything at all to do with the issue/problem.

I will install and test the plugin to find out what the issue/problem is.

 

[AITpro Admin]

Oh I see what the issue is going to be “…Allows you to edit the WordPress Welcome/Forgot Password Emails…”.  This plugin is doing something with WordPress logins.  BPS Pro Login Security is hooking into and using the standard WordPress Login actions and filters and is doing this by the book.  Will have test results shortly.

[James]

I figured that what it was. (It’s usually 99% of the time because of non-sandboxed plugin *sigh*)

I just found it extra peculiar since it only happened after this update.

I would’ve assumed it would’ve been conflicting all the time if it were that. I just found it odd.

 

I usually keep all my email alerts off in BPS but the new Login Security turns their Email Alerts on by default so I assumed turning the Login Security email alerts off would’ve mended that notice. However it didn’t. :C

[James]

Oh, so it doesn’t have to do with email.

HMM, didn’t expect that!

[AITpro Admin]

The coding check below needs additional conditions added.  This condition check is too vague and needs an additional condition check. Code Line: 69 of sb_welcome_email_editor.php. This check checks 2 things: 1. if you are in the wp-admin dashboard and 2. if the referer is set wherever this plugin is checking for that.

if (is_admin() && !isset($_REQUEST['_wp_http_referer'])) {
...
...
...
sb_we_send_new_user_notification($user_id, true);

Source:  http://codex.wordpress.org/Function_Reference/wp_referer_field

Retrieves or displays the referer hidden form field.

The referer field value will be the value of the ‘REQUEST_URI’ element of the $_SERVER PHP superglobal variable, and the field name will be ‘_wp_http_referer’ , in case you wanted to check manually.

Usage

 

Possible solutions:   http://wordpress.stackexchange.com/questions/20271/get-parameters-interfere-with-my-plugin-settings

and here:  http://wordpress.stackexchange.com/questions/80112/how-to-remove-wp-http-referer-from-url-when-husing-wp-list-table

 

[James]

Wow, that’s pretty weird.

I’ll add your example code as a hotfix for now.

Thanks!

 

PS: You’re awesome!

[AITpro Admin]

change…

!isset($_REQUEST['_wp_http_referer'])) {

…to…

!empty($_REQUEST['_wp_http_referer'])) {

and test that the plugin works. isset and empty are very similar, but isset is not appropriate here and empty is.

[James]

This fixed it!

 

However, minor thing:

When ‘Backing up’ my files in AutoRestore, The same notification displayed when it offered me to “Refresh Status”.

Kind hard to explain :S

[AITpro Admin]

I believe I understand the condition this plugin author is trying to check for and additional conditions need to be added to this check.

isset could be used this way, but the whole problem is what is being checked is just too general/vague.

if (is_admin() && !isset($_SERVER['HTTP_REFERER'])) {

Yep, I am not surprised and you can expect to see more errors because well frankly this particular check needs an addtional checking condition added.  I generally understand what this plugin is doing and with that general knowledge what seems to be missing is a $pagenow check which would check for the existing page and then the counterpart of that check would be to check for the intended page.  ie if the current page is not the intended page then do X.  If the current page is the intended page then do Y else do Z.  At least that is what I think he intended to do, but just checking if the Referer is blank or empty is too general/vague.

http://stackoverflow.com/questions/5266945/wordpress-how-detect-if-current-page-is-the-login-page

[AITpro Admin]

This is the intended use for _wp_http_referer per Mark Jaquith

http://core.trac.wordpress.org/ticket/2858

The intention was for _wp_http_referer field to contain the URL of the current page (the referer, to the page the form submits to). _wp_original_http_referer is supposed to be used for cases where you do something like this:

Start at A
Go to B
Do foo at B
Do bar at B
return to A

i.e. you’re not going back one step, but back to a original step. So that’s the one that should be passed along, and _wp_http_referer should always be the previous page.

additional note:
False on failure. Referer URL on success. If page “refered” (form posted) to itself,
returns false (because $_SERVER[‘HTTP_REFERER’] == $_REQUEST[‘_wp_http_referer’])

[AITpro Admin]

Adding a check for the intended page or pages is the best solution and not checking the entire WordPress backend/wp-admin area.

if (is_admin() && !empty($_REQUEST['_wp_http_referer']) && in_array($GLOBALS['pagenow'], array('pageX', 'pageY', 'pageZ'))) {

I think it would be ok to use isset, but I believe the correct usage is probably still going to be empty instead of isset.

if (is_admin() && !isset($_REQUEST['_wp_http_referer']) && in_array($GLOBALS['pagenow'], array('pageX', 'pageY', 'pageZ'))) {

http://wordpress.stackexchange.com/questions/12863/check-if-were-on-the-wp-login-page

http://stackoverflow.com/questions/5266945/wordpress-how-detect-if-current-page-is-the-login-page

Or if there is some sort of issue with getting Globals in general (ie something is turned off in php.ini) then using the standard method to access a global should be used instead.  Less sophisticated, but guarantees that the global is accessible in all conditions.

“To access a global variable in your code, you first need to globalize the variable with”

global $variable;

http://codex.wordpress.org/Global_Variables

function my_admin_notice(){
global $pagenow;
if ( $pagenow == 'plugins.php' ) {
echo '<div class="updated">
<p>This notice only appears on the plugins page.</p>
</div>';
}
}
add_action('admin_notices', 'my_admin_notice');

http://wptheming.com/2011/08/admin-notices-in-wordpress/

[AITpro Admin]

And I now understand the reason that this error is being triggered and actually I need to add an additional check for the Login Security Dynamic Database Form along the same lines.  The Dynamic Database form that is generated on the Login Security page is intended to always be on to display database results on page access, but it only needs to be on when you actually access/visit the actual Login Security page.

[Author]

Posts