After making some coding changes in my project and refreshing the page, I encountered the error below:
This tells me that the file loan.js could not be found. My first thought, then, is to find out what file is trying to make a call to loan.js. When I expand any of those errors to view the stack trace, I see system files like:
system.src.js:xxx
aurelia-loader-default.js:xxx
aurelia-templating.js:xxx
compose.js:xxx
etc
What does not show up is any specific file that would lead me to where my error is. It turns out that in myFile.js
I had forgotten to provide the specific path to loan.js
view-model="loans/loan"
With multiple view models and views where we make references like the above, how are we expected to debug issues like this when the communication is not specific? Is there some debug, logging error options that I am missing? I'm used to compilers at least providing the last place where the file was attempted to be fetched (causing the 404).
Related
The site works fine on Chrome/iOS/Safari/Android (you should be able to select and image and proceed to write a message on the next step). Firefox refuses to run my project's main script (you can't select an image or go forward), and gives the following error in the console:
> Content Security Policy: Directive ‘frame-src’ has been deprecated.
> Please use directive ‘child-src’ instead. (3) Unknown
It's very cryptic. I've tried the following:
1) Adding a meta tag for the CSP in the header.
Result: Creates more errors if restrictive, same amount of errors if
left to wildcards on all parameters.
2) Locally serving all scripts.
Result: I still get three unknown CSP errors. It also loads a lot
slower since the dependencies are not being loaded from a CDN.
3) Removing specific scripts.
Result: It reduces the errors by up to one, but it seems all scripts
are equally responsible. Very strange behavior.
Is this a bug in Firefox that is unsolvable? I'm tearing my hair out over this.
I needed to put listeners in $(document).ready as Firefox loads things differently as pointed out to me by Matt Gibson.
Content Security Policy did not cause the script to fail. However, it is a weird error message that gives you no information to where the error is originating, and can potentially break the site, but that is not what happened here.
I have written a Firefox Extension using Web Extension APIs. It has passed the Preliminary review but the reviewer said that he cannot proceed with the full review cause when he installs it, he gets the following error -
"Unable to parse JSON data for extension storage"
Upon inspecting for quite sometime, I figured that Firefox creates a file called "storage.js" in the profile folder for each extension where it writes and reads from, all the local storage data for that particular extension. And if the extension tries to write to this file before this file is created, the error "Unable to write JSON data to extension storage" is thrown and if the extension code tries to read from this file before this file is created, the error "Unable to parse JSON data for extension storage" is thrown.
Now, my concern is how do I know for sure that the file has been created and that it can be written to or read from?
PS : This happens when the extension is just installed. For consequent sessions, this error wont come as that file is no longer missing.
This seems to be a bug in the current Firefox implementation, and your assessment is spot on:
The underlying ExtStorage module will always call read before get, set etc. even write and clear.
read will unconditionally try to access the underlying, extension specific storage file, that may not exist yet for freshly installed add-ons using the storage API for the first time.
This will therefore result in the logging of one such Unable to parse JSON data for extension storage message, no matter what you do with the storage API.
Therefore triggering the message cannot be avoided.
I suggest you do the following:
Contact the editors team, requesting they re-evaluate your add-on based on:
The message in question is really only a warning (when appearing after first access of the storage API by your addon).
Even when the message would be an actual error (the storage is corrupt), it would still not be your error, as the storage API implementation by mozilla needs to be more resilient then and there is nothing you can do anyway.
The message being issued on first regular use of the storage API, unrelated to what WebExtensions add-on uses that API and in what way, is a mozilla bug, and not something you caused or can fix yourself or at least work around.
Therefore denying a full review just because a mozilla bug erroneously logs a spurious message once without any other severe effects is... questionable.
File a bug about this so mozilla developers can address this issue. You'll wanna CC at least Bill McCloskey (:billm) since he wrote that code ;)
I have just upgraded from kendoui.web.2013.1.514 to kendoui.web.2013.2.716 and have noticed that in the parts of the code where I require (through require.js) a certain kendo.culture.xx-XX.min.js file that also an unsuccessful request for kendo.core.min.js happens and I get an error in the console.
This did not happen with kendoui.web.2013.1.514 and I think this part inside the kendo.culture.xx-XX.min.js files might be to blame:
("function"==typeof define&&define.amd?define:function(e,n){return n()})(["../kendo.core.min"]
Also this reference to kendo.core appears to only be present in the minified versions. Note that I already have kendo.web.min.js fully loaded and the app works fine even with the invalid request so is this a bug?
If you are using the bundles (i.e. kendo.web.min.js) then you shouldn't use RequireJS to load them or any culture files.
I'm sorry that the documentation didn't mention it, I just added a section to explain this.
Is there a way in Codeigniter to override global errors. For instance if an DB error or PHP critical occurs it wont show the error itself but something like 'Our admin guy is fixing the issue' and the error is just logged and emailed.
Codeigniter lets you handle error messages your way, depending on the HTTP status.
Refer to this documentation on error handling
In addition to #Pos5e5s3dFr3ak's answer, you should handle as many errors as you can manually. For example, if you have a database error, your code should acknowledge (or 'catch') it and perhaps load the appropriate view, or pass it onto a library that will log an email the fault, instead of displaying the intended result.
This method can be used as an alternative, or as an addition to the original answer - sometimes you need not locate the error just by its HTTP response Status Code.
As an example, you may find that the database engine in use is down. If this is the case (you would have to determine if it is indeed down - ie. you are not getting the desired response), you would pass the user on to example.com/error/database, for example.
I have a new fairly fresh install of Magento 1.7.0.2. I installed two custom payment method modules that are working fine. But now whenever I try to disable or enable any Payment Method or Shipping Method it gives me an error like this:
An error occurred while saving this configuration: Warning:
preg_match() expects parameter 2 to be string, array given in
/app/code/core/Mage/Adminhtml/Model/System/Config/Backend/Encrypted.php
on line 57
Do you have any idea why?
EDIT 2:
I found the problem. It was caused by a patch I applied to fix to a previous BUG. :P
EDIT:
So I disabled all custom modules and I was still getting the same error. I logged what was happening and it seems that some core modules are sending an array to be saved.
Like PayPal Express Checkout for instance. One of the config options is the Time of Day in the SFTP credentials for Settlement Report Settings. It's composed by three different drop-downs and it's sending an array to be saved!
In the Shipping Methods, UPS has a config options called Allowed Methods, and it's also sending an array!
I still don't know why it wasn't happening before and now it is. They shouldn't be encrypting everything. Any clues?
I had the same issue, its a known bug, try this around line no. 135 on code/core/mage/Adminhtml/model/config/data.php
// add this code
$backendClass=false;
if (isset($fieldConfig->backend_model)) {
$backendClass = $fieldConfig->backend_model;
} // before this
if (!$backendClass) {
$backendClass = 'core/config_data';
}
This actually is a reported bug in Magento that seems to affect encrypted config settings (passwords, API keys, etc.).
http://www.magentocommerce.com/bug-tracking/issue?issue=14217
Try disabling the first of the modules, log out of the admin panel, clear /var/cache and see if the problem still exists. If it does, do the same with the second module.
The problem should be gone. Now that you know which module causes the problems you can either decide to try another module instead or debug to see whats going wrong.
Put a breakpoint on line 57 in /app/code/core/Mage/Adminhtml/Model/System/Config/Backend/Encrypted.php to see what goes wrong. It seems that the second parameter is not a string (might be null for example due to wrong configuration or something) when its given to the preg_match function. Maybe this helps you to identify the problem.
Regards
Disabling modules through the back office isn't a good idea as it only disables the block output, if you would like to disable a module you should go to app/etc/modulesand there you should find Module_Name.xmlfile - in this file just put false in active node.