SOLVED: Form throwing different errors on submission

[NickC4555]

I have a form on a customer website (http://www.stoneseed.co.uk/project-management-as-a-service-brochure) that is intermittently throwing a variety of errors on different PCs and browsers.

On some PCs it works, but during the last 2 days, these errors have been reported:

IE11: Warning: file_put_contents(/var/sites/s/stoneseed.co.uk/public_html/cache/com_fabrik/js/7715621fdd272f59e7f24d7ec95e3e00.js) [function.file-put-contents]: failed to open stream: No such file or directory in /var/sites/s/stoneseed.co.uk/public_html/plugins/system/fabrik/fabrik.php on line 122

IE11: SyntaxError: Invalid character

Chrome: SyntaxError: Unexpected token I

These have all been forwarded to me as screenshots by my customer. I have tested it on IE, Chrome and FF without any errors.

 

[NickC4555]

Bump.

 

[cheesegrits]

Hey.

That is very odd. Can you check your folder permission on the ./cache folder in your J! root?

Here's what the code does:

            $folder = JPATH_SITE . '/cache/com_fabrik/js/';
 
            if (!JFolder::exists($folder))
            {
                JFolder::create($folder);
            }
 
            $cacheFile = $folder . $file;
 
            // Check for cached version
            if (!JFile::exists($cacheFile))
            {
                $script = self::buildJs();
                file_put_contents($cacheFile, $script);
            }
            else
            {
                $script = JFile::read($cacheFile);
            }

Which means that the JFolder::create($folder) isn't working, so the file_put_contents() fails with that "no such file or directory" error you are getting. We should probably put some error testing in there, and test to see if the folder ecists after we attempt to create it.

What's weird is, if the folder permissions aren't allowing the web server to create that folder, I would expect it to fail every time, not just sporadically.

 

[cheesegrits]

I've added that "belt and braces" error checking in, so if for any reason the cache folder isn't created, we should fall back to a non-cached build of the scripts.

https://github.com/Fabrik/fabrik/commit/16981f03746baeba25af43979555caf505933f51

So if there isn't any issue with your folder permissions, do a github update, which should solve the problem. Or at least, work round it. I still don't quite understand how this issue would be sporadic.

-- hugh

 

[NickC4555]

I'll try this later, thanks. Any thoughts on the other 2 errors, please? The three I listed were all separate ones on different PCs.

 

[NickC4555]

That worked, thank you. The other errors were fixed by changing Joomla's error reporting to none. Not ideal, but it worked.

 

[cheesegrits]

Well, you shouldn't really have J!'s error reporting turned on, on a live site, as it can cause all kinds of weird issues.

In this case, it looks like an AJAX call is tossing some kind of PHP warning, which is going back with the AJAX response to the browser, and breaking the AJAX.decode().

I really can't tell you what might be happening, as I'd need to actually see those JS errors happening, and work out what AJAX call they are being generated in, and what the underlying PHP warning is. All those two errors are really telling us is "an AJAX call didn't return a valid JSON formatted response".

So ... if you have a sandbox site you can use (Akeeba is awesome for cloning sendbox test sites) where you can enable J! debug, and point me at the page that generates them, I can help.

-- hugh

 

[cheesegrits]

Just to be clear about the error reporting thing. While it is useful to know if code is throwing PHP warnings, and for "normal" page load code the only effect is a visible notice of the warning somewhere on the page, for AJAX calls from JavaScript in the browser, error reporting is fatal. When the browser makes an AJAX call to the server, be it Fabrik or anything else, it expects to get "structured" data back, either XML or JSON. That structured response is decoded by the JavaScript engine / library (jQuery, Mootools, etc) into data structures the JavaScript doing the AJAX call can then use.

But if PHP error reporting is enabled, that structured data will be corrupted by having the PHP notices / warnings in it, or preceeding it, which then breaks the decoding. Which is what those "unexpected token" and "invalid character" errors are. The JSON decoding in JavaScript is expecting a valid JSON character to start the structured data, like { or [, and instead is getting the text of the PHP warning.

Which is why it is useful to have a sandbox (test version) of your live site, using Akeeba to make a bitwise clone of it, where you can safey whack J!'s error reporting up to max and see / fix errors, without breaking your live site.

-- hugh