The libraries are minimal but functional; they let you perform both anonymous and authenticated queries against the latakoo API endpoint, but I’ve only had time to add method wrappers for a few of api calls. Feel free to fork the project to help flesh these out!

Hopefully these libraries will make it easier to get the power of latakoo behind your project.

Happy hacking!

» API Documentation
» Github Project Page

Initially, it was built for a single project but I’ve ended up using it for many other things, and I thought it might be useful to the Open Source community.

Features

• Pluggable
• Light weight
• Sophisticated events system
• Abstracted database layer
• MVC architecture
• Virtual pages
• Object/Metadata based data model

Its designed to have much of its functionality carried in plugins, many of which I will release a little bit later just as soon I’ve had the time to tidy them up a bit!

Anywho, its available under the MIT licence and hopefully it’ll be useful to you!

» Github Project Page (Core Plugins, Extra Plugins)

This plugin adds open graph headers to posts and pages on a per post basis.

It has no native interface, instead it listens out for og:* headers as input in the Custom Fields section of WordPress’ edit page and adds the ones it recognises to the page header as meta tags.

Once installed you will be able to add the following tags to posts:

• og:title (defaults to page title)
• og:type (defaults to “article”)
• og:image (URL, no default)
• og:url is also used, but this is automatically filled in

I wrote this in about an hour so it isn’t all that fancy, and was designed to solve a specific problem for me. Hopefully it’ll be useful to someone else out there.

Feel free to leave comments and send in any patches!

» Plugin page on Github

So without further ado, I’d like to introduce the Really Simple Test Framework!

This is a PHP command line application, so you’ll need the php5-cli module installed.

Usage

php test.php [-p path/to/tests] [-t HelloWorldTest]

So for example, to run all the tests in the sub directory /tests/

php test.php

To specify another directory to look in for tests

php test.php -p /path/to/my/tests

To run a specific test only, specify it by its CLASS NAME

php test.php -t MyClassTest

You can specify multiple tests to run…

php test.php -t MyClassTest -t AnotherTest

Have a butchers at the README.txt for more details on writing your own tests!

» Github Project Page

ProFTP

I recently had the need to get this working and authenticating off a PHP maintained MySQL backend, and this post is primarily to aid my own memory should I ever have to do it again.

Installing ProFTP

In order to use MySQL as a back end you need to install some packages. If you’re using a Debian based distro like Ubuntu, this is easy:

apt-get install mysql-server proftpd proftpd-mod-mysql

The database schema

Next, you need to install the database schema to store your users and passwords.

CREATE TABLE IF NOT EXISTS users (
userid varchar(30) NOT NULL default '',
passwd varchar(128) NOT NULL default '',
uid int(11) default NULL,
gid int(11) default NULL,
homedir varchar(255) default NULL,
shell varchar(255) default NULL,
UNIQUE KEY uid (uid),
UNIQUE KEY userid (userid)
) TYPE=MyISAM;

CREATE TABLE IF NOT EXISTS groups (
groupname varchar(30) NOT NULL default '',
gid int(11) NOT NULL default '0',
members varchar(255) default NULL
) TYPE=MyISAM;

One important thing to note here – that caused me a fair amount of hair pulling when I tried to use encrypted passwords – is that the password field shown in many howtos on the internet is much too short. This causes the hashed password to be quietly truncated by MySQL when saved.

This results in a somewhat misleading “No such user found” error to appear in the logs when using encrypted passwords.

To end all argument I’ve allowed passwords up to 128 chars, but this field could probably be a good deal shorter.

The user table looks much like /etc/passwd and is largely self explanatory. The uid & gid fields correspond to a system user in most cases, but since we’re using virtual users they can largely be ignored. Homedir points to a location which will serve as the user’s default directory. Shell is largely unused and can be set to /bin/false or similar.

Configuring ProFTP

Next, you need to make some changes to the ProFTP configuration files stored in /etc/proftpd. While doing this it is handy to run proftp in debug mode from the console:

proftpd -nd6

proftpd.conf

1. Make sure the AuthOrder line looks like:
   

   AuthOrder mod_sql.c

2. Ensure that the following line is uncommented:
   

   Include /etc/proftpd/sql.conf

3. For belts and braces I’ve included the following at the end, although I’m not entirely sure it’s strictly required:
   

   <IfModule mod_auth_pam.c>
AuthPAM off
</IfModule>


4. Our users don’t need a valid shell, so:
   

   RequireValidShell off

modules.conf

1. Make sure the following lines are uncommented:
   

   LoadModule mod_sql.c
LoadModule mod_sql_mysql.c

sql.conf

1. Set your SQL backend and ensure that authentication is turned on:
   

   SQLBackend mysql
SQLEngine on
SQLAuthenticate on

2. Tell proftp how passwords are stored. You have a number of options here, but since I was using mysql’s PASSWORD function, I’ll defer to the backend.
   

   SQLAuthTypes backend

3. Tell proftp how to connect to your database by providing the required connection details, ensure that the user has full access to these tables.
   

   SQLConnectInfo database@host user password

4. Define your table structure in the format tablename fields….
   

   SQLUserInfo users userid passwd uid gid homedir shell
SQLGroupInfo groups groupname gid members

Adding users

I manage users from within a PHP web application that I’m developing, but in a nutshell adding FTP users from this point is a simple insert statement looking something like:

mysql_query("REPLACE INTO users
(userid, passwd, uid, gid, homedir, shell)
VALUES
('$userid', PASSWORD('$password'), $uid, $gid, '$homedir', '$shell')");

Have fun!