My squarespace site is in developer mode. I download files, like the .region, .less, and .conf files and edit them locally. I upload these files and expect to see a change on the squarespace site.
Up until yesterday this was working, then I made a mistake in one of the LESS files and got an error about incorrectly parsed JSON in the .conf file where the LESS file was included. I got a whole ton of errors from this, and have since then fixed both the LESS file and the .conf file.
However, the issue is that my squarespace site is now not registering that any changes have been uploaded, despite the fact that my FTP files are successfully being uploaded and downloaded from the FTP server.
I have also not seen any updates to my Git on the developer mode tab since this error was registered.
My question is how to fix this, and how to start seeing edits done locally to region, etc, files again.
You can try to turn off the developer mode and then turn it on back.
Related
I used to use Dreamweaver. I've a huge Classic ASP website. I edit the files on my local system, and when done, I can upload the file(s) via ftp to the remote webserver. Now, I try to switch to VSCode. I've installed ftp-simple, ftp-sync and deploy. But can't find the set-up to get a Dreamweaver like behaviour. Eg, I have to locate for each file I want to upload/deploy, the exact location in the remote file tree.
I really feel like deploy deserves more attention. I spent the past 4 days or so to find an extension that does just that. Auto-upload to an ftp-folder from a local folder. I wanted to make git work for my website, but couldn't get that to work on the server with ftp-simple or ftp-sync because those extensions only download the opened files or open in a different temporary folder each time. I set up deploy now and got exactly what I wanted thanks to your tiny comment, thank you!
(I'm sorry if this post is too old to comment on, but I browsed Stack overflow for days to find this, so I thought it might help others in the future to point this out.)
it sounds like your just missing your mapping configuration. Most text editor FTP packages include a configuration file where you specify the server, your credentials, and the root folder of your ftp server. Have you specified this?
I use CodeAnywhere as an IDE. It's been working great for me. All the sudden, I logged in and was unable to view any folders in any of my projects. All it shows is a blank HTML file. I'm at my wits' end and CodeAnywhere's support is utterly useless.
Any guidance would be appreciated.
CodeAnywhere Screen Shot
From your screenshot I can see that you're accessing via FTP all those servers/folders, is that correct?
Have you tried accessing these servers with other ftp tools, like filezilla? And if so, the files are still there?
I've had a similar problem while configuring a new FTP connection, where the Initial dir I entered was blocked to the Username I was using to connect, thus showing a blank connection. I recommend double checking the configuration you're using and also making sure the files you're trying to find are still there, with filezilla or another ftp tool.
We are creating a SCORM package (zip) and uploading to our Blackboard test instance and if one developer (will call him Bob) creates the zip and uploads then all everything works great. Myself and one other developer have packaged up the zip and uploaded it and a particular js file gets a 404 ("The specified resource was not found, or you do not have permission to access it") error when we try and run the application.
If Bob sends me his zip and I upload it to Blackboard it works fine and if I send Bob my zip and he uploads it then it fails, so I am pretty certain that is is an issue of the zip creation. I have looked at the zips and they look identical in terms of file structure.
3 questions:
Is Blackboard known to have particular problems with zip details? These do look like valid zip files.
Are there logs in Blackboard that describe the unzipping process that Blackboard uses when it installs a new SCORM package?
Is there a way to look at the deployed files/dir structure of a deployed SCORM package?
I am relatively new to Blackboard so if I missed something obvious I apologize.
I don't know any specifics about Blackboard's SCORM handling, but if your ZIP is smaller than 100MB you can test it for free at SCORM Cloud. They have a really great parser that will alert you if there is anything unusual or malfunctioning in your SCORM package. It will also let you inspect the package contents.
If it's just the one file that throws the 404 or 403, I'd check the security settings on the file. If they're too restrictive, the file may be physically present in your ZIP, but blocked from rendering by the server (hence 403) or maybe even blocked in the initial upload by the LMS (hence 404) due to insufficient privileges. I've had this happen a few times, typically on files that I downloaded from the interwebs (esp via Chrome's "Save As" file menu option) or on files I received from others.
If you're on a Mac and not a Terminal/chmod kind of guy, the easiest fix is to apply the containing folder's permissions to all enclosed items. ("Get Info" on the containing folder, then click the lock at the bottom of the Get Info window, then click the cog drop-down menu and select "Apply to enclosed items".)
We discovered that it was a path casing issue; on one of the machines the working copy of the file in question had a mix of upper and lower case in it's name and the script tag that referenced it had an all lower case path. We suspect, but can't be certain, that the server where we are running on received an update that made the http requests path case sensitive. But it may have been that way all along and one of us devs messed up out file names.
I am in an interesting situation where I maintain the code for a program that is used and distributed primarily by our sister company. We are ready to distribute the program to all of the 3rd party users and since it is technically our sister companies program, we want to host it on their website. (in the interest of anonimity, I'll use 'program' everywhere instead of the actual application name, and 'www.SisterCompany.com' instead of their actual URL.)
So I get everything ready to go, setup the Publish setting to check for updates at program start, the minimum required version, and I set the Insallation Folder URL and Update Location to "http://www.SisterCompany.com/apps/program/", with the actual Publishing Folder Location as "C:\LocalProjects\Program\Publish\". Everything else is pretty standard.
After publish, I confirm that everything installs and works correctly when running directly from the publish location on my C: drive. So I put everything on our FTP server, and the guy at our sister company pulls it down and places everything in the '/apps/program/' directory on their webserver.
This is where it goes bad. When I try to install it from their site, I get the - File, Program.exe.config, has a different computed hash than specified in manifest. Error. I tested it a bit, and I even get that error trying to install from any network location on our network other than my local C: drive.
After doing the initial publish in visual studio, I have changed no files (which is the answer/reason I've found by doing some searching about this error).
What could be causing this? Is it because I set the Installation Folder URL to a location that it isn't initially published too?
Let me know if any additional info is needed.
Thanks.
After bashing my head against this all weekend, I have finally found the answer. After unsigning the project and removing the hash on the offending file (an xml file), I got the program to install, but it was giving me 'Windows Side by Side' Errors. I drilled down into the App Cache were the file was, and instead of a config .xml file, it was one of the HTML files from the website the clickonce installer was hosted on. Turns out that the web server didn't seem to like serving up an .XML (or .mdb it turns out) file.
This MSDN article ended up giving me the final solution:
I had to make sure that the 'Use ".deploy" file extension' was selected so that the web server wouldn't mangle files with extensions it didn't like.
I couldn't figure out why that one file's hash would be different. Turns out it wasn't even the same file at all.
It is possible that one of the FTP transfers is happening in text mode, rather than binary?
For me the problem was that .config transformations were done after generating manifest.
To anyone else who's still having trouble, five years later:
The first problem was configuring the MIME type, which on nginx (/etc/nginx/mime.types) should look like this:
application/x-ms-manifest application
See Click Once Server and Client Configuration.
The weirder problem to me was that I was using git to handle the push to the server, i.e.
git remote add live ssh://user#mybox/path/to/publish
git commit -am "committing...";git push live master
Works great for most things, but it was probably being registered as a "change," which prevented the app from installing locally. Once I started using scp instead:
scp -r * user#mybox/path/to/dir/
It worked without a hitch.
It is unfortunate that there is not a lot of helpful information out there about this.
I made a modification in a php file and uploaded it via Filezilla. It always worked fine for me, even if sometimes it would not upload immediately. This time, however, it's not working anymore in any way. I upload the file with the same name and it looks like it overwrites the old one, but the size of the file doesn't change. When I open the site on the browser (I've been testing in Chrome and Firefox and already cleaned their caches many times since then, and still nothing happens) and look at the source code, it shows the new code with the modification, but even so the site is still the same old one. When I open the file directly from Filezilla it also shows the modified file, but the file size doesn't change. It started yesterday, before the upgrading to version 3.7.3. It's updated now, but the files are still not being updated. I also tried renaming the file, deleting it from the ftp and uploading again, uploading it to another folder and then moving it to the root, but nothing happens. Any idea of what can be causing this?
It turns out it was a problem with the permissions with the host. I contacted them and the issue was solved.