Server Requirements

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 5 or Greater
  • Safe Mode OFF
  • GD Library 2.0 (bundled -- see note below) 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:

Example output

See attached file:

Have more questions? Submit a request

16 Comments

  • 0
    Avatar
    Jeremy Voorhis

    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

  • 0
    Avatar
    michael sablone

    hmm, interesting!  i'll get on this.

  • 0
    Avatar
    Paul Brooks

    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

  • 0
    Avatar
    Ryan Davis

    Everything passes except the "File Permissions". What do I need to have my  host change to enable this to say "OK"?

  • 0
    Avatar
    michael sablone

    @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.

  • 0
    Avatar
    VALLET Nicolas

    Document root in 777 is it a joke?...

  • 0
    Avatar
    michael sablone

    @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-context-why-exactly-is-chmod-777-dangerous

    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.

  • 0
    Avatar
    VALLET Nicolas

    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.

  • 0
    Avatar
    michael sablone

    @vallet -- running wp and doing automatic updates (http://forum.slicehost.com/comments.php?DiscussionID=3096) 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.

  • 0
    Avatar
    VALLET Nicolas

    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 ;)

  • 0
    Avatar
    michael sablone

    @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.

  • 0
    Avatar
    Sean L

    Hello Michael,

    Will/Does the HTML5 site work on a server running PHP 5.4?

    thank you

    Sean

  • 0
    Avatar
    michael sablone

    @sean - html5 has little to do with the server environment.  one thing that the html5 sites have that are unique to them are "clean urls" -- and for that, your server requires "loopback" urls.  basically it means your server is able to call itself to pre-render a php page.  the sites will still work fine without loopback connections, but you won't be able to use clean urls.

    other than that, all the same requirements as before.

  • 0
    Avatar
    michael sablone

    Here at Intothedarkroom, we are constantly developing new products, updating existing products, and trying to improve the way we do things and come up with the best solutions to complex problems.

    As we move towards alternatives to Adobe Flash, we're going to require more and more technology-forward platforms and browsers.  In the past, PHP's GD library has been and awesome tool for things like resizing images and creating thumbnails, but by leveraging Adobe Flash's plugin, it never had to do any real work so it was never a requirement.  Now, we're using it to take existing graphics and colorize them based on your design settings.  Since only the most cutting-edge browsers have image manipulation, we need to make sure the most important modifications to raster graphics and images come directly from the server.

    So, for the time being, the bundled version of PHP's GD library is now required.  Most servers don't have any issues with this.  If your server is the exception and preventing installation or update, it is probably running some form of Debian/Ubuntu Linux build, and this post is for you.  Otherwise, you can probably stop reading now.

    A little history:  the omission of GD functions is because a long time ago, the developers of PHP "forked" GD away from the original developer's library to improve upon it since it had become stagnant. They then started "bundling" this new version directly with PHP.  Your hosting platform is using the original library that is about 8 years old in the form of the "php5-gd" package.  But that's all academic. This is a long-standing issue and if you really wanted to, you can see the almost 8 year history of this debate here:
    https://bugs.launchpad.net/ubuntu/+source/php5/+bug/74647

    So, if because of these changes you're in a jam, you've got 3 pathways here:

    1 - Have your hosting company re-compile PHP using the more current, bundled version of the GD library.  Many hosting companies will probably ignore this request or tell you it's impossible.  This is a good time to reflect that in today's day and age, there is just no reason not to have the most recent applications. Even if your hosting company is using Debian -- a 19 year old operating system -- there is a way to make it happen.

    2 - Switch hosting.  We say it time and time again:  not all hosting companies are created equally.  If your server is using an image library whose code is 8 years old, and they can't update to a clearly improved and robust (not to mention approved by PHP) version of the software, that doesn't bode well for you long term.  Eventually someone is going to have to budge -- the internet and technology moves too quickly to be 8 years behind.  You need to ask yourself if that is the kind of hosting company that you want for the long haul.

    3 - If you have an existing product and can no longer update and options 1 & 2 are not an option, you can alternately choose to do nothing.  You can just leave your product at the version it's already at, as it's not using the newly implemented and more modern functionality.  Granted, that means it's the end of the update cycle for you, but please understand that we, as a company, cannot stay stagnant alongside your hosting provider.

    Hopefully this information is useful to you in moving forward, and as always we're here to help you any way we can.

  • 0
    Avatar
    Hadrien Brunner

    Hi,

    I used the capabilities file this morning and everything was green/ok. I then,  tried the update, and everything updated correctly with no error at all.

    I had access to the admin and could see all my sets and contents but i could not access to the front end. this message was displayed :   "You are seeing this message because you have recently installed this product. You will need to setup your admin panel, and create some content, as there is no content yet to display. Please refer to your introduction email for further assistance, or click the link below to visit the resources site."

    I did not make any change in the admin panel, and my content is still here, so, am i missing something ?

    Thanks in advance,

    (and well done for this update, our customers will be pleased with that ! ).

     

    Hadrien

     

  • 0
    Avatar
    michael sablone

    @hadrian:

    please make sure you fill out both:

    Login > Setup > Ordering > Order Email Inbox

    and

    Login > Contact > Owner Details > Your Email

    we used to let those slide, but we are now enforcing those rules.

Please sign in to leave a comment.
Powered by Zendesk