blog.kno.at » Tools http://blog.kno.at Marketing, Webdesign, Graphics, Drinking, a little WebApp every once in a while, it's like love. You could live without it, but why the hell should you? Wed, 18 Aug 2010 16:40:24 +0000 en hourly 1 http://wordpress.org/?v=3.0.1 Sometimes going on is all about closing doors http://blog.kno.at/trash/sometimes-going-on-is-all-about-closing-doors/ http://blog.kno.at/trash/sometimes-going-on-is-all-about-closing-doors/#comments Mon, 29 Dec 2008 21:19:02 +0000 Kno http://blog.kno.at/trash/sometimes-going-on-is-all-about-closing-doors/ If you close a door, you open another one – that’s common belief. I’m not so sure, but I’m quite certain that sometimes it’s necessary to close a door to get any further. Now it’s really easy to close most doors (it’s even easier not to close them, but the ... »

]]> If you close a door, you open another one – that’s common belief. I’m not so sure, but I’m quite certain that sometimes it’s necessary to close a door to get any further. Now it’s really easy to close most doors (it’s even easier not to close them, but the whole open-doors-thingy easily leads to a huge mess and confusion and distracts you from where to go. So many doors to take care of. No good).

But some doors you’d just rather keep open. Most of the time these aren’t even the wide-open ones, but the ones about to slowly slam shut by themselves. The doors where there’s something on the other side you really want. But that damn door won’t just stay open.

Uh oh ah, I’m all philosophical and bullshitty.

However, here’s my end-of-philosophical advice: Close these doors. Maybe, some day, they open from the other side.

]]> http://blog.kno.at/trash/sometimes-going-on-is-all-about-closing-doors/feed/ 0 Highlight Source Pro: Sourcecode Highlighting WordPress-Plugin http://blog.kno.at/tools/highlight-source-pro/ http://blog.kno.at/tools/highlight-source-pro/#comments Mon, 07 Apr 2008 14:26:36 +0000 Kno http://blog.kno.at/?p=178 Syntax-Highlighting for WordPress made easy. Utilizing GeSHi and simple, standards-compliant attribute-based controls the possibilites are unlimited. All styling is done with CSS and can easily be personalized. ... »

]]> Yeah, there’s that WordPress-Blog we have and there are these tools we develop, and when we blog about our ingeniousity we have to go through all those painful code-markup-problems. I hate that. But fear no more, my furry friends, for this is our path to salvation.

Highlight Source Pro

Based upon this Posting I found on my research I tweaked and improved things a little and here it is, in it’s full glory, flexible, automatic, degrading – amazing.

Download Current Version (from wordpress.org)

Donate (PayPal)

Features

  • Highlight sources of any language
  • automatically, server-side (no javascripts)
  • XHTML-Compliant, <div>, <ul> & <span>’s with class-attributes and a css-file are used for styling
  • optionally add a heading for every code-block
  • optionally specify line-number offset (BREAKS XHTML COMPLIANCE)
  • optionally don’t display line-numbers
  • set per-codeblock if the code is html_entity_encoded or not
  • only parses <pre>-tags with the lang-attribute, thus does not interfere with any regular preformatted contents you might have
  • degrades beautifully through <pre>-tags (if you keep the sources clean, that is)
  • all settings through logical, valid arguments for the main container
  • comes with generic cross-browser (IE5/Mac, IE5.5+, FF, Safari, Opera) default CSS-styles
  • see screenshot for preview

How to use

Set your code-blocks as <pre>-tags. If the language is supported by GeSHi (see filelist in the /geshi-directory) use the filename (without extension) as language-attribute. If your code is encoded (html-entities; e.g. < is displayed as &lt; – most likely the case if you write in the visual editor) add the ‘enc__’ – prefix. For example for a php-codeblock you would start as follows:

<pre lang="php">

You can control various things:

  • Start of Line-Offset, e.g. for #17: <pre class="17">
  • define entity-encoded blocks, e.g. for php: lang="enc__php"
  • Define a title for your code-block that appears inside the block, but above the code lines. Everything in the same line as the opening <pre> tag will be considered the title, including HTML. Example: <pre lang="php"><strong>This is</strong> an <em>example</em> with a <h3>headline</h3>
  • disable line numbers by not specifying an offset

Known Issues

  • While the plugin is basically XHTML 1.0 Strict compliant there’s just no way of getting the offset-based line-numbering to display without inadequate (ab)use of javascript & css hacks, so be warned that IF you use the line-number offset, your documents will NOT validate because of the forbidden start-attribute for the <ol>!
  • Watch out for your ampersands (&) for HTML-listings: Those little friends ALWAYS have to be encoded (&amp;), even twice (&amp;amp;) if your source is encoded. This is because GeSHi only checks for HTML 4 Strict.

Example #1: HTML

<pre lang="html"> Some Demo-HTML-Markup
<body>
<h1 class="a_class">What a great afternoon &amp; stuff</h1>
<p>Isn't <a href="http://kno.at/">today</a> just "beautiful"?</p>
</body>
</pre>
Some Demo-HTML-Markup
  1. <body>
  2. <h1 class="a_class">What a great afternoon &amp; stuff</h1>
  3. <p>Isn't <a href="http://kno.at">today</a> just "beautiful"?</p>
  4. </body>

Example #2: PHP

<pre lang="enc__php" class="17"> now <strong>with</strong> headline: <h3>a PHP-Filename</h3>
&lt;?php
/**
 *  Here is a comment! Weeeeeeeee.
 */
function demonstrate_stuff ( $me_so_horny )
{
    $a = 17;
    print ( "$a: $me_so_horny". $a * 3 + $this-&gt;testvar );
    return 'excellent!';
}
?&gt;
</pre>
now with headline:

a PHP-Filename

  1. <?php
  2. /**
  3.  *  Here is a comment! Weeeeeeeee.
  4.  */
  5. function demonstrate_stuff ( $me_so_horny )
  6. {
  7.     $a = 17;
  8.     print ( "$a: $me_so_horny". $a * 3 + $this->testvar);
  9.     return 'excellent!';
  10. }
  11. ?>
]]> http://blog.kno.at/tools/highlight-source-pro/feed/ 61 randomFlickr V0.6 http://blog.kno.at/tools/randomflickr-v06/ http://blog.kno.at/tools/randomflickr-v06/#comments Wed, 02 Apr 2008 12:35:11 +0000 Kno http://blogs.kno.at/personal/2008/04/02/randomflickr-v06/ Fetch one photo from a badge and then do stuff. V0.6 now supports choosing the size to fetch, or can even try to automagically detect the best suited one (woo-hoo!) ... »

]]> I just tweaked randomFlickr a bit and thus am releasing V0.6. Not because it’s a huge update, I just feel like releasing something and my new blog layout still is quite a bit from “done”, so here we go with a few more options on the source-file. See the Release-Notes for details, or just have a look at the Demo-Page code-sample.

]]> http://blog.kno.at/tools/randomflickr-v06/feed/ 0 Finally: Full Google-Calendar Sync with GCALDaemon http://blog.kno.at/tools/finally-full-google-calendar-sync-with-gcaldaemon/ http://blog.kno.at/tools/finally-full-google-calendar-sync-with-gcaldaemon/#comments Mon, 03 Dec 2007 18:48:03 +0000 Kno http://blogs.kno.at/personal/2007/12/03/finally-full-google-calendar-sync-with-gcaldaemon/ Since I use Google Calendar I was looking for an elegant and logical solution to keep it synchronized with my local calendar application (which was to be found) – biderectional. I guess soon this will become a standard feature, however by now it is not. Today I stumbled upon what I was looking ... »

]]> Since I use Google Calendar I was looking for an elegant and logical solution to keep it synchronized with my local calendar application (which was to be found) – biderectional. I guess soon this will become a standard feature, however by now it is not. Today I stumbled upon what I was looking for, and once again this is possible due to the *nix-Core of OSX.

