In the WordPress codex, it explains how to modify what posts are in the loop by modifying the WordPress Query object. However there is a catch with this, because by using rewind_posts() for example, you are generating a brand new query to the database that doesn’t trigger plugins.

Specifically this came up when creating the current theme for my webpage. I wanted to use my tdo-tag-fixes plugin that filters posts on a category template based on a tag. This initially worked fine, but I wanted to tweak the theme so that some category pages displayed all posts from that category but yet could be filtered by tags. (Check out my download section where you can filter downloads by clicking on the tag cloud on the left). Apparently other people are suffering similar problems too when they use the tdo-tag-fixes plugin while trying to modify the query within their theme.

To list all the posts in a category template isn’t hard at all. I just had to set the query var “nopaging” to true and do a rewind_posts(). (You also have to set the category_name again). Once I had implemented this in my category template, the tag filtering stopped working. What was happening was that rrewind_posts() created a brand new query, overwriting any previous set query vars and basically going around my tdo-tag-fixes plugin.

However there is a solution to this (basically how tdo-tag-fixes is implemented in fact). So what you need to do is modify the query before it gets to the template. This way it should be in addition to any other plugins that modify the query (unless your theme overwrites them).

So in my functions.php I did something like this:

add_action('parse_request','show_all_entries_in_category');

function show_all_entries_in_category(
    $args
)
{
    $categories_list = array( 1, 3, 4 );

    // this if checks if it's for a category template
    //
    if(isset($args->query_vars['category_name']))
    {

        $cat = get_category_by_path($args->query_vars['category_name']);

        // if one of the special categories, disable paging
        //
        if(in_array($cat->term_id,$categories_list))
        {
            // make sure all posts are displayed in this category
            //
            $args->set_query_var('nopaging',true);
        }
    }
}

This piece of code will check set the “nopaging” query var on the wp_query for categories with ids 1, 3 or 4, which means that for those category pages all posts will be listed with no previous and next page links.

You can of course alter the code with in show_all_entries_in_category() with what ever query modifications you need to do.

Related Posts:

• Tutorial Video for TDO Mini Forms!
• Where has TDO Mini Forms plugin gone?
• Pet Projects, TDO-Mini-Forms and Forums
• Working on a Taxonomy Widget for TDO Mini Forms
• An alternative to TDO Mini Forms?

It’s becoming a common query about how to make the content field in a TDO Mini Forms WYSIWYG (“What-You-See-Is-What-You-Get”). A WYSIWYG editor is where you see that your input is bold when you set it to bold, instead of seeing it plain with bold tags around the text. This tutorial will run you through quickly how to set this up.

Update #1: There is a bug with this tutorial. There is an incompatiblity between the AJAX code in TDOMF and using TinyMCE. Please disable AJAX before proceeding with this tutorial. If you have already done this, please disable AJAX. Then reset the form and then re-do the steps in this tutorial.

There are tons of javascript implementations of this that can change a normal HTML textarea into one of these WYSIWYG editors such as TinyMCE or NiceEdit. The post content field (and Custom Fields set to Text Area) use the standard textarea element and so can be “skinned” by these libraries quite easily. This is why I haven’t really integrated one of these libraries into TDOMF, I don’t want to restrict user choice and I also don’t want the huge bloat. You could, for example, use the same installation of TinyMCE to skin your comments input form as well as your TDOMF form. However I’m constantly asked how to do it. So lets take TinyMCE, and run though how you might add it to your TDO Mini Forms form.

1. Download latest version from http://tinymce.moxiecode.com/

2. Unpack the tinymce_<ver>.zip

3. Using an FTP client, upload the contents of jscripts (i.e. the tiny_mce folder) to your wordpress site. Best place to do this is under wp-content (i.e. wp-content/tiny_mce).

4. Make sure its readable from the web. You may have to set the permissions using chmod 755 or chmod 777 on the directory and it’s contents depending on your host configuration. You can probably do this from your FTP client.

5. Now, you need a form with a Content widget it on it. If you use the default, unmodified form, you will have one. If not…

5.1. Go to the “Form Widgets” page.

5.2. Drag and drop the Content Widget from “Available Widgets” to “Your Form”.

5.3. Click on the icon beside “Content” and disable/uncheck the “Use Quicktags” and “Restrict Tags” options if they are checked. You can perform any other customisation of the “Content” Widget here.

5.4. Do any other widget customisation and then click “Save Changes”.

6. Now go to the “Form Manager and Options” and go to the options page for your Form. Make sure that “Use AJAX” is unchecked. (With the current version of TDOMF, the AJAX code is incompatible with the TinyMCE scripts).

7. Now go to the Form Hacker and add this to the top:

<!-- TinyMCE -->
<script type="text/javascript" src="<?php echo get_bloginfo('wpurl'); ?>/wp-content/tiny_mce/tiny_mce.js"></script>
<script type="text/javascript">
tinyMCE.init({
mode : "exact",
elements : "content_content",
theme : "simple"
});
</script>
<!-- /TinyMCE -->

Save the hacked form.

8. View your form. The Post Content now should have a WYSIWYG editor!

I used the “simple theme” in this tutorial. TinyMCE supports more advanced editor and other options, so please check the TinyMCE documentation and examples.

And NO! You cannot use the TinyMCE editor that is built into WordPress. The WordPress TinyMCE has been seriously hacked to work with the WordPress UI and cannot be used independently.

You can also extend this approach to use TinyMCE for Custom Fields.

