It seems like I found solution:
I was trying to retrieve data from POST request using $_POST, and it seems like it is unavailable in the .php files which use native WP functions. But when I try to use $_REQUEST – I can retrieve data from POST request.
I’m glad you were able to figure out a solution. As a possible explanation for your observations, it sounds like the requested data was coming by way of $_GET — this explains why $_POST does not work and $_REQUEST does.
FWIW, some consider $_REQUEST a slight security risk because cookie values can override $_GET values using the same key, allowing a bad actor to substitute arbitrary values via forged cookies. As long as you properly sanitize and validate all incoming data I don’t think the risk is very significant.
Thanks a lot for interest to my problem. But I decided try to use $_REQUEST instead of $_POST, because I found this
And one commentator said that he got the same problem (with $_POTST), when he updated his WP to 3.0 (instead 2.9.2).
Also, when I first write that plugin (using $_POST) – it properly worked on my local server, but when I install it on my site on external server – it stop the work, and I spent a lot time to understand what wents wrong.
Since I did not find any mention about not working $_POST for incoming request in WordPress documentation – it is a bug of WordPress?
If both $_POST and $_GET contain no data and $_REQUEST does then the only place where the data could possibly come from is $_COOKIE, which is likely stale data and will fail for a new user. This is yet another issue with $_REQUEST, it gives the illusion something is working when it is not.
It’s difficult for me to imagine WP would have a bug this fundamental this far into it’s release cycle. By now it’s been tested by thousands of people in thousands of ways. Is a bug possible? Yes. Is it probable? Extremely unlikely. Unless you can provide code or instructions for others to replicate your results we’re going to have to assume the fault lies on your end. Don’t take offense, we’ve all been in your position at one time or another.
From your descriptions so far, it sounds like you are requesting a custom .php page that contains WP core functions. Whether from a remote server or browser I don’t think matters at all. Directly requesting a custom .php page containing core functions is flawed already. Either the WP environment is never initialized or it is initialized incorrectly.
You mentioned the admin_post_$action hook. This is one way to properly initialize the environment, if used correctly. You don’t give details, but requesting a custom .php page will result in the action never firing. The request must go through admin-post.php for this method to work. Unless you have additional wp-admin security outside of WP, it would not matter if the user is logged in as admin or not logged in at all, the method remains valid.
It’s not uncommon to run into issues when moving from a localhost to a hosted server. The problem often is solved by accounting for different versions of PHP, mySQL, or by different server settings in php.ini or the applicable .conf files.
Since the using remote post requests can be useful for me in future, I will make the more comprehensive tests with that problem. But at nearest days it is impossible.
