Page 1 of 2

Externals plugins Incompatibility

Posted: Fri Dec 09, 2016 7:38 pm
by ricardovicente
Hello, first of all, congratulations to excellent integration that you made, it's the best by far.

I have some issues and conflicts when I activated your plugin and try to use frontend login. I'm using the popular user management plugin called UserPro (i know, you doesn't provide support for non free plugins, but don't get mad with me, I'll explain :D ) and when I try to login via frontend, nothing happens and then, the user returns to same page without being logged. However, wp-admin login is working, but when I'll try to logout in the same frontend, the page keeps user logged (not respecting the logout). Basically, the login / logout do nothing in the frontend.

I've spend about 2 days reading all old supports about login problems, external plugins, your documentation, etc.
The configs on WP and phpBB sides are ok. ;)

Then, I've found some explanations made about external plugins fix (like Ultimate Member). In addon folder of your plugin, it's have a comment line like this:

--> //// workaround for some plugin that substitute wp-login.php default login page
//// ... but that DO NOT reset $_POST array (like some frontend ajax login widget plugin do)

and in Wordpress support forum, that guy made a this topic and his problem is marked as solved:

https://wordpress.org/support/topic/cus ... n-problem/

(I know, I'm typing too much, but I promise, I'll finish soon :roll: )

Looking at ajax.php file of UserPro, I've found this similar idea of login, with some differences (I can show you later if you could do just a litte check).
You have mentioned in your comment line and in another topics about this $_POST array (which could not be restarted), but I haven't found any $_POST array (just $_POST). Probably this conflict occurs because the custom login code is not sending the necessary cookies to the phpBB, right?

I guess that I'm stucked, because I can't find the "x" of the question and where exactly the conflict happens.

After describing this scenario, I need to do some questions:

1 - That bypass that have you made in "ext_plugins_fixes.php" of your plugin, can be improved to works with more external plugins?
2 - Do you have any start idea or hint to enlighten me how I can set the custom login to send cookies properly?

and

3 - In the worst case, if I can not do this works correctly, then can you tell me how to disable or nullify your Single Sign On integration with phpBB? (Sending new registered users in WP to phpBB automatically soon after making a registration, without login integration, or simply sending the users manually just via WP w3all transfer).

Thank you for the patience. 8-)

[EDITED=Title Modified]

Externals plugins Incompatibility

Posted: Sat Dec 10, 2016 9:17 am
by axew3
Hello, np :) This will try to fix as explained, changing, i think (but i need to go into code and see to be sure) with some precedence execution modification on some filter and/or just adding one custom more.

The problem as explained in the post you mention is about $_POST vars that are send out by the custom plugin forms onlogin.
If login vars are same as on WordPress, and aren't reset, WP_w3all work well. It work well on any default WordPress code, or plugin coded maintaining native WP vars.

By the way many functions calls on WP_w3all plugin are on init event, and this lead that WP_w3all check commonly before any other plugin what is coming into WP about inputs, process them, and log you out.

The code you have see is the right one that grab $_POST vars (array) so these are after processed on code.
Put on top of ext_plugin_fixes.php or wp_w3all.php files, a line like this:

Code: Select all

print_r($_POST);exit;
try to login with your plugin form.
The code will stop and output $POST array with values if there are vars passed, revealing you what $_POST vars are available, so you can check what POST vars are used/passed to login by your external plugin.
So you'll add the two you want, user and password vars.
In this line you can see there are as example:

Code: Select all

 if( strstr($key,'username') OR strstr($key,'password') OR strstr($key,'log') OR strstr($key,'pwd') OR strstr($key,'user_login') OR strstr($key,'login_user_pass') ){
one i think was about ultimate member if i'm not wrong, but you can see the two used by default by WP for sure,
which are

Code: Select all

strstr($key,'log') OR strstr($key,'pwd')
This will work on custom plugin's login page. Add here yours external login vars to grab and pass.

While about frontend ajax widgets that reset $_post, the fixes can be done directly on these plugins code or better, by changing on WP_w3all the precedence of filters executions.

All this i will try to fix once for all before 1.6 and if possible already on coming soon next vers. 1.5.7.

In the while if you can get it working with this explain, after i will explain how to fix about profile fields if this require a fix also.

Re: Externals plugins Incompatibility

Posted: Sun Dec 11, 2016 2:09 am
by ricardovicente
The code you have see is the right one that grab $_POST vars (array) so these are after processed on code.
Put on top of ext_plugin_fixes.php or wp_w3all.php files, a line like this:

Code: Select all

print_r($_POST);exit;
Hi, thanks for response axew3, it seems to be a good idea to start tracking where's the conflict.

I don't know if I'm misreading something, but when I've tried to put this suggested line on top of ext_plugin_fixes.php or wp_w3all.php, and after that when I returned to frontend site or did logout in wp-admin, just appeared a blank page with the text:

Array ()
Image

And nothing happens. However, after your explanation, I tried to look for these vars and I've found something familiar:

Code: Select all

			if (empty($output['error']) && $username_or_email && $form['user_pass']) {
				
				$creds = array();
				$creds['user_login'] = $username_or_email;
				$creds['user_password'] = $form['user_pass'];
				$creds['remember'] = $rememberme;
				$wp_login_hook_arr = array();
				$wp_login_hook_arr = $wp_filter['wp_login'];
				remove_all_actions('wp_login');
				$user = wp_signon( $creds, false );
				foreach($wp_login_hook_arr as $key=>$value)
				{
					foreach($value as $wp_login_hook)
					{
						add_action('wp_login',$wp_login_hook['function'],$key,$wp_login_hook['accepted_args']);
					}
				} 
				
Assuming that maybe "username_or_email" is like "log" and "user_pass" is like "pwd", I've tried to add these lines with new "strstr($key,'username_or_email')" (did same thing with pwd), but still no success.

Maybe I really missing something I guess :geek:

PS.: If you want, I can send to you the file via PM to make a fast check.

Re: Externals plugins Incompatibility

Posted: Sun Dec 11, 2016 11:25 am
by axew3
Yes unfortunately, the output array() in this way, indicate that the login $_POST vars, have been reset previously.
Now since there is no way to know if the user come from a login (this is the point) , because $_POST is empty, how we can know if the user is onlogin action with these plugins, and let WP_w3all release the correct phpBB cookie, so we aren't logged out?
If look around this several times, not in deep but several times, without a valid solution that can be equal for all.

Any hint about really appreciated.

It is a frontend widget of this plugin where you try login with this result? Or is the custom page login of the plugin that report the empty array?

Re: Externals plugins Incompatibility

Posted: Sun Dec 11, 2016 7:22 pm
by ricardovicente
Yes unfortunately, the output array() in this way, indicate that the login $_POST vars, have been reset previously.
Now since there is no way to know if the user come from a login (this is the point) , because $_POST is empty, how we can know if the user is onlogin action with these plugins, and let WP_w3all release the correct phpBB cookie, so we aren't logged out?
If look around this several times, not in deep but several times, without a valid solution that can be equal for all.

Any hint about really appreciated.
If you can, send me a PM with your email and I'll attach the file for you just check. I've thinking about these external plugin conflicts, and it's common found people in your support or forums asking about that problem or mine is more specific?

I'm really interested not just help myself, but help you to bypass these conflicts (of course, inside of my knowledge limitations) and maybe help another users if are facing the same problem, because your plugin have fully potential.
It is a frontend widget of this plugin where you try login with this result? Or is the custom page login of the plugin that report the empty array?
It's a mixed bag. I'll explain.

It's not (exactly) a widget, but I have two ways to make a login in my website. First, I have a persistent topbar in all pages, with a modal popup link. This modal popup starts when I use the following code:

Code: Select all

<a href="#" class="popup-login">Text to Link Modal Popup Login</a>
This class "popup-login" fires the modal popup login, and loads a wp-includes/js/jquery.js (when you check in browser console).

Maybe this file is a default popup of Wordpress, However, I've found specific lines that plugin maybe rewrites with your own credential code, look:

Code: Select all

function(e) {

  var up_username = '';
  if (jQuery(this).data('up_username')) {
    up_username = jQuery(this).data('up_username');
  }
  if (/popup/.test(jQuery(this).attr("class")) == false) {
    var template = jQuery(this).parents('li').attr('class').split('-')[1].match(/\w*/);
  } else {
    var template = jQuery(this).attr('class').split('-')[1].match(/\w*/);
  }
  var id = jQuery('.userpro').length;
  shortcode = '[userpro id=' + id + ' template=' + template + '';
  jQuery.each(jQuery(this).data(), function(key, value) {
    shortcode = shortcode + ' ' + key + '=' + '"' + value + '"';
  });
  shortcode = shortcode + ']';
  if (jQuery('body').find('.userpro-overlay').length == 0) {
    jQuery('body').append('<div class="userpro-overlay"/><div class="userpro-overlay-inner"/>');
  }
  userpro_shortcode_template('insert', jQuery('.userpro-overlay-inner'), shortcode, up_username);

  if (template == 'request_verify') {
    jQuery('.popup-request_verify').remove();
  }

}


And the second way to login is via login page (it's a bit different than first method), but at this time it loads his own js scripts with indeed similar lines (except popup things).

About the Blank page with empty Array (), the weirdest thing is that happens even with guest users without account too. No matter if users are logged in or out. If I just put the code on the top of your files, this empty Array starts. So, I just can't even test it well.

So, I'll check more deeply the functionality of these logins and I'll do a report if I found something, sorry if I can't tell you more about (I don't find anything suspicious about logins in another files, but I'll look another time).

Re: Externals plugins Incompatibility

Posted: Sun Dec 11, 2016 10:41 pm
by axew3
It is quite easy to fix for a plugin where it isn't possible grab $_POST to recognize that we are onlogin, so is impossible to determine if it is time to release or remove an authentication cookie. One way is that is possible with easy maybe declare a var in php like:

Code: Select all

$an_external_login = true;
or in js if more comfortable (but the logic change in this case) inside the external plugin to get compatible. This need to be placed exactly where the external plugin have completed the authentication successfully, not before.
So the authentication on wp_w3all.php file, can be fired adding code like this:

Code: Select all

    function wp_w3all_ext_login( $user_user_login, $user ) {
   global $an_external_login;
 
     if ( $an_external_login ):

        $phpBB_user_session_set = WP_w3all_phpbb::phpBB_user_session_set_res($user);
     
     endif;
   
   } 
             
add_action( 'wp_login', 'wp_w3all_ext_login', 10, 2 ); 
p.s this need to be added +- just after:
search for line

Code: Select all

add_action( 'wp_logout', array( 'WP_w3all_phpbb', 'wp_w3all_phpbb_logout' ) );
on wp_w3all.php file.

[EDITED]