Hi,
My client said he added 4 products in this category, but done it via the clone option. He then said he went to open the ‘soft’ hyperlink and it wouldn’t work, as viewable when clicking the link above.
I have no idea what’s going on here. Any help would be greatly appreciated.
Thanks
Jon
p.s. checking on another PC has revealed a different error message. One that says a 30 second limit has been exceeded.
Nevermind I fixed it…for now…But i’m going to contact the host about the set_time_limit() thing.
I removed the sub-category. The only trouble is that doing this caused the shop front to mess up. Basically nothing would display apart from the quick links and top menu. Not the first time this has happened neither.
Anyways, I ended up having to restore from an old backup. I am starting to wonder about the reliability of CS Cart to be honest, especially considering this is the 2nd time the store front has corrupted now…and i’ve only performed expected tasks each time…
plus an experienced cs cart person installed it the first time for me, and I had an issue with displaying the store front after making a change in the admin panel. I just hope it’s a problem with the host because I don’t want to be constantly having to help the client fix problems with the cart…and obviously the more clients you have using cs cart the worse it could get.
I’ve had issues with my shop displaying after making a minor change, too. I thought it was just me! 
Maybe it’s not!!
I was also wondering if there are more issues than we know if in the cart. I can’t believe that I try to change one part of a tpl file to change the layout on a screen and it completely messes up the whole cart front end! I even tried clearing out cache and compiled folder with no luck.
Hope these things aren’t a bad omen for CS-Cart and its stability.
Regards,
Stephanie
Testing/Developing 2.0.8
So i’m not the only one then 
I suppose the only thing I can do is get the client to keep making backups. Otherwise he could end up adding a few hundred products, then make a changing somewhere…and the shop front could dissapear, or pages might not load ha ha (not really a laughing matter)…
Then he has to restore from a backup, and all the products will obviously be gone.
He only made a clone of a product 4 times, and this broke the cart.Hmmmm
Since the subject of this thread is “500 Internal Server Error”, a footnote …
There is 5 major types of PHP configurations out there …
- SuPHP (by far now the most popular)
- DSO (Apache module)
- Direct CGI (Very rarely used)
- PhpSuExec (Almost always what is meant by CGI)
- FastCGI
For ANYTHING listed above (except for DSO), you cannot set any of your files or folders to permission ‘777’ as doing so will kill your site and cause Error 500 pages, the very title subject of this thread – thus the comment!
(Internal Server Error 500 can also be caused by uploading files in “binary” mode where “ascii” mode is required in FTP, low resources, bad commands in .htaccess, missing system folders, and a host of other reasons but if you get “Internal Server Error” (Error 500) right after trying to install or upgrade CS-Cart or any other web program for that matter, chances are it’ll be something to do with the PHP items listed here)
Unfortunately, CS-Cart in what I would call “questionable wisdom” apparently assumes everyone is using DSO for their PHP configuration blindly sets a number of files and folder permissions to “777” from within their code at several different script locations. This, (though not recommend), might work well enough on DSO based systems, speaking from a technical operational perspective, but it can literally bring a site to a screeching halt on most server with any other PHP types and the great irony is that these other PHP platforms have now become far more popular among hosting providers than Apache modules (DSO) based PHP primarily for their security and / or performance advantages respectively.
For those of you on CGI, phpSuExec, SuPHP, or FastCGI systems, your situation is a little bit complicated than those on the quickly fading DSO systems but your problems are still very easily fixable.
Other than setting alternate permissions, you will need to edit a few places in your CS-Cart code where chmod() functions are called with a “777” and change those to “755” instead in those particular code locations.
Rules to adhere to on non-DSO (IE: Not Apache Module) systems:
--------------------------------------------------------------------------------------
- Never set “777” permissions to any file or folder!
- Do not use any “php_flag” or “php_admin” command in .htaccess
- Make sure all your files are owned by the same name as your login.
- Be careful with “AddType” commands in .htaccess that involve PHP.
Each of the above 5 items can and do cause “Error 500” pages to be displayed if ignored.
Jon
I was getting 500 when installed PHP scripts on some strange servers, some of my customers were using. It was usualy due to the low resources available. Too much content or search function enabled and bang. 500 in a full glory. CPU was at 2% max and RAM 32Mb.Moved to a proper one, and all problems were gone. I had it with X -C script, Joomla and LiteComm…
Also, sometimes htaccess configured incorrectly can cause the famous 500.
If you use CPanel, do not enable hotlinkig protection. On some servers causes trouble for unknown reason.
I hate shared hosting!
Good luck.
Thanks for the ideas…
So do you think it’s worth setting permissions to 755, rather than 777?.
I’ve asked the client to try adding 4 products again via the clone method, and bang it breaks again. Basically after he adds the 4 products and trys to view them on the site, the page that contains the products becomes very slow and then just shows an error.
I’m really lost as to what to do. I don’t even have any .HTACCESS files as cs cart doesn’t work for me if I do.
Thanks
From my experience installing your site to your host, changing hosts would be my first choice.
As Roban said…
… I would also change your host. Lack of resources.
And yes, go with 755 and test it. It doesn’t hurt if you know which folders and subfolders need 755.
ha ha I know it’s just terrible.
I’ve just discovered my permissions where not correct.
I had 777 on var, images & skins
I had 604 on admin.php
I had 644 on config.php & index.php
I suppose this doesn’t exactly help lol.
EDIT: I’ve changed them all to 755. Hope this solves the problem. I wasn’t even aware I didn’t set perms correctly.
[quote name=‘jbenitos’]So do you think it’s worth setting permissions to 755, rather than 777?.[/QUOTE]
That question cannot be answered without first knowing your PHP type as I said previously above …
I would NOT recommend ‘777’ be used NO MATTER WHAT PHP TYPE YOU HAVE RUNNING …
However, the exact permissions you need are going to be different depending on your PHP type so you will need to know that.
If you are indeed “DSO” (Apache Module) based then ‘yes’ you technically could use 777 but you will probably still want to use something a bit tighter and there is no logical or legitimate reason to actually use any ‘777’ permissions anywhere. For those who do not realize this, you don’t actually need the execute bit set for files needing to be set writable nor do your files technically need to be in a folder that is setup to be globally writable either to be script writable in a DSO based PHP environment!
The above is actually a common misconception by a lot of people and even some programmers!
If you are using any of the other PHP types (usually shown as some form of CGI in ‘phpinfo’) then you will want to set either 755 or 600 for your scripts (depending on the PHP type exactly), 644 for your non-scripts (images, plain html, templates, etc), and 755 for all your folders.
[QUOTE]I’ve asked the client to try adding 4 products again via the clone method, and bang it breaks again. Basically after he adds the 4 products and trys to view them on the site, the page that contains the products becomes very slow and then just shows an error.[/QUOTE]
This sounds very much like your problem is caused by CS-Cart using “777” permissions internally inside their script code. Basically and in a nutshell, their script code that sets up a new files blindly sets “777” permissions to those files automatically and when that happens then “bam!” your site is dead because nothing but Apache module (DSO) based PHP allows for 777 permissions unless the administrators have explicitely allowed it (not going to happen and would be extremely unwise).
Assuming you are on a host using something other than DSO (very highly likely these days) then your solution would be to go into the script code and find all the “chmod” commands and replace the ones with “777” in them to “755” and that will make the program set newly uploaded or modified files to “755” automatically instead of “777” and fix your problem. I do have a program that can make these changes automatically within a matter of seconds if anyone would need that incidentally.
[QUOTE]I’m really lost as to what to do. I don’t even have any .HTACCESS files as cs cart doesn’t work for me if I do.[/QUOTE]
Your comment just further suggests the permission issues per above.
[QUOTE]Thanks[/QUOTE]
You’re Welcome.
[quote name=‘Roban’]From my experience installing your site to your host, changing hosts would be my first choice.[/QUOTE]
Your comment falls in the “stupid” advice category! :rolleyes:
Why would I actually say such a thing, you no doubt ask?
Very simple — [QUOTE]
[i]
- The vast majority of hosts out there are not “DSO” based and do not allow
hosting accounts to use “777” permissions and that is for very good reason.
- Those hosts remaining still using “DSO” are dwindling and fading quickly.
- The other PHP types, all except perhaps “plain” CGI, are all many times more
secure than direct DSO based PHP and this is one of the main driving factors
why most hosts have left DSO (Apache Module) based PHP in the first place.
[/i][/QUOTE]
If you make it a policy of changing hosts each time you run into an “Error 500” or because your host doesn’t permit “777” permissions then you are going to not only waste a lot of time and money doing that but you are going to quickly run out of hosting providers because you’ll have to keep on moving as each of the few remaining hosts go ahead and migrate to something better and safer.
The solution is not changing hosts —
The solution is waking up CS-Cart to the reality that they are very much in the minority and going to lose the market entirely if they don’t start catching up to the real world and programming things better.
It would only take a couple simple lines added to their code and they would be able to easily handle every single server type and PHP platform with no trouble whatsoever and I would even be glad to show them what they need to do! There is a command built into PHP that was even designed precisely for that too!
Until then ----
You will just need to set the correct permissions and / or modify the code as applicable so that the “777’s” don’t kill your web site!
[quote name=‘jbenitos’]
I had 777 on var, images & skins
I had 604 on admin.php
I had 644 on config.php & index.php
[/QUOTE]
Based on the things you have said, I know at least that you are not DSO based PHP …
With that, the folders should be changed to 755 (The 777 on var, images, and skins is your main problem)
There is NO REASON to put “4” in the third digit on your PHP scripts in your case so the “604” should actually be “600” and your other PHP scripts can probably go to “600” as well.
Your NON-Script files (Those not ending in .php) should be set to 644
Jonathan’s host does not support .htaccess at all.
wow lots to digest here.
I managed to solve the problem. I made sure all the necessary perms where set to 755.
I then proceeded to clone a product 4 times, and bingo it worked this time. And i’m pretty sure this solved the problem as I attempted the exact same thing 3 times before and it displayed an error.
I suppose the only question now is “Should I be that worried that I had to delete the .HTACCESS file?”.Hmmm
I understand I could change host, but on this occasion it would be handy to keep things as they are (saves any hassle, and the client only signed up a month ago) Obviously for future installations of cs cart I will have to look into going with another host. Obviously if .HTACCESS being deleted is a major problem then I will have to change though.
Thanks
[quote name=‘jbenitos’]Obviously for future installations of cs cart I will have to look into going with another host. Obviously if .HTACCESS being deleted is a major problem then I will have to change though.[/quote]
Not just because of CS-Cart. With htaccess you can control other server things like spamer IP, php behavior and much more.
Thanks…
I’ve now worked out the problem is something else.
If I set the QUANTITY as 999999999999999999999999999999 on the 4 cloned items then it prevents the page being loaded.
Basically I create 1 item, then clone this item 3 times. Then set the quantity as 999999999999999999999999999999 on the original item and the 4 cloned ones.
Is this some sort of bug?. Because If I then go back and change the quantity to 1000 the page works fine. I’ve tested this 3 times to confirm this… Hmmmm
EDIT: I’ve also noticed it randomly changes the number to 8388607
It also seems to slow down if I enter 99999. So i’m not sure what is happening but the more numbers I enter the slower it seems to get…So in that case I could understand why 999999999999999999999999999999 is causing the server to time out…
[quote name=‘jbenitos’]Then set the quantity as 999999999999999999999999999999.[/QUOTE]
Why are you setting the quantity at such a high number? If you are not keeping track of stock, you need to choose the “do not track” option when creating the product and you don’t need to put any quantity in.
If you are keeping track of stock, I really don’t believe you have that many of one product in stock.
Use realistic numbers and you may not have the problem.
Thanks for your reply. I understand this but it seems like bad code.
Any number that is allowed to be entered into that box should work. Surely there could be some sort of data validation that sets a limit?.
I work with software at work, and in my code I would never allow the user to input something that could break the program. Hmmm
Well, Chuck Norris can brake your software easily. He knows all the numbers you can imagine and you cannot.
Long time ago, he was able to count to infinity. Twice!
[quote name=‘jbenitos’]Thanks for your reply. I understand this but it seems like bad code.
Any number that is allowed to be entered into that box should work. Surely there could be some sort of data validation that sets a limit?.
I work with software at work, and in my code I would never allow the user to input something that could break the program. Hmmm[/QUOTE]
ha ha. Maybe so but not if you set a limit on quantity. You can’t enter anymore numbers than the software will let you then. A simple piece of code prevents the user from breaking the software. I suppose the agument could be “why limit people to their stock quantity”. But in fact they are limited anyways because it throws up an error.
And I wouldn’t say that 9999999999 is an imposibility. If you was dealing with currency exchange with cs cart for instance, you could quite easily offer that sort of maximum.
Maybe a bad example, but i’m sure there is plenty of possible options for having such a high quantity.
And even if you didn’t have such a high quantity…you could be setting this up for a client and he/she could accidently input a higher number than necessary. Or they may even feel that putting 0 in stock seems a bit backwards, and feel like entering a large number seems more logical.
I know this is all unlikely (we like to believe) but shouldn’t we be avoiding the pottential of things going wrong in the first place. Did cs cart even test their input boxes, drop down menus etc. I can see they sort of added a bit of validation by changing letters to numbers for the quantity…but that’s only half a job done in my opinion.
EDIT: I suppose i’ve developed some frustration here because my customer was under the impression that he could enter a very large number to in effect give him ‘unlimited’ stock, and he could use “track with options” on all these products. Then in the future if he wanted to change stock level he could just change the quantity number on main products page, rather than having to also select “track with options” for the all the necessary products (which could be hundreds for all we know).
Now my only answer to him is. “Sorry the software designers of the cart haven’t designed it to allow you to enter large numbers”…even though you can enter them haha.
Hi,
I think there is internal limits. I was setting inventory for product options at 500000. Had about 10 product options with the same number. I also got some unusual behavior and reduced each to 5000 and problem went away. Never any error messages, but the cumulative amount may have caused a problem.
I set my quantity high and track inventory, only to be able to specify SKU. I don’t track in cart, but need sku for Quickbooks. I have the same 10 options SKU’s for 140 products.
I do feel as jbenitos indicates, that if there is boundry for some fields, the system should at least have a warning or indicate an error.
Bob