Quantcast
Channel: WordPress.org Forums » All Topics
Viewing all articles
Browse latest Browse all 59525

The problem of interactions with Query Monitor

$
0
0

Replies: 0

Hi,

Sorry, I had to interrupt my activities about WordPress during quite ten month.

The precedent thread is closed but the problem remains.
I think that I have found more clear explanations.

This concerns exclusively the case of the full page login display, not the widget inside a document (no status bar displayed because the user is not logged in yet, and full page display).

When query monitor is used, after login with ajax, the login page is displayed again but with the query Monitor report under the login form.
At this step :

  • The login form appears empty like new and ready to be filled
  • The user is in fact logged in and just see the login form empty because it has been reloaded, normally he should have been redirected to the url redirect_to, but because Query Monitor displays his results it is shown again without values neither information about the user status
  • There is normally no way to continue because there is no link to the redirect_to url into Query Monitor code (into html code an hidden input with the url as value.
  • So if you reload the page you reset the login and perform a logoff (empty login input fields). This generates the infinite loop
  • the lonely way to go out his to refill the form (each one even though you are logged in, when you have twenty or more admin backend pages to restore which is completely boring) or forgot your current job and restart each tab from the main page of the site

A particularity is that if you fill at this step (Report displayed) the form with wrong value you will display the login Error (with the report). So if you submit again the login form it will run normally and will reach the redirect_to. This happens because you have created the case of lwa form filled at same time of the Query Monitor have displayed his report.
Another particularity is that if the url refers to a front end document the document will be shown but for a visitor. This come from the fact that by default when you reload an url for front end it shows directly the document for visitor. But naturally if it is for admin it will re-display the login form.

This fact is particularly boring when you have leaved accidentally a browser because you cannot restore at all your admin tabs, while for front end you will have simply to login once and reload each tab to get back them for current user logged in again.

What I have done just today : add for test to query monitor five lines of script which allows to submit a link to the “redirect_to” url. The result is the following :

  • If you are logged in (using a front end url which allows to login), you reach your redirect_to url
  • If you are not logged in you remains naturally into the loop

The result of my analyse is this that there are several problems into query monitor and lwa to make them work together (it is the reason why it was so difficult to explain and understand with more various conditions which can make impossible to reproduce the problem) :

  1. Query monitor needs my patch. It solves the problem of the submission of the redirect_to url
  2. LWA needs, in my opinion, when the full page is re-loaded, to check if the user is already logged in and consequently set the whole context as if a return from submit “logged in” had been executed. Then the login form could be not activated and grayed and “you are logged in” displayed”. In such case as normal behavior two thing can happen :
    1. Query monitor is not running and already previously displayed then directly without this display the user is redirected_to
    2. Query monitor has not yet run and it displays his report, but when the link is activated the form is not submitted as it is currently done

In any case if lwa :

  1. checks the status
  2. inactivates his login form when logged in
  3. runs the “redirect_to” url

we can reach the solution.

I think that the solution of an action of lwa is better because more general.
Nevertheless it remains the case of the use of the form used to change the current user.

Note : I could develop an extension of my patch which solves the problem adding a JQ script with action on both :
When query monitor runs his report the patch check the user status and if “logged in” the LWA form is unactivated. So normally the link to the url should reach his target.
For now it seems that when the link is activated this launches the Ajax transaction for the current form which is empty and automatically create a disconnection.

When I began to write this I hope to be short… I failed, sorry.

Best regards

Trebly

  • This topic was modified 33 minutes ago by Trebly.
  • This topic was modified 31 minutes ago by Trebly.
  • This topic was modified 29 minutes ago by Trebly.

Viewing all articles
Browse latest Browse all 59525

Trending Articles