Update: Flawless Sync with CalDav

Sync without any tweaking around is working perfectly with Google’s CalDav. Check out how to set it up here and enjoy flawless syncronization.

Big thanks go out to an anonymous commenter!

Update for OSX 10.5 Leopard

As things are by now it seems that Leopard stores iCal’s files kind of unusual and without extra PERL-Scripts and other humpty-tumpty hacking there’s no way of getting GCALDaemon to properly work with it. Therefore this solution is plain not working and not recommended for Leopard. I’ve hear that Plaxo Online can do all the syncing, but haven’t tried myself.

But don’t mind that, in clear words what this solution does is: Whatever calendar program you’re using, as long as it is based on .ical-files this handy little tool will run in the background and then, every few minutes, will synchronize this file with your google calendar. That way it’s totally independent from the calendar application and basically you can use whatever program suits your needs. You install this tool only once and then, forever, can sync any local ical file with any online google calender – bidirectional. The following instructions are for setting the thing up with Apple’s iCal, but other programs are pretty much the same.

GCALDaemon

A great and simple program, doing one thing: It synchronizes your remote google calendar with your local .ical-sourcefile, and vice versa. That’s not just great because it simply works, it also brings along two major features: The local calendar file will keep the calendar 100% available offline plus it’s no problem switching to any other program that’s using the ical – format.

However since we’re talking about an unix-application here the installation requires a little Terminal-fiddling, but not as much as one would expect. The following tutorial will make you a happy synchronized person and I promise things are easy, because I’ll use the finder instead of the terminal as much as possible. Now for the process:

  1. Download GCALDaemon
  2. Unzip to the correct directory
  3. Create your calendars
  4. Configure with the built-in GUI
  5. Install as startup-application

1: Downloading GCALDaemon

That one’s easy. Click the headline. Download the Linux/Mac – compatible .zip-archive. That’s it. don’t bother with the installation instructions, we’ll get that done in a second

2. Unzip to the correct directory

Unzip the archive to your desktop. In the now new directory you’ll find another directory: GCALDaemon. We’ll need this in a second. Now, first time for some Finder trickery. Click on an empty place on your desktop so the finder is the active application. Now either press Command + Shift + G or go to the menu bar and select “Go To > Folder …”. A dialogue box will pop up. Enter, and enter exactly:

/usr/local
  1. If everything's right you now should have a Finder window showing the folders: /lib and /sbin. If the latter doesn't exist, create it now from within the Finder. You'll probably have to identify as administrator, as those directories can be write-protected. That's ok, enter your password, create the folder and get in. Congratulations, you're now in /usr/local/sbin. On with the stuff.
  2.  
  3. Copy the folder GCALDaemon from your desktop to /usr/local/sbin. Once again it's possible the system will ask you to identify - do that (do that whenever it happens during the installation process).
  4. <h2>3. Create your calendars</h2>
  5. If you haven't already done that, go to iCal now and create your calendars <strong>as normal local calendars.</strong> If you just wanna try this you can also use the default calendar that's already set up, repeating step 4 you can easily add more calendars whenever you feel like.
  6. <h2>4. Configure with the built-in GUI</h2>
  7. This one was listed at <strong>the end</strong> of the manual installation instructions and I kind of hated the GCALDaemon-Guys for a few minutes there. But you don't have to suffer, but can profit from my findings. Now for the first of two terminal commands (you'll need no more than those two, I promise). Open a Terminal window (Applications &gt; Utilities &gt; Terminal). Now type, and once again type exactly, the following:
  8. <pre lang="bash">/usr/local/sbin/GCALDaemon/bin/config-editor.sh

Execute the command by hitting the Enter. After a second or so a window will pop up. Ignore the whole settings-stuff and go to "File synchronizer". Click the first line: "Enable file-based calendar synchronizer" until it's checked green. Do the same with "Enable dial-up connection and/or use PDA synchronizer ['offline-enabled' mode]" (the latter is theoretically unnecessary when you're on a constantly connected workstation, but the sync-mode is more flexible and there's no disadvantages whatsoever, so just check if if you don't have a good reason not to). The "Google Calendar polling interval" is the interval GCALDaemon uses to synchronize your online-calendar. The 15 minutes setting should be fine, so if you're not excessively switching between browser and iCal access you can leave this alone.

Now for the real part. On the bottom right there's a button "Google Accounts". Click it, choose New Account, enter your mail and enter your password twice. Check with verify. If everything's fine click ok. The next interesting button is the "New"-Button, just three steps left from the "Google Accounts"-one. Click it, select the remote calendar you want to synchronize and the local Calendar you want it to be synchronized with. Close the application and if you're asked to save your changes click "Ok". Tada, Magic done. You can repeat this step whenever you need to add or edit a calendar.

5. Install as startup-application - THANK YOU BUILD CHIMP

This is a little bit tricky, but if you follow the steps below you should be fine. Credits for that all go to Build Chimp. Now we need to tell OS X to execute this file on startup. This is being done with a .plist file. Open the editor (Applications > Utilities > Editor). Don't use TextEdit, you'll need the Editor! Create a new file, copy the following code - exactly - to the editor:

EnvironmentVariables
  1.  
  2. JAVA_HOME
  3. /System/Frameworks/JavaVM.framework/Versions/1.5
  4.  
  5. Label
  6. net.sf.gcald
  7. OnDemand
  8.  
  9. ProgramArguments
  10.  
  11. /usr/local/sbin/GCALDaemon/bin/standalone-start.sh
  12.  
  13. RunAtLoad
  14.  
  15. ServiceDescription
  16. GCALDaemon
  17. StandardErrorPath
  18. /usr/local/sbin/GCALDaemon/log/launchd.stderr
  19. StandardOutPath
  20. /usr/local/sbin/GCALDaemon/log/launchd.stdout

Easy. Now save the file to your desktop with the name:

net.sf.gcald.plist

Watch out that editor doesn't add a file extension. Next we'll have to move it to it's final destination:

/Library/LaunchDaemons

Go to your desktop, double-click your harddrive ("Macintosh HD", or "OSX", or whatever yours is called). Select the folder "Library", then select "LaunchDaemons". There's a good chance the folder is empty, but never mind, that's ok. Now move the file net.sf.gcald.plist from the desktop to this folder (Indentification might be needed once more). We're almost done.

Finally open a Terminal window again and type in the following line:

sudo launchctl load -w /Library/LaunchDaemons/net.sf.gcald.plist
  1. Hit Enter. You'll be asked for your password. As you enter it the Terminal will not reflect your input, no stars, no nothing, that's normal. Just enter your password and finish with Enter.
  2. <h2>Congratulations, you successfully installed full iCal / Google-Calendar synchronization.</h2>
  3. If you're fine with the terminal you could now start the tool manually with the line
  4. <pre lang="bash">/usr/local/sbin/GCALDaemon/bin/standalone-start.sh

or initialize a first sync with

/usr/local/sbin/GCALDaemon/bin/sync-now.sh

