In a recent project a client wanted WordPress thumbnails stacked in this way. I first added some code to functions.php in order to set widths and heights to the selected thumbnails.

 // this goes into functions.php
add_image_size( 'front-thumb', 150, 9999 ); //150 pixels wide (and unlimited height)

UPDATE 20 DEC 2011:

// this goes on top of the page, either to header.php or on top of the specific page template

<script type="text/javascript" src="jquery.min.js"></script>
<script type="text/javascript" src="jquery.masonry.min.js"></script>

<script type="text/javascript">
jQuery(document).ready(function($){

  var $container = $('.front-box-container');
  $container.imagesLoaded( function(){
    $container.masonry({
      itemSelector : '.front-box',
      singleMode:true
    });
  });

});
</script>

// On the specific page or category archive create a new loop and create the markup for Masonry to catch:

<?php query_posts(array('paged' => get_query_var('page'),'posts_per_page' => 25, 'cat'=> '-3' ) ); ?>

<div class="front-box-container">
<ul class="front">
<?php while ( have_posts() ) : the_post(); ?>

<div class="front-box">
    <li<?php if (! has_post_thumbnail()){echo (' class="front-noimage"');}?>>
    	<a href="<?php the_permalink() ?>">

    	   	<?php the_post_thumbnail('front-thumb'); ?>
    	        <div class="front-info">
            <h2><a href="<?php the_permalink() ?>"><?php the_title(); ?></a></h2>
            <div class="alternate-content"><?php the_excerpt(); ?></div>
        </div>
    </li>

</div>

<?php endwhile;
wp_reset_query(); ?>

</ul>
</div> <!-- front-box-container -->

That should make the images with (.front-box) inside the parent div (.front-box-container) float nicely with Masonry. Good luck!

Updated 22 November 2011.

1. Rewrite and redirect URLs with query parameters (files placed in root directory)

Original URL:

http://www.example.com/index.php?id=1

Desired destination URL:

http://www.example.com/path-to-new-location/

.htaccess syntax:

RewriteEngine on
RewriteCond %{QUERY_STRING} id=1
RewriteRule ^index\.php$ /path-to-new-location/? [L,R=301]

2. Redirect URLs with query parameters (files placed in subdirectory)

Original URL:

http://www.example.com/sub-dir/index.php?id=1

Desired destination URL:

http://www.example.com/path-to-new-location/

.htaccess syntax:

RewriteEngine on
RewriteCond %{QUERY_STRING} id=1
RewriteRule ^sub-dir/index\.php$ /path-to-new-location/? [L,R=301]

3. Redirect one clean URL to a new clean URL

Original URL:

http://www.example.com/old-page/

Desired destination URL:

http://www.example.com/new-page/

.htaccess syntax:

RewriteEngine On
RewriteRule ^old-page/?$ $1/new-page$2 [R=301,L]

4. Rewrite and redirect URLs with query parameter to directory based structure, retaining query string in URL root level

Original URL:

http://www.example.com/index.php?id=100

Desired destination URL:

http://www.example.com/100/

.htaccess syntax:

RewriteEngine On
RewriteRule ^([^/d]+)/?$ index.php?id=$1 [QSA]

5. Rewrite URLs with query parameter to directory based structure, retaining query string parameter in URL subdirectory

Original URL:

http://www.example.com/index.php?category=fish

Desired destination URL:

http://www.example.com/category/fish/

.htaccess syntax:

RewriteEngine On
RewriteRule ^/?category/([^/d]+)/?$ index.php?category=$1 [L,QSA]

6. Domain change – redirect all incoming request from old to new domain (retain path)

RewriteEngine on
RewriteCond %{HTTP_HOST} ^example-old\.com$ [NC]
RewriteRule ^(.*)$ http://www.example-new.com/$1 [R=301,L]

If you do not want to pass the path in the request to the new domain, change the last row to:

RewriteRule ^(.*)$ http://www.example-new.com/ [R=301,L]

