swaggerbear Posted August 9, 2013 Share Posted August 9, 2013 Hi there! So, I just finished building my first Prestashop site and I'm totally pleased with it. Everything seems to be working so I just swung it into the root directory of my server (it had previously been in a subdirectory). When I cut it over, I made sure to change the path to the root under Prestashop's SEO & URL's page, and had Prestashop regenerate the .htaccess file. Then I went into my service provider and set it to use one php.ini file only just in case something went wonky. On the surface, everything looks totally fine (at least as far as I can tell). However, I installed the clicky.com module so I could watch real time logs. In those logs, many URL's show up as 404 errors, even though the pages seem to be working fine in a browser. Also I installed the Prestashop module for Beetailer so I could link my store into Facebook, and that module keeps throwing 500 errors (and doesn't work at all). My Prestashop logs are totally empty, so they're no help. I tried to force-turn them on by playing around with both /config/config.inc.php and /config/defines.inc.php [@ini_set('display_errors', 'on');] but neither edit produced log entries so I've since reset them all back. It seems a bit coincidental to me that TWO different external interfaces would be having problems. So I'm wondering if there was a step I missed when I moved the site. The address is http://cranetraxmusic.com Does anyone have any ideas? Cheers and thanks!!! *hug* Geoff. Link to comment Share on other sites More sharing options...
(\)icholas Posted August 9, 2013 Share Posted August 9, 2013 (edited) Hey Geoff. I stepped through your site in the latest version of Chrome. Everything appeared to be working well. No 404's or 500's. The facebook link worked fine. Previewed some tracks as well. Nice site! display_errors will cause the software to print errors to the front office if it detects that something went wrong during a page load. So a user will see a description of the error if one occurs. Logs should be captured regardless of display_errors. However the errors that would be showing up in the Log section of the Back Office are (I'm pretty certain) a log of php errors. Php handles the software. 404's and 500's are server errors. You would look for 404's and 500's in your Apache error log, assuming your running on a Linux box. Prestashop has the functionality to gracefully handle 404's. 500's are most likely due to a fatal condition that was encountered by php, I'm not certain that the prestateam has implemented techniques to capture fatal errors that php can't detect on its own. Using php's ob_start() method is one technique to do so. The problem is that fatal errors should be very rare and will only occur in code that wasn't thoroughly tested. It wouldn't be high on their priority list as they do thoroughly test their code. Its more likely the Log section of the B.O. will get filled if your working with a version that is still under development. I have been running, testing, altering and updating my prestashop for 3 years and only have 2 errors listed under the Logs section. I'm not familiar with either of the two modules you purchased, but in my experience many of the modules available for purchase are buggy. Because they can be developed by one or two people with little or no credentials, or with insufficient time to do the testing and code-revision required by commercial grade software, or that opensource software inevitably goes through. In fact of the 5 modules I have purchased 4 have been noticeably buggy. But at the same time I'm sure others have had better luck. Another thing to keep in mind is that once you expose your site to the interweb, bots and hackers will search your site for vulnerabilities. They will search your server for urls like /admin, /phpmyadmin and such looking for backdoors to log into. Thus why prestashop requires you to rename your admin file. This activity will fill your log with 404 error's as these villains attempt request after request for non-existent urls. Even if your site gets low traffic expect several attempts on it a day. Try finding the URL's that are generating the 404's in your Apache error log. If they are attacks like these don't worry about them too much, maybe double check your security settings. If they are legitimate URL's that exist on your website try copy pasting them into your browser and see what they give you. Edited August 9, 2013 by (\)icholas (see edit history) 1 Link to comment Share on other sites More sharing options...
swaggerbear Posted August 10, 2013 Author Share Posted August 10, 2013 (\)icholas, thank you very, very much for such a considered reply!! I appreciated your comments especially because after having my nose buried so deep in this thing all week I've sort of lost sight of where I should be looking. As soon as you reminded me that 404s and 500s are server related I stopped bashing my head against the wall trying to get the error messages to show up in Prestashop! ROFL That's really interesting that after 3 years you only have 2 errors in your log...you'd sort of think there'd be a lot more in that length of time but it's good that Prestashop just kind of deals with it. The 404s in my clicky.com logs seem to be diminishing. I was still making tweaks to the site up to last night so it's possible that the 404s were left over from clicky's interpretation of wonky input from my server, and it's just now catching up. As for the 500s from Beetailer, I suspect you're right. Not to knock Beetailer, but their response to my mails was pretty hands off. "Your module is throwing 500s. Check your logs." LOL It's too bad because they looked really promising in terms of me not having to recreate my shop on Facebook if I wanted a sales vehicle there too. I didn't pay for either of these modules...both are free as long as you sign up for their service, and both services have free options so you can test stuff out. I will say I do wish more Prestashop module vendors had a "try before you buy" option so you can a) see if you like their stuff and get the chance to see first hand how solid the code is and what the support is like. But that's maybe just me and it's likely not always possible. LOL Anyway (\)icholas I appreciated the time you took to answer me! It helped put things in perspective. :-) 1 Link to comment Share on other sites More sharing options...
Recommended Posts