Otherwise you'll have to logout and back in. Remember that the synchronization-interval is 15 minutes and the data transfer might take some time, but for me it by now works perfectly fine and I really enjoy the synced calendaring.

]]> http://blog.kno.at/tools/finally-full-google-calendar-sync-with-gcaldaemon/feed/ 28 The holy Grail: Image browser freeware stuff http://blog.kno.at/tools/the-holy-grail-image-browser-freeware-stuff/ http://blog.kno.at/tools/the-holy-grail-image-browser-freeware-stuff/#comments Sun, 02 Dec 2007 16:47:39 +0000 Kno http://blogs.kno.at/personal/2007/12/02/the-holy-grail-image-browser-freeware-stuff/ I’m a heavy Keep-Everything-Even-If-It’s-Trash kind of person if it comes to digital data. This includes, but is not restricted to, photos. My little crappy snapshot cam is in high use and my flickr-Account already stuffed with a few thousand snapshots. What I really crave for is a little ... »

]]> I’m a heavy Keep-Everything-Even-If-It’s-Trash kind of person if it comes to digital data. This includes, but is not restricted to, photos. My little crappy snapshot cam is in high use and my flickr-Account already stuffed with a few thousand snapshots. What I really crave for is a little handy tool that let’s me manage my photos offline. But I couldn’t find one yet. Also the discussion on my favourite (german) mac freeware-blog OS X Freeware didn’t end up all too promising, so on with the search.

There’s iPhoto packed with OSX, but since I like to have control over my data and iPhoto does stuff like copying photos if you manipulate them and some other uncontrollable stuff it’s no choice. Most of the other stuff is too heavyweight or does too much. I want focused stuff – do what you have to do, and stay slim. Freeware is preferred, of course.

So right now I just downloaded 13 potential candidates to become my favorite photo-assistant and since I’m currently trying the handy offline-blog-management tool ecto I’ll just document each single of those 14 guys on-the-fly to share my experience and ease this process for others. I’m nice, eh?

Candidate #1: CocoaSlideShow

Hm ok, I guess I didn’t carefully read the description here. This tool does what it’s name suggests: It makes slideshows. You add the files, click “view” and there you go: Slideshow. But it’s doing this pretty good, so I’ll keep it for that purpose. You never know. It’s only 280kb, non-installing and keeps focus – the kind of software I like.

Candidate #2: CocoViewX

This is a good thing! First of all it’s offering a great way of browsing. You have a list just like in the finder. Choose the folder to start, and click your way through your collection. Intuitive. As you explore it you find out about it’s features. There’s a drop box: A sidebar on the right, where you can – surprise – drop photos you find for quick access later. It creates thumbnails by default, however you can fasten the whole thing by either turning this behaviour off (there’s a button to do this manually for the folder you’re in) or at least by disabling anti-aliasing for thumbnails.

Under the graphical surface there’s a lot of power, like exif viewing / editing, batch processing, thumbnail generation and a lot more. If you customize the toolbar you’ll find out about the Rotate CW / CCW buttons. Also there’s a slideshow feature, a fullscreen mode and easy access to favorite folders. Looks like the tool to go. Definitely being kept. Ah, and by dragging a picture from the dropbox back to the browsing window you move it from it’s original location (or, with the default finder ALT-key-cheat, copy). I like this. Oh, 3.4MB by the way. On to the next.

Candidate #3: FFView

Now that’s going to be interesting. This is intentionally done to read mangas and comics on-screen. First of all the mac speech control is popping up, so it’s audio-accessible. However I don’t use that feature at all, so none of interest for me. Uhm … strange things happening. The folder browser looks good, however if I click a folder it pops to a fullscreen-window, no file list anymore. Don’t know why, can’t seem to prevent this. Clicking the “list” – icon doesn’t do anything, clicking fullscreen shows the pictures fullscreen, portrait-formats to be scrolled down. I get the idea of that being useful if you read a manga, however I’d like to stop that fullscreen thing with ESC or at least by accessing a menu with the right mouse button. But nope. Had to quit it and won’t start it again :) In a field of 14 starters there’s no 2nd chance.

Candidate #4: FootageHead

Wow, nice. Very fast, very minimalistic: A simple folder-drawer to the left, a viewport to the right. Creates thumbnails and views pictures almost instantly. Perfect for browsing through and deleting the baddies, however doesn’t offer any form of manipulation (even the rotation only affects the view, I couldn’t find a way to save that). But it’s very fast, so I’ll gonna keep it. Funny enough it’s 2.4MB, that’s about ten times the size of CocoaSlideShow by offering quite the same features. But hey, 2.4MB in times of terabyte-harddrives …

Candidate #5: ImageBrowser

Huh, welcomes me with a donation-dialogue and is asking for a code (you get one if you donate). However, the only disadvantage is that this dialogue pops up on startup. And hey, if the program turns out to be great I’ll consider a donation anyway. So on with the testing. First of all customize the toolbar and throw in the useful stuff that’s not there by default: A button for “fit to window”, a dropdown to change the sort-by-behaviour, a dropdown with applications to edit the current file (supports view for videos & audo, as well as selecting all kinds of files and define an editor in the preferences). There’s a button to generate thumbnails for all files in the directory and one to stop, if things get too slow.

The preferences offer a lot of useful customization, like turning off auto-thumbnail-generation, an option to generate thumbnails when the picture is viewed, one-click-file-renaming and so on. However, especially compared to FootageHead, that thing’s real slow. Loading the same picture takes about one second. Sounds fast, but try for yourself. FootageHead beats that by far. But the cool thing about this is I can specify all kinds of programs to show up in the edit with dropdown, so I’ll probably keep it as a small browser to edit specific types of files. There’s potential, but the image-thing doesn’t work all that well …

Candidate #6: Image Browser X

Similar name, other software. They’re not related. This one starts up kind of weird, with a huge info dialogue and a strange startup-window … hmmm. Hm ok, whyever that one was listed as an image-browser, it in fact isn’t. You have to “prepare” single pictures first, with a helper application, and I guess you then can view it or stuff, but that’s not what I was looking for at all. So on with the tool testing.

Candidate #7: Images

Yep, I really think it’s good for software to have unique name. Makes it easy to find in Google, does it not? Okay, I’ll not be too sarcastic, due I admire people releasing free software. This thing is neither visually beautiful, nor very functional. It’s preview is slow, you can’t edit anything. It’s basically pretty much the same as the finder, just with less functionality and worse looking. Sorry, but this just is … uhm … useless (ah, turns out it’s a java-app. Those tend to be slow, and are just not the way to go for imaging software).

Candidate #8: ImageWell

Once more an application that’s not for browsing. There are some nice features, like flickr-uploading, iDisk uploading and stuff like that. You can add watermarks and do some fancy editing. But once again it’s slow, especially with bigger pictures, and there’s no browsing-like-functionality whatsoever. Probably does another job real well, but it’s no good for what I need. So dismissed.

Candidate #9: MultiThumbs

Starts up with a huge dialogue and an easy-to-understand message: Open a folder with the file menu or drag photos here. I’ll do the file menu thing. Ok, it opens the folder, creates thumbnails and displays them clean on a black background. I didn’t check out the preferecnes, but you can open a photo fullscreen by clicking it and probably do some more stuff – however the creation takes it’s time and isn’t anything like browsing. So this one also isn’t what I am looking for, however does another nice job so if you’re looking for thumbnail-stuff give it a try.

Candidate #10: Photopolis

