Here’s my take on the subject of men’s clothes. I realize I’m going against current trends with this view, but thanks to my recent experience with severe back pain, I’ve gained additional insights into the effects that clothes have on our posture, our bodies and ultimately our health. I know and I have seen first-hand how some clothes can provoke back pain and others can relieve it, and that’s what I talk about in this video. I hope it helps you!
I was asked by a reader (Andrew M.) how I display the most recent photos from my SmugMug galleries on my home page. He was aware that I use the SimplePie plugin for WordPress, but wasn’t sure how to get the same look when starting from scratch.
Before you read any further, keep in mind this is a very specific tutorial about WordPress, SimplePie and SmugMug. It has other applications, like for other image feeds and with some code tweaking, for other blogging platforms, but if you want to do those things, then Google is your friend.
The thing that makes things a little complicated in my situation (as opposed to other image feeds) is the somewhat non-standard structure of the SmugMug feeds. For one thing, they don’t provide a URL for the image thumbnail where you’d expect it to be, and for another, they provide the image description instead of the image title. (To check this, mouse over a SmugMug thumbnail, and you’ll see the description pop up over the image.) But as long as you’re willing to dig into the feed code and find the names for the fields you need, then you can plug that info into SimplePie and go from there. Thankfully, I’ll do it for for you below. Lucky you.
Just a quick general disclaimer before I start though: I don’t do handholding. I’ll provide the instructions for how I did it. But in the unlikely event that things still don’t make sense to you, do me a big favor and read the SimplePie Manual, before you ask me questions. I did it and it helped me work things out. It should do the same for you if you use a little elbow grease. Thanks.
Okay, onto step 1: find the SmugMug feed URI. SmugMug provides several feeds for each user account. Go to the bottom of your gallery page and click on the Available Feeds link to see all of them. We’re going to use the Recent Photos Atom feed. In my case, it is:
Step 2 is creating an Images Only template for SimplePie. If you’re not sure what this is, you need to read through the SimplePie documentation. The location where you need to place the new template is:
This is not arcane info, btw. It’s provided in right on the SimplePie general settings page, which is what I’ll talk about in Step 3 below. Now let’s talk about what you’ll put in the template file. This is where the digging through the feed code part comes in. I kept things simple, and this is what my images_only.tmpl file looks like.
As you can see, the code is minimal, which is the way I like things. I am specifying a simplepie class in the code, but as you can see from my CSS file, I’m not styling the div in any way. I’m letting the rest of the CSS code and the other divs handle the way the images flow within this particular section.
Step 3 is adjusting the general settings for SimplePie. Now that we’ve created an Images Only template, we need to let SimplePie know that it should use it. Go to the WP Admin Panel and locate the SimplePie settings. Match my settings as you see them below.
I’m telling it to pull the latest 18 photos. You may find you need to pull less or more. It’s really up to you. Use the caching option, it’s faster, but know that you’ll need to create a cache directory where SimplePie can store the images. It’ll walk you through it when you say Yes, and you may need to adjust privileges on the server side. Check out this chmod tutorial from WordPress if you’re not sure how to do that.
Step 4 is placing a code snippet on the home page. Now that you’ve gone through all that fun, you’ve got to wrap things up. Go to your home page template in WordPress, and where you want the images to appear, place the following code snippet — it’s what triggers SimplePie to pull your SmugMug photos feed and display the feed items how you want them, in accordance with the code in your Images Only template.
See the highlighted text, but you only need to worry about the php code line. The rest is my own code that specifies the div and section styles. Use your judgment about how to style the thumbnails, and how you want them to display. It may take a bit of trial and error until you get it right, but if you persist, it’ll look good in the end.
Hope this helps!
I’ve been running an experiment for the past three months. I wanted to see how well WordPress would do if I ran it by itself, without any sort of caching. So far, so good.
About four months ago, my web server kept getting pummelled into the ground almost daily, and I couldn’t figure out why it kept happening. After researching the issue, I found the prevailing opinion to side with the need for a caching plugin. People were complaining that it’s just not optimized well, and must be run with the aid of such a plugin, otherwise higher levels of traffic will bring the web server down. Trouble was, I already ran my WP install cached, using WP Super Cache, had been doing so for over a year, and my server still went down. (I should specify it had only recently started to go down.) What was I to do?
I posted a message in the WP forums asking why WordPress doesn’t generate static files. Were there any plans to do so in the future? To my surprise, Matt Mullenweg (WP’s founder) replied to my post, and told me that while there are caching plugins out there, WordPress.com doesn’t run any, and they’re doing just fine hosting millions of blogs. Others chimed in as well, and their replies got me to make the following changes:
- Made the switch to a VPS (Virtual Private Server) with SliceHost. Four months later, I’m still very happy about that move.
- Doubled the RAM on my web server (to 512MB from 256MB).
- Turned off WP Super Cache and started running my site by itself.
Each step followed the other in succession. I wanted to make gradual changes so I could see why my server kept having issues. Switching to a VPS host was good, and it was needed, but for my traffic levels, it wasn’t enough. Doubling the RAM was good and it was needed, and while the new RAM is enough for now, I’d still be having problems if I didn’t also disable my caching plugin.
Here’s where I think the crux of the caching/non-caching issue lies: it has to do with the load placed on the server as cached versions of the pages get created. Normally, that’s a non-issue. But as I monitored my server carefully, I discovered that it went down only as it started to get indexed heavily by search engines. Their bots visited my site in spurts, with traffic peaking, then falling back down. They spawned multiple threads, over ten at times, following links and slurping up the content. It’s when bot traffic peaked that an incredible load was placed on the web server. It kept generating cached versions of pages it hadn’t already cached, RAM and CPU demand increased to unsustainable levels, and it went down.
No amount of tweaking the Apache and MySQL config files helped with this sort of scenario, or at least it didn’t help me. You see, the difference between peak traffic levels with search engines vs. people is that people will go to a single article or a group of articles that are in demand. A caching plugin works great for those sorts of situations. There’s a limited number of pages to worry about caching, and those pages get served up time and time again. The load is acceptable. When a search engine bot starts indexing your site, it’ll call up any and all available pages that it can find. That can place a huge load on the web server as it scrambles to serve up those pages and build static versions for the caching plugin. I believe that it’s too much for most medium-sized servers to handle, and they will usually go down.
In my case, disabling the caching plugin and making sure no traces were left in the .htaccess file were the only things that helped. Now, I might have up to four different search engine bots crawling my site, each spawning multiple threads, and my server will usually not go down. Sure, there are times when the server will get dangerously low on RAM, and will be unresponsive for 5-10 minutes, but that’s an acceptable scenario for me. And if I should all of a sudden get huge amounts of people traffic to a post, it’s possible that the web server will also become unresponsive, at least for a time. But the great thing about running WordPress by itself is that Apache will usually take care of itself. As the requests die down, Apache will kill the extra threads, the available RAM will go back up again, and the server will recover nicely. That wasn’t possible while I ran the caching plugin. When it went down, it stayed down, and that was a problem.
I realize that what works for me may not work for others. I have not tested what happens with WP Super Cache on a larger server, for example one with more RAM. It’s possible that the larger amount of RAM there will offset the greater demand placed on the server as it builds static versions of the pages, although I’m not sure what to say about the CPU usage. That also peaked as the caching plugin went crazy. Not sure how that’ll work on a more powerful server.
WP Super Cache has some options that allow you to cache more pages and keep them cached for longer periods of time. Perhaps fiddling with those options would have allowed me to keep running the plugin, but I wanted to see how things stood from the other side of the fence. Like I said, so far, so good. Caveats aside, running WordPress by itself was the cure for my persistent web server outages.
One of the reasons I bought a Nokia N95 was the ability to tether it as a Bluetooth modem on my MacBook Pro. I wanted to access the internet via my mobile phone if I’m away from home or from a WiFi spot. While Nokia’s PC Suite of applications includes an option to tether the phone to a Windows machine with just a few clicks of the mouse, it’s not that simple for the Mac.
Fortunately, once you go through a 5-10 minute initial setup process (outlined below), connecting to the net via the N95 becomes a simple matter of two mouse clicks. Keep in mind that this tutorial will help you configure a Nokia N95 phone only for the T-Mobile network; you’re on your own when it comes to other service providers, but the process should be fairly similar.
I’m indebted to this pre-existing tutorial from The Nokia Blog. However, I found the instructions a bit confusing, as the Mac OS X operating system has been updated since and the network preference screens don’t look the same. Consider my post an updated tutorial, with screenshots from the current Mac OS X (10.5.5).
1. Get the 3G modem scripts for Nokia phones from Ross Barkman‘s website.
Look for the section called “Scripts for Nokia 3G (EDGE/UMTS) phones”.
He’s written numerous such scripts and posted them for download on his site. They work fine for countless people, so please, if his script works for you, show your thanks by donating a few dollars to him.
2. Drop the “Nokia 3G” folder containing the modem scripts (yes, the entire folder), in the /Library/Modem Scripts/ directory at the root level of your Mac’s hard drive.
It should look like this once it’s in there:
3. Add your Nokia N95 phone as a paired Bluetooth device.
If you haven’t added your phone as a Bluetooth device yet, click on the plus sign in the lower left corner and go through the wizard to add it. Make sure to check both boxes shown below, and to pair it as well.
If you have already added it as a Bluetooth device, you may want to run through the configuration wizard again, making sure to mark both checkboxes, as seen below. Click on the phone to select it from the list of Bluetooth devices (see screenshot above), then click on the little gear icon in the lower left corner of the dialog box and select “Configure this device”. You will get the following screen. Click on Continue and run through the wizard to the end.
4. Configure the Bluetooth service preferences.
Go to Network preferences. Here’s where you have a choice. If you’re going to want to use multiple mobile phones or Bluetooth devices as modems, you may want to duplicate the existing Bluetooth service and configure each copy separately, naming them accordingly (Nokia N95, iPhone, etc). To do that, select Bluetooth, then click on the little gear in the lower left corner and select “Duplicate Service”.
I’m only going to use the Nokia N95 as a Bluetooth modem, so I chose to work directly with the existing Bluetooth service, as you can see below. To do that, click on the Configuration drop-down menu and choose “Add Configuration”. You’ll be asked for a name. I named it “T-Mobile Internet”. In the Telephone Number field, I put “internet2.voicestream.com”.
Now click on Advanced, and you’ll get a whole series of preference panes. Modem is the first one. Make sure the information matches what you see below.
Now click on DNS. Some say you should pre-fill DNS server addresses, because your mobile service provider may or may not give them to you. Thankfully, T-Mobile will automatically assign you two DNS server addresses when you connect, but just to be on the safe side, grab one or two more DNS addresses from a public DNS server list like this one and add them to the DNS preference pane. If you look below, the two DNS addresses that are grayed out were automatically assigned by T-Mobile after I connected through the phone, and the single address in black was the one I manually added.
Don’t worry about WINS or Proxies, go to PPP, where you’ll have a drop-down menu. The Session options on the PPP preference pane should look like this:
And the Configuration options on the PPP preference pane should look like this:
Some people say you should disable “Send PPP echo packets” and “Use TCP header compression”. I left them enabled, and my connection works just fine. But, if you should have problems connecting and staying on, you may want to disable them. Just uncheck them and hit OK.
5. Apply the changes and click on Connect.
The Bluetooth modem status should change in the menu bar and first say “Connecting…” then “Authorizing…”. After it connects, it should show the time elapsed since the connection started, like this:
There’s one thing I haven’t been able to figure out though, and I would appreciate your help on this. Getting the Mac to connect to the internet reliably through the phone, every single time, is still something that I need to work out.
That first evening after I configured things as outlined above, I was able to connect and disconnect at will. However, the second morning, I got a “Could not authenticate” error. I clicked on the “Set Up Bluetooth Device” (shown above), and re-configured my N95 (as detailed in Step 3). After that, it was okay for the rest of the day, but the same connection issue re-surfaced the next day. I’d read that keeping iSync open while you connect will help, and I tried it, but it didn’t seem to work reliably for me. What has seemed to work is logging in and out of my account on the Mac, and rebooting the phone.
It seems that Nokia would be best equipped here to make things easier and more reliable. I do wish they’d release a tethering app for the Mac, just like they released an iSync plugin that lets the N95 sync with the Address Book and iCal. Until then, you can try any of the following workarounds when you experience connection issues:
- Re-configure the phone as a Bluetooth device (as outlined in Step 3 above)
- Disable “Send PPP echo packets” and “Use TCP header compression” in the PPP Configuration preference pane
- Open iSync before you try to connect to the Internet through the phone
- Log out of your account on the Mac and reboot the phone
Once the phone is tethered properly, it’s an enjoyable experience. There’s a newfound freedom I feel when I can go online from just about anywhere. There’s something elegant in using my phone as a Bluetooth modem. It can stay in my pocket or on the table next to my laptop, tethered wirelessly, still working fine as a phone while also letting me get on the Internet. Cool stuff indeed.
I recorded a few video clips with my wife’s mobile phone today, and when I tried to import them into iMovie ’08, I found out that I couldn’t. Apparently, I’m not alone, because if you do a search for this on Google you’ll find there are plenty of other people with the same problem.
Fortunately, there are two ways to work this out, but neither is necessarily obvious. Pick one of them:
- Open up the clips in Quicktime. I was able to open them up and play them right away. Now, export each clip as an MP4 file. You must specifically select File > Export, then select Movie to MPEG-4 from the Export drop-down menu. Don’t just Save the clip, because it’ll package it as a MOV file, which iMovie ’08 will still refuse to import. You must Export it as an MP4 file. You may also be able to export to other formats, but MP4 is what worked for me.
- Open them clips in Turbo.264, then export them to some format (try Apple TV or iPod Standard, for example). There’s a catch here though. If the resolution of the clips is too small, Turbo.264 may not be able to convert them, and will give you an error. Best stick with Quicktime then.
Now open up iMovie ’08, and go to File > Import Movies, browse for them, and import to your heart’s content. That’s it!
You can try bothering with the preferences files, or the codecs, or the color profiles, as the forums tell you to do, or you can do the following:
- Go to your home folder > Movies > iMovie Events. Locate the folder with the last clips you imported. Delete the iMovie Cache and iMovie Thumbnails folders.
- Restart iMovie. For most of you, that’s all you’ll need to do.
- If it still crashes, that means one or more of the actual clips themselves weren’t closed properly by the video camera (perhaps you ran out of battery, space on the card, etc.). Open them up in Quicktime (if you have Quicktime Pro) or some other application (like the software that came with the camera) and snip 1-2 seconds off the end of each clip. Save them, then delete the iMovie Cache and iMovie Thumbnails folders (in case iMovie re-created them).
- Now restart iMovie. It should work fine now.
A few words to explain some things:
- If a movie clip doesn’t open at all from the Finder, then it is corrupted. Perhaps only its header is messed up for some reason. At any rate, I have not yet found software that will fix those movie clips. I searched enough, and only found spyware that promises to do it.
- If a movie clip opens and plays fine in Quicktime, but iMovie crashes when trying to import it, then its ending is corrupted, as explained in step #3 above. Cutting 1-2 seconds off the end of the clip in some software other than iMovie will restore its ending and let you import it without crashes in iMovie.
- The method I described above has worked reliably for me on three occasions now, and this is after I wasted hours on the phone with Apple Support. It only occurred to them to let me re-import video clips after having me try all of that other stuff, including a re-install of iMovie ’08 and also the creation of a new account to see if the problems re-occur there. Pointless. I say go to the root of the problem and take care of it right away, don’t beat around the bush.
Hope this helps you too.
If you know how to log in via SSH (Secure Shell Access), then you will be able to upgrade your WordPress site in three minutes or less by using the following lines of code.
I have to admit right away that I’m highly indebted to this pre-existing tutorial from Techtites. But that tutorial is a little dated for the newer versions of Linux, and one of the commands given there no longer works on my web server, because it’s been deprecated (I use 1and1). I thought it useful to provide the right commands in this post, and to keep it updated in case something changes.
A few words of CAUTION:
- BACK UP all of your site files and your site database before running the upgrade. Take the time to do both, or you may deeply regret it later. As a matter of fact, it’s a great idea to back up your site files and database on a weekly basis, if not more often, just in case you get hacked or the web server crashes, etc.
- I’m not a Linux expert. I’m just glad I found these commands and that they’ve made the upgrade process easier for me. Don’t ask me to help you configure this for your web server. If the commands don’t work there, or something gets screwed up, you’re on your own.
- Should you use the WP-Cache plugin, disable it and delete any cached files BEFORE running the upgrade process. Even better, disable ALL your plugins before the upgrade process. If you don’t do this, you may get a big, fat 500 error afterwards.
Now, initiate a SSH session to your web server (I use Putty). Your web host should have the directions on how to do this. Go to the root level of your site/WP install folder (this is NOT the same as the root level of your SSH login).
Once you’re at the root level of your WordPress install (the one where you can see the wp-config.php file), enter the following Bash commands, in the order they appear. Wait for each of them to execute successfully before proceeding to the next one.
This will download the latest version of WP directly from WordPress.org:
This will unzip it, creating a directory called wordpress:
tar xfz latest.tar.gz
This will delete the wp-includes and wp-admin folders:
rm -rf ./wp-includes/
rm -rf ./wp-admin/
This will take you inside the wordpress folder:
This will copy everything inside the wordpress folder to the root level of your site, overwriting any existing files and directories. This line is the only line that’s changed from the Techtites tutorial:
cp -rpf -f * ../
This will take you back out to the root of your WordPress install:
This will delete the wordpress directory and the downloaded WP archive, since they’re not needed any more:
rm -rf ./wordpress/
rm -f latest.tar.gz
Hope this helps!