plyr.js instantiation causing 503 error in production - javascript

I'm instantiating plyr.js using their beta (3.0.0) in elixir/phoenix and I'm getting these errors
"Failed to load resource: the server responded with a status of 503 (Service Unavailable)"
This prevents me from scrolling on the page at all
for whatever reason if I don't include the Plyr instantiation in the JS files, the 503 error goes away. Anyone have any idea why this occurs?
Here is the JS code:
import Plyr from 'plyr';
(function() {
document.addEventListener('DOMContentLoaded', function() {
const plyr = new Plyr('#player', {
autoplay: true,
controls: [''],
fullscreen: {
enabeled: false
},
loop: {
active: true }
});
});
})()

Looks like the fact that this is in beta makes this a legitimate bug. It has been filed to Github.
For now the developers of Plyr recommend using v2 for production

Related

Failed to load resource (file not found) Electron js cannot import or export

Failed to load resource: net::ERR_FILE_NOT_FOUND
I am using latest version of npm, node.js and electron.
My html file calls upon a terrautils.js:
<script type="module" src="./terrautils.js"></script>
My terrautils.js file has first line as:
import { LCDClient, Coin } from './node_modules/#terra-money/terra.js';
Which is the link to an npm module that I want to use, and I have it installed and have confirmed that the folder is really there using file explorer. I also know the module works perfectly file, because this issue only happens when I run using npm start but when I run using node terrautils.js and swap from using import to using require, it works perfectly fine.
This is something to do with electron I think, and not sure what to do. My main.js has createWindow function like:
function createWindow (site) {
var win = new BrowserWindow({
width: 700,
height: 600,
webPreferences: {
preload: path.join(__dirname, 'preload.js'),
nodeIntegration: true,
contextIsolation: true,
devTools: true,
}
})
win.loadFile(site)
}
I do not care about security, I just want this to work. Thank you.
Solution:
Change html invoking of the js file to this instead:
<script>
require('./terrautils.js')
</script>
dont know how it works, but it does.

Electron + Vue API requests fall to app://

I've built a Vue app and added Electron to it. I used Vue CLI Plugin Electron Builder
It's ok in development mode, all API requests fall on address which is written in my vue.config.js:
proxy: {
'^/api': {
target: 'http://my-api:3000',
changeOrigin: true
},
},
For example, Axios POST request /api/open_session/ falls to http://my-api/api/open_session as needed.
When I build the project it creates an app:// protocol to open the index.html file.
But it also makes all url paths beginning with app:// including API requests.
My background.js:
if (process.env.WEBPACK_DEV_SERVER_URL) {
// Load the url of the dev server if in development mode
await win.loadURL(process.env.WEBPACK_DEV_SERVER_URL)
if (!process.env.IS_TEST) win.webContents.openDevTools()
}
else {
createProtocol('app');
// Load the index.html when not in development
win.loadURL('app://./index.html');
}
I want these paths to be directed to my API, while open all my files as usual (via app protocol)
Well, it's been a longer time and I coped with that on my own. However, here's an answer I came across some forums for those who are struggling with the same issue:
Firstly, I modified my vue.config.js:
proxy: {
'^/api': {
target: 'http://127.0.0.1:3000',
changeOrigin: true
},
},
Then, I made some changes in main.js - added a session variable:
const sesh = session.defaultSession.webRequest.onBeforeSendHeaders({
urls: ['*://*/*']
}, (details, callback) => {
// eslint-disable-next-line prefer-destructuring
details.requestHeaders.Host = details.url.split('://')[1].split('/')[0]
callback({
requestHeaders: details.requestHeaders
})
})
that defines app's behavior when requests get called. Also, I've added a session value to webPreferences:
const win = new BrowserWindow({
width: 1500,
height: 700,
title: "Title",
webPreferences: {
session: sesh,
nodeIntegration: true,
webSecurity: false
}
})
And, finally, load my index.html via app protocol
createProtocol('app');
win.loadURL('app://./index.html');
In result, all my requests got redirected to my server.
Forgive me for not knowing the source, if the author of the code is reading this, you can surely mark yourself in comments :)

service worker registered when serving locally, but doesn't work online