Ok, this is an exotic thing. It will use photo’s creation dates and build a virtual town (3D) you then can walk through, for example on the “December Street” or the “2007 Street” (years = vertical, months = horizontal). No for the startup. Ok, the first thing with an installation dialogue. I don’t really like this, because I want lightweight stuff I can just delete if I don’t need it anymore, but I really want to try this. I chose my whole pictures-folder (1.5GB). It’s 16.18 now. The progress bar looks good, seems to process the pics kind of fast (yeah, Live-Blog-Reporting. I should do this for a NFL-game: “NOW ALL NEW: LIVE-BLOG-ENTRY-WRITING-AND-AFTERWARDS-READING – All the excitement, as fast as you like!” 16.35 – it’s done. 17 minutes to export 1.5GB isn’t all that bad. Now for the city. Wow, that’s really nice. It’s damn slow on my PBG4 though (3fps isn’t that exciting), but on a fast machine this most be great. Give it a try, it’s a great way to explore your archive! Not of much use, but hey – life’s not only about efficiency.

Candidate #11: PixelWalker

Starts up instantly and the first impression is good – kind of like the column browsing in finder, but all columns accessible. Looks good to me. I’ll check the toolbar and the preferences. Ok, nothing there. The toolbar includes everything, the preferences are minimalistic: Choose your default editor, add file extensions to exclude and decide if thumbnails shall be loaded in the background. Now for the program. Hm ok, it’s kind of fast, but uhm … uncomfortable to operate. There’s four states of window arrangement, bot none with thumbnails + browsing. You can browse to a folder and then switch to thumbnail view, but you can’t see thumbnails as you browse. Not so good. Ok, the shortcuts for the views are 1 – 2 – 3 – 4, so switching is as easy as can be. This way you can browse very fast with the keyboard. Strange enough the folder-view doesn’t show some of the pictures, whereas switching to thumbnail view lists everything. I’ll keep this one and play around a little more, could be handy to find stuff. The thumbnail creation is pretty fast.

By the way it just turned out that any of the tools tested until now has manipulated some of my files. Renamed them quite strangely, one Thumbnails-subfolder has been created … damn, that’s the stuff that just shouldn’t happen at all. Should have checked that after every tool, shouldn’t I? Indeed, I should. DAMN.

Candidate #12: Xee

A highspeed starter. The preferences are loaded with keyboard shortcuts. A few highlights: You can define up to 10 destinations and define shortcuts to move or copy pictures there. Basically you can browse through any folder with the keyboard damn fast and “throw the pictures around” with ease. Sounds like one hell of a productivity application. Wooohooo! Image display is the fastest yet. I like the keyboard navigation, however the scroll wheel works just as fine. There’s a crop function and you can save the cropped part to a new file, however can’t just overwrite the original (what’s probably a good thing). Also you can mirror and rotate pictures and save that over the original file. Somehow the preview isn’t updated, so if you move on to the next pic and go back the just rotated image will show up as before the rotation, but the file is updated. Strange. I like Xee.

The statusbar shows a lot of Info, like how many frames (this not only includes animations, but also the default finder-preview is detected as another frame – neat!), the zoom rate, the total picture count in this folder, date & time, file name, file size in bytes and file dimensions in pixels. There’s a fullscreen-mode as well. That’s the closest thing to IrfanView (PC) and it’s going to have a fix place in my tool collection. Recommended!

Candidate #13: RapidoMap

Ah, finally another one with an installation dialogue. But this isn’t a picture browser, it’s something special I decided to give a try: It’s a geotagging-tool, for adding your photos to a map. Based on yahoo-maps it first of all fetches map data from the web. Now I can add locations. The interface is simple and functional, I like this. As I geotag all my flickr-images and this application has a built-in flickr-upload function it’s just one thing: Perfect. Well, almost. Unfortunately it won’t let me add locations when I’m offline. I need a tool like that for travelling. I want to add locations based on addresses wherever I am, add the photos and the next time I connect to the web the app should assign the locations to the map and let me upload the photos. By now the tool just won’t let me start it up if I’m not online, but I wrote a feedback mail and am looking forward to the reply. After all it can’t be that much of an issue to implement this, it’s just delayed assigning of the info. THEN it would be perfect.

Preview: JetPhoto Studio & a view more

Just stumbled upon this handy thing. With 20MB it’s real heavyweight compared to the rest, but it looks damn promising: Calender view, flickr-integration (tagging, geotagging, uploading, organization by EXIF-data, …) The downloads almost done, now for the testing. I expect another installation dialogue ;)

Also I found more freeware image stuff, I’ll continue my report another day – I’m tired of this screen and I already unpacked too much stuff for one day by now. A quick summary of today’s odyssey: Xee, CocoView X, Footagehead are potential candidates for browsing, as is Pixelwalker. CocoaSlideshow will be kept, cause you never know and it’s just nice, plus ImageBrowser will stay on the disk for browsing other stuff than images.

]]> http://blog.kno.at/tools/the-holy-grail-image-browser-freeware-stuff/feed/ 2 One random photo from your flickr-stream http://blog.kno.at/tools/one-random-photo-from-your-flickr-stream/ http://blog.kno.at/tools/one-random-photo-from-your-flickr-stream/#comments Sat, 01 Dec 2007 20:51:16 +0000 Kno http://blogs.kno.at/doc/2007/12/01/one-random-photo-from-your-flickr-stream/ Note: Since ANY badge-url will work you can use randomFlickr with whatever photo you feel like, if your badge fetches the most recent photo of a category that’s what will be used, you’re only limited by what the badge-url can do I’m a heavy flickr-user, trashing it with all my ... »

]]> Note: Since ANY badge-url will work you can use randomFlickr with whatever photo you feel like, if your badge fetches the most recent photo of a category that’s what will be used, you’re only limited by what the badge-url can do

I’m a heavy flickr-user, trashing it with all my snapshots, useless party-pics, all kinds of stuff. And I like to use my flickr photos outside flickr, e.g. on my personal blog. Now there’s the flickr API and all kinds of wrappers and kits, but all of this is kind of hardcore stuff if the task as simple as: Gimme one random photo from my stream. randomFlickr.class can do this for you.

Download V 0.6

Donate (PayPal)

Applying filters requires PHP5+. There’s a PHP4 version available, too. GD Library 2 is required for image resizing, that should be included as a standard extension. If you plan to do anything above that I’d suggest having a look at the various available PHP-tools for flickr:

But if all you want to do is fetch a single photo then have a look at the randomFlickr Demo. Now for the documentation.

The initial bright idea was brought to me be an article I can’t seem to find anymore, but I’ll try to give proper credit. The class utilizes a flickr-feature: Javascript-badges. There’s a page to create a badge on flickr, which results in a JavaScript / CSS codeblock. While that works it has a few major downsides:

  • it’s javascript where javascript definitely isn’t appropriate
  • it doesn’t give control over the images themselves
  • it only can fetch kind of small images

But what it does is it provides the necessary image data we then can process with PHP. For the development I used this badge-url I set up to fetch one random medium-sized image from my whole photostream. Click the link to see what the returned HTML/JS-Stuff looks like.

Focus

While building the class I always had one thing in mind: This is for one image, nothing more, so the class was built to offer a nice variety of things to do with that one picture, however doesn’t support anything beyond. The final result should achieve three goals:

  • light-weight
  • easy to use
  • easy to integrate

Basic usage

Most of the code is kind of self-explanatory and, as I like it, heavily documented, so best you just browse through the class file you can download from the demo-page. Now for the class. It’s kind of hard to wrap my mind inside-out back to the start now that all is done, so I’ll do it the other way round and explain what’s happening from the usage point-of-view, that should work. So let’s have a look at how the thing is integrated on a webpage:

/flickpic/index.php
  1. <?php
  2. $badge  = 'http://www.flickr.com/badge_code_v2.gne?count=1&amp;display=random&amp;size=m&amp;layout=x&amp;source=user&amp;user=7353617%40N04';
  3. $width  = 400;
  4. $height = 240;
  5. $gray   = true;
  6. include_once('flickpic.php');
  7. ?>

