Log in to your Managed Hosting Server via SSH
Add these two lines to .bashrc:
<html> | |
<head> | |
<script src="http://code.jquery.com/jquery-1.9.1.min.js"></script> | |
</head> | |
<body> | |
<iframe id="frame" style="width: 250px; border: solid 1px red;" ></iframe> | |
<script type="text/javascript"> | |
var elFrame = $('#frame')[0]; | |
$(elFrame.contentWindow).resize(function() { | |
$(window).trigger('zoom'); |
var gulp = require('gulp'), | |
sass = require('gulp-sass'), | |
rename = require('gulp-rename'), | |
cssmin = require('gulp-cssnano'), | |
prefix = require('gulp-autoprefixer'), | |
plumber = require('gulp-plumber'), | |
notify = require('gulp-notify'), | |
sassLint = require('gulp-sass-lint'), | |
sourcemaps = require('gulp-sourcemaps'); | |
// Temporary solution until gulp 4 |
// UPDATE: In 2023, you should probably stop using this! The narrow version of Safari that | |
// does not support `nomodule` is probably not being used anywhere. The code below is left | |
// for posterity. | |
/** | |
* Safari 10.1 supports modules, but does not support the `nomodule` attribute - it will | |
* load <script nomodule> anyway. This snippet solve this problem, but only for script | |
* tags that load external code, e.g.: <script nomodule src="nomodule.js"></script> | |
* | |
* Again: this will **not** prevent inline script, e.g.: |
The following will guide you through the process of enabling SSL on a Apache webserver
Create a directory within /etc/apache2/
using Terminal.app: sudo mkdir /etc/apache2/ssl
Next, generate two host keys:
You probably arrived here because of a curt message in response to an issue you filed on a repo that I contribute to. Sorry about that (particularly if you filed the issue long ago and have been waiting patiently for a response). Let me explain:
I work on a lot of different open source projects. I really do like building software that makes other people's lives easier, but it's crazy time-consuming. One of the most time-consuming parts is responding to issues. A lot of OSS maintainers will bend over backwards to try and understand your specific problem and diagnose it, to the point of setting up new test projects, fussing around with different Node versions, reading the documentation for build tools that we don't use, debugging problems in third party dependencies that appear to be involved in the problem... and so on. I've personally spent hundreds of hours of my free time doing these sorts of things to try and help people out, because I want to be a responsible maintainer and I