@badkins has joined the channel
@badkins set the channel purpose: A channel for Frog users to communicate/collaborate.
I’ve decided to use https://github.com/greghendershott/frog\|Frog for my personal and professional blogs, so I thought it would be convenient to have a channel for Frog users to communicate.
I’ve moved the personal blog over, and my current nginx config is the following. In particular, the rewrite rule in the “listen 443” block transforms the old Wordpress URL into the new static .html URL. server {
listen 80;
server_name <http://blog.example.com\|blog.example.com>;
rewrite ^(.*) <https://blog.example.com>$1 permanent;
}
server {
listen 443 ssl;
server_name <http://blog.example.com\|blog.example.com>;
root /home/deploy/sites/blog;
index index.html;
rewrite ^(.+)/$ $1.html permanent;
try_files $uri $uri.html;
ssl_certificate /.../blog.example.com.crt;
ssl_certificate_key /.../blog.example.com.key;
ssl_session_timeout 5m;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers 'EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH';
ssl_prefer_server_ciphers on;
ssl_session_cache shared:SSL:10m;
}
I was pleased to discover that I could organize my _src/posts/ directory with a sub-directory per year, and Frog will process the entire tree as I was hoping. For example: _src/posts/2007
_src/posts/2008
etc. with: _src/posts/2007/2007-12-01-crayon-physics.md
...
It appears the URLs for the RSS/Atom feeds are slightly different between Wordpress and Frog, so my next task will be an nginx rewrite rule to handle that.
@spdegabrielle has joined the channel
Hmm… just got a 500 error w/ the above nginx config. I commented out the rewrite and try_files directives in the second server block to resolve it, so I apparently got those wrong.
The problem was the try_files , possibly in combination with the rewrite above it.
The Wordpress URLS seem to always end in / as in .../my-blog-article/, and the rewrite handles that. I wasn’t sure if there might also be back links w/o the trailing / as in .../my-blog-article, so the try_files was an attempt to also rewrite those. I’m thinking URLs w/o the trailing / probably don’t exist in the wild, so I’ll just skip it.
This is really strange. Twice today I had support files magically deleted while going through the blog workflow. First it was .css files in the /css directory, then later on it was all of the .js files in the /js directory. I have no idea what series of commands caused this to happen, but I’ll be looking at my git status more closely moving forward, and maybe I can identify what caused it to happen.
@yfangzhe has joined the channel