This is the more ‘dummy-friendly’ way to integrate, since there’s hardly anything related to coding. Just replace the badge url with whatever badge you want, modify the size settings and you’re fine. The $gray-thing converts the image to grayscale, if set to true. Using the whole thing this way will result in an image linked to it’s flickr-page and doesn’t require anyone to write any php, or to alter any files. We’ll shortly reveal the real magic, so hold on for a more programmer-like approach giving you the details you want.

A few more details: flickpick.php

/flickpic/flickpic.php
  1. if ( !isset($_REQUEST['imageUrl']) )
  2. {
  3.     try
  4.     {
  5.         $x = new randomFlickr($user);
  6.         if ( $badge )
  7.         {
  8.             $x->setBadgeUrl($badge);
  9.         }
  10.         $x->fetch();
  11.     }

Line 08 checks if an image-url has already been submitted. That’s not the case when including the file, so what’s about to be done is to display some nice HTML to display the image. try – catch is needed due the methods throw exceptions. In line 12 the randomFlickr-object is being created using a variable $user. This variable isn’t specified here, therefore will just be ignored. Then we check if a badge-url has been specified in $badge. If so, we change the object’s badge url according. Time to fetch some data on line 17.

A few words about the fetch()-method. It will check if there’s a user id specified (the ugly flickr user-id string, that is, due the badges don’t seem to work with the usernames). If so, it uses the default badge-url for 1 random image and passes that user-id. Easy. If there’s no user specified, the badge-url will be used as-is. That way there are four possibilities to get a valid result:

  1. specify a user and rely on the default url
  2. specify a full badge-url
  3. specify a user and a badge url
  4. specify nothing and pass the user-id to fetch() (will override a stored username for this one call only)

The method doesn’t really do much, just usual dirty regex-info-fetching, no great inventions there. Most important, it doesn’t retrieve the actual image, it just sets up meta-information, like dimensions, title and that kind of stuff. So let’s go on in the code of flickpic.php:

/flickpic/flickpic.php
  1. $src_post = ( $width ? "&amp;width=$width" : '' ) . ( $height ? "&amp;height=$height" : '' ) . ( $gray ? '&amp;grayscale' : '');
  2. $http = 'http://'. $_SERVER['HTTP_HOST'] . dirname($_SERVER['REQUEST_URI'] . 'x') .'/'. $relpath;
  3.  
  4. print ( $x->getHtml(false, array('src_pre' => $http .'flickpic.php?imageUrl=', 'src_post' => $src_post, 'fixwidth' => $width, 'fixheight' => $height)))

The first line builds a parameter src_post, the next line uses the current directory (the ‘x’ is added to “simulate” a file if the home dir is being requested, otherwise we’s loose one directory here – just try, it’s stupid to explain) plus any specified relative path to build the path to this file for the output-generation later. Now the next line does some magic. It prints the result of the getHtml()-method which, obviously, generates HTML code. Let’s have a look at the method and the parameter, due this is one of the most flexible parts of the whole thing:

HTML is what we need

/flickpic/randomFlickr.class.php
  1. //  @param  string  $sFormat    the new format – anything you want, that is

So there’s the first parameter $sFormat. This parameter will, if specified, override the object’s default HTML-template (this can also be done permanently using the setDefaultHtml()-method). HTML-Template? Yessss! The class uses this default HTML to create the output: <a href=”{url}” title=”{title}” class=”{class}”><img src=”{src}” title=”{title}” alt=”{title}” {html_dim} /></a>, so nothing more than a link-wrapped image. BUT note the template-variables enclosed by {}. There’s a whole bunch of them available, namely:

  • {title} title fetched from flickr
  • {url} url for the link the image is wrapped with
  • {src} image’s src
  • {html_dim} image’s dimensions as html attributes (see getHtml() for details)
  • {width} image’s width
  • {height} image’s height
  • {hwidth} width value used for the html-attributes (image’s width or fix width)
  • {hheight} height value used for the html-attributes (image’s width or fix width)
  • {fixwidth} value passed to getHtml() to use for width-attribute
  • {fixheight} value passed to getHtml() to use for height-attribute
  • {class} a string for a css-class

All these variables can be used in custom HTML-Templatecode to suite all kinds of possible ajax or whatnot needs, thus making the display as flexible as you like. But back to getHtml(). There’s a list of special parameters to pass as indices of an associative array (second method parameter $aParams):

  • ‘fixwidth’: for the width=”" attribute of the <img>
  • ‘fixheight’: for the height=”" attribute of the <img>
  • ‘nativedim’: the image’s real dimensions will be used for width=”" & height=”"
  • ‘class’: for the <a>, by default
  • ‘src_pre’: inserted just before the image’s src
  • ‘src_post’: inserted right after the image’s src
  • ‘url_pre’: inserted right before the url to the image

Using those values the image source can be utilized as a parameter for a PHP script (that’s what flickpic.php does), giving us <strong>much</strong> more possibilities to control it’s appearance. All possibilites, that is. Now on to that part that’s responsible for generating the actual image:

Now for the image

/flickpic/flickpic.php
  1. $x = new randomFlickr();
  2. $x->init('', urldecode($_REQUEST['imageUrl']));
  3.  
  4. if ( isset($_REQUEST['width']) || isset($_REQUEST['height']) )
  5. {
  6.     $x->resize(( isset($_REQUEST['width'])   ? $_REQUEST['width']  : false ),
  7.     ( isset($_REQUEST['height'])  ? $_REQUEST['height'] : false ));
  8. }
  9.  
  10. if ( isset($_REQUEST['grayscale']) )
  11. {
  12.     $x->applyFilter(IMG_FILTER_GRAYSCALE);
  13. }
  14.  
  15. $x->send( 90 );

There you go. First of all a new randomFlickr-object is being created (the script is called again, so there’s no object there). Then the actual image is loaded with the init()-method. This method either uses the data already present within the object or any passed url (the urldecode() is necessary because the script generates XML-validating URLs, thus urlencoding all parameters. By the way the method can also be used to fetch any non-flickr image, if you only want to use it for the image manipulation the class offers). The init()-method accepts two parameters. The first one is for the image size. If not specified, the default size (large) will be used. Then for the probably most important feature the class has to offer: Intelligent image resizing:

  • Only width / height specified: The image will be resized proportionally
  • width & height specified: The image will be resized proportionally to fill the whole format, then will be cropped to it’s center

This way you can show your pictures in any unusual format, what’s not only cool but also handy if it comes to fitting them into your design. On with the code. The next thing we’re doing is we check for the grayscale-variable. If it’s set we apply the grayscale filter (we’re clever, aren’t we?). The applyFilter() method is a full-featured wrapper for the imagefilter-function, so have fun doing stuff!

Finally the last line sends the appropriate headers and the image data itself. So the endresult is kind of a recursive script (probably not, but sounds sophisticated) that doesn’t need much of editing to work for anyone, but provides a lot of flexibility if you’re willing to play around in flickpic.php.

Version History

  • 2008-04-02: V0.6

    There’s new options to choose different source-sizes. Specifying $size = “auto” will let the script guess which version to use based on the destination dimensions. This, however, may only work for close-to-standard formats, you might want to either leave everything as it is if it’s working or use one of the new constants to explicitly define which source to use:

    • xxs = 75px by 75px
    • xs = 100px by X
    • s = 240px by X
    • m = 500px by X
    • l = 1024px by X
    • xl = your uploaded file

    Note that flickr always uses the bigger side to scale the sizes, so portrait-format images will be scaled to 1024/500/240/100 Pixels height, while landscape-format images will be scaled to 1024/500/240/100 Pixels width. The three smaller sizes are the ones being used by flickr itself and are fixed-size.
    Oh, and I switched the Demo-Page from XHTML 1.1 back to XHTML 1.0, due to the inability of some browsers to handle the application/xml mime-type. Welcome to randomFlickr, Win IE6 Users.

  • 2008-03-19: V0.5

    now falling back on CURL if allow_url_fopen is disabled. As the title says the script now checks if allow_url_fopen is enabled, if not it tries to fall back on the CURL-library. One of both should be available on every hosting plan and I hope compatibility increased.

  • 2007-12-07: V0.4

    PHP4-Version: There now is also a PHP4-Version. Please note that image-filters are only available in PHP5, thus the PHP4 version can’t convert your images to grayscale, thus resizing + cropping work perfectly fine.

]]> http://blog.kno.at/tools/one-random-photo-from-your-flickr-stream/feed/ 48 Das erste offizielle Kno-Plugin http://blog.kno.at/tools/das-erste-offizielle-kno-plugin/ http://blog.kno.at/tools/das-erste-offizielle-kno-plugin/#comments Sat, 17 Nov 2007 16:15:38 +0000 Kno http://blog.kno.at/2007/11/17/das-erste-offizielle-kno-plugin/ Da i seit a kurzem net nur WordPress zum Bloggen verwend, sondern im Zuge eines Umzugs (man beachte den gefinkelten Wortwitz! Ha. Hahaha!) und aufgrund der Tatsache, dass i mehrere Blogs führen werd (und woascheinlich alle davon a weng inkonsequent, oba do foit ma scho no wos ei) auch WordPress MU, ... »

]]> Da i seit a kurzem net nur WordPress zum Bloggen verwend, sondern im Zuge eines Umzugs (man beachte den gefinkelten Wortwitz! Ha. Hahaha!) und aufgrund der Tatsache, dass i mehrere Blogs führen werd (und woascheinlich alle davon a weng inkonsequent, oba do foit ma scho no wos ei) auch WordPress MU, mit dem ma mehrere Blogs verwalten kann. (Wer sich für so a Lösung intressiert dem sei mein Vergleich Moveable Type 4 vs. WordPress MU an’s Herz gelegt).

