Hypertext
Warning: Undefined variable $category_id in /home/juanmonr/juanomatic.net/wp-content/themes/monroy2014/category.php on line 7
I don’t know how long this will last, but I managed over the last few weeks to get my email inbox to zero messages. That means that I have responded to, completed, filed, or deleted every message in my email inbox. Did someone invite to an event? It’s now in my calendar. Did you ask me to do something? It’s now in my task manager of choice OmniFocus. Did I get a marketing message or invitation to a conference I can’t afford to attend? It’s the trash for you.
Speaking of OmniFocus, it now shows a ton of items I have to complete. I better get cracking.
After having some trouble with incorporating the WordPress comments into my hand-crafted WordPress theme, I have installed Disqus. It was really easy to incorporate, not because I used the WordPress plug-in, but instead I just added the HTML and Javascript code to my theme.
Perhaps, I will figure out a way to reintroduce WordPress comments back to my theme, but let’s see how this works for a while.
Although I have only received forty comments over the last four years, I am letting everyone know that the comments on each individual blog post are unavailable. Until I figure out how to write a proper comments.php template and incorporate it into various templates, no comments will be displayed.
At the moment, I am considering closing discussion on this site, since there seems to be very little happening anyway. But then I reconsider this rash decision when think about some of the thoughtful comments I have received in the past, especially on technical topics such as a partial FiOS outage in Long Island City and Greenpoint and the finer points of fixing a MacBook Pro logic board.
For quite some time, I have been using web fonts from TypeKit on this website. Being as miserly as I am, I kept using the free Trial plan that only allowed me to use two fonts on a single website. Since I run another website, I resorted to using two very lovely TypeKit fonts on this blog and using somewhat uglier Google Web Fonts on the other one. I had been tempted to upgrade to a paid plan—the Personal plan offers up to five fonts on two websites—but when Adobe bought TypeKit, paying for a plan was suddenly less urgent.
Since my web traffic has been climbing over the last few months, I decided that I could splurge on the TypeKit Personal plan for both websites. It would allow me to have a larger selection of fonts at my disposal for this site and my professional site.
Here are the fonts I chose and how I am deploying them.
The Professional Site
For two semesters, I had been using Adobe’s "Source Sans Pro," a font that Adobe had released as open source. The font is very versatile and was well suited for both paragraphs and headings. Until yesterday, this site used only this single font.
Starting now, I am using Tablet Gothic Wide by TypeTogether for the headings on the site. The "paragraph" font, which is a bit of a misnomer because I am also using for lists, footers, and certain headings, is Museo Sans by exljbris. I have always liked the look of this font since the Film Society of Lincoln Center began using it for their site. It also makes a nice substitute for the ubiquitous Gotham.
The Personal Site
I am using three fonts on this site. For as long as I can remember, I have been using Depot New Web by Moretype for the headings, and even today, I have yet to tire looking at it. Even with upgrading to the Personal plan, I remain committed to using it. Since it looks so nice on my professional site, I am using Museo Sans for the paragraphs on this site, too. Since I occasionally use monospaced text for code, I have selected Anonymous Pro by Mark Simonson Studio.
Although I really like the way that these fonts look on both sites, I still have the flexibility to tweak the look by selecting a different font. For example, I really like Franklin Gothic but it doesn’t come in a 100 italic weight. I need a native italic for the paragraphs because I italicize a fair amount of text.
Since I switched over to WordPress for managing this website in 2009, I have been using an even older platform for sharing my photos: Gallery. Although it took a lot of tweaking, I managed to get WordPress and Gallery to work nicely via a plugin called WPG2, which I am pretty sure is deprecated by now.
Using WPG2 as “middleware” between WordPress and Gallery 2 has made it really easy to embed an image in a blog post. All I have to do is add a bit of shortcode. The code is based on Gallery’s own item number for an image. For example, the image located at http://juanomatic.net/photos?g2_itemId=47586 has an item number of 47586 . To embed this image into a post, I simply include WPG2’s own <wpg2> and </wpg2> wrapper around the Gallery item number.
<wpg2>47586</wpg2>
When added to a WordPress post, the code above will call the appropriate image from Gallery and display it according to the size stipulated in Settings > WPG2 > WPG2 Tags. In my case, I’ve set everything to 500 pixels to allow landscape-oriented images to take up the entire width of the content area, but you can set it anything you want.
However, given the increasing size of my photo gallery, which is now approaching five gigabytes, the fact that both Gallery2 and WPG2 are by now pretty old, I pay for a Flickr Pro membership, and having my Flickr images on served via WordPress.com can produce retina-caliber images, I am tempted to migrate from Gallery to Flickr. Both WordPress and Flickr natively support oEmbed, a pretty common way to share content, with only requiring a simple URL. That makes it possible to include in a WordPress post, something like this to embed an image in a post:
http://www.flickr.com/photos/juanomatic/8424712368/
oEmbed works with several popular platforms, such as YouTube, Vimeo, Slideshare, Soundcloud, and many more. When I try to embed a Flickr image inside of a WordPress post, it generates an image, as one would expect, however, it is not the 500 px size I want.
As you can see, the image is only 320 pixels wide. That’s because when WordPress makes an oEmbed request from Flickr, it sends three (maybe four) pieces of information.
- the URL of the Flickr page where the interesting content (i.e., my image) lives;
- the maxwidth of my theme so that Flickr provides a right-sized image;
- the format of Flickr’s response. WordPress and most others prefer JSON but XML is also common.
- It might also send the maxheight of my desired content, which I understand WordPress defines as 1.5 times the width by default.
My theme does not actually specify the width of the content because in previous versions of WordPress, the user had to specify desired sizes of embedded content in Settings > Media. However, since WordPress 3.5, you now have to add a function that specifies the content_width. To comply with the requirement, I added the following to my child theme’s functions.php file:
if ( ! isset( $content_width ) ) $content_width = 500;
Looking around the wp-includes/class-oembed.php file in my WordPress installation, it appears that when WordPress makes an oEmbed request, it uses the content_width value for the value of maxwidth. Since I added that value to my WordPress theme, the request should be for an image from Flickr with a maximum width of 500 pixels. Flickr actually natively resizes images to 500 pixels, among a variety of other sizes, for viewing on their website. For oEmbed, however, it only serves a 320-pixel image. I found that when I change the content_width value to anything greater than 640, it serves a 640-pixel image. The same is true for values higher than 1024. But if content_width is any value between 320 and 639 pixels, it will only serve a 320-pixel image.
How do I get Flickr to serve a 500-pixel image? Looking through countless message boards, it appears that Flickr not only used to serve 500-pixel images via oEmbed, but also restricted the size of images to exactly 500 pixels.
Not being able to easily embed a 500-pixel image from Flickr has left me with a few options:
- Continue using Gallery2 and WPG2 for the image gallery and embedding.
- Use a theme with content width of 640 pixels. This is actually a pretty good idea since I can use or devise a single-column theme that looks good on desktop, mobile, and tablet environments.
- Look to yet another image hosting solution. I would think that 500px.com would be a perfect solution, since I’m looking for images of exactly that size, but they don’t support oEmbed.
- Deal with teeny, tiny 320-pixel images. Nah!
- I could also change the CSS to make images in the content layer no greater than 500px wide. But this seems like inelegant solution because that would require changing the
content-width value to 640, which could cause problems with other oEmbed content I might add later.
After a couple of days of this entire site being down and then only the photo gallery, which embeds photos into each post, not working, I am happy to announce that I’m back up.
A PHP memory issue was causing the photo gallery to stop functioning. I hadn’t told WordPress to use more memory from PHP. My host allows me to use 256MB of memory, where WordPress was limited to a measly 32MB.
I’ll write a summary of all the things I had to do to get my site back up over the last few days. But if I may tease you a bit about it, it required editing DNS and PHP configurations.
Say goodbye to the old Juanomatic.net website. A new site is coming!
In the last few days, I’ve decided to completely redo this site, migrating from a site where I documented many of my misdeeds to something a little more grown up. Also, this has enabled me to finally abandon Movable Type as the site’s CMS to Word Press, which is something I should have done years ago. (Word Press is so much better!)
In the coming weeks, I’ll be making many changes to this site and maybe even trying to resurrect some of the more popular parts of the old site, such as the photo gallery and the softball blog.
Thanks for your support over the years. And now that I am getting something more to my liking (and appropriate for my 30s), I’ll be bringing a spiffy new site.
