I've never seen this before, and am not even really sure I can explain it properly, but I desperately need a solution.
My website uses header and footer files. When you access the files directly from the browser, they work fine. But when I access them through another file using the "include" function, the queries on the files do not work.
In my case, the header and footer files need to establish whether or not the viewer is logged in. And the files work just fine on their own. If I access the files directly through the browser (by address: website/html/header.php), the queries function and the results are correct.
If I go to my index.php page, which uses: include("$webpath/html/header.php"); the queries in the header.php file do not return the correct data.
I've just recently transferred the website to a new webhost. The files were working just fine on the previous webhost, so I'm assuming it's a setting or something in the webhost? Althought I don't see anything relating to that in my control panel, and the webhost swears that it should function properly.
Any ideas? I would greatly appreciate any input.
You could always do:
<?php
function loadContent($file){
if(!file_exists($file)){die($file.' not found.');}
ob_start();
require($file);
$return = ob_get_contents();
ob_end_clean();
return $return;
}
echo loadContent("$webpath/html/header.php");
?>
Related
I set up my htaccess file to redirect to a PHP script when users try to access /wp-content/uploads/2020/05/test.pdf. The PHP script is in my root directory. The redirect works just fine. In the script, I have the following code:
require_once('wp-load.php');
if (is_user_logged_in()) {
wp_redirect('https://mywesbite.com/page1/');
exit;
} else {
wp_redirect('https://mywesbite.com/page2/');
exit;
}
I tested this on a few different Wordpress websites and in two of them it works as expected. If the user is logged in they will go to page1. However, on the website that I need it to work for, it always takes them to page2. I've tried deactivating all the plugins and changing the theme to the same as the websites the code works with. Still doesn't work. This makes me think it has something to do with the server setup. It's on Managed WordPress through GoDaddy. Is it possible that there is some server configuration that is preventing it from working correctly like the other websites? That's the only difference that I can think of.
I found out the login cookie was not being recognized in the PHP script. I suspect that it has something to do with the server setup, but couldn't pinpoint the issue.
I did however find a workaround. Rather than having the script located in the root directory, you can create a template file within your child theme and have the script there. Then have the redirect point to a page you create with the template. Everything worked as expected once I made this change.
<?php
/**
* Template Name: Redirect Template
*
*/
if (is_user_logged_in()) {
wp_redirect('https://mywesbite.com/page1/');
exit;
} else {
wp_redirect('https://mywesbite.com/page2/');
exit;
}
?>
I have the following issue. I want to load the Wordpress environment into an external php file. All my work is currently on a localhost and my php code is as follows:
<?php
require("../../wp-blog-header.php");
$admin = do_shortcode("[su_user field='user_email']");
if ($admin === "admin#email.com") {
// Do stuff here
}
else {
echo "<h1>Forbidden.</h1>";
}
This works perfectly fine in my localhost, so I figured that when I upload the file to the server it must work too, given that the file is stored in the same directory as it is locally, hence ../../wp-blog-header.php. Sadly, this does not work. When I echo $admin; the following error appears:
User: user ID is incorrect
I tried using the native Wordpress functions without using the shortcode like this:
<?php global $user_email;
get_currentuserinfo();
echo $user_email;
?>
This does not work either. Is there a more efficient way to load the Wordpress environment into an external php file? Any suggestions on what is happening here? It does not necessarily have to be an e-mail, it could be the user id as well, which I tried and gives me 0.
I forgot to mention, the php file loads and echoes Forbidden together with the error. This makes me believe that the file require("../../wp-blog-header.php") is actually being loaded because when I change the directory I directly get an error that the file is now working/available.
The shortcode works as I have tested it inside a new Page returning the e-mail address of the logged-in user.
UPDATE
My root is:
/var/www/vhosts/test-website.com/httpdocs/
Which I tested with require("/var/www/vhosts/test-website.com/httpdocs/wp-blog-header.php") as well. Still same result. The weird thing is that if I add wp_head() below this line, the header gets loaded. I reformulate my question:
How can I get the current e-mail address of a logged-in user in an external php file?
If your file is same folder root with Wordpress instance. just use code bellow:
<?php
define( 'ROOT_PATH', dirname(__FILE__) );
require(ROOT_PATH . "/wp-blog-header.php");
//your stuff
So, I consolidated various php login files from here into one file.
to consolidate it to one file, I append the url, and do different things based off of what is appended.
This works locally but not on my remote server.
Anyway...
At the top of my 'consolidated' file I have
session_start();
This is the only time I have a session_start(). The rest of my post.php code looks like this:
if(isset($_GET['app1'])){
...do stuff
header("location:post.php?app2");
exit();
}
if(isset($_GET['app2'])){
...do other stuff
header("location:post.php?app3");
exit();
}
Locally, if I start at post.php?app1, it will go to post.php?app2 and work fine, but on the remote server it just gets stuck (no redirect). Does anyone know why?
maybe these happen because there was a code that provide an output before trying to redirect.
try add buffer function in your 'consolidated'file.
ob_start();
session_start();
I am experiencing some very strange behavior when including a php file.
I need to load a script that is not on the same domain as the page that will be calling it.
I have already created a system that works using cURL, but I just recently found out that many of the sites that will need to have access to this script, do not have cURL installed.
I did, however, notice that these sites have allow_url_fopen set to on. With this knowledge I got started creating a new system that would let me just include the script on the remote site.
Just testing this out, I coded the script test.php as follows:
<?php
echo("test");
?>
I include this script on the remote page using:
<?php
include("http://mydomain.com/script.php");
?>
and it works no problem and "test" is printed at the top of the page.
However, if I add a function to the script and try to call the function from the page, it crashes.
To make it worse, this site has php errors turned off and I have no way of turning it on.
To fully make sure that I didn't just mess up the code, I made my test.php look like this:
<?php
function myfunc()
{
return "abc";
}
?>
Then on the page including the file:
<?php
include("http://mydomain.com/script.php");
echo(myfunc());
?>
And it crashes.
Any ideas would be greatly appreciated.
This is not odd behavior, but since you load the file over the internet (note in this case the World Wide Web), the file is interpreted before it is sent to your include function.
Since the script is interpreted no functions will be visible, but only the output of the script.
Either load it over FTP or create an API for the functions.
My guess: The PHP of http://mydomain.com/script.php is interpreted by the web server of mydomain.com. All you're including is the result of that script. For a simple echo("test"), that's "test". Functions do not produce any output and are not made available to the including script. Confirm this by simply visiting http://mydomain.com/script.php in your browser and see what you get. You would need to stop mydomain.com from actually interpreting the PHP file and just returning it as pure text.
But: this sounds like a bad idea to begin with. Cross-domain includes are an anti-patterns. Not only does it open you up to security problems, it also makes every page load unnecessarily slow. If cross-domain inclusions is the answer, your question is wrong.
You are including the client side output from test.php rather than the server-side source code. Rename test.php to test.phpc to prevent executing the script. However this is dangerous out of security point of view.
As the title suggests, I am having problems trying to move an existing site over to a new host.
I have edited my .htaccess find to point the php.ini session.save_path value to a new folder stored in my non public root.
This is working fine, I can see the sessions appear in this folder, with the correct entries written to them.
But for some reason, my scripts cannot make use of these sessions, as in the variables associated to them hold no value, as in, they come out blank.
Now, these scripts are in use on my old host and do work perfectly. And comparing the actual session data, once the files have been downloaded off each host, they are both exactly the same.
This leads me to think that this could be a server side issue. Possibly another php.ini value.
Has this happened to anyone before, or can anyone suggest a reason behind this kind of behavior.
It anyone has absolutely any input regrading this, or could point me in the right direction as to solve this issue. It would be more than greatly appreciated.
Thank you!
#Marc
sess.php
<?php
session_start();
$_SESSION['test'] = 'test';
include 'sess2.php';
?>
sess2.php
<?php
echo ''.$test.'';
var_dump($test);
?>
session data file value
test|s:4:"test";
Now when I load sess.php it includes sess2.php but the page only displays the vardump which is NULL. This is odd because the data has been written to the session as shown in the downloaded data file value...
Any ideas?
Looks like you're depending on register_globals. That's a hideously BAD thing in PHP which defaults to off these days. Try echo $_SESSION['test'] instead now. As well, such variables are only registered at script startup time/session_start. You'd need to use session_register() (DON'T) to make it take effect during the current execution run