I mag AJAX-Funktionen (des neimodische Zeig, wo ma net Seiten neu laden muss, sondern des alles gaunz toll vollautomatisch tuat) und wollt’ mir ein AJAX-Kommentar-Plugin installieren, hob aba keins gefunden, des funktioniert hat. Also hab’ i selber eins gebastelt.

]]> http://blog.kno.at/tools/das-erste-offizielle-kno-plugin/feed/ 0 Moveable Type 4 vs. WordPres MU http://blog.kno.at/tools/mt4-vs-wpmu/ http://blog.kno.at/tools/mt4-vs-wpmu/#comments Sun, 04 Nov 2007 17:01:34 +0000 Kno http://blogs.kno.at/doc/2007/11/04/moveable-type-4/ Since I set up WordPress MU in order to manage a few blogs from one central tool it just so happened that I found out about Moveable Type 4. As I was fine with WordPress I didn’t think much of looking at other blog-applications, so I just didn’t care. Today I stumbled upon MT4. And I ... »

]]> Since I set up WordPress MU in order to manage a few blogs from one central tool it just so happened that I found out about Moveable Type 4. As I was fine with WordPress I didn’t think much of looking at other blog-applications, so I just didn’t care. Today I stumbled upon MT4. And I thought I’d just give it a try. See what the very superior me knows 10 minutes after getting MT4 up and running.

Basic Differences

First things first: MT isn’t a tool for the casual user. It’s another approach than WordPress. While the latter is an encapsulated PHP-application aimed to be as simple as possible (upload – customize – blog), MT feels much more like a publishing platform. The first difference is the installation. For WordPress (MU is pretty much the same, the differences are minor) that is:

  1. Upload to your desired operating and blogging directory.
  2. Call the installation script
  3. Start Blogging

Whereas the MT installation looks like this:

  1. Upload the Application to your maintenance directory
  2. Adopt the configuration file
  3. Call installation script
  4. Login to the Maintenance Part
  5. Create blogs wherever on the server you feel like having one
  6. Start blogging

The difference might not look that big, however I think it is. It’s another backend approach of publishing content. Let’s have a look at my WordPress MU and my Moveable Type 4 installations to compare.

WordPress MU

  • Main Site: http://blogs.kno.at/
  • Maintenance: http://blogs.kno.at/wp-admin/
  • Automatically sets up a “godfather-blog” at the Main site location
  • Various blogs are here: http://blogs.kno.at/blog-name/
  • Various blogs administration is there: http://blogs.kno.at/blog-name/wp-admin/

Moveable Type 4

  • Main Site: http://kno.at/apps/mt/
  • Maintenance: http://kno.at/apps/mt/
  • From the beginning, there’s only the basic application
  • Various blogs are here: Every blog’s address can freely be assigned
  • Various blogs administration is there: http://kno.at/apps/mt/

So what’s that mean?

For WordPress MU, the location where files are stored, the overall handling of what’s being done where and the paths to the blogs are fixed. If I chose to use subdomains for blogs and my domain is example.com, all my blogs will have an url like blogname.example.com. If I chose dubdirectories all my blogs will have an url like example.com/blogname. Eventually uploaded files will be stored in wpmu/wp-content/blogs.dir/. Period.

For Moveable Type things are more flexible here. Let’s pick up that example.com – example (uh, repetition!): My domain is example.com. Now I can set paths and URLs for all Blogs to whatever I feel like. There can be blogs with URLs like blogname1.example.com, example.com/blogname2, example.com/here-be-blogs/blogname3, it just doesn’t matter. Also I can easily have my blogs spread all over the domain URL-wise, but keep all my data organized by pointing the storage paths like so: /home/www-root/blogdata/blogname1, /home/www-root/blogdata/blogname2, /home/www-root/blogdata/blogname3. Note that as far as I found out by now you’ll have to care about URL-rewriting yourself!

More crucial differences

The name Moveable Type isn’t just for fun and cosy Web2.0ish feelingness. Actually it’s what the application does – creating moveable contents. That is because, by default, MT4 creates static files every time something is changed in the specified publishing directory for everything – images, archives, feeds. So if I want to move my blog from one domain to another, all I have to do is to move those files to their new location. Neat!

More about moving

Actually it’s not that easy because MT4 currently builds the files with absolute URLs. I couldn’t find an option to change this to relative and am not absolutely sure why this is, but I guess it’s answered somewhere in their FAQs. However it still doesn’t require any magic to do this, because MT comes packed with two options particularly helpful in this case: Blog Cloning and URL changing. Both do exactly what they are called. You might clone a blog any time, to whatever location you feel like. For that cloned blog you then might change the base URL any time, resulting in a full rebuild with the new absolute URLs. If this new URL is on another server and you plan to keep blogging there you’ll have to migrate the database and the actual Moveable Type application too, by the way. At least as far as I see by now. However the static-file-thing would make it easy to write a small shell-script (or even MT-plugin) to automatically synchronize any blog with any FTP location wherever you feel like having your blog. There are also options to publish your blogs dynamically, however when I tried I got 404s for all files except the directory itself – but this might be because of errors in my custom root-.htaccess configuration (I hope not).

Conclusion

