Links for June 3rd through June 18th Links for June 3rd through June 18th
  • Home
  • Posts
  • Home
  • Posts

Archives

Links for June 3rd through June 18th

Links for June 3rd through June 18th:

  • Ten logo design tips from the field | Logo Design Love
  • 10 astonishing CSS hacks and techniques
  • Adaptive CSS-Layouts: New Era In Fluid Layouts? effective techniques to create 100%-functional adaptive CSS-layouts
  • WordPress Theme Development Frameworks If you build and develop WordPress themes often, you will probably be fed up of all the repetitive code writing, the constantly checking of your mark-up and all you really want to do is focus on the design and the project-specific features. The answer is a WordPress development framework
  • How to Draw Pixel-Perfect iPhone Toolbar Icons Using OmniGraffle
Read More

Sort your Flickr photostream

Flickr has a limitation that your photostream is ordered by the date you uploaded your photos, and this order can’t be changed. If you’ve done a big import of photos – say, from iPhoto – then they could show up in your photostream in any order.

There’s been some talk about the issue, with one suggested solution being to manually set the ‘posted’ date of every photo to the ‘taken’ date. A utility exists to do this, but it has some major limitations, including a difficult user interface and limitation that causes the process to fail if you have any photos that were taken before the date you set up your Flickr account.

So, I’ve made a utility specifically for sorting a Flickr photostream. It should be fairly user friendly, and provides the ability to backup and restore your photo metadata, in case you ever want to revert.

Check it out here: SortMyPhotostream, or get access to the SortMyFlickrPhotostream source.

200906081230.jpg

Leave a comment below if it’s useful to you.

Read More

Flickrpress: WordPress Flickr widget

Flickrpress screenshotFlickrpress is a widget/shortcode function to display items from Flickr in the sidebar or within pages and posts. This widget supports:

  • Flickr RSS feeds
  • Photostream
  • Filtering by tag
  • One or more photosets
  • Favorites
  • Displaying random items

Other features:

  • Choose from three different thumbnail types
  • Lightbox/Thickbox are supported
  • Data is cached locally to lower server load
  • Secure Flickr API used, to eliminate the risk of damage to your server, unlike some other Flickr widgets
  • Flickrpress is a multi-widget, so you can use more than one instance (e.g., one in your sidebar, one in your footer)
  • Use as a shortcode to insert into posts and pages — multiple instances supported in the one entry

Flickrpress uses the excellent phpFlickr library.

Read More

Links for May 21st through June 2nd

Links for May 21st through June 2nd:

  • 49 Decent Virtual Assistant & Personal Outsourcing Resources
  • PHP: Display Adobe PSD files on a web page "Any webdesigner know the PSD filetype, which is the Adobe Photoshop format. PSDs have a lot of great features, as such as layers, but they can’t being read by a browser. Unless you use this great PHP class!"
  • Iconfinder – Icon Search Made Easy
  • Typetester – Compare fonts for the screen
  • KNAppGuide KNAppGuide is a Cocoa framework for embedding “guides” into your application, visually inspired by Apple Guide from the System 7 and 8 era
Read More

Flash video cache on OS X

I just make a happy discovery: Flash stores videos it’s currently playing (eg. from YouTube, Megavideo, etc) within the /private/var/folders/.../ area.

Access it by hitting Cmd-Shift-G in Finder, typing in /private/var/folders and hitting enter, then navigate around until you see something like a TemporaryItems folder – within will be a file called something like FlashTmp0, which is the .flv file.

Copy it somewhere and rename it, and it’ll play in VLC or any other player that supports the format (like Quicktime etc with Perian installed).

Read More

Keeping Flickr away from iPhoto

iphoto.png
Update: Andrew made a better suggestion in the comments below that I hadn’t thought of: De-authorise iPhoto from your Flickr account, then just delete the Flickr albums in iPhoto. Thanks, Andrew!

iPhoto ’09 introduced Flickr support, so that you can post photos and albums to your Flickr account. Unfortunately for some, it has some issues: A tendency to perform mass-deletions on uploaded photosets after the initial upload. For example, for me, having uploaded several hundred images, iPhoto has deleted almost all of them on two separate occasions, requiring the photosets to be constructed from scratch.

For those who were considering using Flickr from iPhoto, don’t, and save yourself the hassle (use FlickrExport instead). For those who have and are seeking a remedy to keep iPhoto away from Flickr, read on.