I built a PWA with Vue, and for some reason when I try and deploy it online, I get this error message in the console:
service-worker.js:168
Uncaught (in promise) Error: Request for https://example.com/dist/service-worker.js?_sw-precache=935625ad5331efd775a1f6b37f06e3e3 returned a response with status 404
at https://example.com/service-worker.js:168:25
at async Promise.all (index 1)
I'm thinking that the problem is that service-worker.js is being fetched from example.com/dist/service-worker.js, which does throw a 404 error when I try to access it. The right path is example.com/service-worker.js.
I am using render.com for my hosting and I've set the Publish Directory to /dist, since that's where the built files are outputted.
This is the content of registerServiceWorker.js:
/* eslint-disable no-console */
import { register } from 'register-service-worker'
if (process.env.NODE_ENV === 'production') {
register(`${process.env.BASE_URL}service-worker.js`, {
ready() {
console.log(
'App is being served from cache by a service worker.'
)
},
registered() {
console.log('Service worker has been registered.')
},
cached() {
console.log('Content has been cached for offline use.')
},
updatefound() {
console.log('New content is downloading.')
},
updated() {
console.log('New content is available; please refresh.')
},
offline() {
console.log('No internet connection found. App is running in offline mode.')
},
error(error) {
console.error('Error during service worker registration:', error)
}
})
}
When I build and serve the app locally, it works fine, and I can install it without any problems. I don't know how I can change things so the service worker is fetched from example.com/service-worker.js instead of example.com/dist/service-worker.js, which is an invalid path.But I'm not an expert on this so I'm not sure if this is even the problem.
I used sw-precache to generate the service worker.
I have looked at other questions with similar titles, but most of the comments or answers say to use HTTPS otherwise it won't work, but I am using HTTPS, so they don't solve my problem.
Thanks in advance
I used workbox to generate my service worker and it works fine now.
https://developers.google.com/web/tools/workbox
// workbox-config.js
module.exports = {
"globDirectory": "dist/",
"globPatterns": [
"**/*.{css,ico,svg,png,xml,html,js,json,txt}"
],
"swDest": "public/sw.js"
};
// vue.config.js
const {GenerateSW} = require('workbox-webpack-plugin');
module.exports = {
pwa: {
name: 'Name',
themeColor: '#fff',
msTileColor: '#fff',
appleMobileWebAppCapable: 'yes',
appleMobileWebAppStatusBarStyle: 'black',
// configure the workbox plugin
workboxPluginMode: 'GenerateSW',
workboxOptions: {
swDest: 'sw.js',
}
}
}

Winston only writes to Console, does not successfully log anything to my log file

I am using NodeJS/React/Express/winston in conjunction. Here are the versions:
react & react-router-dom: 15.6.1
express: 4.15.3
node: 8.4.0
npm: 5.3.0
winston: 2.3.1
express-winston: 2.4.0
I instantiate my logger as such:
var logger = new (winston.Logger) ({
transports: [
new(winston.transports.File) ({
filename: 'log.txt',
handleExceptions: true,
prettyPrint: true
})
], exitOnError: false
});
I have created log.txt so the directory and file both exist.
At this point, I can go to my server and everything renders successfully as before.
If I add any calls to my logger, such as:
logger.info("Hello World!");
my application no longer renders, however I do not see any errors in the Console.
I have tried this as well with express-winston to log middleware requests which has the same outcome: logging works in the console for express-winson, but not when I want to write to an external file.
I just cannot seem to locate the source of this problem, it has absolutely baffled me. Please let me know if you see any red flags or have suggestions for how to debug this problem. Thank you very much for your time and help!
****** UPDATE ******
I have found that if I use:
try {
logger.info("hello");
}
catch(e) { alert(e); }
I get this message:
TypeError: fs.stat is not a function
I cannot find anything online that can fix this. Please advise

Dojo RequireJS 404 error handling from thirdparty URL

I have a dojo require as
window.config= {
async: false,
paths: {
'thirdParty' : 'https://s3.amazonaws.com/thirdPartyJSSrc'
}
};
In Page Javascript I am using thirdParty as
require([
'thirdParty'
], function(){ });
Now if my thirdPartyJSSrc returns 404 the other buttons handlers from JS is not working..It is showing the following error
Failed to load resource: the server responded with a status of 404 (Not Found)
Error {src: "dojoLoader", info: Array[2], stack: (...), message: "scriptError"}
Because of this error no JS is working on other elements of page..
I don't want to include the JS if particular JS returns 404 on the page..Anyway to do this?
I suggest config your dojo with dojoConfig, see documentation here.
e.g
dojoConfig = {
baseUrl: "js/",
packages:[
{ name:"dojo",location:"//ajax.googleapis.com/ajax/libs/dojo/1.10.0/dojo/"},
{ name:"dijit", location:"//ajax.googleapis.com/ajax/libs/dojo/1.10.0/dijit/"},
{ name:"dojox", location:"//ajax.googleapis.com/ajax/libs/dojo/1.10.0/dojox/"},
{ name:"thirdParty",location:"https://s3.amazonaws.com/thirdPartyJSSrc"}],
parseOnLoad : true,
async : false,
isDebug: true,
locale: 'en'
};
I should you to use "dojo/has" for test if exist your "thirdParty" JS. The dojo/has module is Dojo’s feature-detection API. It provides a simple, consistent, and easily extensible approach for evaluating existing feature tests, and for creating your own custom feature tests. dojo/has also implements the AMD loader plugin API, which allows you to use it to conditionally load modules. See "Dojo FAQ: How can I conditionally load AMD modules?" for more detail.

Categories