Nanoc - compile output different to nanoc view - nanoc

If you create a new nanoc site, and then run nanoc view, it works well. The CSS, pathing, and assets are correctly handled. However, when I run a nanoc compile, it's not handled the same way. I get broken CSS, broken paths etc.
What is causing this - I assume it's the rules and

Compile only generates files in /output. Opening one of the html files there is possible, but as the docs state, your browser will not be able to find the CSS files.
Either use nanoc view to load CSS files correctly, or use a local web server to view the files. (Note: nanoc view is nothing more than a local web server).

Related

I'm using tailwindCSS for a simple html site but deployment on netlify does not work, why?

I've been learning how to use tailwind css by following the offical video tutorial and I just wanted to try to deploy the site example to Netlify to see if it works using the drag and drop feature.
This means taking the entire project folder and dumping it into netlify. This usually works with vanilla html css js sites but for some reason I get the error
Page Not Found Looks like you've followed a broken link or entered a URL that doesn't exist on this site.
This is how the project structured looked like:
What am I doing wrong? Inside the build folder there is another file called tailwind.css
On your Netlify dashboard, change the publish directory to the directory where your index.html file resides: public/. That should do it.
You can also, as you said, take everything out of the public folder and put it at the same level as the other folder and files, which makes the index.html available at the root of the project. However, then you lose your project's file organization.
I've fixed the problem.
The trick was to take everything out of the public folder and put it at the same level as the other folder and files.
This would make the index.html file available at the root of the project and would allow the site to work properly once deployed.

IIS suddenly refuses to serve PDF or RTF files; still serves DOC files

Yesterday everything was working just fine but now today when I try to access a PDF or RTF file served by IIS, I get a 404 error (when accessing it through HTTPS) or a 403 error (when accessing it through HTTP). I can still access DOC files hosted by this server. What could have possibly changed to prevent the PDF and RTF files from loading? They are being generated properly in a folder that belongs to a virtual directory being requested.
Looks like I had two similarly named folders and the files were being written to one folder and read from the other, which of course did not contain them because they were actually in the first folder. Fixing this issue solved my problem. Must have goofed up a configuration setting somewhere that this broke...

Mime type error with Meteor and Recorder.js Web Worker in Production Mode

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...

Publish Web App files to different locations

I'm start to develop modules for DotNetNuke. I followed different tutorials(most by Chris Hammond) but there is something i don't like, and I'm searching a different way to do so.
He recommends to put a DotNetNuke installation, with IIS and SQL Server, on the developer PC and put your Project into the DesktopModules folder. I don't like it because i want to separate my project from DotNetNuke.
Is there a way to split the build/publish to different location like dll into folder x and all other stuff into folder y?
You could, but I don't really see the point. I see where you're coming from because it seemed awkward to me at first as well, but it really is the most efficient way to develop on the DNN platform. I have mine set up so all of my modules are in the same solution and branched in source from the root DNN folder. We don't keep the DNN core in source so the developer is responsible for that, although that may change at some point to keep versioning consistent.
By keeping your project located where it's installed, you can develop your modules the same way you'd develop any other web app you're building. If you make a change in markup you just have to save the file and refresh your page. If you change something in code just build and refresh.
If you really must keep them separate, you can absolutely do so (really the only benefit of this that I can see is that if you uninstall a module and accidentally click the checkbox to delete files - it happens - you don't have to worry about it). Create your project where you want it, change the Output Path to your DNN bin folder, and create post-build events to copy all of your .js, .ascx, and .css files (plus any others you may need - images, HTML files, XML files, etc.) to appropriate folder(s) in the DesktopModules folder. Just remember that you have to build the project every time you make ANY changes to test them, and you have to write/change your post-build events every time you add a new type of resource, change/add a directory, etc.
Either that or you can build an install package and uninstall/reinstall the module every time you change some padding in your stylesheet ... but I'd stick with keeping the project in the DesktopModules folder.
Sure you can do that.
Set up your solution and module projects anywhere, build the projects and copy the appropriate parts (such as the *.ascx , *.ascx.resx, *.dnn files) back to your website folder -
website/ DesktopModules/Your_module_name
Copy the module dll to the website's bin and you good to go.

Coldfusion security issue...how to hide directory of files?

So, I decided to try to break my website...I googled my site by typing in site:mysite.com/whatever and behold, all of the users uploaded files were available for view under a specific directory.
What kind of script/ counter measure should I use to block these files from being viewed? I already have a script that checks the path and the logged in status, however this doesn't seem to be working. I've looked all over for solutions...but I can't quite find one. I'm using ColdFusion 8.
This isn't a ColdFusion issue so much as a web server configuration issue.
You should either:
configure your web server not to show a directory of files when using a URL without a filename (e.g., http://www.example.com/files/)
drop a blank default web document (index.html, index.htm, default.htm, index.cfm, whatever) into that directory so that it displays that document rather than the list of files. If you use index.cfm, it'll fire your Application.cfm/cfc in your file path and use whatever other security you've built.
(or, better, do both)
The best way to secure your file listings and the files themselves is to store them in another folder outside of the Web site root folder. You can then serve them up using CFDIRECTORY and CFCONTENT. The pages that display the files can check your access controls and only serve the files to those allowed to see them.

Resources