I am totally enamored with Flickr, the social photo sharing service. It has plenty of nifty features; but more than anything it's just super simple to use. I love looking through the (ever changing) latest photos, as well as sharing a few of my own. Flickr is exactly the solution I needed to provide to my mom for her to share her photos. My sister has also found it to be a great service.
The WordPress Flickr plugin is a fantastic effort, and really blends the best of two great products. This is what I set up for my mom, so that she can share her photos from her blog without requiring her or her readers (ie: our family) to juggle bookmarks to different places. I suspect I'll put the plugin to use for my sister, as well.
I value Flickr's (extreme!) convenience, and I enjoy the groups functionality, but I just can't reconcile paying someone else to host my photographs when I have my own server and plenty of bandwidth. The flip side of this is that I've yet to find a photo gallery package that I can host myself that provides me with all the features and convenience that I really want. I've been eyeing gallery for what feels like forever, but I'm just not sold on it. I've been using jigl for quite some time, and I'm reasonably happy with it, but it's a little brittle. Providing titles and descriptions to my photos is a little more time consuming with jigl.
I've looked at all the other WordPress photo gallery integration efforts, but none have really struck my fancy. Carina has been using the Exhibit plugin, and she seems happy enough with that. I forget why I didn't like that one, now, but there was some reason. Probably something vague, just like my aversion to the python programming language.
Krzysztof Kowalczyk makes an argument for bundling a wiki with a blog. I agree wholeheartedly with his endorsement of wikis. I've used a few, and installed two of them myself, and I think they're terrific. But I don't think that wikis should be bundled with blogs (especially WordPress) by default.
First, blogs and wikis serve different puposes. Wikis can be used as a publication engine -- see the Wikipedia as a perfect example -- but the kind of thing you'd publish on a wiki is fundamentally different from the kind of thing you'd post on a blog. The power of wikis is the interconnectedness of all the data: you're only one click away from any other page on the wiki. That's why a wiki makes perfect sense for an encyclopedia, or a knowledge base, or random notes collections. Blogs have a certain interconnected-ness, what with trackbacks and pingbacks, but blogs impose more continuity ... my comments here will be linked to Krzysztof's site; but if someone else blogs their response to my comments, the connection won't be passed on to Krysztof automatically (unless the blogger specifically elects to trackback or pingback him as well as me). If someone uses my comment form below to comment directly on this post, Krysztof will never know unless he comes to visit. Blogs have a linearity to them that wikis don't.
Second, blogs have an implicit power structure that results from the limited selection of authors. A blogger chooses who posts top-level entries to his blog, restricting everyone else to mere "commenter" status. Commenters rarely get the ability to edit their comments; the blog administrator(s) have the sole power to edit or remove comments. The power structure ensures that a blog's readers are always in the position of respondent, and never initiator. In order to initiate, one must control their own blog. Wikis are completely different, though, because (usually) anyone can post and edit. Wikis level the playing field a bit, because any visitor can create new directions for participation. Visitors can correct their own comments, as well as correct the comments of others. Instead of one-to-many communication from a blog, wikis support many-to-many communication, where all participants are authors, editors, and readers. Although the wiki administrator still has absolute power, and wikis can be configured to restrict who can post, constraining wiki operation in this way vastly limits the utility of the software. If you're denying wiki features to people, why use a wiki at all?
Third, wikis lack much of the distribution conveniences of blogs: syndication feeds, trackbacks, and pingbacks. To really use a wiki, participants need to go to the wiki. A blogger can read aggregated blog entries in a feed reader, then post replies to an entry on her blog and alert the source that she's responding (trackback or pingback) without ever visiting the source blog. Blogs allow conversations to be carried out while maximizing each participant's convenience because blogs are predominantly one-to-many publications. Blogging in aggregate approaches many-to-many communication, but there's a lot more infrastructure involved to support that. Wikis gracefully support many-to-many communication by constraining the necessary infrastructure: the wiki is the hub through which all conversations are routed.
Integrating blogs and wikis probably doesn't have much appeal to too many people, since blogs and wikis really serve different purposes. The kind of people who want to use a wiki will largely be able to do so (or figure it out) for themselves. Integrating wikis within a blog package unnecessarily complicates the core package, increases support requirements from the development team, and may possibly bloat the package with features that people don't use.
(hat tip: Blogging Pro)
I wrote up a quickie hack for Sushubh to pull random blog entries from the database. To make it generally useful, I wrote it as a function that takes two arguments:
random_posts ($catID = 0, $count = 4);
By default, it'll grab four random posts from any category. Give it a category ID and/or a specific number of posts to pull in order to change it.
If you know you're not going to use all of the posts' data, you could tweak the last SQL query to grab just the bits you need, instead of everything, thereby easing the load on your database.
Oh yeah, this hack does not honor my per-post user-level restrictions modification. If you're using that, this hack will happily display all your restricted posts.
Not the most useful of hacks, but maybe someone somewhere will put it to good use.
UPDATE: I've made this into a proper plugin for WordPress 1.5 and above. To use it, simply install and activate the plugin, then insert the following code in your template:
<?php
echo "<ul>";
$rp = random_posts($catID, $count);
foreach ($rp as $p) {
$title = get_the_title($p);
$link = get_permalink($p);
echo "<li><a href='$link' title='$title'>$title</a></li>";
}
echo "</ul>";
>
Download random-posts.zip!
WordPress 1.2
Per-Post User Level restrictions
(c) 2004 Scott Merrill skippy@skippy.net
This program is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License
as published by the Free Software Foundation; either version 2
of the License, or (at your option) any later version.
INTRODUCTION
This modification allows blog authors to assign a minimum user level required to view each post. The default value is zero (retroactively applied to all existing posts), which means anyone can see the post. By choosing the post level on the admin post or edit screen, the author can limit who sees what.
INSTALLATION
PART ZERO
Extract the contents of the file post_level.tgz into your WordPress directory. No files will be overwritten. The contents of the download file are thus:
- post_level.txt
- post_level.diff
- post_level.mysql
- wp-admin/post_level_install.php
- modified/wp-blog-header.php
- modified/wp-admin/post.php
- modified/wp-admin/edit-form.php
- modified/wp-admin/edit-form-advanced.php
- modified/wp-includes/template-functions-general.php
PART ONE
This modification requires the addition of a new row to the wp_posts table, called "post_level". There are sever al ways to accomplish this:
1) Make sure the included post_level_install.php is in your wp-admin directory. Call this page from your browser:
http://www.example.com/wordpress/wp-admin/post_level_install.php
2) Edit the included post_level.mysql file to correctly identify the name of your wp_posts table (only necessary if you're using a custom table prefix for your database tables), then execute the following:
mysql -uusername -p wordpress post_level.mysql
Replace "username" with your database username, as defined in wp-config.php.
Replace "wordpress" with the name of your WordPress database, as defined in wp-config.php
3) Use a tool like phpMyAdmin to manually alter the table. The post_level row must be UNSIGNED INT(2), default zero, not null.
PART TWO
Next, you need to modify five files:
- wp-blog-header.php
- wp-admin/post.php
- wp-admin/edit-form.php
- wp-admin/edit-form-advanced.php
- wp-includes/template-functions-general.php
Again, there are several ways to do this:
1) From the command line, run the patch command in your WordPress directory to automatically modify all the files for you using the included post_level.diff file:
patch -p0 post_level.diff
2) If you haven't modified any of the listed files yourself (to apply other modifications, for example), you can simply copy the files from the modified/ directory to their respective locations:
cd modified
cp -r ./* ..
3) You can look through either the post_level.diff file, or the files in the modified/ directory to see what chan ges I've made. I've prefaced all of my modifications with this line:
// SDM 23-05-2004 post_level modification
to help you identify what has been changed.
USING THE MODIFICATION
Once installed, you'll note that the post and edit screens now have a drop-down select box labelled "Post level". This is the minimum user level required to view the post.
Enjoy!
Update 03-06-2004
By default, WordPress grants the ability to create new posts to any user with a user level greater than 0. So restricting posts with this mod and granting visitors user levels high enough to read your restricted posts means that your readers can become writers and blog on your blog. The fix is easy enogh: In wp-admin/post.php, find the line "default:" (this regex -- ^default: -- will take you right there). It's line 721 in my copy. Below that is a line that reads:
if ($user_level > 0) {
Change that zero to any higher number, depending on the number of restricted levels you want to have. If you only want a single level of restricted posts, change the zero to 1. Then raise your privileged readers up to user level 1. They'll see level 1 posts, but not be able to edit.
My sincere apologies for any trouble this oversight has caused.
NOTICE: I have permanently disabled the test implementation of this plugin. (2004-12-16)
Current Version: 1.6
Download tgz: commentauth.tgz
Download zip: commentauth.zip
I've made my first plugin for WordPress. When activated, this plugin will send an email to people who comment (and supply a valid email address) with a unique link. Clicking on the link will approve the comment for immediate posting, without waiting for an administrator's approval.
The basic idea is that if the user supplies a valid email address, and they check that email account, then the commenter is most likely not a spammer. It's not foolproof, but it's a step in the right direction.
The unique URL is calculated using an md5 sum of the comment text plus a "seed". The formula could be brute-forced by someone who really wants to bypass your authorization process; but the burden of effort is on them. Edit the $seed variable in both files to use something unique for your site. Make sure the seed is identitical in both sites, or people will never be able to authorize their own posts!
There are two files included in this plugin:
- commentauth.php
- moderate.php
Install moderate.php into your WordPress root directory, and commentauth.php in your wp-content/plugins/ directory. Ensure that comment moderation is activated, and then activate this plugin. That's all there is to it.
Download this plugin!
UPDATE: the original version of this plug-in was incompatible with the WordPress 1.2 Release Candidate. I've fixed that. Please download this package again, or edit moderation.php to remove the following line:
require_once('./wp-includes/functions.php');
UPDATE #2: I'm not currently using this plugin on this site, so please don't comment just to see it in action. You can do that over on my test installation!
UPDATE #3: Thanks to David, I've added a few extra headers to the generated mail so it should play nice with anti-spam systems. The download link has been updated to the newest version.
UPDATE #4 (2004-09-23): Thanks to Mark for suggesting a fix to help people who have their blog homepage in a different directory than the one in which they installed WordPress.