PHP: Passing data on the same server without conflict

Hi Experts,

My site is currently split into two parts - a wordpress front end and a custom built trading area.

I am currently passing whether a user is logged in from the trading area to wordpress in the form of a php generated xml file.

and I have the following in my wordpress header.php file:

if ($xml->status === "false") { 
echo Menu A
else {
echo Menu B

Open in new window

It works ok but seems from my limited knowledge like using a http request on the same server isnt the best way to go about it.

I also now want to display my wordpress menu in the trading system but do not want to include wp-load.php for fear of conflicting functions.

I am thinking of add the menu to the xml file I've already created.

I'm hoping I've explained myself well enough and that someone can either confirm that the way im doing it is ok or whether there is a better way of passing information from one part of my website to the other?

Thanks in advance
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Julian HansenCommented:
Any reason you can't use a SESSSION variable.
// You have to have this at the start of your script before any output is sent to the browser

// Set your session variable to some value you can check later
$_SESSION['user'] = 'loggedon';

// Check session variable exists and it has a specific value and act accordingly
if (isset($_SESSION['user']) && $_SESSION['user'] == 'loggedon') {
    echo "Menu A";
else {
    echo "Menu B";

Open in new window

maccaj51Author Commented:
Hi Julian,

We seem to be getting a conflict with our trading sessions and wordpress ones.

Also we want to be able to "send" the menu items of the wordpress menu as well.
That's understandable about sessions conflicting. However, you can still use cookies as long as both sites are on the same domain:

As long as you use a name for your cookie that isn't in use by either site, you should be fine. You can use Firebug (Firefox) or Chrome developer tools to watch your cookie values for easier development.
CompTIA Network+

Prepare for the CompTIA Network+ exam by learning how to troubleshoot, configure, and manage both wired and wireless networks.

Beverley PortlockCommented:
Another possibilty is to send what you want via https if your server has the relevant certificates. An alternative that I sometimes use is to encrypt the data with something like blowfish and send it as an encrypted string, that way I can send any data I please in a secure fashion. Your server would need to have mcrypt installed
Julian HansenCommented:
We seem to be getting a conflict with our trading sessions and wordpress ones.
What sort of conflict - the only conflict you can have is on name - in which case use a different name for your session variables.
We run multiple sites on the same server that all use sessions we just have a prefix in a config file that we prepend on to all variables so they don't bump into each other

// Config file
define('SITE_PREFIX', 'mysite_');

// In our functions file
function getSession($id) {
    return isset($_SESSION[SITE_PREFIX . $id]) ? $_SESSION[SITE_PREFIX . $id] : '';
function setSession($id, $value) {
    $_SESSION[SITE_PREFIX . $id] = $value;

Open in new window

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
@maccaj51 and @Beverley,

Both of you had mentioned HTTP or HTTPS requests.

Just my two cents. Usually network requests going from one server to itself can be problematic due to IP routing and DNS, and HTTPS can exacerbate the problems with those specific reasons.

For example, let's say you have two PHP scripts:

If sender.php tries to post data to the URL "", it becomes a question of how your server's firewall and DNS are configured. I'd say you have about a 50/50 chance that it will work, because many DNS configurations can either turn into a local IP (particularly if you run a mail daemon on the same server), or the firewall won't understand how to route a request for an external IP that it is already hosting, so it hangs.

If the DNS turns it into a local IP (a loopback like, then the request will hit the web server at that address. If the web server is even listening on the loopback address, then it will require that the server is configured for that hostname on that IP. If the web server isn't configured to listen on that IP or doesn't have the hostname associated with that loopback address, then the request could go to the wrong folder.

With HTTPS, you face a bigger problem in that you typically have one IP address per host, so if you're hitting that loopback DNS issue, then you would need to have the loopback IP configured for HTTPS -specifically- for that hostname.

Overall, there are usually just a lot of hurdles with same-server HTTP/HTTPS requests. They aren't impossible, but they usually depend on specific configuration on both network and web server ends.

Aside from the network configuration, the HTTPS / HTTP requests to receiver.php will not change the visitor's session / cookies. Those requests will execute without the visitor's own cookie data, so it will be similar to a stranger simply posting data straight to without logging into or anything like that. So in maccaj's scenario of trying to access "isLoggedIn.php", it would always return false, because in that scenario, the SERVER is the visitor, and the server is not logged in.

It really is best to use sessions or cookies here.
Beverley PortlockCommented:

I usually avoid https. I mentioned it in case it was already in place.


Sessions can give conflicts if you have multiple instances of the same browser open and attempting to do different tasks on the same website. The browser instances all share the same session data and if both browser window #1 and browser window #2 depend on session data to determine their state then window #1 can affect window #2. I agree that it is then a case of designing the session data sensibly, but at that point it usually gets simpler to create a session key and place it in the URL and use it to access the session data which would then be held in an array keyed by the URL key.


Both of the above is why I sometimes find it simpler to encrypt a string, send it and decrypt it at the other end. Admittedly I often do this on different websites where I want RESTful type interfaces to control things and need a way to prevent malicious updates. It also has the advantage that it matters little whether the sender and receivers are on the same server or not so it gives flexibility as well. The minor inconvenience of keeping keys sorted out is worth the trouble (I usually use symmetric encryption rather than public key)
maccaj51Author Commented:
Thanks for all your help
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.