Forum Replies Created

Viewing 15 replies - 31 through 45 (of 172 total)
  • A little complementary comment :

    After loading first the login page while you are not logged in as admin the Query Monitor results will not naturally be displayed.

    To display the Query Monitor report you need to fill your credentials as admin and submit.

    But after the display of the Query Monitor report you can check the user : even it has been temporarily connected (display of Query Monitor report) it has been disconnected after the load…

    What happens ?

    Best regards

    Trebly

    A little complementary comment :

    After loading first the login page while you are not logged in as admin the Query Monitor results will not naturally be displayed.

    To display the Query Monitor report you need to fill your credentials as admin and submit.

    But after the display of the Query Monitor report you can check the user : even it has been temporarily connected (display of Query Monitor report) it has been disconnected after the load…

    What happens ?

    Best regards

    Trebly

    Hi,

    The problem is quite at his end, is it clear for me with a solution that I have developed.

    I could not get help because the explanation has finally come with a solution of the problem (four days of work), the observed phenomenon was very complex to explain by text, because of the multiplicity and variability of the circumstances.

    Since the beginning each time I tried to be shorter in my explanations… but nobody seems to have understood the problem that I explain again here the most quickly as possible.

    Note that LWA is not directly implied nor Query Manager but their interaction during the login.php process. The case is in my opinion important for the login process. This happens when the to plugins are both present and interact with login.php.
    The best for checking is to have a video, I produced several but it was remaining rather complicated and long to get a good walk into the implied tabs concerned by the process demonstration and to describe each issue. But now with one day more, I got :

    • A clear explantion
    • A piece of code which is a good workaround

    Note that this concerns exclusively the case of the login displayed on the full page display after a failed attempt to load an admin url after an automatic reload by a browser while the user is not yet logged in as admin, ( not with the LWA widget inside a document and obviously no status bar displayed because at the beginning the user is not yet logged in).

    So the context to produce the problem
    is after restore of several tabs after a crash or from bookmarks :

    • several wp_Admin pages to reload is :
    • not logged in as admin before the restoration of an admin page
    • you are running currently LWA for login and a plugin like Query Monitor for which the login page is automatically reloaded to show some results

    Note that In this case WP displays automatically the login form with, into the query, the “redirect_to” url that we should reach when logged in as admin. This is what we cannot perform.

    I have checked, tested and finally, while explaining, developed a workaround for the problem which is that, from the first display, it is in the 4.8.5 WP version fully impossible to reload such url. The reasons for the fact that “reload the login page inits in fact an infinite loop” are multiple, the main are :

    1. resubmit from the current login form with your good credentials doesn’t connect you and displays again the same page, more it will disconnect you if you have got before the connection by another mean
      • when you reload without using the Query Monitor plugin, if you are logged in as admin by another way you will be redirected to the redirect_to url, but with the plugin you are not redirected and then enter into the loop

    Summarily, if you try, from this first point, to use the login form displayed, no matter the true login situation (connected as admin or not) you cannot reach the redirect_to url, and more you are simply disconnected.

    To avoid this you have no solution without complements of code.

    The complements of code that I have added (a supplementary js file of one hundred lines loaded by LWA plugin) :

    1. a warning message
      • An ajax check of user status
      • A link to submit a clean login (submit the url “<site>/login.php” without admin query)
      • A link to the “redirect_to” url
      • Then, with this tools, when you have logged in as admin (using the proposed link or by an other way), you can use the link to redirect_to.
        If you have several login page for admin access you will connect once and after just use the activable link.

        I have developed this extension into LWA for two reasons. Because if LWA is not used the phenomenon doesn’t happens, secondarily for not to have to produce a plugin, necessarily heavier, so I directly I uses the development context of LWA. The inconvenient is to have to perform a patch (add an inqueue of the script) into “login_with_ajax.php”. It displays into the common login page when we are into the concerned case :

    1. At the top of page a warning message : after analyse of the context
      • A div which contains the button and the two links

    I have two video of demonstration :

    • Showing the loop process
    • Showing the solution implemented

    Best regards

    Trebly

    Hi,

    Sorry, It seems that all that I have written last night is without object for lwa, even the reported phenomenons are true and pertinent.
    I checked again the problem this morning and found that even though lwa is loaded it doesn’t interacts here.
    This because the submitted login by the url is login.php it is the main WP login which is concerned.

    My add-on to Query monitor script (only to not add another script) adds a link “Back to initial request”. This link has href=”redirect_to” url.
    Then if user is connected the link lead to the right url, if not, because it is a link to wp-admin, it leads necessarily to a new identical login page.

    Because of this I am adding just now a check of the login status when the tab is displayed, the user can then use efficiently the “link back to redirect” if it is logged in.

    But this doesn’t solves the main problem : when a tab is restored by the browser the user is not yet logged in so the page doesn’t tell that the user can use the link. I have to add a capture of the event to check to user status, then :

    • if the user is logged in and as admin the link is launched and the redirect_to page restaured
    • if the user is not an admin logged in the script will propose to log : this will launch into a new tab “<site domain>/wp-login.php” (because to submit again with valid ids the current login page fails, this doesn’t come from lwa but from login.php)

    After the successful login which issue which result is a connection to WP admin main board page, when the user will try the link on the failing page it will be successfully redirected.

    I have not yet tested but I think that this can occur even though Query Monitor is not used, I was so sure that it was linked with the display of QM. The failing login with valid ids then displays the same login page but with an empty bottom… and this even though the user has issued a successful login with another page. This come from the fact that login.php when is re-submitted seems not to check if the user is yet or not logged in. Because I will not changes this into the core, my script grafts the right test.

    This seems to be lonely way to avoid the failing login loop (WP 4.8.5 I am preparing to upgrade to 4.9 ).

    Best regards

    Trebly

    note: I have movies (movies capturing the screen ) of all of this. If you are interested I can send you an url (shorted) to download them from cloud.

    Hi,

    To understand something in what happens the context must necked.

    I have tested the login process (main login page) with and without LWA and no other plugin.
    It seems that there is a problem with LWA with the main “loginform” after disconnection (no widget nor login panel for reconnect problem) because when used the log in successes but the page is not redirected.
    Because of the LWA load the basic submit of WP doesn’t function any more.
    This is the first point to solve.

    For QM the first separate problem, in my opinion, is the following :

    1. what should happen, and what happens, when you submit the main login form to re-log (login) the admin after disconnection, does the QM panel (that you can see on my video) is displayed or not ?
      • If it is displayed how you can reach the reconnect_to (to find in debug mode the “input hidden”

    Are you able to :

    1. Disconnect from admin homepage (this displays the main login page with message “you are now disconnected”)
      • Reconnect and display QM report for this login page
      • Access the main admin home page

    QM is not a debugging plugin. During production it is transparent, it has effect only for admin or if admin has activated a cookie on the computer. This allows to get a report of loading process. This gives information for debug surely but mostly execution time which is tuning steps of generation of pages.
    It is then used without changes on the site to understand why there can be long time to load some pages.

    I have said “incompatibility between the plugins” it is wrong, but there are problems with each of them with the login page, not in any other case.

    Best regards

    Trebly

    Hi,

    I have checked again this in debug mode.

    The problem is that in the defined conditions you script executes nothing.

    It is loaded and all JQ query are listed and initiated but after there no one instruction executed (no event kept).

    For the page displayed by WP with the form name=’loginform’ it seems that no actions are defined for LWA.
    Particularly

    			if( data.widget != null ){
    				// ...
    			}else{
    				if(data.redirect == null){
    					window.location.reload();
    				}else{
    					window.location = data.redirect;
    				}
    			}

    Is never executed.

    But the presence of LWA script seems to disallow the standard issue of the submit.

    Because I have just spend a few minutes on your script I cannot explain the problem but it is probably somewhere near this.

    Best regards

    Trebly

    Hi,

    I have performed some test in conditions of inactivation of all others plugins.

    In these conditions I have found in an elementary test a error of behavior of LWA :
    This test 1 is :
    – during admin session : disconnect and try to reconnect immediately after
    Case 1 : LWA not activated (no plugins activated)

    1. Logout from an admin page : you get the url : https://<site>/wp-login.php?loggedout=true
      • You log in again (reconnect) with the same user

    You reach the previous admin page (referred into html sources as input id=”reconnect_to”)

    Case 2 : LWA activated
    (new test with only one plugin : LWA activated) :

    1. Logout from an admin page : you get the same url : https://<site>/wp-login.php?loggedout=true
      • When you try to reconnect you get the same login page but not the reconnect_to admin page
        You seem not to be able to log in again (reconnect) with the same user

    But if you make a complementary a test during these operations : to load the “welcome page” into another tab :

    1. just after logoff : you get the simple “visitor” welcome page
      • after the “try to login” (which seems have failed because you have not loaded the waited previous admin page) when you reload the welcome page you get the “admin line on top” : this is the proof that you have been logged in by LWA but that LWA has been unable to redirect to the defined redirect_to.
        (note : This was observed with QM but it is an independent behavior.

    The presence or not of others plugins doesn’t changes anything.

    When this problem will be solved, we will be able to test with QM.

    Best regards

    Trebly

    ________________________________________________________
    note : after disconnection, if you try to reload an admin page you get a login panel (displayed by LWA) the login is successful and the page which has not been leaved is reloaded. So the problem come from the treatment of the location to reconnect_to (quite sure) when connection is successful with the main form in main login default page

    Hi,

    I will answer later to the question of a pull request, here I just answer to your first question by two examples.

    • I had some articles which became obsolete (to be replaced) but I was not wanting to loose their content and stay able to read them (and edit to copy selected parts), then I have decided to move them (drag and drop) from a menu “visitor accessible” to a submenu which is into a menu header “admin” (restricted to administrators).
      This had the effect to get a main menu of many lines with these articles as main headers of menu. Such operation needs in fact that these articles inherit from the menu “menu” of the restricted access of this menu element.
      To avoid this I had to change for each article his NMR rights by copying the rights of “admin” menu element.
    • The second case is to add the exact reverse, after moving temporarily an article from visitor menu to admin-author menu, after changes replace at his first place. This need to change again the intrinsic rights

    My proposal is to avoid this problem making that an element will inherit dynamically of restrictions of the access of the parent into the menu. This avoids to generate accidentally orphan elements of menu. I think that the review of right is independent for the soft basic features considerations : production of orphan should be impossible in my opinion. Is this a new feature or should exist by default ?

    Best regards
    Trebly
    _____________________________________________________________________
    note 1 :

    This procedure allows to show versus to hide elements to visitor (or any other role) using one alone operation into the menu without changing the intrinsic rights
    ________________________________________________________________________________
    note 2 : Join the NMR and UAM advantages

    As a finality but not security features (protect against orphans), there is an other manner to perform this, it is to use UAM, changing the UAM-group (or several) of the article it will appear versus disappear from the view of visitor (particularly from menu but also from list and indirect access) and or to admin-author-reviewers.
    You understand that is not the same perspective of use nor the same operations. If you uses UAM to do the same you need to create a list of elements selected by their UAM group into a menu “admin and review” the list of articles which must be modified (for example because a major error has been found after a first publication).
    But when you uses this procedure, to check to menu view you must log out to be able, after reload, to see the true and verified menu content.
    This is a more elaborated and heavy process for which security is a problem (complex tools to check the content generated ; by basic operations it is easy to produce very bad errors with a simple checkbox typing error; one unique error should make that the article appear to admin into a “rights anomalies list” )

    • This reply was modified 2 years, 7 months ago by Trebly.

    Hi,

    WP : previously 4.6.2 idem now with 4.8

    LWA : last : 3.1.7

    QM : last : 2.13.4

    WP reCaptcha Integration : no effect on behavior tested but currently used 1.1.10

    No I have not until now tested when all others plugins inactivated, nor with another theme than mine (twentythirteen rewritten). I will do it. But I have nothing different into the theme from default for back-end.

    Some details which can create a behavior difference :

    • When QM and LWA are activated do you get after login submit (admin to admin page) the second display with the botton of page filled with the QM data ? This display (as in my video) is produced only when lwa is used :
      • if it is not (this is a not normal behavior for QM and WP), in this case of ignored QM request then the problem doesn’t occurs and we have to find why it is displayed in my configuration (normal behavior).
      • If the display of QM data occurs when LWA gets the logged in success it seems normal to not be able to go out and loop, this because there no action which can avoid to not repeat this step
    • So, If you get the QM data (at the bottom of the page) what do you do to access the requested page (the requested page has “<site>/admin” which displays the main form when you are not logged in.

    Notes :

    • The use of lwa in widget always functions (the qm data are displayed into the admin bar when the page is displayed the second time, necessarily with front end).
    • When you ask the display of a front end page you get it always (as visitor), then there is no link to back-end and to become admin user you use the widget. The case cannot occur.
    • You get also the main loggin form when you logout from a back-end page.

    Best regards

    Trebly

    • This reply was modified 2 years, 7 months ago by Trebly.
    • This reply was modified 2 years, 7 months ago by Trebly.
    • This reply was modified 2 years, 7 months ago by Trebly. Reason: more details

    Hi,

    Are you preparing an answer ?

    A little complement:
    About what happens when your browser have reconnected a folder (group of documents being currently in edition for modifications) you can look at how to reconnect several tabs when you use LWA and QM

    Thanks
    Best regards

    Trebly
    ____________________________________________________________________________
    note 1: this is the exact copy of what I have send today to LWA developer.
    note 2 : I am completely aware of the job of plugins developers I just try to do so that a true problem is followed, particularly when several persons are involved

    Hi,

    Do you agree with my comments ?

    Best regards

    Trebly

    Hi,

    Are you preparing an answer ?

    About what happens when your browser have reconnected a folder (group of documents being currently in edition for modifications) you can look at how to reconnect several tabs when you use LWA and QM

    Thanks
    Best regards

    Trebly

    Hi,

    We are perfectly in the same point of view.

    The problem is that an element can have his own basic rights, but when it is attached to a parent which have stronger limitation, dynamically it will currently appear into the menu as an isolated element at first level.
    For example an element “visible by everybody) and it is set into a menu branch accessible by everybody everything is right. The admin decides to replace it but want to keep the current version into is own private branch. If the admin moves the element into his branch (access limited to admin) the result is that the element will appear as a first level menu element when visitor accesses the site, this while the admin purpose was exactly the contrary. To reach the result the admin must change the “static” rights of the elements to “logged in -> admin”.

    I think this is important and can change some elements of the presentation of your product :

    • introduce the concept of “static” and “dynamic” rights (you began to tell about into your answer) : when an element is attached to a branch it inherits dynamically (for the current treatment) of the limitations of the parent, this all along the tree.
    • this allows to move element from one branch to another and keeps a coherent structure of the menu
    • this simplifies the creation of the rights of elements of menu because the rights then created for an element are only “static”. Then for example if an element is statically declared “limited access to logged in admin” it can never be seen by somebody else even attached (by error) to an accessible branch by visitor.
    • this makes much more easy the management of rights by the admin of menu.
    • Thanks

      Best regards

      Trebly
      _________________________________________________________________________
      Note : A problem for future : when menu element leads to an article which has not good rights (for example more complex with the use of UAM), the access will become unallowed but after nmr had allowed the access. For this I uses a default page which explain to the user and creates a report to admin (page defined to uam when access is refused to avoid a 404). A future extension of UAM could be that a function (substituted -hook, to core request to elements access) could be asked for rights before activation of the link (the element is visible into menu but link is launched only if this function answers OK). Then this UAM function could tell : “you have no access … because…” or proposes an action or forbids access simply. This feature would avoid to load the forbid page but only a content loaded by ajax into a messagebox from the UAM function (or core).

    Hi,

    Sorry, I have inactivated the Captcha integration and nothing is changed.

    Look at 2nd video into the folder pointed by this link (5mn)

    This video shows the same for the “pseudo loop” but without captcha and at the end with the workaround using an error to finally get a successful login for admin (board).

    note : I have not checked for other user login, I am quite sure that it functions because in this case QM report is not displayed. Nevertheless there is an option of QM which allows (very useful), after the installation by admin of a cookie, cookie which indicates at QM to produce is report even though the user is not admin (but on the computer prepared by admin). In this last case we will get (I am quite sure) the same problem.

    I am quite sure that the wrong process is :
    – when LWA submits the login form with ajax, just after the logged in is successful LWA tries to redirect to the requested url, but at same time QM sends his report, and because of the reception of the report which is displayed LWA cannot redirect and finally LWA refreshes the form empty quite ready to be filled again (while user is already logged in).
    – the next time the form is submitted with same credentials the answer is “already logged in” then nothing is done. This can be repeated ad vitam.
    – when an error of credential occurs the next submission is not performed in exactly the same conditions ( because log has failed previously), but QM has probably done his job or has been initiated before, then if this new logged in is successful the redirection will succeed after.

    Best regards

    Trebly

    note : I don’t tell here what should or could be.

    • This reply was modified 2 years, 8 months ago by Trebly.

    The same problem, the site is down and the html code created by site developer is modified by WP 4.8 into a widget text.

    I had to to use the backup of database to get back the good code (more than 10,000 lines of HTML into 20 widgets…).

    The basis principle of text widget was to inject html code tested elsewhere into WP display using directly the widget or the corresponding shortcode. This feature is broken and replaced by some grub with 4.8.

    This comes from a crazy idea by somebody who ignores the basic concepts of SGML->HTML.

    A basic principle : no chars CR, CRLF, TAB used commonly into editors are taken in account by html interpreter (html parser + graphic generation, this special chars are replaced by who writes the code by &xxxx; codes or tags as <br> new line, and to create paragraphs into text <p></p>).

    The previous version with the option “treat the “change-line” as paragraph”, the option “auto generate paragraphs” was an infringement to concepts but it was an option, then the code (syntax is generally tested by other ways) was always preserved when the option was not choosen.
    Generally if the basic html rule were used into the html code the result using this option was an invalid code able to crash any site, server and browser if the content was not a very simple text.

    Any editor developer had always two main problems :

    • Write using WYSIWYG and generate good html code (parsable without error)
    • Be able to show any HTML code into their WYSIWYG editor

    This problem was absent from previous version and problem have been added unconsciously.
    The problem is that it is not an addition of a new feature but an important change in basic features which simply suppresses the use of html into text widgets replaced by some grub.

    For interpreters, a first problem was that, sometimes, the code submitted to display was wrong, then they had to check the code before and reformat with some hypothesis or send warnings on display about errors found (as Phpstorm does).
    Another problem has been and still exist is that the WYSIWYG editor is not always able to display any nevertheless valid code (for example SVG draws).

    The idea to add a WYSIWYG editor to widget text is not basically foolish, it can be a useful option for some simple widget text (avoids to have a main HTML source code into an editor like PhpStorm (parser, syntax manager and test on browsers) from which the code is copied into the text widgets.

    But the idea to change the source code given by the developer (admin-webmaster) to fit hypothesis of the interpreter on the content defined by the site developer is pure delirious.

    So, it is not a bug it a main conception error.

    Best regards

    Trebly

Viewing 15 replies - 31 through 45 (of 172 total)