Pantheon environment: doing_front_end returning true on post.php and skipping JS

[loganyott]

Greetings!

I'm currently running WP 4.1.1 on a Pantheon environment. I have the LSB enabled and see them working correctly locally. However, when I deploy to the actual server environment, the LSB don't appear on /wp-admin/post.php and none of the admin JS scripts are included on the page.

I tried dropping in var_dump($q_config['url_info']['doing_front_end']); here. It returns true on /wp-admin/post.php on my server environment, but false on my local. Confusingly, it returns false on both environments on other admin pages.

Just thought I would check if anyone has encountered a similar problem. Alternatively, if you have any ideas on what may be causing this, I would appreciate any of them to expedite this debug. Thanks!

[loganyott]

So I think I found the issue. This only happens when I visit the page and click "Edit Page" from the admin bar.

The script first checks if WP_ADMIN is defined, but doesn't set doing_front_end to false if it is.

It next checks the referrer. Since I came straight to the post.php page from the frontend, the referrer link doesn't contain wp-admin for the check.

At this point it calls qtranxf_parseURL($http_referrer) and assigns the return to $ref_info. On the final check, it assigns the value of $ref_info['doing_front_end'] to $url_info['doing_front_end'], which is somehow true. Once this is set to true, it appears the plugin skips loading the admin scripts that enable the LSB.

[loganyott]

To clarify, I suppose the question here is in what situation would WP_ADMIN AND doing_front_end be true such that we can't assign doing_front_end = false in the first check?

[johnclause]

Hi Logan, when wp-admin/admin-ajax.php is called, WP_ADMIN and DOING_AJAX are always both defined, but the call is frequently meant for front-end. This problem gave birth to 'doing_front_end' thing. I am still not sure why WP does not have some native global flag to specify whether front-end of back-end is being done. Apparently in a single language environment it is not important, but in qtx, this is one of the most important parameters, since a completely different code is running in each case. The referral url is the only way I was able to come up with to distinct front-end in ajax calls. If you find a better way, please let me know.

Which version do you mean? I could not reproduce your case in the latest version from GitHub. The problem you described must have been fixed or something else is going on. Could you check?

[loganyott]

Hi John,

Thanks for the detailed explanation. I am running version 3.9.2. The most puzzling aspect is that I can't reproduce this in a local environment. It only occurs on my staging/live environments. Since this isn't a deal-breaker for the client, I'll probably hold off on trying to debug this further at the moment.

I'll definitely look into admin-ajax in the future. In the past, I think I have looked at pagenow to determine whether I was truly on an admin page or just responding to ajax. I imagine this could run into problems if people start adding their own custom admin pages though.

[johnclause]

Did you try the latest version, under which I could not reproduce your problem? You may download it with button "Download ZIP", which you may also click here for the sake of convenience.

I believe this will be ok, and I am closing the issue to save further clicks. We can still write into closed issue and we may re-open it if needed.

[loganyott]

If I pull master from the repo, I still experience the issue on the Pantheon environments even though local works fine.

[johnclause]

I hope this is not a show stopper for 3.3 release, is it? Could you troubleshoot it on Pantheon environments and tell me what needs to be changed?