9. Add a Custom Field widget to your Form using “Form Widgets”. Set the Custom Field “Type” to “Text Area”. Disable “Use Quicktags” and “Restrict Tags” options. Save the widgets.

10. On the “Form Hacker” use the “Reset” button to pick up the latest changes.

11. Now scan the code of the form for the Custom Field textarea tag. It should be something like this:

<textarea title="true" rows="10" cols="40" name="customfields-textarea-1" id="customfields-textarea-1" ><?php echo htmlentities($value,ENT_NOQUOTES,get_bloginfo('charset')); ?></textarea>

Please note the name of the custom field textarea element. In this case it’s customfields-textarea-1.

12. Now at the top of the form add this:

<!-- TinyMCE -->
<script type="text/javascript" src="<?php echo get_bloginfo('wpurl'); ?>/wp-content/tiny_mce/tiny_mce.js"></script>
<script type="text/javascript">
   tinyMCE.init({
      mode : "exact",
      elements : "content_content,customfields-textarea-1",
      theme : "simple"
   });
</script>
<!-- /TinyMCE -->

Note that I’ve appended the name of the textarea to the “elements” array.

13. Save the hacked form.

14. View your form. Now your content and your custom field widget use TinyMCE.

If you want to configure TinyMCE in even more complicated ways, please refer to the TinyMCE documentation. You can, for example, configure a Custom Field differently to the post content, by having the tinyMCE.init called separately before the different elements. In a similar way, you can add WYSIWYG editor to your comments, if you are so inclined.

Any questions and queries are probably best served on the TDOMF support forum. If you did find this helpful, please consider dropping me a few euros, thank you.

Related Posts:

• Where has TDO Mini Forms plugin gone?
• Pet Projects, TDO-Mini-Forms and Forums
• Working on a Taxonomy Widget for TDO Mini Forms
• An alternative to TDO Mini Forms?
• You want Custom Taxonomies in TDO Mini Forms?

Found this neat little feature in Pligg that allows you to easily add a link to Pligg. The simple code can be expanded so you can add a button to your webpage that allows it to be easily submitted to Pligg. It’s not world-shattering, nor is it an unusual feature to find.

However, if your a Redbrick Member you could add this piece of code to any of your webpages that would all you or another Redbrick user to submit it to Pligg.

Submit this to Redbrick Pligg!

If you want, you can replace “document.location.href” with an explicit URL. I guess what we really need is a icon for Redbrick Pligg!

I’m considering adding it to Planet Redbrick and Redbrick Wiki. Is it a good idea? I could package it up in a WordPress plugin but I don’t know how many Redbrick Bloggers use WordPress.

The same also applies for Game Crafter’s Guild’s Pligg, however this Pligg is specifically for Gaming and Roleplaying related content, and we don’t have an icon either!

Submit to Game Crafter’s Guild’s Pligg!

Related Posts:

• A thought-exercise: Redbrick “Web 2.0″
• Frustrating!
• Integrating Pligg beta 8.1.0 with WordPress 2.0.4 (v1.1)
• Integrating Pligg beta 8.1.0 with PubCookie
• A new look for thedeadone.net

I’ve managed to get Pliggto use WordPress authentication and user database. You can see it running on the Game Crafter’s Guild website.

I recently got Pligg using Pubcookie and that formed the basis of this work, however they are very different.

I’ve only tested this with Pligg Beta 8.1.0. I believe future versions may have a better approach for external authentication so I can’t guarantee this will work with future versions.

This approach is very “hacky”. I’ve also been slightly lazy. It assumes that you will use WordPress’ login, logout and register pages. This will break the existing login, logout and register forms in Pligg. The ultimate solution would allow the Pligg forms to login and logout also on WordPress and the register form to create new users in WordPress.

It also does not attempt to merge the user databases from WordPress and Pligg together. Instead they are left seperate. This means that administrators have two places to manage users. If you want to delete a user, you’ve got to delete them from WordPress and Pligg seperately.

I’ve done previous external application integrations with WordPress, most notable with DokuWiki. In these previous case, I was able to allow the use of WordPress template tags in DokuWiki. However, in the case of Pligg, it is not possible as there are several function name clashes. Pligg and WordPress are considered CMSs (Content Management Systems) and it is inevitable that function names and variables clash.

Version History

1.1 (19/10/2006)

Stray header redirection in login.php removed.

1.0 (17/09/2006)

First Release

Installation locations

The first thing to do is decide on where you will install Pligg and WordPress. Pligg must be installed in either a directory on the same level as WordPress or a subdirectory of WordPress. In my code examples, I’ve installed WordPress and Pligg on the same level. I will refer to the WordPress directory as “wp” and Pligg as “p”. So, for reference, I have Pligg and WordPress installed like this:

/public_html/wp
/public_html/p

Equally valid would be:

/public_html/wp
/public_html/wp/p

Pligg and WordPress should be part of the same domain. Otherwise the WordPress cookies won’t be picked up by Pligg.

Installing the software

Install WordPress normally and configured it how you will. Make sure it’s all working. Make a not eof your database prefix and site url. You can get your database prefix from ‘wp-config.php’. It is the ‘$table_prefix’ variable. Your site url (or URI if you want to be pedantic), is where you access WordPress from. You can get the exact value from your “Options”, “General” panel when you log in to WordPress as admin. Your site url should have no trailing slash. It is important you get this right as you won’t be able to log in to Pligg later otherwise. For example, if you install into a different directory, then your webpage’s url will be different from your WordPress url.

