I am experiencing a strange error with Odoo 15. When I run a forecast report for a product if its done over SSL I get this error
Uncaught Promise > Cannot read properties of null (reading 'querySelector')
The strange thing is this only happening over SSL. When I run it over HTTP. I get no issues.
The only thing I can guess is that there is an issue with NGINX, but I have configured plenty of Odoo servers before with no issue, and I am running all the standard configs from the documentation. https://www.odoo.com/documentation/15.0/administration/install/deploy.html
I have attempted to change the system parameters on the setting with the same results.
Both the odoo and nginx logs show no errors.
Related
I have made a flask application at my local computer in the debugging mode and it runs all fine. But when it comes to production, the website gives me 500 or internal server error, which I have no idea what the bug is. I am fairly new to flask production and this has been stopping me from moving forward for quite a few days.
My questions are:
1> in my local development environment, one could always print things out. But how can I see those prints in the production stage?
2> Do I see them through Apache2 log? Where is Apache2 log?
For production, I actually followed the tutorials from pythonprogramming.net. Youtube link is here:
https://www.youtube.com/watch?v=qZNL4Ku1UQg&list=PLQVvvaa0QuDc_owjTbIY4rbgXOFkUYOUB&index=2
To use a very simple example, if the code imports a package which wasn't installed, where can we see the errors?
Thanks in advance.
I've tried to use to use try ... except block for every flask function. Whenever there is an exception, it can be return to the front-end. But what about other errors?
I found out:
Use logging module
Read apache2 log from /var/log/apache2
I am trying to install Forticlient EMS onto Windows server. The apache service has been running fine however when running the application it loads with the following error:
Failed to load URL https://localhost/ with error ERR_CONNECTION_REFUSED (-102).
There is not much online to work with regarding this error. I changed the ports in the .conf file to 82 instead of 80 as it was clashing but stuck as to why this error is being produced. Has anyone come across this? This is not running in Chrome rather i am launching Forticlient EMS application for this error to show on the application.
Using stencil 3.0.3, node 12.21 cornerstone theme was working and suddenly stopped with a weird server error:
Debug: internal, implementation, error
Error: The BigCommerce server responded with a 500 error
at Object.internals.getResponse (/usr/local/lib/node_modules/#bigcommerce/stencil-cli/server/plugins/renderer/renderer.module.js:128:15)
at processTicksAndRejections (internal/process/task_queues.js:97:5)
at async internals.implementation (/usr/local/lib/node_modules/#bigcommerce/stencil-cli/server/plugins/renderer/renderer.module.js:39:20)
at async module.exports.internals.Manager.execute (/usr/local/lib/node_modules/#bigcommerce/stencil-cli/node_modules/#hapi/hapi/lib/toolkit.js:45:28)
at async Object.internals.handler (/usr/local/lib/node_modules/#bigcommerce/stencil-cli/node_modules/#hapi/hapi/lib/handler.js:46:20)
at async exports.execute (/usr/local/lib/node_modules/#bigcommerce/stencil-cli/node_modules/#hapi/hapi/lib/handler.js:31:20)
at async Request._lifecycle (/usr/local/lib/node_modules/#bigcommerce/stencil-cli/node_modules/#hapi/hapi/lib/request.js:312:32)
at async Request._execute (/usr/local/lib/node_modules/#bigcommerce/stencil-cli/node_modules/#hapi/hapi/lib/request.js:221:9)
I have tried to re-install big commerce stencil, clean build and still get the same error.... at this point I have no idea what could be causing this issue.
Importantly, there was no code changes in between the day where everything was working and the day where it stopped.
Are you using CloudFlare for a CDN? I've ran into this issue and have had to edit my hosts file
I add the following 3 lines.
The first one is for the Store Domain, i.e. if you have MyShoeStore.com
The second 2 contain the auto-generated store-hash for a BigCommerce store that should be visible in your URL bar if you are on the BigCommerce control panel (Logged into the admin view - that's the easiest way to get it, there are some others)
35.186.223.98 mystoredomain.com
35.186.223.98 store-abcdefg[store-hash].mybigcommerce.com
35.186.223.98 www.store-abcdefg[store-hash].mybigcommerce.com
For some reason, Stencil-CLI gets thrown for a loop when trying to connect to a BigCommerce store that is running behind CloudFlare CDN. This has caused 500 errors in the Stencil-CLI, and a failure to render, during local development, but the store is able to be uploaded and hosted in production without a problem.
I'm not sure if this is the actual issue that you had which caused your 500 error, (It can be due to an error in the syntax of one of the HandleBars templates, but usually Stencil-CLI will output an informative error for that reason.)
The other situation I have seen this in is if you are trying to run Cornerstone on a very old BigCommerce store which is still running their old template framework (Blueprint) - in that situation, certain pages will 500, but others will work.
This may be helpful for others who are running into this.
I installed a proxy tool to capture traffic between stencil and BigCommerce in order to perhaps find more details on this error.
Unfortunately, as soon as I did that, the site worked again...
So I had an SSL certificate, I bought one from a new company, through plesk, I installed the new one and then the website just stopped working completely.
The host company cant help, the developers we have dont know how to get it to work.
We essentially have a very large site crashed due to ssl installation.
There was no error, just a blank page, after turning on error reporting, Here is the error we are getting on the website when we go to the website url
Warning: require_once(): open_basedir restriction in effect.
File(/usr/share/psa-pear/MDB2.php) is not within the allowed path(s):
(/var/www/vhosts/domain.com/:/tmp/) in
/var/www/vhosts/domain.com/httpdocs/inc/general.php on line 7 Warning:
require_once(/usr/share/psa-pear/MDB2.php): failed to open stream:
Operation not permitted in
/var/www/vhosts/domain.com/httpdocs/inc/general.php on line 7 Fatal
error: require_once(): Failed opening required 'MDB2.php'
(include_path='.:/usr/share/psa-pear/') in
/var/www/vhosts/domain.com/httpdocs/inc/general.php on line 7
This started only when we installed the new certificate, changing back to the old one does not work, still the same error on the website
Modify your php.ini's basedir setting to include /usr/share/psa-pear/.
I am using a java raw HTTP client to connect to Shopify API (specifically, using Play Framework with the non-defualt sync driver which is actually the JDK's default driver).
My application usually manages to connect successfully and convert the temporary access token into a permanent one by calling the /admin/oauth/access_token endpoint.
However, sometimes I get this error result from the API:
Generic Error(400)
{"error":"invalid_request"}
I haven't been able to reproduce the issue with my test stores - I've tried installing a fresh store, reinstalling existing stores after uninstalling, I'm not sure why this call sometimes fail and how to debug it. The API call still continues to succeed for some stores using our application.
Some things that I am doing:
Even if the URL of the store is on a custom domain, I'm always using the https://foo.myshopfiy.com/admin/oauth/access_token URL and not the URL of the custom domain, to prevent a redirect.
I am always using an https URL and never an http one, again to prevent a redirect (we noticed a few issues with redirect with the Java HTTP client, so we aim to have zero redirects)
A thread I found about this error suggest possible problems with our SSL certificates, however I don't think this is my problem because some requests work for us, and the result of running openssl on our machine does't show any issues.
How should I proceed? Open a support ticket with Shopify?
FYI, I see that this specific problem only started yesterday on Feb 19 2013, so it might be a temporary issue.
FYI, the problem was caused by reusing a temporary access code.
Our fault - Shopify could have been more clear in their error message though.