I encountered the uncomfortable scenario where iPhoto had forgotten about three quarters of the images in the uploaded photosets, and upon launch, looked like it was going to delete the remainder from my Flickr account. Rather than let this happen, I force quit iPhoto, and performed the following steps to force iPhoto to forget about my Flickr account. This is a very complicated process, not for the faint of heart, but it was necessary for me to save my Flickr account:

  1. Right-click on the ‘iPhoto Library’ package, probably in the ‘Pictures’ folder
  2. For the files AlbumData.xml and AlbumData2.xml:
    1. Backup the files somewhere
    2. Open the file in a text editor
    3. Search for the term ‘http://www.flickr.com’
    4. Wherever this is found, delete the surrounding text between and. There will be one of these dict structures for every photoset
    5. Save the file
  3. Now the tricky part: Find an SQLite editor (I used Froq) and open up iPhotoMain.db within the ‘iPhoto Library’ package. To access the file, I had to copy it to my Desktop first, then open it there (back it up first).
    1. Click on the SqPublishedAlbum table to see the contents. This lists all of the published albums, including Flickr, Facebook, etc. Find the entries with a publishedURL at flickr.com, and delete them. In Froq, I had to take note of their primary key values, and manually execute an SQL query (DELETE FROM SqPublishedAlbum WHERE primaryKey = 12345). Remember those primary key values, because you’ll need them.
    2. Click on the SqAlbum table, and delete the albums with the same primary key values – if you used an SQL query as above, you can just re-use the same query but change the table name to SqAlbum.
    3. Repeat the same process for the AlbumsPhotosJoin table – in this case, you’ll need to delete entries with the sqAlbum field values matching the prior primarykey values. Something like DELETE FROM AlbumsPhotosJoin WHERE sqAlbum = 12345 will do it.
    4. Done with this database – commit and close, but remember the primary key values for the Flickr albums.
  4. Next, open up the other SQLite database, iPhotoAux.db, after backing it up
    1. Delete the Flickr album records from the SqAlbumSubclasses table. Something like: DELETE FROM SqAlbumSubclasses WHERE primaryKey = 12345.
    2. Commit and close
  5. Send a bug report to Apple

That’s it! Now, after starting iPhoto, the Flickr albums should be gone, safe at last. FlickrExport is a £12 plugin that provides better, more reliable functionality than iPhoto ’09.

Read More

Google Gears issues

If you’re running (or trying to run) Google Gears under Mac OS X and persistently receive this message:

A Google Gears update has been downloaded.

Please close all browser windows to complete the upgrade process.

— It’s a problem with locks that never get unlocked. I’m not sure how this happens, but it’s easily fixed:

  1. Open a Finder window
  2. Navigate to your temporary folder:
    1. Press Command-Shift-G
    2. Type in /private/var/folders
    3. Navigate through folders to find the -Tmp- folder. For me, this is located at LW/LWyYk1hzEbCzrBJpFMdhE++++TI/-Tmp- within /private/var/folders
  3. Look for any files that look like IsRunning{gears} or IsRunning{gears}-##.##.##.##
  4. Delete those files
  5. Start/Restart your web browser, and all should be fixed
Read More

Firming up WordPress’s security

There’re thousands of articles out there describing how to secure WordPress better against attacks, but I still had a little difficulty with the nuts and bolts, so I thought I’d detail the process I underwent here.

I recently had a bit of a security breach – some lowlife broke into my account and injected some phishing stuff into my personal webmail software. Consequently, I went on a bit of a security binge and deleted some apps I wasn’t using much, changed all of my passwords to ridiculously long strings, and set up layers of HTTP authentication on my WordPress login/admin pages, the latter of which is described here.

The general idea is to make it hard to get to the login/admin pages in the first place, which should block some attacks.

The AskApache password protect WordPress plugin will do all of this for you, unless it thinks your webserver doesn’t have the supporting software. It failed for me on Site5, saying I lacked HTTP digest authentication support, which is actually not true, as it’s enabled. I couldn’t be bothered debugging it though, so I proceeded with the manual route.

Create the password file

First, I created an htpasswd file, containing a login and password. There’re many sites describing how to do this, but on the terminal, it’s fairly easy:

htpasswd -c /path/to/.htpasswd myusername

Note that it’s a good idea to put the .htpasswd file somewhere outside the web root – your account’s home directory is one option.

Protect the login page

I opened up the .htaccess in the WordPress root folder, and added the following:

ErrorDocument 401 default
 
AuthUserFile /path/to/.htpasswd
AuthName "Blog"
AuthType Basic
 
 
    require valid-user

ErrorDocument 401 default AuthUserFile /path/to/.htpasswd AuthName "Blog" AuthType Basic require valid-user

Note that ‘ErrorDocument 401 default’ line – this is in place to avoid getting a ‘404’ error whenever you load up the login page. I’m not entirely sure of the details, but it seems that if the rewrite module is used (the thing that allows WordPress to define an arbitrary website structure, without needing physical files), then this causes problems with HTTP authentication.

Also, if you wish to protect access to the XMLRPC access point as well, you can add the following:

 
    require valid-user

require valid-user

However, if you do this, I’m pretty sure pingbacks (the WordPress-specific version of trackbacks) will no longer work. I think trackbacks will still be functional – as far as I know, they use a different access point. If you use a desktop blogging app, you’ll want to make sure it can handle HTTP authentication. I know ecto can.

Protect the admin area

Finally, I created a new .htaccess file in the wp-admin directory, which looks like this:

ErrorDocument 401 default
 
AuthUserFile /path/to/.htpasswd
AuthName "Blog"
AuthType Basic
 
require valid-user

ErrorDocument 401 default AuthUserFile /path/to/.htpasswd AuthName "Blog" AuthType Basic require valid-user

Read More

Hi! I'm Michael Tyson, and I run A Tasty Pixel from our home in the hills of Melbourne, Australia. I occasionally write on a variety of technology and software development topics. I've also spent 3.5-years travelling around Europe in a motorhome.

I make Loopy, the live-looper for iOS, Audiobus, the app-to-app audio platform, and Samplebot, a sampler and sequencer app for iOS.

Follow me on Twitter.

Posts pagination

« 1 … 21 22 23 … 34 »
© 2021 A Tasty Pixel.