Today marks WordPress’ 10th year of existence. To celebrate, #wp10 parties are being held all over the world. In the Minneapolis/St. Paul area we met at Minnehaha Park. Unfortunately, the weather didn’t cooperate for the bike-ride/run that we planned to do before grilling. So, we stuck to socializing in the pavilion, grilling bratwurst (some hotdogs, chicken and a lonely hamburger made it to the grill as well), and eating birthday cake.
-John Havlik
[end of transmission, stay tuned]
Back when I posted my photoset from WordCamp Minneapolis 2013, rather than performing any post processing, I just uploaded the full images from my camera’s SD card. Normally, I would open up the Gimp and reduce the resolution by 50% and then crop to a 3:2 or 16:10 ratio depending on what was appropriate for the images. This produces small files that are easy for the server to handle.
Since WordPress generally does a good job generating the image sizes it needs, I didn’t worry about uploading the full, unreduced images. Normally, the end users would never see the full size images, so no harm, right? Wrong. At least if you use Jetpack.
If you use the tiled gallery feature in Jetpack (like I do on this site) you end up using the WordPress.com CDN. Unfortunately, Jetpack tries to load the full image size when caching for the tiled gallery. Trying to pull 50 or so images, at 1 MiB to 2 MiB a piece to cache didn’t work too well. Naturally, Jetpack could do things slightly more intelligently and request for the closest, already existing, image size to be used, but that’s a topic for another day.
To get things to play nicely I needed to reduce the ‘original’ file sizes. Thankfully, Weblogs.us has ImageMagick installed. Thus, fixing the issue was as simple as running:
convert P*.jpg -resize 50% \ -quality 88 \ -set filename:newsize '50_%t' '[filename:newsize].jpg';
Then, after inspecting the results, all that was left to do was to rename the 50_ prefixed files back to the original file name.
-John Havlik
[end of transmission, stay tuned]
Introducing Monitor Logins, a simple plugin that allows you to monitor login attempts (successful and unsuccessful) made against your user account on your WordPress install. Failed attempts to login to user accounts cause email notices to be sent to that user. That is, if they have notifications enabled. Notifications are enabled on a per user basis, and are off by default.
Additionally, Monitor Logins will remember devices used to login with, should a device be “new” upon successful login a notice will be sent to the user. Devices are forgotten if they have not been seen for a few months. The last several successful logins are remembered and displayed in a list akin to what Gmail does. Only a user can view his/her own login activity.
I originally wrote this plugin to gain greater visibility into login attempts made against user accounts on this site almost a year ago (Way before the recent botnet dictionary attacks). Since then, it has been steadily refined to make it more suitable for a wider range of users. For those of you who attend the MSP WordPress meetups, this is the plugin I demoed during a lightning talk session in March.
More information is available on the Monitor Logins project page.
Download Monitor Logins 0.2.0 from Git Hub.
-John Havlik
[end of transmission, stay tuned]