Now install Pligg, but use the same database. Make sure everything is working, in particular that you can log in using the “god” account.

Modifying Pligg

All the work to modify Pligg takes place in ‘libs/login.php’. What we want to do is get Pligg to login using WordPress cookies/authentication. If the user doesn’t yet exist in Pligg, create it. Also, copy over all the existing user data to the Pligg database. We won’t be using Pligg’s login, authentication or logout any more.

However, we can’t just include wordpress and call wordpress functions. Instead, we’re going to have to do it manually. What I’ve done is added a function called is_user_logged_onto_wp(), which does all the extra work.

Here is the modified ‘libs/login.php’. Make sure to correctly set the $wp_db_prefix to your database prefix (including the underscore) and $wp_siteurl to your WordPress url.

< ?php
// The source code packaged with this file is Free Software, Copyright (C) 2005 by
// Ricardo Galli .
// It’s licensed under the AFFERO GENERAL PUBLIC LICENSE unless stated otherwise.
// You can get copies of the licenses here:
// http://www.affero.org/oagpl.html
// AFFERO GENERAL PUBLIC LICENSE is also included in the file called “COPYING”.
// Modified by Mark Cunningham
// (http://thedeadone.net). Log in using WordPress
// WordPress path (you don’t really need this)
//if(!defined(‘WP_ROOT’)) define(‘WP_ROOT’, mnmpath.’/../wp/’);
//
// Can’t do this, sadly as “get_permalink” collides in both code bases.
// Must do everything manually!
//require_once WP_ROOT.’wp-config.php’;
$wp_db_prefix = “wp_”;
$wp_siteurl = “http://www.myblog.com/wp”;
// Generate cookie keys!
if( !defined(‘WP_COOKIEHASH’) ) {
// this value should be the same as siteurl
$cookiehash = md5($wp_siteurl);
define(‘WP_COOKIEHASH’, $cookiehash);
}
if ( !defined(‘WP_USER_COOKIE’) )
define(‘WP_USER_COOKIE’, ‘wordpressuser_’. WP_COOKIEHASH);
if ( !defined(‘WP_PASS_COOKIE’) )
define(‘WP_PASS_COOKIE’, ‘wordpresspass_’. WP_COOKIEHASH);
// TODO: storing copy of password in pligg?
class UserAuth {
var $user_id = 0;
var $user_login = “”;
var $md5_pass = “”;
var $authenticated = FALSE;
function is_user_logged_onto_wp(){
global $db, $wp_db_prefix;
// Most of this stuff I’ve taken (and modified) from WordPress codebase
// Do we have a username and password?
if ( !empty($_COOKIE[WP_USER_COOKIE]) && !empty($_COOKIE[WP_PASS_COOKIE]) ){
$wp_username = $_COOKIE[WP_USER_COOKIE];
$wp_password = $_COOKIE[WP_PASS_COOKIE];
// Does the user exist in wordpress?
if(!$wp_user = $db->get_row(“SELECT * FROM “.$wp_db_prefix.”users WHERE user_login = ‘$wp_username’”)){
// User doesn’t exist in wordpress… so…
// … should I delete this user in Pligg?
echo “This user $wp_username does not exist in WordPress!
“;
return false;
}
// Grab data for user
$wp_userdata = $db->get_results(“SELECT meta_key, meta_value FROM “.$wp_db_prefix.”usermeta WHERE user_id = ‘$wp_user->ID’”);
if ($wp_userdata) {
foreach ( $wp_userdata as $meta ) {
@ $value = unserialize($meta->meta_value);
if ($value === FALSE)
$value = $meta->meta_value;
$wp_user->{$meta->meta_key} = $value;
// We need to set user_level from meta, not row
if ( $wp_db_prefix.”user_level” == $meta->meta_key )
$wp_user->user_level = $meta->meta_value;
}
}
// Check if username and password are valid!
if ( md5($wp_user->user_pass) != $wp_password) {
// bad password!
echo “Bad password in cookie for $wp_username!
“;
return false;
}
// Okay, user exists and _is_ logged into wordpress!
// check if user exists in pligg!
$ok = 1;
// if a user doesn’t exit… create the user
if(!user_exists($wp_username)){
$userip = $_SERVER['REMOTE_ADDR'];
$ok = $db->query(“INSERT INTO users (user_login, user_email, user_pass, user_date, user_ip) VALUES (‘$wp_username’, ‘$wp_user->user_email’, ‘password’, now(), ‘$userip’)”);
}
// if user creation was okay or user was already created, sync and log in
if($ok) {
// grab pligg user data
$user=$db->get_row(“SELECT user_id, user_pass, user_login FROM users WHERE user_login = ‘$wp_username’”);
// Copy user data from wordpress!
$sql = “UPDATE users set “;
// admins should be set as “god” in pligg. What other levels should be mapped?
if($wp_user->user_level >= ’10′){
$sql .= “user_level=’god’, “;
} else {
$sql .= “user_level=’normal’, “;
}
$sql .= “user_date=’$wp_user->user_registered’, “;
$sql .= “user_url=’$wp_user->user_url’, “;
$sql .= “user_aim=’$wp_user->user_aim’, “;
$sql .= “user_yahoo=’$wp_user->user_yim’, “;
$sql .= “user_gtalk=’$wp_user->jabber’, “;
$sql .= “user_email=’$wp_user->user_email’ “;
$sql .= “WHERE user_id=$user->user_id”;
// there are other fields in pligg that don’t exist in wordpress.
// Just ignoring them for the time being.
$db->query($sql);
// These are required for login to Pligg
$this->user_login = $user->user_login;
$this->user_id = $user->user_id;
$this->authenticated = TRUE;
$this->md5_pass = md5($user->user_pass);
$this->SetIDCookie(1, false);
// Oh, don’t forget to log the ip!
$lastip=$_SERVER['REMOTE_ADDR'];
mysql_query(“UPDATE users SET user_lastip = ‘$lastip’ WHERE user_id = {$user->user_id} LIMIT 1″);
mysql_query(“UPDATE users SET user_lastlogin = now() WHERE user_id = {$user->user_id} LIMIT 1″);
// All good!
return true;
}
else
{
echo “Problem creating user in Pligg!
“;
}
}
else
{
//debug
//echo “No wordpress user found!
“;
}
return false;
}
function UserAuth() {
global $db;
// Are we logged into wordpress?
// Don’t do anything unless we are!
if($this->is_user_logged_onto_wp()){
if(isset($_COOKIE['mnm_user']) && isset($_COOKIE['mnm_key']) && $_COOKIE['mnm_user'] !== ”) {
// Si ya está autentificado de antes, rellenamos la estructura.
$userInfo=explode(“:”, base64_decode($_REQUEST['mnm_key']));
if(crypt($userInfo[0], 22)===$userInfo[1]
&& $_COOKIE['mnm_user'] === $userInfo[0]) {
$dbusername = $db->escape($_COOKIE['mnm_user']);
$dbuser=$db->get_row(“SELECT user_id, user_pass, user_level FROM users WHERE user_login = ‘$dbusername’”);
if($dbuser->user_id > 0 && md5($dbuser->user_pass)==$userInfo[2]) {
$this->user_id = $dbuser->user_id;
$this->user_level = $dbuser->user_level;
$this->user_login = $userInfo[0];
$this->md5_pass = $userInfo[2];
$this->authenticated = TRUE;
}
}
}
// Logout of Pligg if not logged in to wordpress
} else {
$this->user_login = “”;
$this->authenticated = FALSE;
$this->SetIDCookie (0,false);
header(“Cache-Control: no-cache, must-revalidate”);
header(“Expires: ” . gmdate(“r”, time()-3600));
}
}
function SetIDCookie($what, $remember) {
switch ($what) {
case 0: // Borra cookie, logout
setcookie (“mnm_user”, “”, time()-3600, “/”); // Expiramos el cookie
setcookie (“mnm_key”, “”, time()-3600, “/”); // Expiramos el cookie
break;
case 1: //Usuario logeado, actualiza el cookie
// Atencion, cambiar aqu?cuando se cambie el password de base de datos a MD5
$strCookie=base64_encode(join(‘:’,
array(
$this->user_login,
crypt($this->user_login, 22),
$this->md5_pass)
)
);
if($remember) $time = time() + 3600000; // Lo dejamos v?idos por 1000 horas
else $time = 0;
setcookie(“mnm_user”, $this->user_login, $time, “/”);
setcookie(“mnm_key”, $strCookie, $time, “/”);
break;
}
}
function Authenticate($username, $pass, $remember=false) {
global $db;
$dbusername=$db->escape($username);
$user=$db->get_row(“SELECT user_id, user_pass, user_login FROM users WHERE user_login = ‘$dbusername’”);
$saltedpass=generateHash($pass, substr($user->user_pass, 0, SALT_LENGTH));
if ($user->user_id > 0 && $user->user_pass === $saltedpass) {
$this->user_login = $user->user_login;
$this->user_id = $user->user_id;
$this->authenticated = TRUE;
$this->md5_pass = md5($user->user_pass);
$this->SetIDCookie(1, $remember);
$lastip=$_SERVER['REMOTE_ADDR'];
mysql_query(“UPDATE users SET user_lastip = ‘$lastip’ WHERE user_id = {$user->user_id} LIMIT 1″);
mysql_query(“UPDATE users SET user_lastlogin = now() WHERE user_id = {$user->user_id} LIMIT 1″);
return true;
}
return false;
}
function Logout($url=’./’) {
$this->user_login = “”;
$this->authenticated = FALSE;
$this->SetIDCookie (0);
//header(“Pragma: no-cache”);
header(“Cache-Control: no-cache, must-revalidate”);
header(“Location: $url”);
header(“Expires: ” . gmdate(“r”, time()-3600));
header(“ETag: \”logingout” . time(). “\”");
die;
}
}
$current_user = new UserAuth();
?>
[/soure]

Now login to wordpress and go to your Pligg frontpage. You may have to reload, but you should be automatically logged into Pligg! Remember, don’t use Pligg’s login or logout any more. I’ll deal with what you need to change in the templates to handle that soon. If you use your wordpress admin account, you’ll have full ‘god’ mode in Pligg.

Final modifications

Your site isn’t fully secure yet. Delete ‘register.php’ so that no-one can create accounts using Pligg. We can also simply remove ‘login.php’ but lets not be so drastic. Lets modify ‘login.php. Look for these lines:

1
if($_POST["processlogin"] == 1) {
$username = trim($_POST['username']);
$password = trim($_POST['password']);
$persistent = $_POST['persistent'];
if($current_user->Authenticate($username, $password, $persisten$
$errorMsg=PLIGG_Visual_Login_Error;} else {
if(strlen($_REQUEST['return']) > 1) {
header(‘Location: ‘.$_REQUEST['return']);
} else {
header(‘Location: ‘.my_pligg_base.’/');
}
die;
}
}

We want to prevent hackers from using direct URLs to log in. So comment out the normal authentication test, as below.

if($_POST["processlogin"] == 1) {
$username = trim($_POST['username']);
$password = trim($_POST['password']);
$persistent = $_POST['persistent'];
if($current_user->Authenticate($username, $password, $persisten$
$errorMsg=PLIGG_Visual_Login_Error;} else {
if(strlen($_REQUEST['return']) > 1) {
header(‘Location: ‘.$_REQUEST['return']);
} else {
header(‘Location: ‘.my_pligg_base.’/');
}
die;
}
}

Pligg also comes preconfigured with one special user account, the “god” account. You can’t delete this account via the admin interface. You can create the “god” account in WordPress to prevent some user creating it and gaining “god” rights on Pligg. Or if you know sql or have access some sort of web access to your database, you can rename the “god” account to match the username of an existing admin user or delete the user outright.

Required Template Changes

So, now your WordPress users can log in on WordPress and then be automatically logged in to Pligg. But you’ve got to point the login, logout and register links to your WordPress equivelents. If your happy enough modifying the template then your ready to go. However, heres a run down of the minimal changes required to make sure it’s okay.

Lets create a copy of the existing template, mollio-beat. To do this, just make a copy of ‘templates/mollio-beat’ in ‘templates/’ (including all subdirectories). Make sure the permissions are correct, etc. I renamed this copy “gcg1″ (for Game Crafters Guild version1), so I now had a ‘template/gcg1′. I went into the admin interface in Pligg and under the Template configuration, changed ‘mollio-beat’ to ‘gcg1′ and disabled the option that lets users change the template. We don’t want users being able to go back to the old way of authentication.

We can’t use WordPress template tags. You can always write PHP and SQL code that access the data manually in your database if your that way inclined. This means we have to use direct links.

template/gcg1/header.tpl

Open up ‘template/gcg1/header.tpl’. Look for these lines:

{else}

Change them to:

Note: In my installation of Pligg, I’ve updated “my_base_url” (via the admin interface) correctly. I also have WordPress as a subdirectory of that same base url, so it became a handy shortcut to use ‘{$my_base_url}/wp’ to reference any WordPress links directly.

header.tpl controls the header of all the Pligg pages so these changes will make sure those login, logout and register links are fixed across the entire Pligg site.

template/gcg1/profile_center.tpl

‘template/gcg1/profile_center.tpl’ controls what users can modify in their profile. We’ll want to disable as much as possible of this as their profiles are overwritten from WordPress everytime they login.

Some where in the file, add this so users know where to modify their profile:

Please use this form to modify your profile.

Delete these lines. Users won’t be able to modify their passwords here, so remove the option:

{#PLIGG_Visual_Profile_ChangePass#}

Now we need to disable the fields that are copied over by wordpress. These are aim, email, yahoo, url and gtalk.

template/gcg1/story_center.tpl

‘template/gcg1/story_center.tpl’ controls the display of individual stories. If a non-logged in user, views a story, they will see a login and logout link!

Replace:

{#PLIGG_Visual_Story_LoginToComment#} {#PLIGG_Visual_Story_Register#} {#PLIGG_Visual_Story_RegisterHere#}.

With:

Login
Register

template/gcg1/sidebar/login.tpl

‘template/gcg1/sidebar/login.tpl’ is the sidebar login form you see. Replace it with this:

{#PLIGG_Visual_Login_Title#}

Register

Login

template/gcg1/sidebar/logged_in.tpl

‘template/gcg1/sidebar/logged_in.tpl’ is the sidebar panel you see when logged in. Replace the logout link:

{#PLIGG_Visual_Logout#}

With something like this:

{#PLIGG_Visual_Logout#}

I also add a link to the WordPress Admin panel for convience here.

Ready to go!

After all these changes, you should be able to login using WordPress only and be logged in on your Pligg page too! If you have any comments, feedback or find any bugs, just leave a comment here. Thanks.

Related Posts:

• Add a “pligg it” button to your webpage!
• Frustrating!
• Getting DokuWiki to use WordPress Authentication (v1.2)
• GCG… it’s alive!
• Where has TDO Mini Forms plugin gone?

I’ve managed to get Pligg to use Redbrick’s PubCookie to authenticate logins. For the moment, you can see it in action here. However, this was done for demo purposes so I don’t know if it’ll stay there forever.

I reused the approach that worked for integrating MediaWiki with PubCookie for our Redbrick Wiki. This was based on the work originally described here.

I’ve only tested this with Pligg Beta 8.1.0. I believe future versions may have a better approach for external authentication so I can’t guarantee this will work with future versions.

I’m assuming that you already have an existing and working pubcookie installation. The first thing to do is install Pligg. Get it up and running with it’s own authentication. Make sure you can login with the pre-created “god” account.

We’re going to need to modify the template quite a bit, so create a copy of the existing template, mollio-beat. To do this, just make a copy of ‘templates/mollio-beat’ in ‘templates/’ (including all subdirectories). Make sure the permissions are correct, etc. I renamed this copy “rb” (for Redbrick), so I now had a ‘template/rb’. I went into the admin interface in Pligg and under the Template configuration, changed ‘mollio-beat’ to ‘rb’ and disabled the option that lets users change the template. We don’t want users being able to go back to the old way of authentication.

Next, create a ‘custom_auth’ directory in your pligg directory.

Create a ‘login1.php’ with these contents in ‘custom_auth’. Make sure to replace ‘[url to your pligg install]‘ with the correct URL to your pligg directory. This file simply redirects the user to a pubcookie protected page.

< ?php

session_start();

//we don't want people accessing this page directly!
if (isset($_SERVER['HTTP_REFERER'])) {
//save the referrer so we can redirect back to the page they came from
$_SESSION['http_referrer'] = $_SERVER['HTTP_REFERER'];

//now send them off to the PubCookie protected login page
header('Location: https://[url to your pligg install]/custom_auth/login2.php');
}
else {
header('HTTP/1.1 403 Forbidden');
echo "This page cannot be accessed directly";
}

?>

Create a ‘login2.php’ with these contents in ‘custom_auth’. This page will be protected by pubcookie. The user will then login via pubcookie, be redirected back here and be logged into pligg. You can replace the “@redbrick.dcu.ie” in the email field to something that makes more sense for your setup.

< ?php

// Needed by Pligg

include_once('../Smarty.class.php');
$main_smarty = new Smarty;
include('../config.php');
//include(mnminclude.'html1.php');
//include(mnminclude.'link.php');
//include(mnminclude.'smartyvariables.php');

require_once "HTTP/Request.php";

//this script must be run behind some type of Apache user authorization
//fail immediately if it isn't
if (!isset($_SERVER['REMOTE_USER'])) {
die("The remote user variable is not set");
}

//get the login username
$username = strtolower($_SERVER['REMOTE_USER']);

session_start();

$redirect = $_SESSION['http_referrer'];
unset($_SESSION['http_referrer']);

global $db;

$ok = 1;
// if a user doesn't exit... create the user
if(!user_exists($username)){
// come up with some default email
$email = $username."@redbrick.dcu.ie";
$userip = $_SERVER['REMOTE_ADDR'];
$ok = $db->query(“INSERT INTO users (user_login, user_email, user_pass, user_date, user_ip) VALUES (‘$username’, ‘$email’, ‘password’, now(), ‘$userip’)”);
}

// if everything is okay…
if($ok) {
// log in!
$user=$db->get_row(“SELECT user_id, user_pass, user_login FROM users WHERE user_login = ‘$username’”);
$current_user->user_login = $user->user_login;
$current_user->user_id = $user->user_id;
$current_user->authenticated = TRUE;
$current_user->md5_pass = md5($user->user_pass);
$current_user->SetIDCookie(1, false);
$lastip=$_SERVER['REMOTE_ADDR'];
mysql_query(“UPDATE users SET user_lastip = ‘$lastip’ WHERE user_id = {$user->user_id} LIMIT 1″);
mysql_query(“UPDATE users SET user_lastlogin = now() WHERE user_id = {$user->user_id} LIMIT 1″);
}

//finally redirect the user back to his original page
header(“Location: $redirect”);
?>

Now create a ‘.htaccess’ file. This will make ‘login2.php’ protected by pubcookie. On my setup, to do this, I use this:

PubcookieAppID cpig1
AuthType pubcookie


       require valid-user

Now you need to modify your template to use this new login approach. Go into your template directory (in my case thats ‘template/rb’) and modify “login_center.tpl”. Add these lines near the top of tile and replace [url to your pligg install] with the correct URL to your pligg directory. This will cause all logins to redirect to the new login scripts.

< ?php
/* these lines added to enable pub cookie login! */
header("Location: http://[url to your pligg install]/custom_auth/login1.php");
exit;
?>

Now, open up your Pligg in a browser of choice. Assuming your not currently logged in, follow the login link at the top. You should now have to login using pubcookie. If login is sucessful, you should now be logged into Pligg.

However, you’ll want to give yourself admin powers. So login using your own pubcookie account so that the user account is created in Pligg. Now change the template from ‘rb’ back to ‘mollio-beat’. Hopefully now you should be able to login using the original ‘god’ account. Once logged in, change your pubcookie account to ‘god’ level. Nowe change the the template back to ‘rb’ (or whatever you called it).

People can now log into your Pligg using pubcookie. However, your site isn’t fully secure. Delete ‘register.php’ so that no-one can create accounts. We do not want to delete ‘login.php’ however as this does our ‘logout’. Instead we will modify ‘login.php. Look for these lines:

if($_POST["processlogin"] == 1) {
$username = trim($_POST['username']);
$password = trim($_POST['password']);
$persistent = $_POST['persistent'];
if($current_user->Authenticate($username, $password, $persisten$
$errorMsg=PLIGG_Visual_Login_Error;} else {
if(strlen($_REQUEST['return']) > 1) {
header(‘Location: ‘.$_REQUEST['return']);
} else {
header(‘Location: ‘.my_pligg_base.’/');
}
die;
}
}

We want to prevent hackers from using URLs to log in. So comment out the normal authentication test, as below.

if($_POST["processlogin"] == 1) {
/*$username = trim($_POST['username']);
$password = trim($_POST['password']);
$persistent = $_POST['persistent'];
if($current_user->Authenticate($username, $password, $persisten$
$errorMsg=PLIGG_Visual_Login_Error;} else {
if(strlen($_REQUEST['return']) > 1) {
header(‘Location: ‘.$_REQUEST['return']);
} else {
header(‘Location: ‘.my_pligg_base.’/');
}
die;
}*/
}

Your site is now ready to be used. However I would suggest some further template changes. These are not required to make your site work, but they do improve usablity for your members.

In the template file ‘header.tpl’, remove the line:

This will remove the “register option” from the top of the page.

In the template file ‘profile_center.tpl’, remove these lines:

{#PLIGG_Visual_Profile_ChangePass#}

This will remove the change password option from users profiles. It’s harmless, as the password is not used, but it could convince your users.

In the template file ‘sidebar_modules/login.tpl’, you may want to replace, pretty much everything in this file so that users don’t see a login form in the sidebar. This is what I put in it.

{#PLIGG_Visual_Login_Title#}

You can log in using your Redbrick
username and password due to the magic of pubcookie. Just follow the link
below.

{#PLIGG_Visual_Login#}

A final suggestion, in the admin panel in langauge configuration, I’d recommend changing all instances of “login” to “sign in” and “logout” to “sign out”.

Related Posts:

• Add a “pligg it” button to your webpage!
• A thought-exercise: Redbrick “Web 2.0″
• A new look for thedeadone.net
• Phew! Made it!
• thedeadone.net is back!

So the online Irish gaming community has moved, without a word, to livejournal. They even have a “community” setup.

But to be honest, I’ve already got my own homepage setup so I don’t particularly want to setup another blog just to join in. Well, luckly I found Live+Press, a little plugin for WordPress that allows you to synch blog entires from WordPress to LiveJournal.

I’ve setup a LiveJournal account with the uninspired name “tdo_ie” (thedeadone and many variants have already been taken). This post will actually be the first inaugural post on the account and also be synced on both sites! Lets see if it works…

Update: That was a flop. I spent some time trying to debug the plugin but I couldn’t get to the source of why the sync failed. Ah, it was worth a try.

Update #2: So Live+Press sucks but I found LiveJournal Crossposter. Lets see what happens…

Update #3: Still having difficulty but at least with Crossposter the code is much easier to debug. The problem lies with WordPress file class-IXR.php. It has no support for proxies. Seeing if I can hack it a bit…

Update #4: The error is “Something went wrong – -32300 : transport error – could not open socket: 110 Connection timed out”. This comes from the file class-IXR.php from WordPress. AFAIK, my host, Redbrick, does allow outgoing connections. Is this a LiveJournal thing or a Redbrick thing? There are no settings for proxies in either the plugin or the WordPress file.

Update #5: It appears the “110 Connection timed out” is a proxy problem. I hacked class-IXR.php a bit to use the redbrick proxy.

if ($this->timeout) {
//$fp = @fsockopen($this->server, $this->port, $errno, $errstr, $this->timeout);
$fp = @fsockopen(‘proxy.dcu.ie’, 3128, $errno, $errstr, $this->timeout);
} else {
//$fp = @fsockopen($this->server, $this->port, $errno, $errstr);
$fp = @fsockopen(‘proxy.dcu.ie’, 3128, $errno, $errstr);
}

Unfortunantly this isn’t enough. The fsockopen is successful but the fputs isn’t. The error is now: “HTTP/1.0 400 Bad Request”. I’m getting closer at least.

Update #6: Final update. I got it to work!

It requires a further update to class-IXR.php however. The request string that is passed to fputs is missing info that I guess the proxy needs. I needed to add the full url, not just the path and a “http://” to the beginning of the Host field.

$request = “POST http://{$this->server}{$this->path} HTTP/1.0$r”;
$request .= “Host: http://{$this->server}$r”;
$request .= “Content-Type: text/xml$r”;
$request .= “User-Agent: {$this->useragent}$r”;
$request .= “Content-length: {$length}$r$r”;
$request .= $xml;

I guess I better pass this info around!

Related Posts:

• Some fun with Planet Irish Gaming
• Is this a good idea: a livejournal “friends” page on my wordpress site?
• Speaking of upgrading software
• Arg, how I hate Internet Explorer!
• A new look for thedeadone.net

This is rather funky. If your a WordPress user there is this nice plugin called X-Dashboard which allows you to configure the ‘dashboard’ on the WordPress interface.

I only recently figured out how to get the Dashboard working properly on Redbrick (see the Redbrick Wiki Topic “Installing WordPress”) so I fired up the plugin and am now able to configure what appears in it.

Whats just a little bit cooler is that you can write mini plugins for the plugin that allow you to include different feeds. So I wrote two, one for Planet Redbrick and one for Planet Irish Gaming.

Install the X-Dashboard plugin normally. There should be a folder in your plugins directory called x-dash-plugins. Create a file called redbrick_feed.php (you can use nano, pico or touch) with these contents:

< ?php
/*
x-Dash-Plugin-Name:Planet Redbrick

*/

global $wpdb, $user_ID;

$rss = @fetch_rss('http://planet.redbrick.dcu.ie/rss20.xml');
if ( isset($rss->items) && 0 != count($rss->items) )
{
xdash_show_title(‘Planet Redbrick’);

if ($xdash_cur_section == ‘main’) {
?>

< ?php _e('Below is the latest blogs from Redbrick users, click on a title to go that site.'); ?>

< ?php } ?>

< ?php
$rss->items = array_slice($rss->items, 0, 6);
foreach ($rss->items as $item )
{
?>
• ‘>< ?php echo wp_specialchars($item['title']); ?> — < ?php echo human_time_diff( strtotime($item['pubdate'], time() ) ); ?> < ?php _e('ago'); ?>

< ?php
}
echo "

“;
}
?>

and chmod it to 755. Now you can have the latest redbrick blog posts in your dashboard!

Likewise for the Irish Gaming Planet feed, create a file called igp_feed.php with this:

< ?php
/*
x-Dash-Plugin-Name:Irish Gaming Feed

*/

global $wpdb, $user_ID;

$rss = @fetch_rss('http://irishgamingwiki.com/planet/rss20.xml');
if ( isset($rss->items) && 0 != count($rss->items) )
{
xdash_show_title(‘Planet Irish Gaming’);

if ($xdash_cur_section == ‘main’) {
?>

< ?php _e('Below is the latest news from Irish Gaming, click on a title to go that site.'); ?>

< ?php } ?>

< ?php
$rss->items = array_slice($rss->items, 0, 6);
foreach ($rss->items as $item )
{
?>
• ‘>< ?php echo wp_specialchars($item['title']); ?> — < ?php echo human_time_diff( strtotime($item['pubdate'], time() ) ); ?> < ?php _e('ago'); ?>

< ?php
}
echo "

“;
}
?>

and also chmod it to 755.

Related Posts:

• Frustrating!
• Who reads this blog anyway?
• Some fun with Planet Irish Gaming
• A new look for thedeadone.net
• Maybe not the end of an era, but the end of something!

This is a tutorial for creating new “skies” for the levels and maps for the computer game Vampire the Masquerade: Redemption.

It was originally written for ModHaven (when it was still around).

Have a look at my “Akashic Records” level for a sample of a new sky in a level.

Contents

• Assumptions
• Background Info
• Tools
• How to
• Troubleshooting

Assumptions

Background Info

Tools

How to

• Step 1. Deciding what you want to do

  Have an idea of what kind of sky you want. Say you want just to have a sky that doesn’t have that annoying
  black bit the the other default day skies have. Or perhaps you want to create a sunset rather then straight day.

  With this in mind, inspect the default skies and pick one that matchs as closely as possible to what you want. (I’ve posted a list of the default skies along with pictures on ModHaven to help you).

  But for the sake of completeness here is the list of the default skies avaliable:

  NAD file	NOD file
  PragueCastleNight.nad	PragueCastleNight.nod
  pragueDaySky.nad	pragueDaySky.nod
  pragueEastNight.nad	pragueEastNight.nod
  Prague2Night.nad	Prague2Night.nod
  Prague2NightVysehrad.nad	Prague2NightVysehrad.nod
  PragueWestDay.nad	PragueWestDay.nod
  PragueWestNight.nad	PragueWestNight.nod
  judithBridgeDay.nad	judithBridgeDay.nod
  judithBridgeNight.nad	judithBridgeNight.nod
  londonNightSky.nad	LondonNightSky.nod
  londontower.nad	londontower.nod
  newyorkdocks.nad	newyorkdocks.nod
  newyorkuptown.nad	newyorkuptown.nod
  ViennaDay1.nad	ViennaDay1.nod
  ViennaNight1.nad	ViennaNight1.nod
  ViennaSky.nad	ViennaSky.nod
  Sky.nad	Sky.nod

  For example, the default sky (sky.nod/sky.nad), covers fully and would be useful for maps “floating” in the sky but for a sunset it would be useless because it’s kinda blocky rather then from bottom to up.

• Step 2. Selecting your starting point

  Extract the sky’s nod file (using the list above) (from your Resource.NOB) into your Vampire directory including the subdirectories (which should give you the dir structure 3d\Models\*.nod).

  Open the nod file in your hex editor. You should see something like this (click on the image to see in full size):

  

  You’ll notice you can read several names at the top of the file (clouds1, moon, StarField2 and dfltMatte). These are the “skins” or textures for your sky.

  Extract the files with extensions tga and nam and with the same name from Resource.NOB into your Vampire directory including the subdirectories (which should give you the dir structure 3d\Materials). Open them in your paint
  program to get an idea of what they are. Now you should figure out how and what you want to change in the sky textures.

  Choose the textures you want to edit and copy them. Rename them, but for the sake of simplicity, keep the filenames the same length (example, rename clouds1.tga to myouds1.tga).

  If any of the textures you want to use have nam files you’re going to have to edit them, which isn’t difficult: After you’ve renamed, open up the nam file in
  any text editor you like. You should see at least one entry:

  texture name.tga

  where name.tga is the name of the original texture. Just change the entry to point to your renamed texture.

• Step 3. Lets go

  Copy the sky’s nod file and rename it. Such as mySky.nod or fulldarkSky.nod.

  Open it in your hex editor and for the textures you wish to modify, rename them (by replacing character by character).

• Step 4. Create your new sky!

  Modify the new textures (most skinning tutorials should apply here).

• Step 5. View your new sky!

  Assuming you have a map prepared, open it and open the scene editor. Go to sky and in the nod text field, put in the name of your nod file. For the nad file, take the nad file from the original unedited sky.

  Export your map and Walla!

• Step 6. Including your new sky with your exported map in a nob

  Package your map as normal for a release in a NOB file. Make sure to include the nod file you created and any of the new textures you created maintaining the correct directory structure in your NOB file.

Troubleshooting

Replace the dfltMatte texture (or that odd texture thats all black) with a transparent texture (refer to the MapDepo’s Dynamic FAQ avaliable on ModHaven on how
to create transparent/masked textures).
Walla, it’s gone.

For other problems, I suggest reading up on skinning and/or ask the skinners.

Originally posted 29^th June 2001

Related Posts:

• Akashic Records (A VtM:R level)
• Seriousily, do you think I might be a terrorist?
• TankStorm