English
Deutsch
Español
Français
Forums/General knowledge/Tutorials, Guides & How-to Articles
Server Requirements
michael sablone
posted this on July 13, 2011 11:54 am
Requirements
Your hosting platform is the most important part of the installation process. Unfortunately, not all hosting companies are created equal. For the record, here are the server requirements:
- PHP 4.3 or Greater
- Safe Mode OFF
- GD Library 2.0 or Greater
- cURL Library
If you know your server does not support these items, you may want to consider switching hosts -- these are pretty basic requirements! We recommend Hostgator
Testing
You can download our server capabilities test file, and upload it to your server. It is basically the same set of tests we use in our installer, but you can try it yourself. it should spit out something similar to this:
See attached file:
Comments
Thanks for providing this tool. I just ran this before setting up my wife's new site, and I noticed an issue when checking for GD. On line 344, you use the expression version_compare($gd_version, '2.0.0', '>=') to check for a usable GD version, but on Debian Squeeze, the latest available GD version is "2.0". version_compare() seems to report "2.0.0" as a higher version than "2.0", causing the check to fail.
Cheers,
Jeremy
hmm, interesting! i'll get on this.
Hi, my server/host meets all these requirements and I ran your capabilities test file and all came back ok. But, once I bought and installed the Tarragon website and Flaunt, I just get a message saying that flash and java are not available. What's going wrong? How come it doesn't work even though my host matches or exceeds all of your requirements? And does this mean I've just wasted $200?
http://www.pauljbrooks.co.uk
Looking forward to your reply, thanks,
Paul
Everything passes except the "File Permissions". What do I need to have my host change to enable this to say "OK"?
@ryan -- it probably just means the document root of your server isn't writeable by PHP -- and that's a requirement. since we sell websites, and websites are usually in the document root, it's just a requirement we have for everyone. if you server is running php as apache, you will have to set your public_html folder to 777 --- even if it's just during installation and updates. if it's php as cgi, you should be ok leaving the document root set to 755.
Document root in 777 is it a joke?...
@vallet -- no joke. our websites are written in php, and if your server runs php as apache, php's user (nobody) needs permission to unzip the files and folders that make up the website. once the files and folders are in place, there is only one folder -- a storage folder -- that needs write permissions from php. after it's installed, you can return your permissions back to normal.
if your server runs php as cgi, these permission hassles are not a problem as php runs as the same user as you typically login with.
this is not out of the ordinary. wordpress has the very same issues. if you are running a LAMP stack that uses apache for php, if you want to run automatic updates, you need to allow php complete read/write access to any folders it will modify, and if your blog is running in the document root, that means you need to allow that access to the doc root as well.
some good reads about what 777 means and it's general safety:
http://green-beast.com/blog/?p=120
http://stackoverflow.com/questions/2338641/in-a-php-apache-linux-co...
we're not advocating you leave your document root set to 777 permanently, but setting it to 777 to install/update software is a very common practice. once it's installed, you should set it back to 755 or 750. please remember that we have to deal with installing software across thousands of different server configurations, so we're always dealing with the lowest common denominator. our recommendation is to run php under cgi, and you won't have to worry about permission issues at all.
as with everything, YMMV.
Thks for the explain but my wp is running without this permissions, if the FTP account that we give to you have the write access to the subdirectory you need why don't write the files with ftp account either than php? It would be i think more interoperable no? Have to sleep for the moment, but will be glad to discuss this with you.
NB: i was able to resolve the ticket i opened by chown www-data:ftpuserexample and 775 (the last 7 is really dangerous depending your account politics on the server, imagine a webmail server often users have ftp rights (attachments) if there is no chroot they could deface document root if the webmail is in the document root). Ok it is temporary but on public hosting where worms scans a lot of websites (with known ftp accounts failures/login) it could really be dangerous if sby modify access to try to install your software, open a support ticket etc (could be 72hrs?).
BTW in the installer you said you don't store ftp password but if we open a ticket the password is in clear at the right of the ticket (so stored in db)...
I may be a little too much paranoid (working in it security lol) but i never seen this kind of process before so i am a little curious and worry about the security of my server.
Best regards and wishes.
@vallet -- running wp and doing automatic updates are 2 different things. everything else you are speaking about you and i understand, but the majority of people do not. we try to make sure our stuff installs across the broadest range of hosting companies. the alternative, of course, is forcing you to host with us -- not very appealing.
as for leaving it 777 for any amount of time -- it's up to you. we're not forcing you to do anything. installation of our products too much of a security risk? fair enough. maybe down the road, we'll get it right for you.
passwords in the installer: we don't store passwords during the installation. we do, however, send passwords along in a ticket if you choose to request help via the installer. you do not need to auto-submit the help ticket. you are more than welcome to call us instead. the help screen is there for convenience.
if you work in security, you should know that nothing is secure.
Nothing is secure because humans are unsecure :) Just kidding.
I m not here to tell you how to work or something else, i am not a dev and not a web expert. I am just trying to say (sry may be bad english i m french) that it could work another way and it would be better. Ok it is temporary but if it is just for write file during installation why don't use ftp account that we type which have all the good write permissions? It is how automatic updates work in wp if you don't give the apache account the right to write, you type your ftp account. From my point of view (it may have considerations that would change my opinion) it would be more interoperable and don't need to ask your clients to modify the way is webserver run.
For the password, we aren't notify that password will be transmit with the ticket. The idea to have my primary webhosting ftp account stored and known by others persons disturb me... Just need little more transparency.
BTW when during the installation there is only the write permissions errors it would be good to link to your explanations, it could save some debug time to your customer :)
I am conscious that i could be sound like a negative person but believe me it is just positive customer worries/return. I discover the two products i bought and exept that installation process i am happy of your work ;)
@vallet
i have taken your advice, and the help screen is much more informative about what kinds of information we send along with the ticket if you choose to request it. i have also included a note about email security in each outgoing email when a ticket is closed about the intrinsic insecurities of transmitting sensitive information via email, which in a support site for installing software on a webserver is essentially mandatory.
we take security seriously, and i hope these changes reflect that.