I guess the choice really depends on your needs and likings. If all you want to do is blogging, WordPress MU will do just fine. If you want to implement a content management system you might want to consider Moveable Type, due it seems to be much more flexible and appropriate for those things. My opinion, however, might not be very valuable by now, since I only had a rough glance at Moveable Type and don’t know nothing about how flexible it can be used, extended or modified, whereas I have quite a bit experience on doing those things with WordPress.

]]> http://blog.kno.at/tools/mt4-vs-wpmu/feed/ 0 WordPress MU and AJAX comments http://blog.kno.at/tools/wordpress-mu-and-ajax-comments/ http://blog.kno.at/tools/wordpress-mu-and-ajax-comments/#comments Sat, 03 Nov 2007 15:35:16 +0000 Kno http://blogs.kno.at/doc/2007/11/03/wordpress-mu-and-ajax-comments/ Discontinued This plugin has been discontinued. There are better, more compatible ones available by now so there’s really no reason to further support this one! How complicated could it be to adopt a WordPress plugin to work with WordPress MU? Pretty complicated, if you’re the purist and ... »

]]> Discontinued

This plugin has been discontinued. There are better, more compatible ones available by now so there’s really no reason to further support this one!

How complicated could it be to adopt a WordPress plugin to work with WordPress MU? Pretty complicated, if you’re the purist and perfectionist I am. From adoption to rewrite, up to a weird WordPress issue i am currently fighting.

Starting

I already mentioned a while ago that I am looking for an elegant solution of combining multiple blogs. Well, turns out that WordPress can do just this for me, with the superior free thing that WordPress MU is. During installation I stumbled up a PlugIn that is called AJAX Comments, and this is something I always wanted to have in WordPress. So i thought I’ll just grab it, bring it to WordPress MU and enjoy the sexyness of AJAXified commenting.

I wished.

Reality turned out to be much more cruel. First of all the plugin didn’t work. Ok, probably I’m just missing out on a few adoptions. Probably that would have done the trick, but as I started digging into the code I got enthusastic to bring this thing to a more sophisticated stage of operating. What was bothering me about that PlugIn?

  • It’s all mixed in one file
  • The whole comment processing happens independent from WordPress core functionality
  • Therefore it’s interfering with other plugins
  • It needs in-depth adoption for different themes, which especially for use with WordPress MU seemed to be a problem

Please note that, by now, there’s still a problem with fetching the WordPress error message, so the PlugIn will just use a generic, non-localized, uninformative standard error message!

Organize, baby!

So I started rewriting (as I thought it might be interesting to others I added precious documentation to everything, so if if you’re not interested in my rambling and just want to get to the code have a look at the sources). First of all WordPress MU seems to not like PlugIns inside folders (at least not in the folder /mu-plugins), so I put the main file to /mu-plugins and added the folder for the additional stuff. Then I started separating functionality. The JavaScript was output through that very file, due it needed a few little parameters. I took the whole JS-functionality and put it into one clean, static .js – file and then hooked in a few variable definitions that would solve the parameter problem. So let’s have a look how the JavaScript-sections turn out after the little rework.

@/wpmu/mu-plugins/ajax-comments.php
  1. global $ajax_comments_count;
  2. $ajax_comments_count = 0;
  3. add_action('wp_footer',    'ajax_comments_getcount');
  4. add_action('comment_text', 'ajax_comments_countdisplay');
  5. add_action('wp_head',      'ajax_comments_js');

What for?

43, 44 and 45 handle with a simple but annoying issue. The problem is that when a page is viewed by anyone who is logged in chances are that there are more comments actually being displayed than are approved. For example if you’re an admin you’ll see all unapproved comments, but the variables available in WordPress core functions don’t tell us anything about how many comments there actually are on the page. So what I did was to hook a function to comment_text, abusing a filter, to increment the global variable $ajax_comments_count by 1 for every actually displayed commment. Neat:

  1. @/wpmu/mu-plugins/ajax-comments/functions.php
  2. function ajax_comments_countdisplay($comment = '') {
  3.      global $ajax_comments_count;
  4.     $ajax_comments_count++;
  5.     return $comment;
  6. }

Line 44 hooks in just before the closing body-tag and hardcodes the JavaScript variable telling the scripting-magic-pixie-stuff if there’s an even or odd number of comments:

  1. @/wpmu/mu-plugins/ajax-comments/functions.php
  2. function ajax_comments_getcount() {
  3.    global $ajax_comments_count;
  4.    echo '<script type="text/javascript">ajax_comments_odd  = '. ($ajax_comments_count % 2 == 0 ? 'true' : 'false') .';</script>' . "\n";
  5. }

Multiple Theme Support

Line 46 deals with everything else regarding JavaScript, including theme-specific settings. Yep, if you install the original PlugIn it soon turns out that you’ll have to modify it for various themes. That’s disturbing, but ok in general. However, when using this for WordPress MU you’d run into problems if the available themes use different markup. So I added a few settings to make this more flexible:

@/wpmu/mu-plugins/ajax-comments/functions.php
  1. function ajax_comments_js() {
  2.    require_once('themes.php');
  3.    if (!$ajax_comments_themes['hardcode']) {
  4.        $curTempDir = (substr(TEMPLATEPATH, strlen(dirname(TEMPLATEPATH))));
  5.        $allThemes  = array_keys($ajax_comments_themes);
  6.        for ($i=0; !is_array($theme), $i&lt;count($allThemes); $i++) {
  7.            if (strpos($curTempDir, $allThemes[$i])) {
  8.                $theme = $ajax_comments_themes[$allThemes[$i]];
  9.            }
  10.        }
  11.        if (!is_array($theme)) $theme = $ajax_comments_themes['default'];
  12.    } else {
  13.        $theme = $ajax_comments_themes[$ajax_comments_themes['hardcode']];
  14.    }

Okay, so let’s have a look at this. Line 2 includes the theme-settings script themes.php. In this script you can specify theme-specific settings, like so (this also is the default setting the PlugIn falls back to if it can’t figure out anything else):

  1. @/wpmu/mu-plugins/ajax-comments/functions.php
  2. $ajax_comments_themes['default'] = array(
  3.     'commentform',   // [0] = id or classname form
  4.     'commentlist',   // [1] = id or classname 04: comment-&lt;ol&gt;
  5.     'commentform',   // [2] = id or classname element comments are inserted before
  6.     ''               // [3] = comma-separated list of element-id's to hide
  7. );

Line 3 is easy: If there’s a hardcoded theme-setting the PlugIn will obey, use it and just go on. The more interesting part happens if there’s no hardcoded setting. Then the current template path is used to find a matching setting (hint: if you add settings, name them according to the directory they are located at and all the magic will do just fine). If there’s no matching setting available, the default settings will be used, matching the default kubrick-theme.

  1. @/wpmu/mu-plugins/ajax-comments/functions.php
  2.     $hideMore = $theme[3];
  3.     if (strpos($hideMore, ',') !== false) {
  4.         $all = explode(',', $hideMore);
  5.         for ($i=0; $i&lt;count($all); $i++) {
  6.             $all[$i] = trim($all[$i]);
  7.         }
  8.         $hideMore = join("','", $all);
  9.     }
  10.  
  11.     if (!empty($hideMore)) $hideMore = "'". trim($hideMore) . "'";

$hideMore can be one or many Id’s, so the PlugIn has to act accordingly, creating a nice string that can be used as output to feed the new Array() that soon will follow:

  1. @/wpmu/mu-plugins/ajax-comments/functions.php
  2.     echo '<script type="text/javascript" src="'. PLUGIN_AJAXCOMMENTS_ROOT.PLUGIN_AJAXCOMMENTS_PATH .'ajax-comments/scriptaculous/prototype.js"></script>' . "\n";
  3.     echo '<script type="text/javascript" src="'. PLUGIN_AJAXCOMMENTS_ROOT.PLUGIN_AJAXCOMMENTS_PATH .'ajax-comments/scriptaculous/scriptaculous.js"></script>' . "\n";
  4.     echo '<script type="text/javascript" src="'. PLUGIN_AJAXCOMMENTS_ROOT.PLUGIN_AJAXCOMMENTS_PATH .'ajax-comments/ajax-comments.js"></script>' . "\n";
  5.     echo '<script type="text/javascript">' . "\n"
  6.         .'  ajax_comments_path = "'. PLUGIN_AJAXCOMMENTS_ROOT.PLUGIN_AJAXCOMMENTS_PATH .'";' . "\n"
  7.         ."  ajax_comments_form = '${theme[0]}';\n"
  8.         ."  ajax_comments_list = '${theme[1]}';\n"
  9.         ."  ajax_comments_here = '${theme[2]}';\n"
  10.         ."  ajax_comments_hide = new Array($hideMore);\n"
  11.         ."</script>\n";
  12. }

