I recently added support for HTTP 0.9 to my site. I have access to no browsers that use that protocol, and it’s highly unlikely that anybody is visiting sites with one. Why support it then? It’s not that hard (for me), and it fits with the progressive enhancement related concept that all browsers should be able to use the most basic functionality of a website that they are capable of.
Continue reading post "Supporting HTTP 0.9"site posts page 3
I spent numerous hours looking into what appear now to be separate gzipping issues / non-issues with my site.
Continue reading post "#1724"Apparently, I had some short_open_tags in some examples on my site, but didn’t enable that setting when switching to my new server.
I’ve started to play with Dreamcompute (basically Dreamhost’s unmanaged VPS solution). The plan is to move my sites from shared hosting over to that before my next shared hosting bill is due.
Continue reading post "#1501"Ideas: Remotely hosted personal site with home data store that syncs as client
This idea is based on my Local + Proxy Remote Hosting for Personal Site idea, but attempts to mitigate some of its problems further.
Continue reading post "Ideas: Remotely hosted personal site with home data store that syncs as client"Blogs moved and merged
This weekend, I moved my wordpress.com “professional” (web development) blog and my “personal” blog both to my main website and merged them together. I had been planning on moving my blog from wordpress.com for a while, but recent problems with writing posts with code blocks pushed me to finally take the plunge. I’ve also been feeling like maintaining a separate personal and professional site might be more trouble than it’s worth. I do worry that the different sort of audiences that would go to the one wouldn’t want to see the content from the other and vice versa. I might be less inclined to write some personal stuff on my professional blog. But I think I will be able to find ways to mitigate those issues and make it work well.
Both sites are now redirecting to my main site. I had to pay wordpress.com ($13 a year) for the privilege, but I think it is worth it considering the “link juice” I have with that blog. I will probably continue paying for at least several years. With the use I’ve gotten out of WordPress so far, they’ve probably earned it.
There are still some things to fix:
- The content imported from my professional blog didn’t bring over the markdown formatting, and thus all of the code blocks are messed up. I am going to have to manually copy them over one by one from the wordpress.com admin as far as I can tell. A pain.
- I accidentally deleted all of the media files imported from the wordpress.com due to the way I deploy my site. I’m going to have to reimport on a local install and upload, then make sure my deploy ignores that directory. Hopefully the redirect I set up doesn’t cause problems for this.
- There is plenty of non-blog content on my personal site that I will need to move to my main site. I don’t have any real “link juice” with that site, so I can move things wherever I see fit or not copy it at all if it doesn’t seem worth keeping.
- The theme is just a slightly modified ‘twenty fifteen’. I’m going to have to decide what I want to do with it to better integrate it into the rest of my site.
My eventual plans are to move my blog out of WordPress and into the same system I’m using for the rest of my site. I may lose some things in the process, including possibly my connection to the WordPress project, but I will gain control.
I had a number of problems during my move, but am way too tired to write about them currently. Hopefully they’ll make for a few posts this upcoming week.
Command-line weather with wttr.in
Cool, lightweight, and simple ASCII weather forecast site that can be curled: wttr.in. It does user-agent sniffing to show plain, colored text for curl, wget, and the like so that it looks nice on the command line, while browsers get HTML with a similar appearance. The “home page” does IP lookup to guess your location. Results of curl wttr.in/cleveland:
XHTML version of my pages
Continuing in the interest of providing multiple file formats for my web pages, I now have my home page available in XHTML5 format. URL’s just need .xhtml tacked on the end, except for the home page, which needs index.xhtml. This makes use of Symfony’s _format URL parameter.
Symfony 3.0 has finally been released. I hadn’t even noticed for almost a week. It took some time, but I’ve updated my boilerplate and related bundles to use it. I then updated my site. I haven’t delved too far into 3 yet, but I like the new directory structure and profiler / dev toolbar.
Websites in Multiple File Formats
Since I saw Symfony’s _format routing parameter, which is used to effectively set the file type of the response, I’ve thought it would be cool to have every page on a website support more than just ‘html’ response types by adding a .{_format} to the end of the URL and make a template version for each. Users would be able to consume the same information in different formats depending on their needs. ‘txt’, for example, would basically have just the content that would go in the “ element, in pure text format, providing a fallback or simplified view that can be read even by curl users. ‘json’ or ‘xml’ formats might provide the content and meta data about it in a machine consumable format. You could even go all out with an ‘mp3’ format where you read the page content.
Yesterday, I took my first step toward this idea on my site by implementing my homepage in the ‘txt’ format. This was very simple since my content is already being composed in markdown, a visually pleasing structure for text content.
Obviously, adding more pages and formats will add development time. This probably wouldn’t be useful enough to be worth it for a normal site, but for my own site, I get to play with whatever cool ideas I want.