CGI Installation and setup instructions

From what I have read in other posts, it seems that more and more people are using shared hosting on CGI based servers. It is also obvious that a large number of members here do not like CGI and that the CS-Cart Installation Guide does not cater for CGI.



A larger number of thread posters say “move to a different host”, but that is not always possible.



The problem is, no one seems to have actually documented clear instructions for such a set-up. Some threads talk about xxx permissions and others yyy. Can we clarify what settings are actually needed and explain how best to go about it?



If this thread was then stickied, you guys wouldn’t need to half-answer so many posts about the problem and people like me would have one central thread to help us install CS-Cart.

I guess before people start off on their journey of installing CS-Cart, the first thing they should do is find out what kind of PHP your hosting server is running …



Create a “phpinfo.php” file and view this on your site:

Code:


[QUOTE] phpinfo();

?>[/QUOTE]



Look for the line on the screen shown to you that is labeled “Server API” …



(It’s near the top of the screen just after the long ./configure options line)



You should find something saying “Apache module”, “Apache xx Handler”, “Apache2Handler”, or even “dso” depending on your specific web server. This is what you would need to see before going ahead and following CS-Cart’s printed installation instructions.



If you see ANYTHING ELSE and that might include for example statements such as “cgi”, “cgi/FastCGI”, “fcgi”, or “suphp” then you should throw the CS-Cart installation instructions in the trash!



(Incidentally if your server is in the later group, you can completely forget the “777” folders as well!–

In fact, you actually would have to skip those in that case or you would break your web site)

So, what permissions are needed and to which folders/files?



How does one set permissions for those hundreds of sub folders without having to do it manually?



If they need to change permissions to folders, do they need to change the permissions on the files in those folders too? Is filezilla capable of changing permissions on folders and subfolders without changing files?

If your PHP environment info string from above does not contain the word “Apache” or “DSO”, these permissions should work:


folder permissions = 755
file permissions = 644




If you have shell access, change to the root directory of your store and execute the following commands:


find . -type d -exec chmod 755 {} \;
find . -type f -exec chmod 644 {} \;




Bob

And what if you don’t have shell access?



What is the easiest way to change the folder permissions to one and the files to another?

Does this apply to all folders and all files?

What should the permissions be returned to post installation?

[quote name=‘suitedscooter’]And what if you don’t have shell access?



What is the easiest way to change the folder permissions to one and the files to another?[/QUOTE]

It will depend on whatever client software you use. Some FTP programs will you to set all folder/file permissions regressively.


[QUOTE]Does this apply to all folders and all files?[/QUOTE]

Yes, all folders and file starting at the root directory for you installation.


[QUOTE]What should the permissions be returned to post installation?[/QUOTE]

In a non-DSO setup you can set the 755/644 permissions prior to install but I always recheck them as every installation and upgrade can reset permissions. Also, before installation, you should change the default permissions is config.php to match whatever you use:

// Default permissions for newly created files and directories
define('DEFAULT_FILE_PERMISSIONS', 0644);
define('DEFAULT_DIR_PERMISSIONS', 0755);




If for some reason you have a permissions issue with the above settings in a non-DSO setup, you could then loosen the permission for the specific file or folder. However, I have never had a problem with these settings and I actually reduce the permissions on my .php files to 600.



Bob

[quote name=‘jobosales’]It will depend on whatever client software you use. Some FTP programs will you to set all folder/file permissions regressively[/quote]

FileZilla is pretty good. You can change permissions of files, folders, subfolder and files inside of those subfolders with one action.

[quote]

f you see ANYTHING ELSE and that might include for example statements such as “cgi”, “cgi/FastCGI”, “fcgi”, or “suphp” then you should throw the CS-Cart installation instructions in the trash!

[/quote]



Not sure what experience drives this comment is coming from. I run cs-cart under mod_fastcgi for many stores. No problems on installation or runtime.

[quote name=‘tbirnseth’]Not sure what experience drives this comment is coming from. I run cs-cart under mod_fastcgi for many stores. No problems on installation or runtime.[/QUOTE]

I think he is making reference to the fact that the looser permissions recommended in the manual will often throw an error 500 if you are in a non-DSO PHP environment.



Bob

[quote name=‘jobosales’]I think he is making reference to the fact that the looser permissions recommended in the manual will often throw an error 500 if you are in a non-DSO PHP environment.



Bob[/QUOTE]



I don’t agree with their policy of 666 for files and 777 for directories being the default. Would make more sense to grab “.” and “.htaccess” at run-time to determine what the default permissions should be for a particular site. Then if “.” is set to 755 and “.htaccess” is set to 640 then those should be the permissions to use for the site rather than hard-coding it into a define in config.php.

[quote name=‘tbirnseth’]I don’t agree with their policy of 666 for files and 777 for directories being the default. Would make more sense to grab “.” and “.htaccess” at run-time to determine what the default permissions should be for a particular site. Then if “.” is set to 755 and “.htaccess” is set to 640 then those should be the permissions to use for the site rather than hard-coding it into a define in config.php.[/QUOTE]

I am not sure why they don’t see the benefits if this. As it is currently, people trying out the cart follow their instructions and end up with an error 500, quickly deciding to look elsewhere for a solution.



Bob

[quote name=‘jobosales’]I am not sure why they don’t see the benefits if this. As it is currently, people trying out the cart follow their instructions and end up with an error 500, quickly deciding to look elsewhere for a solution.



Bob[/QUOTE]



My experience is that they are very reluctant to engage in a dialog about anything. Best I’ve seen so far is the recent Roadmap section of this forum. I think it’s a cultural issue, I’m not sure.



The user-voice stuff is a joke. Any comment (even negative) counts as a vote and there is little if any participation of the development or marketing staff. It’s all noise and I don’t even bother to go look there anymore.



I’ve expressed countless times that they need to pick out about a dozen of their users who represent technical savvy as well as business acuity and use them as “the users” to head in the right direction with the right emphasis. This means proposing ideas, listening to responses, adjusting and coming up with a real plan that meets the need. I’ll use the data-feeds as an example. All of a sudden, it appeared but does very little to help with anything.



The development team is very good technically, but how can you develop something to meet a user-base need when you don’t have discussions with your users? Very strange, I’ve just written it off as “it is what it is” and do my best to work with what I have.



Okay, rant off! The technical implementations are very good. What’s missing is the “use cases” and merchant feedback to ensure the market need is met.