Bug: doing_front_end wrong value

Resolved nsp-code
(@nsp-code)

9 years, 9 months ago
Hi,
Thanks for this great plugin. I came across due to a topic of a user https://wordpress.org/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://wordpress.org/plugins/qtranslate-x/

Viewing 4 replies - 1 through 4 (of 4 total)

Plugin Author John Clause
(@johnclause)

9 years, 9 months ago

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)

9 years, 9 months ago

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)

9 years, 9 months ago
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)

9 years, 9 months ago

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.