To get WordPress to purge when you create or edit posts, I have tried W3 Total Cache, but the Varnish implementation doesn’t seem to work that well. The only plug-in that I have gotten to work with this setup is WP-Varnish by Pål-Kristian Hamre.

The single specified backend config has to do with another test I’m working on with getting Varnish to serve different sites running for example Drupal and WordPress, with a single VCL. I’ll get back to that one.

backend wp1 {.host = "mywpsite.mydomain.com";.port = "8080";}
sub vcl_recv {
if (req.http.host == "mywpsite.mydomain.com") {set req.http.host = "mywpsite.mydomain.com";set req.backend = wp1;}
}
acl purge {
"127.0.0.1";
}
sub vcl_recv {
 set req.grace = 6h;
 if (req.request == "PURGE") {
if (!client.ip ~ purge) {error 405 "Not allowed.";}purge("req.url ~ " req.url " && req.http.host == " req.http.host);error 200 "Purged.";
}
}
# Do the PURGE thing
sub vcl_hit {if (req.request == "PURGE") {set obj.ttl = 0s;error 200 "Purged";}}
sub vcl_miss {if (req.request == "PURGE") {error 404 "Not in cache";}}
sub vcl_recv {
 # set standard proxied ip header for getting original remote address
set req.http.X-Forwarded-For = client.ip;
 # logged in users must always pass
if( req.url ~ "^/wp-(login|admin)" || req.http.Cookie ~ "wordpress_logged_in_" ){return (pass);}
 # don't cache search results
if( req.url ~ "\?s=" ){return (pass);}
 # always pass through posted requests and those with basic auth
if ( req.request == "POST" || req.http.Authorization ) {return (pass);}
 # else ok to fetch a cached page
unset req.http.Cookie;
return (lookup);
}
sub vcl_fetch {
 # remove some headers we never want to see
unset beresp.http.Server;
unset beresp.http.X-Powered-By;
 # only allow cookies to be set if we're in admin area - i.e. commenters stay logged out
if( beresp.http.Set-Cookie && req.url !~ "^/wp-(login|admin)" ){unset beresp.http.Set-Cookie;}
 # don't cache response to posted requests or those with basic auth
if ( req.request == "POST" || req.http.Authorization ) {return (pass);}
 # Trust Varnish if it says this is not cacheable
if ( ! beresp.cacheable ) {return (pass);}
 # only cache status ok
if ( beresp.status != 200 ) {return (pass);}
 # don't cache search results
if( req.url ~ "\?s=" ){return (pass);}
 # else ok to cache the response
set beresp.ttl = 24h;
return (deliver);
}
sub vcl_deliver {
# add debugging headers, so we can see what's cached
if (obj.hits > 0) {set resp.http.X-Cache = "HIT";set resp.http.X-Cache-Hits = obj.hits;}
else {set resp.http.X-Cache = "MISS";}
# remove some headers added by varnish
unset resp.http.Via;
unset resp.http.X-Varnish;
}

The main thing with this setup is to avoid permission issues when installing and running Drupal and WordPress. Since they depend quite heavily on writing files, changing settings, updating plugins and modules you may end up with a very loose permissions scheme that tends to lead to an insecure installation.

Goals

• make Apache run PHP applications as an arbitrary user (not www-data)
• create “sandboxed” websites and users to avoid Apache user gaining access to other sites on the same machine (especially important if you’re using or want to create a shared hosting environment)
• avoid 777 permissions all over the place

(If Apache is already installed, this is where you begin)

Install modules:

aptitude install apache2-suexec libapache2-mod-fcgid php5-cgi
/etc/init.d/apache2 restart

You might get the following error message, ignore it for now:

"Could not reliably determine the server's fully qualified domain name,
using xxx.xxx.xxx.xxx for ServerName"

Disable the mod_php - we will use fcgid instead:

a2dismod php5

Enable the newly installed Apache modules:

a2enmod rewrite
a2enmod suexec
a2enmod include
a2enmod fcgid

Open and edit /etc/php5/cgi/php.ini

nano /etc/php5/cgi/php.ini

Uncomment or add the following line:

cgi.fix_pathinfo = 1

