Put just the code <?php phpinfo(); ?> in a file called phpinfo.php , upload it to your webserver, and then go to that file in your web browser. That will give you a read out of all the php settings on your server and you can see if safe mode is off, as they say.
Sounds like your host needs to be more helpful with figuring out permissions; try using an FTP client like Filezilla to check and set permissions.
Thanks. The host says that safe-mode is off, but your suggestion gives me
“Warning: phpinfo() has been disabled for security reasons in /home/xxxxxxx/public_html/phpinfo.php on line 1”
I changed the permissions first of all in FireFTP, then in Filezilla, (which keeps the changes, but the changes are not registered in WP), and then in the CP, which also keeps the changes, again to no avail.
I’ve just download Filezilla 3.8 as I am using 3.7.1 and someone on another forum suggested there may be bugs in the old one.
Some hosts disable php_info for security reasons. Talk to your host about the permission problems; at this point it’s their problem, not yours. FInd another web hosting service if they’re not helpful; good hosting is not hard to find.
Do you have shell access to this account? If so show a line for the filename that shows us permissions, or ask your tech support if they might log in as root and do it for you. Do you log in with admin privileges?
Sometimes I change the FTP client. WS_FTP is a good client that worked when FileZilla did not.
TooNa1, you’re barking up the wrong tree.
He’s used three different FTP clients. He can see full permissions in his FTP client and his hosting control panel; he doesn’t need to go to shell, if he even has one with his account. His host needs to be sure his account his properly owned by his account so he can write to it.
I do not disagree.
Shell access would verify permissions. An FTP client is not a good way to verify perms IMHO.
The login is also important. Depending on his type of plan, he may not be allowed to change perms unless he is root. The phpinfo issue he is having sounds like a shared plan issue – he may lack the privileges .
I assume this is a UNIX platform? Just curious.
Shell access would verify permissions. An FTP client is not a good way to verify perms IMHO.
and why is that?
I’m resisting the urge to school you publicly.
Depending on his type of plan, he may not be allowed to change perms unless he is root.
he doesnt need shell access to test whether or not he can change permissions.
—
a host that has disabled phpinfo is NOT going to give shell access to it’s users.
—
to the original poster, who is your host?
Shell access removes the gui. You are basically talking directly to the server. I am sure the FTP gui interface is correct most, if not all of the time, however I prefer the talking directly to the server to get my info. I have seen failures using FileZilla, some of these may have been local or caching issues, but to get directly to what I want to know I cut out the GUI middleman.
“he doesnt need shell access to test whether or not he can change permissions….”
Shell access in this case is recommended to disregard the gui output from the FTP client and just verify – using shell – that his perms are what his control panel says he set them to. Whenever there is a problem use shell instead of any gui interface. Using PuTTy I can FTP, edit text and config files, change perms, admin UNIX, create users, create subhosts, etc – all without any kind of gui and there are no caching issues and is just plain faster and more accurate.
Caching issues for me arise when I have multiple customer accounts open in my browser at once (I may have 10 to 20 windows open). If I get a call about an issue like the one mentioned, I will start with shell and work from there. If I want to see what my client sees I will use his/her gui interface. It us not uncommon for me to open a different browser or FTP client to VERIFY what my control panel shows me because of a caching issue I may have.
“a host that has disabled phpinfo is NOT going to give shell access to it’s users….”
I would tend to agree. This may be an account with one IP address and several subhosts configured on the “other side” as opposed to an acount with its own IP address.
