Bug: doing_front_end wrong value

  • Resolved nsp-code

    (@nsp-code)


    8 years, 9 months ago

    Hi,
    Thanks for this great plugin. I came across due to a topic of a user https://www.ads-software.com/support/topic/qtranslate-x-an-wp-hide?replies=2 mentioning when WP Hide & Security Enhancer is being active no menu is being show for qTranslate X
    I was able to replicate this issue, and the file which set the menu is being loaded actually when $url_info[‘doing_front_end’] is being set as FALSE. But when admin url is being set for another slug through our plugin e.g. new-admin, your code is not able to correctly identify if being on front / admin side.
    This is quite an easy fix, within qtranslate_core.php line 334 replace the following code

    $url_info['doing_front_end'] = true;

    with 

    if(defined('WP_ADMIN') )
                $url_info['doing_front_end'] = false;
                else
                $url_info['doing_front_end'] = true;

    This will actually check if being on admin or not, instead just set the variable to an arbitrary True.

    Thanks

    https://www.ads-software.com/plugins/qtranslate-x/

Viewing 4 replies - 1 through 4 (of 4 total)
  • Plugin Author John Clause

    (@johnclause)

    Thanks a lot for your research, @nsp-code, I wish everybody would do that much work ::+1!

    I think, your code will break some of AJAX calls, which have WP_ADMIN defined, but need to go as front-end. Complexity of this logic forced us to introduce ‘doing_front_end’, otherwise you would be correct and we would not even need ‘doing_front_end’ variable. I am not still quite sure on the best way of doing all this logic, we may redesign it one more time in the future taking into account all the cases we have seen during the past year. For now, it works apparently more or less stable for the majority of our 100K+ users, but it might be possible to improve even more.

    We must use some other solution for WP-Hide. I did not try it, I read on description:

    Change the default WordPress login urls from wp-admin and wp-login.php to something totally arbitrary

    When you replace wp-admin with something “totally arbitrary”, could you try to preserve prefix ‘wp-‘? It helped on other security plugins. Does it help to WP-Hide? I think it should at least fix problem with wp-login.php, not sure if it will work on wp-admin. If it does not, we can improve that place to check for ‘wp-‘ prefix too.

    Thread Starter nsp-code

    (@nsp-code)

    Hi,
    I believe it will be a good idea to threat all AJAX calls separately than being WP_ADMIN or front side. since every AJAX call is actually set the WP_ADMIN constant as being True, no matter where it came from, either admin or front url.

    Hope there will be an update for this area for a new version, meanwhile i’ll rely on qtranslate_parse_language_info filter to make the change.

    Thanks

    Thread Starter nsp-code

    (@nsp-code)

    I would use the following logic to identify exactly if it’s an admin / ajax / front side. This will be better than rely on actual url (e.g. if contain a wp- prefix) 

    if(is_admin() && defined('DOING_AJAX'))
    {
        //being an AJAX call
        if(is_user_logged_in())
            {
                //user is loged in
            }
            else
            {
                //anonymous ajax call
            }
    }
    else if (is_admin())
        {
            //being admin interface

        }
    else
        {
            //this is front side
        }

    Hope this helps.

    Plugin Author John Clause

    (@johnclause)

    We know how AJAX call works, I do not see your point. WP_AJAX is just one piece of the whole complex thing. There are also WP_CLI, WP_CRON, and God knows what else WP will add. We are trying to make it in a general way. You can always customize it for your case anyway you want for your site.

    Did prefix ‘wp-‘ work for “WP Hide“?

Viewing 4 replies - 1 through 4 (of 4 total)
  • The topic ‘Bug: doing_front_end wrong value’ is closed to new replies.