Title says it all. I haven't made any major code changes and the debugger is still connecting. However, it isn't listing any files:
Did something change in the Node dev tools to stop these files from showing up? This is all very mysterious and I've seen instances of other developers 'losing' their source folder listings when using --inspect with Chrome Node DevTools.
However, Cmd/Ctrl-P still lists the files and clicking on file names in the logs still takes me to the files (assuming I don't get some mysterious alternate empty version). Why can I no longer navigate my project's file system from Node Debugger on Chrome?
I have checked to make sure that the files are loaded (they are, as you can see, properly running and these particular microservices are responding as expected and pass tests). So I don't think it's an issue with my code.
Related
I'm creating a local web-server in python for web-page testing purposes. While testing the web-page, I get two different results depending on whether I open localhost:8000/index.html or 127.0.0.1:8000/index.html in the web-browser (Chrome).
In the first case, it pulls an older version of the index.js file (from like days-ago old); but the 127.0.0.1 version pulls the correct file. So why would I be getting two different javascript files depending on the source when both are technically from the same directory? Where might I find the days-old file at?
I run the server from the html directory using the command:
python3 test_server.py
Index.html, Index.css, Index.js and test_server.py are the only files located in the directory...
Thanks,
So this is a caching issue. The Python webserver is not even requesting the new js file from a couple days ago was pulled on localhost Whereas the one on 127.0.0.1 was either expired or never pulled, so chrome pulled a new one.
To do a hard pull in chrome, right mouse click and then click on inspect. This opens the dev tools. Now right mouse click on the refresh page button and click on 'Hard Reload'. This will tell chrome to disregard any cached files and instead pull them from the server.
To avoid having to do this each time:
Click on the network tab in the devtools and make sure the box disable cache is checked.
However, be aware this will slow down load times on other sites, because no site will use caching with that box checked. So make sure you uncheck it when you are done doing dev work.
Because SVG-Edit is such a unique and appealing program, I've been searching for an answer to this question for years, but have come up dry.
After a major struggle, I was able to get it to work by installing Windows IIS, then setting up a web server, etc. However, this is far from ideal.
Is there some reason why it won't (or shouldn't) run in a fully standalone/offline mode? Specifically, what I'd like to do is extract the GetHub zip file to a local folder, and open "svg-editor.html" in a browser. In general, this produces either a blank window, or (in some previous versions) a window with various missing items.
There had been a race condition which was causing svgedit to err, evident in Chrome when loading with file:// URLs, and now fixed in the master branch on Github.
You won't be able to load svg-editor-es.html locally from a file:// URL--svg-editor-es.html being the original source which relies on ES6 Modules to load its files but problematic as they are not permitted to load locally, causing origin errors to show in the console), but the svg-editor.html file (which is the backward compatible way to use svgedit) appears to be working now after the fix--at least for some basic functionality like making drawings.
Some functionality may not be possible to work, however, due to limitations related to limited permissions with file:// URLs, e.g., loading some images. (I seemed to recall browsers previously preventing files outside of their directory or child directories from loading files in parent directories, but this restriction does not seem to apply now, though there are some warnings I see about Ajax not being able to load some images which svgedit attempts to load.)
As such, even with the above-mentioned recent fix, it might not be possible to fully work offline, unless perhaps you opt to disable the security restrictions on your browser, something one should not do lightly. But it does appear to work for some basic drawings at least.
While I figure this may address your direct question about why it doesn't work without a server, there is also another approach to working "offline" which, though it would need a server to initially serve the files, may allow svgedit to store the application files to work completely offline the next time you visit that URL in the browser--and not run into problems with browser security restrictions. Browsers nowadays can work offline even when served from a server (done by something called "service workers"--see https://caniuse.com/#feat=serviceworkers for the browsers that support this).
Service workers are, however, not all that easy to cobble together, and though you should be able to track any future progress on this by subscribing to the issue at https://github.com/SVG-Edit/svgedit/issues/243 (as it is already a requested feature), there is no one currently undertaking to implement this at this time. Hopefully someone will be inspired to implement this.
By the way, if you install svgedit using "npm" (a tool which becomes available if you install Node), svgedit has a start script which you can invoke from the command line with npm start from within the svgedit folder, and that will run a local (Node) server for you, specifically a simple static file server which will simply allow you to load svgedit from http URLs (i.e., http://localhost:8000/editor/svg-editor.html or http://127.0.0.1:8000/editor/svg-editor.html; you can also use the ES6 Modules file if you are on a modern browser: http://localhost:8000/editor/svg-editor-es.html )--without your needing to install any other server.
Ok, I have never seen anything like this before and hoping someone else has. I just finished patching our Dev and Test servers to Nov2017CU (SharePoint 2013). Since then, any solutions that are using JS injection from Site Assets are not updating. I'll make a change to the file, the library reflects that I made the change, but when I attempt to load the page accessing the js file, the changes are not reflected. Hard refreshes and full cache cleans are not affecting it. If I close and reopen my editor (VSCode) my changes are gone. When I look at the version history, the current version doesn't have my changes, but the previous version does. If I try to revert to that version, it doesn't take (still shows the previous version of the file).
Here's where it becomes extra weird. I have deleted the entire file from the library. Reset IIS (heck, I even rebooted the server at one time). It somehow still loads the file. The file is no longer in the library, but the server is still serving it up to the browser. I have confirmed it is not getting it from another location as the Dev tools are showing the file is located in the Asset Library the file was deleted from. Even users who have never accessed the site before are still getting that file in their browser.
This isn't limited to a single site either. I have other developers in different sub sites (same site collection) that are having the same issues.
Anyone seen this before?
Looks like your web application has BLOB cache enabled which is causing files to served from the cache.
There are 2 ways to fix:
1) The heavy handed way would be to flush the BLOB cache using powershell commands mentioned:
$webApp = Get-SPWebApplication "<WebApplicationURL>"
[Microsoft.SharePoint.Publishing.PublishingCache]::FlushBlobCache($webApp)
This will flush all the files in the BLOB. Usually, the files are cached based on the max-age attribute value. So, that is the reason that your files are being served even if you had deleted it from the source.
2) The surgical knife approach would be to append a query string, like (https://sitecollurl/siteassets/app.js?v=1.1), to the file references (usually in master page, page layouts, webpart references, script links etc. wherever it is referenced). When you append a query string to the file, it will force the browser to download the newer version of the file. Would prefer this approach as it will not unnecessarily clear other files from BLOB.
I'm using Recorder.js with Meteor for client-side audio recording, and it works wonderfully in development. However, when I run in production, the web worker associated with Recorder throws a syntax error: unexpected token '<'.
I think it has something to do with concatenation of Javascript files in production mode, because the file has already been minified (works in development after minifying). A look at the development console shows,
Resource interpreted as Script but transferred with MIME type text/html: "http://myapp:3000/client/compatibility/recorderWorker.min.js".
I experienced the same errors/issue while trying to implement Recorder.js in Meteor. After fiddling around with it a bit, I have Recorder.js working well in Meteor by performing the following steps:
Move the recorderWorker.js file to your apps /public folder.
Put your recorder.js file anywhere within your apps /client folder.
Open up your recorder.js file and edit the WORKER_PATH variable to
var WORKER_PATH = '/recorderWorker.js';
Use the Sources tab in chrome debugger (or your tool of choice) to see the uglified js file, saved it to disk, and poked around in there. There is probably a de-uglifier available somewhere.
Try loading the ugly file in an editor and poking around. At least that's something...
That file is probably present in the .meteor resources, but I've given up before I found it. The create a bundle for production tool should make that more obvious...
I am tearing my hair out with a file weird file upload issue that I have never run into before. For some reason I’m unable to upload images via the file manager (both in the file manager itself and if I upload with a custom field using the “file” fieldtype). Strangely, if I add files directly to any of the file upload directories, and sync the files, everything works fine.
After selecting the file and hitting “upload file” (see 01_choose_file.jpg) the modal window displays the CP homepage in an iframe (see 02_upload_progress.jpg).
Has anyone else seen this? Does anyone know how I can start troubleshooting this?
Background Info:
I’m running EECMS v2.5.2 - Build Date: 20120606 in MAMP (only 2 out of 15 sites I have set up locally are not working)
I have tried uploading images/files using the latest versions of Chrome, Chrome Canary, Safari, and Firefox (OS X 10.7.5)
This issue is showing up on the two latest sites I’ve started dev’ing locally on, no other site (locally or otherwise)
Things I’ve done:
Checked Apache/PHP error logs; they don’t show anything
Confirmed file upload paths and file upload directory settings are correct – I can sync files that i manually move into the various file upload directories
Permissions are fine; image manipulations and thumbnail creation work fine if I manually add files to the upload directories
Tested various other 2.5.2 installs I dev on locally and they work fine (settings on these two new sites are identical to sites that work)
Only a handful of native add-ons are enabled
“Apply XSS Filtering to uploaded files?” setting Yes or No does not make a difference
Huge thanks for any help!
I can't post images so here are links to the images:
01_choose_file.jpg: http://expressionengine.com/?ACT=51&fid=105&aid=16264_Jiof3p0V1gfEEFrpC55G&board_id=5
02_upload_progress.jpg: http://expressionengine.com/?ACT=51&fid=105&aid=16265_mjGH02xK2fIFZJI6kruP&board_id=5
I have sorted this out. I went back through to make sure I disabled all third party add-ons and I had forgotten to uninstall the "Quickee" extension http://devot-ee.com/add-ons/quickee. For now that seems to be the culprit.
I've submitted the bug to Matt (the developer) and it should be patched up soon.
The ExpressionEngine filemanager sends out a AJAX POST request to the following URL:
http://YOUR_ADMIN_CP_URL?S=0&D=cp&C=content_files_modal&M=upload_file
Have you tried loading that URL yourself? You should get a page like this
But maybe EE is trying to POST to a different URL. You can find it by uploading a large file and while it's uploading using Firebug and in the Network tab at the bottom of the list you will find the URL EE is posting to