Trebly

Hi,

You can look at the message sent to “LWA” author

Best regards

Trebly

Hi,

Thanks.

Is it simple, I imagine that for the main treatment there are a few lines to add into the recursive process ?
May be I can implement it roughly (and test it), this because for now I am a little locked (wrong treatment) by the “w4pl” index with the old version and I cannot at all use the 2.0. without uam-visitor.

Best regards

Trebly

Hi,

Will you answer ?
Must I wait ?

Best regards

Trebly

Hi,

I explain.
Sorry for the length but you will see that the problem is not simple.

The basic problem description is :

• Fill form
• Submit
• Get the form back but without error
• Loop without anyway access to the requested url (i.e. <site>/admin for exemple)

I summarize the history inside note 1 (detailed messages sent and which remain without answer).

After quite a long time and several messages to “LWA”, “WP support” and more recently to you “QM”, by verifying each of my explanations (based on my first observations) I have finally discovered the core of the problem, everything I had said before was around, and thought finally about who was involved in several ways and why.

First of all, everybody is involved (at several levels, “LWA”, “WP basic behavior and login process” and you “QM”).

• You are involved several times with this subject “integration of the display of “QM” content when login process is involved :

• because when the login form is submitted as main page (request an admin access and not yet logged in), if the cookie option (QM) is not defined, when the form is submitted and treated by “LWA” with success, automatically the “QM” contents will be displayed because now the user is logged in : the paradox of the process is that the login page is displayed again while the user is logged in while the normal behavior should be to be redirected to the requested url. The is the loop bootstrap.
• Because when “LWA” is not used but the standard WP login page your “QM” display (which gives your data for the page into a grid at bottom) never occurs (after login success to page is redirected directly to the original url requested (input hidden redirect_to value – the requested original url)
• This problem seems recurrent : I cannot detail this by sometimes I think to had to load twice some pages to get the “QM” data (into admin top bar), but not sure.

In my opinion you have nothing to do into your code, but WP core and LWA must care to the fact that it is possible that some pages, as login is performed at same time, can be displayed a second time to include plugins data, which result from the previous action taken in account on server or not (loop in local js). This while something else has changed in others parts of the page and particularly a validation (for example you have saved a change of some data, but the form will be displayed again with the “validate button” still activated (as nothing had happened) while it should be disabled while nothing else has been changed since the validation (this is exactly what happens in our present case for the login form, but it is not the unique case).
You are involved as an actor to obtains some (little) changes into the main processes of pages validation handled by WP core or by plugins which lead “QM” or others plugins using Ajax to display data after an action.

• “LWA” is involved because when it gets a valid login and that the “QM” then displays his data it must offer the capability to the user to launch the requested url (look at note2 how I workaround). Probably with a timer because, if not, an automatic reload of an admin page should be displayed without user action if the user is previously correctly logged in (this verification of the logged in of the user is an elegant way to generates an automatic cascading log of waiting pages for log after a browser restore)
• WP core is involved to take in account and invite plugin developer to care to the fact that after a validation their current page can be displayed again even validated because another plugin came and has changed some content elements, they must introduce, for this case, a second level “validation” in such case with “validation OK” and button “Quit page” for example.

Philosophically this problem come from the fact that your plugin is an “observer” which modifies the behavior of the “object observed”.

I must at the end explain a little the practical consequences :

• When you log for first time you must use any of the workarounds (note2)
• When your browser reloads several admin page when you are not yet logged in, this is terrible because you get the form for each page, and you have to repeat the workaround for each one.

Sorry for the length of this text but the subject cannot be explained clearly in a shorter way (for my current knowledge)… I have not found any other way (note : I have propose to send a movie – link to download, a few mo).
More, first, I have : not connected the phenomenon with “QM”… and not understood the process problem.

Sorry this my “catch-thread”, in one way it reflects exactly the truth, there are often no way to get a reaction from the plugins authors when you give first, detailed explanations, in the second way it is the first time that I used such a way to raise a question. I have needed several hours and message writing to find a good way to have a good presentation of the subject which is not simple (see note 4).

My first message was two week ago without any answer. I got quite the same situation for questions sent to “WP support and “LWA”. You will find the link to my messages to each one in note3.

Best regards
Trebly
______________________________________________________________________
Note1:

First I met a problem in login process with full form, to connect as admin.
I summarize :

• Fill form
• Submit
• Get the form back but without error
• Loop without access to the requested url (i.e. <site>/admin for exemple)

Then I have submitted the problem by sending a message to “LWA” : answer : “not involved”, see WP support. This was near one month ago.
WP support as not answered (two years ago)… and give me advice to write to you (two weeks ago)

Testing again after first LWA messages, I discover a lot of various case with same basic problem : The form was returned without error and on access
___________________________________________________________________
note2 : I found two ways to workaround :

1. go into debug mode : copy the value of redirect input and use it as main url : if url was successful it will be normally executed
2. use of another bug : produce an error in login, the next login even successful will not display the “QM” data and behave as default WP login redirecting immediately to the requested url.

__________________________________________________________________

note3 : link to same subject on others forums
“LWA” : When disconnect the login loops while all tabs opened are not closed
“WP support” (two year ago no answer) : Login request repeated for each page after the restart after a navigator crash
“WP support” (1week 3day – no answer to my last reply) : Coherence problem between plugin lwa (login with ajax) and query-monitor

___________________________________________________________________
note4 : to John “lack of interest” : no reaction to my first alert at all even it was not so clear. I have send this to “QM” which have a fine and very well done plugin and the same for “LWA” (first to answer but probably bored… by the length of my messages)
Perfectly aware of plugins developers problems. I have myself 3 or 4 plugins and theme and patched near ten plugins (which is a main problem when main WP version is upgraded) in test and I had discussions with more that ten developers).

• This reply was modified 6 years, 10 months ago by Trebly.

Hi,

Please see my last discussion with WP support :
Coherence problem between plugin lwa (login with ajax) and query-monitor

Main be a new thread should be opened because the subject, as result of the analyze, has changed

Best regards

Trebly

Hi,

I have submitted the problem to each one :

• – WP support
• – query-monitor support
• – login with ajax support (I had several exchanges with Alex Schneider during the last month)

nevertheless I confirm that the problem comes from the structure of the login process which do not take in account the case when :
– the login form is displayed while the user is already logged in.

This occurs in three main cases :

• When several url of back-end are (tried to be) loaded while the user who must have admin rights is not yet logged in. Then several login pages are open… and as I have explained there no way to reopen the urls.
• A particular case is when “query monitor” reload the login form after the first submit (as any in the previous case when a first succesful login has been submitted)
• When a successful login as admin is performed from a widget form inside any document

For now I cannot tell who have to change something or not :

• If Login with ajax is not activated, the main login form leads to the fact that query-monitor results for login page are not (never) displayed problem

and that after a first login the refresh of the login form leads to new display the form and to login again before the access to (redirect_to). This while using the url of redirect_to is directly accepted. This is not normal : two defaults.

• Login with ajax uses quite the main structure of login process (just avoids to reload the whole page) but as the whole page is not displayed it got for the second display :

• – the login status (but without changing anything at the form)
• – the results of query monitor which are never displayed with standard form.

• query monitor just generates a display of result which appears when login with ajax is used and are not displayed with standard login form. This because query-monitor needs to be displayed twice for his first run. This is caused by the fact that query monitor needs that the user should be login in as admin before displaying result, this except when cookie option is used. So, when login successes data from query monitor appear temporarily but the redirect runs immediately with standard login

So everybody is involved into the solution which needs to allow all of this, which is not currently satisfied :

• When the current user is logged as admin (no import the way) to submit the form even empty will display the known “redirect_to” (url which is the value of the tag input id=”redirect_to” “hidden”)
• When the form is displayed and the user admin is not yet logged in after a successful login submission the data provided by “query-monitor” are displayed, but the user can load the redirect_to page
• When login with ajax is used after the first display followed by a successful login, if query-monitor is used his content is displayed either the redirect_to (as currently) is displayed. When the logged in is acquired the submit form will automatically redirect to redirect_to and not run again the form.

All of this comes from the fact that the basic case :
What happens when the login form is submitted when the user is already logged in ?

I have, I hope so, proved that the problem node is in this last question.

I know how to solve this problem but it should be lost time if the problem is not held from his kernel.

Best regards

Trebly

• This reply was modified 6 years, 11 months ago by Trebly.

Hi,

Sorry to come here again on the same subject, but recent test and analyze clarify the problem while another plugin is involved.

Then I am quite sure that there is an interaction between three functions and plugins :

• lwa
• query monitor (new *)
• loggin process of wp

I summarize :
When you have to login as admin : you can get the main login (which is managed by lwa)
If you have activated the plugin “query monitor” the following steps appear:

• fill the login form and submit
• if login is successful (or a cookie previously setup*1) “query monitor” will display again the form but this time with the result of his analyze of the login form page
• from this step no option is offered else than fill again the login form.
• if you log again you enter into a loop : each login displays again exactly the same form (checked by comparing the content).

If an error is produced in login process (bad user provided for example), the login form with the “query monitor” data remains displayed, but when you try to login with good credentials that you have provided is now successful and the url requested the first time is normally displayed. This is a workaround.

My conclusion is :
the first login is successful
the display with the “query monitor” results is produced else than the requested url (to display “query monitor results), but because when you try to login again (nothing else to do), you are already logged in, you loop else than displaying the first requested url. A button which tells “you are logged in : reach the requested url” is missing*2 while the login page is displayed by lwa.

I have submitted the problem to anybody I could not get any answer (else than yours) :
Support » Plugin: Query Monitor » Main login form loops

For now I don’t know where, when the login form page is displayed again with the contents coming for “query monitor” while the user is in fact logged in, the button could be added to submit the original url requested.

Thanks

Best regards

Trebly
_________________________________________________________________________
notes :
*1 : the cookie set optionally by “query monitor” while you are logged in as admin allows the display on the computer of the query monitor data even you are not logged in. The purpose is to get query monitor data for any user or visitor on the admin computer

*2 : the proof is that if, at this step, you type the url

<site>/admin

else than default

<site>/wp-login.php?loggedout=true

you will access the main admin page

*3 : I had not seen the query monitor datas because of the current height of viewport they where at bottom and not visible.

*4 : I have recorded a video which shows everything and can be downloaded (need an e-mail to give the downloading url)

• This reply was modified 6 years, 11 months ago by Trebly.
• This reply was modified 6 years, 11 months ago by Trebly.

Hi,

Not so immediate.
I cannot upgrade if I do not write a patch for my “uam-visitor”.
You have reviewed the whole structure then, if I understand the whole of what you have done, I have not gone into details of the recursive treatment.

I would have your advice about the way to tell into your functions (without missing something) :
if userID is 0 then the role to take is account is “uam-visitor”

A first glance says to me that there are, may be, three locations involved :

• in isObjectMember -> isRoleMember : ?
• in isRoleMember assign value ?
• in isObjectMember -> isUserMember add a check

May be, more simple.

Thanks for help.
Best regards,

Trebly