Restart Apache:

/etc/init.d/apache2 restart

In Webmin, go to Servers > ProFTPD Server > Files and directories

Set "Limit users to directories" to "Home directory". Save.
Apply changes (restart ProFTPD Server).

Create a directory for the site which also will be the home directory for your web user:

mkdir -p /var/www/mynewsite.com/public_html

In Webmin, create a user under System > Users and groups > Create a new user

Username: mynewuser
User ID: Automatic
Home directory: browse to /var/www/mynewsite.com/ and select it
Password: Normal password > (Choose a good, random password)
Primary group: New group with same name as user
Create home directory: Yes
Copy template files to home directory: Yes
Create user in other modules: Yes

Make your new user owner of their webroot:

cd /var/www/mynewsite.com 
chown -R mynewuser:mynewusergroup *
NOTE: sometimes the permissions might get corrupted, in that case, try: chown -R mynewuser:mynewusergroup /var/www/mynewsite.com

Create a fastcgi wrapper script for the new site:

mkdir -p /var/www/php-fcgi/mynewsite.com
nano /var/www/php-fcgi/mynewsite.com/php-fcgi-starter

Add the following to php-fcgi-starter then save:

#!/bin/sh
PHPRC=/etc/php5/cgi/
export PHPRC
export PHP_FCGI_MAX_REQUESTS=5000
export PHP_FCGI_CHILDREN=8
exec /usr/lib/cgi-bin/php

Make the script executable and owned by the user:

chmod 755 /var/www/php-fcgi/mynewsite.com/php-fcgi-starter

cd /var/www/php-fcgi/mynewsite.com chown -R mynewuser:nynewusergroup *  

In Webmin, remove the catch-all virtual server if it exists (Handles the name-based server on address *.)

Then remove the leftovers from the virtual host:

rm /etc/apache2/sites-enabled/000-default

Create a new virtual host:

Servers > Apache webserver > Create virtual host:

Specific address:  mynewsite.com Add name virtual server address (if needed): Yes
Listen on address (if needed): Yes
Port: 80
Document root: /var/www/mynewsite.com/public_html
Allow access to this directory: Yes
Server name: mynewsite.com Add virtual server to file: New file under virtual servers directory
Copy directives from: Nowhere

NOTE 1: if you later create sites to be handled by fcgi you may copy/paste the directives from the initial site and then only change document root and user/group info in the new site’s directives.

NOTE 2:  you still need to create new fastcgi wrapper scripts and unique user for each site.

Tell Apache to listen for the new site:

Servers > Apache webserver > Global configuration > Networking and addresses:

Check "Include all addresses".
Under "Adresses for name virtual servers" add:
mynewsite.com:80

Save and restart Apache (“Apply changes” in Webmin).

Add directives for the site. Virtual server > Edit directives:

ServerName mynewsite.com
ServerAlias mynewsite.com
DocumentRoot /var/www/mynewsite.com/public_html
<IfModule mod_fcgid.c>
 SuexecUserGroup mynewuser mynewusergroup 
 <Directory /var/www/mynewsite.com/public_html>
  Options +ExecCGI
  AllowOverride All
  AddHandler fcgid-script .php
  FCGIWrapper /var/www/php-fcgi/mynewsite.com/php-fcgi-starter .php
  Order allow,deny
  Allow from all 
 </Directory></IfModule>
# ErrorLog /var/log/apache2/error.log
# CustomLog /var/log/apache2/access.log combined
ServerSignature Off

Save and restart Apache. Done!

(Based on Falko Timme’s guide)

API skillz.

Support for editing and exporting photos and video to social networks and photo sharing sites is found in iPhoto (Facebook, Picasa etc – only by 3rd party though). The thing with PS Express is that you’re allowed to import your external pics from within the web app. After finishing them up with a basic set of tools much like those found in iPhoto or Picasa you simply send them back to your site of choice. As of today Facebook, Photobucket and Picasa Web album is supported. Flickr should be there soon as well.

Annoyance warning: PS Express puts a caption on its own on all photos you upload back to Facebook. Meh.