On to sophisticated AJAX-Magic

There you go. All JavaScript-stuff done, theme-related settings included. So we can head on to the next part our PlugIn will have to do server-sided: Handling the AJAX-request. Here is where to biggest changes happened, because I totally changed the way this worked. The original PlugIn was called instead of WordPress, then imported WordPress-functionality and finally handled the comment-process itself, hardcoded and separated from core WordPress functionality. This is a method I just can’t get along with. Not only does it intefere with all other PlugIns by just stripping them out, but it also makes the PlugIn very unstable due it totally relies on the current state of WordPress.

Integrating

PlugIns should be integrated into, and therefore benefiting of, the core application’s functionality. WordPress offers a very nice way of doing so: Hooks, that is. I already handled the JavaScript-stuff with hooks, so doing the same with the AJAX-functionality seemed like a good and clean idea. After a little research, however, it turned out that action hooks are a kind of unconsistent implemented thing. There are a lot of hooks, granted, but there are also a lot of hooks missing. Especially if it comes to comments, things get kind of weird. When WordPress encounters an error there’s a good chance it will simply call wp_die();, thus killing the app immediately, without any notice to PlugIns. That’s no good. But let’s get back to this later. First the core AJAX-section:

  1. @/wpmu/mu-plugins/ajax-comments.php
  2. if(isset($_POST['ajax-comments-submit'])) {
  3.     add_action('comment_post', 'ajax_comments_send');
  4. }

Update: The PlugIn now takes the whole error-page as a response and then strips out the error-message from there. This way no files need to be modified whatsoever.

The first hook is a native WordPress-hook and calls ajax_comments_send() after a comment is saved to the database. That’s exactly when we want to jump in to cut off the regular application, fetch the last comment and send it back as AJAX-response. Nice. However when I started looking for the hook when a comment-error is encountered I soon realized how loose WordPress’ error-handling is. To be honest I was disappointed, that’s really bad implementation there. Let’s have a look at wp-comments-post.php and see what’s happening if there’s an error:

  1. @/wpmu/wp-comments-post.php
  2. // If the user is logged in
  3. $user = wp_get_current_user();
  4. if ( $user-&gt;ID ) {
  1. @/wpmu/wp-comments-post.php
  2. } else {
  3.     if ( get_option('comment_registration') )
  4.         wp_die( __('Sorry, you must be logged in to post a comment.') );
  5. }

Uhm … great. No error is being generated, no action is being called, no handling of this issue whatsoever occurs. The developer is being left with a silent application kill, that’s just a no-go. If wp_die() would call do_action() at least we could react to this in some way, however we can never be sure what happened, because there’s no error code or anything like this. All we would know is: The application has been terminated. Have fun! However, that seems to be the most we can do without going in for some really crucial changes on WordPress’ core. So I added one line of code that should keep me busy for about 10 hours or so:

Update: The PlugIn now takes the whole error-page as a response and then strips out the error-message from there. This way no files need to be modified whatsoever.

AJAX-Response

Looks easy and makes sense, due the function ajax_comments_send() is hooked in to wp_abort and the $message is the most we can get out of WordPress at the time. I’ll explain the problem with this line at the end, due it’s still unresolved. Let’s have a look at the last function:

  1. @/wpmu/mu-plugins/ajax-comments/functions.php
  2. function ajax_comments_send () {
  3.     $passed  = func_get_arg();
  4.     $comment = @get_comment($passed);

So far, so easy. We fetch the argument, check if it was a valid comment-id, and die() with whatever error-message has been sent by do_action(‘wp_abort’) being identified with a status code 406 header if something went wrong. get us the saved comment’s data and go on:

  1. @/wpmu/mu-plugins/ajax-comments/functions.php
  2.         header('Content-type: text/html; charset=utf-8');
  3.         ob_start();
  4.         $comments = array($comment);
  5.         global $comment;
  6.         include(TEMPLATEPATH.'/comments.php');
  7.         $commentout = ob_get_clean();
  8.  
  9.         preg_match('|(<li.*</li>)|ims', $commentout, $matches);
  10.  
  11.         die($matches[1]);
  12.     }
  13. }

This part is hardly modified from the original. This idea is great and I love the simplicity how the comment can be integrated in the current theme without any problems. What we do is we call the template with a fake list of comments only including the one generated by the AJAX-request. Then we fetch out this one comment from the generated HTML and return it. Lovely! And works perfect. Basically I only changed the regexp to fetch the whole list-item, not to loose any attributes. The alternation will be dealt with via JavaScript.

Update: Due the function is only being called if a comment has successfully been saved we don’t need to implement any kind of error handling here. How useful would the message ‘unknown error’ be anyways?!

Finally: DHTML

This part already was very nice, so I only made a few minor changes. I didn’t like the alerts so I added a function that would display the message inside a div with the id ajax-comments-message, nested in another div and getting class error attached if status code 500 is being returned (wp’s header status for wp_die()). Also, if the result is an error, the actual message has to be fetched from the whole page, which is pretty easy due to very simple markup. A lot of words, let’s just have a look of how this turns out:

  1. <div id="ajax-comments-message" class="error">
  2.     <div>
  3. the message
  4.     </div>
  5. </div>

The outer div is for easy CSS access and may has the class error, the inner div is for DHTML compatibility (guaranteeing a firstChild-node) and contains whatever WordPress returns in $message (at the time either p or ul). Furthermore in the original plugin there was no check if the form is there. So I added an onload-block:

  1. @/wpmu/mu-plugins/ajax-comments/ajax-comments-js
  2. ac_oldLoad = window.onload;
  3. window.onload = function () {
  4.     ac_oldLoad;
  5.     f = ajax_comments_find_element(ajax_comments_form, 'form');
  6.     if (f) {
  7.         f.onsubmit = ajax_comments_submit;
  8.         new Insertion.Bottom(f, '<input id="ajax-comments-submit" name="ajax-comments-submit" type="hidden" value="1" />'); // toggle ajax-catch
  9.     }
  10. };

This ensures that the AJAX-functionality on the server is only activated when the script can find the comment-form, otherwise the behaviour will fall back to default. The rest of the JavaScript is pretty straight forward, so just browse through the file if you want to know more.

A pain in the Source

If you’re still reading you’re probably interested in my problem with the do_action() in wp_die(). This is an interesting story and I’d be glad if you have a look at it in the WordPress Support Forum Thread I opened, hoping for help.

Update: The PlugIn now takes the whole error-page as a response and then strips out the error-message from there. This way I don’t need the do_action() in wp_die() anymore, however it’s interesting why it didn’t work …

]]> http://blog.kno.at/tools/wordpress-mu-and-ajax-comments/feed/ 19