The idea was to create a remotely synchronised dynamic wallpaper with text that could be set by another person remotely. Person A would type in some text, a wallpaper with the text formatted would be generated, Person B’s computer would detect that there is an update, download the wallpaper and set it immediately. (I originally wanted to make a pop up message, but realised that having "Go and exercise!" pop up during a powerpoint presentation with your boss wasn’t the best thing)

The system would operate as such: I would create a html form on my webserver to allow somebody to type in text. PHP would take the text and use GD to generate a .jpg file of an image with the text overlayed on top. Batch file on Windows computer would download the .jpg file (either on startup, or via cronw) via URL2FILE. Batch file will call imagemagick installed on the Windows computer to convert .jpg to .bmp because apparently that’s what Windows likes for wallpaper formats and converting on the server would mean a ultra big file download. Finally, batch file will tweak the registry to change the wallpaper and "refresh" it such that it changes immediately.

Here’s an example :)

PHP code:

<?php
if (isset($_POST['submit']) && isset($_POST['nag']) && !empty($_POST['nag'])) {
$width = 1280;
$height = 800;
$imgname = "wallpaper_blank.jpg"; # The empty blue background template
$im = imagecreatefromjpeg ($imgname);
$text = $_POST['nag'];
$textcolor = ImageColorAllocate($im, 255, 255, 255);
$font = 20;
$font_width = ImageFontWidth($font);
$font_height = ImageFontHeight($font);
$font_width = 10;
$text_width = $font_width * strlen($text);
// Position to align in center
$position_center = ceil(($width - $text_width) / 2);
$text_height = $font_height;
// Position to align in abs middle
$position_middle = ceil(($height - $text_height) / 2);
imagettftext ($im, 15, 0, $position_center, $position_middle, $textcolor,
'/path/to/ttf/fontfile/AllOverAgainAllCaps.ttf', $text); # We're offsetting this a little to give space for desktop icons
Imagejpeg($im, '/path/to/final/image/wallpaper.jpg', 100);
chmod('/path/to/final/wallpaper.jpg', 0644); # Ensure we can download it (depending on server setup)
echo 'Nag done!';
} else {
echo '<form action="" method="post">';
echo '<textarea name="nag" rows="10" cols="50"></textarea><br />';
echo '<input type="submit" name="submit" value="Nag!">';
echo '</form>';
}

Batchfile code:

C:\path\to\URL2FILE.EXE http://mysite.com/wallpaper.jpg C:\path\to\save\wallpaper.jpg
C:\path\to\imagemagick\convert.exe C:\path\to\save\wallpaper.jpg C:\path\to\save\wallpaper.bmp
REG ADD "HKCU\Control Panel\Desktop" /V Wallpaper /T REG_SZ /F /D "C:\path\to\save\wallpaper.bmp"
REG ADD "HKCU\Control Panel\Desktop" /V WallpaperStyle /T REG_SZ /F /D 2
REG ADD "HKCU\Control Panel\Desktop" /V TileWallpaper /T REG_SZ /F /D 0
%SystemRoot%\System32\RUNDLL32.EXE user32.dll, UpdatePerUserSystemParameters

I thought it was cute, parents loved it.

P.S. If anybody knows a sane wait to input code into WordPress/Blogilo and have it immediately embedded in <code> tags as well as not lose whitespace, give me a poke.

No related posts.

To quote some random person, this release truly brings out the “hey, it’s like a working site now“. This release sports super fancy upgrades courtesy of my schedule, which is now free from exams and school. Check out the WIPUP website now, and read the release notes.

Of course it’s also open-source, so not only do we welcome new users, but developers too! This is hopefully the last “alpha” release, so feel free to join.

No related posts.

A little history first. E2-Productions.com used to be the center of attention – thriving with the latest adolescent community fads such as animation, art and music "portals". It later saw the rise of the Blender Model Repository, a personal portfolio, several forums (trendy, weren’t they?), and finally ended with the death of the original animation portal. thinkMoult then emerged somewhere on the Blogspot blogosphere and went on to become a moderately-hacked install of WordPress on the E2 server. E2-Productions had become, and still is now, a dead site.

I’ve been toying with the idea of turning E2-Productions into a personal cloud for quite some time. It did actually occur at one point. Even though a PHP developer myself, it would take too long to create my very own cloud to implement existing free scripts. In the end I had created a network of individual PHP scripts giving me a web based RSS reader, filebin, imagebin, and a proxy. With the helpful addition of several rsync scripts and sshfs, it was usable and offered all the functionality. However of course it was very hacked together and didn’t offer the sort of integration I wanted.

Today I decided to look into other cloud services. One currently in development is ownCloud by Frank Karlitschek, the guy resonsible behind the openDesktop websites. Unfortunately the results were disappointing. Taking into account that it’s still under construction (and therefore incomplete and buggy), like the openDesktop websites themselves, ownCloud is unfortunately yet another developer service that underestimates usability. Whilst it had some nifty features in the works, it’s priorities were skewed away from the rightful mentality that design maketh a website, not the function. Further probing into the code revealed some serious problems with the structure of the coding that didn’t look very well thought out. Needless to say ownCloud is not for me.

The other famous personal cloud is the open-source EyeOS. This one goes all the way, completely replicating the desktop interface in the browser. Again, most of the design of EyeOS 1.x, their stable version, approaches the design of the system as a desktop interface. The canvas of a webpage is not suited for a desktop interface. They both have strengths and weaknesses and unfortunately most of these uncanny designs don’t play to the webbrowser’s strengths. Despite the overblown interface (which excusably is amended quite a bit in their 2.0 unstable version) it’s quite featureful and its extensibility in terms of developing it yourself is quite attractive. However the lag which accompanies such client-side interactive bloat (and server-side too!) doesn’t exactly make it the most practical of choices. It’s definitely worth keeping an eye on, though (excuse the pun).

Further searching yielded an exemplary system called Tonido. Unfortunately due to its proprietary nature it’s not for me either. However it does provide a fine example of the potential of a well executed cloud service. This motivated me to reconsider creating a cloud. I began with considering the basic user objectives for the web interface:

• Ability to dump a file online with a unique private URL, and easily share it via public URL (or a single obfuscated URL).
• Private browsing of my files with support for subdirectories.
• Browsing of images will be represented in userfriendly thumbnail form.
• Browsing of PIM data (vcard, ical) will be parsed and displayed in an appropriate format.
• Web-based uploader and/or form of synchronisation technique.

You see the "cloud" I had described (in terms of its most basic user-side functionality) as such is pretty much just a smart web-based filebrowser with mini-webapp additions for (mainly) PIM-data. Our latest newcomer to the fad, Ubuntu One, actually provides these needs very well – leaving the browser to do what it does best, and the rest to the desktop. However it falls short in a vital area – proprietariness. This isn’t a question of evangelism, it’s more of one of the simple requirements of a personal cloud. If we analyse the 5 basic user-side needs to its roots, we get a shorter list of what actually makes a personal cloud, personal:

• Fine control of private, limited, and public files.
• Convenience – data should be searchable by tags, and there should be no limit on the filestructure or methods of access.
• Timelessness – data should not be locked into any vendor.

The first issue is tackled quite well in existing cloud providers, with probably the best implementation (in my opinion) being Ubuntu One. Convenience is another easily satisfied need, with wonderful tools like rsync, sshfs, and version control software (though again, most providers lock you into their own system, and convenience ends once you leave it). However the key feature that in my eyes hasn’t yet been solved by any provider is timelessness. Any proprietary client or syncing software is instantly disqualified due to dependency on the vendor. Now, even if the software was completely open and extensible, many so called personal clouds are simply connecting to existing external services. Whilst consistent with the definition of the personal cloud, the service centralises in what is hoped to be seen as the path of least resistance – that is, only for people actually already using those services. What services am I talking about? Oh, things like Flickr, Google, Facebook and Twitter. Social is a hot topic, but not for everybody. Services don’t even have to be online – dependency on, for example Tomboy Notes or Evolution in Ubuntu One qualifies as a dependency and thus means the service is not timeless.

So how is this overcome? Not easily, for sure. I want to propose that the ideal personal cloud be one that focuses simply on file management and synchronisation. It should stop there – the actual display of files and searching of files should be handled by plugins. Plugins can decide how to properly format an image gallery. Plugins can decide how to display PIM-data. These plugins should be accomodating for the most timeless format ever, plaintext, as well as industry standard formats. The user then only applies the plugins that fits their exact workflow, if necessary writing their own for interpreting their own files. This satisfies the 3 criteria of a personal cloud.

I’m still coming up with a few plans and extra ideas on how it’ll be – but meanwhile I’ve got exams to get over. If anybody knows something similar that exists, let me know, otherwise this’ll be a fun project after WIPUP reaches stable.

No related posts.

A while back I set up Asides on this blog. The problem was that previously I was displaying 5 posts per page. Now with asides it still displayed 5 posts per page, but as asides are probably one sentence long at most I personally don’t consider them to be blog posts. This meant that it didn’t display 5 “real” posts per page. So, how do I fix this?

Disclaimer: I’m not experienced in the under-the-hood of WordPress and as a result some of this solution might be hackery. However it works for me, and that’s what counts.

Problem 1: displaying 5 real posts per page regardless of how many asides there are.

WordPress loops through a series of posts per page and displays them one by one. Initially I thought they would increment a counter, of which I could easily change so that if the post category was in “asides”, it will not increment the counter. However there were a couple flaws: 1) There was no counter, or I completely missed one, 2) The database queries sets the LIMITs from the administrator settings right at the very beginning, and 3) pagination will be completely messed up.

The solution was pretty simple, firstly we set the database query LIMIT to an obscenely large amount – more posts than we ever think we’ll need on a page. This can be done in the administrator panel. Change “display posts per page” to a random large value. I chose 15 because it seems pretty realistic that real posts + aside posts < 15 for 99.9% of the time.

The second step is to manually change the criteria for when the loop terminates. This way it will not actually show 15 posts, but instead up to 15 posts. What we’ll do is create a new counter, where ever time we display a post that isn’t an “aside”, we increment the counter, until it hits 5 posts (if I wanted 5 real posts per page) – at which time it’ll terminate the loop.

This can be done in the wp-includes/query.php page. To begin with we’ll need a new variable in the class for our counter. So below class WP_Query { we should add:

var $counting_up = 0;

Just to make sure that $counting_up resets itself as it should, we’ll add this to the init() function:

$this->counting_up = 0;

Now the next step is to modify the the_post() function. When the loop has started and the category is not an aside, we’ll increment our counter. In this example my aside category ID is category 429. This will be different for you, so you change it. So simply add this to the the_post() function:

if ( !in_category(429) && $this->current_post != -1 ) {
$this->counting_up++;
}

Now we’ve got our counter, we’ll set up the loop to terminate correctly. This can be done in the have_posts() function. Notice this is the have_posts() function inside the WP_Query class, not outside. We can modify our if statement to terminate when our counter hits 4 posts (as the first isn’t counted – therefore in effect we’ll display 5 real posts), and also when we don’t have a do_not_terminate variable set to the WP_Query. Why this do_not_terminate variable is important is if we ever need to override this, as well as later I’ll explain when we look at pagination issues. Here is my completed modified if statement:

if ($this->counting_up == 4 && !$this->query_vars['do_not_terminate']) {
$this->in_the_loop = false;
do_action_ref_array('loop_end', array(&$this));
$this->rewind_posts();
return false;
} elseif ($this->current_post + 1 < $this->post_count) {
return true;
} elseif ($this->current_post + 1 == $this->post_count && $this->post_count > 0) {
do_action_ref_array('loop_end', array(&$this));
$this->rewind_posts();
}

Now we’ve solved problem 1, and 5 real posts are displaying on our front page, let’s move on to problem 2.

Problem 2: previous page, or going to older posts will no longer work.

Since pages are pretty obsolete at this point, we’ll switch to using offsets. This is because each page will no longer display a fixed number of posts, each may display a variable amount of posts, minimum being 5 (that we set just now), and maximum being 15 (that we set at the very beginning). So to start we’ll hop over to our index.php in our theme file, and simply get the offset from the URL and pass it through to our post loop. Here goes:

<?php if ($_GET['offset'] && is_numeric($_GET['offset'])) {
query_posts('offset='. $_GET['offset']); $offsetting = $_GET['offset'];
} else { $offsetting = 0; } ?>

So with that code in index.php, we can now visit myblogsite.com/?offset=20 and offset our posts by 20. To determine how many posts to offset by in previous pages, we simply take how much we’re currently offset by, and add all the posts we’ve displayed on the page, regardless of whether or not it is an aside or a real post. To do this we need another counter. So we’ll initialise our counter, perhaps near the beginning of index.php:

<?php $on_page = 0; ?>

… then within our while (have_posts()) { loop, (or whatever equivalent loop your theme uses), we’ll just increment it:

<?php $on_page++; ?>

So then we recode our “previous posts” link to go to:

<a href="http://yourblog.com/?offset=<?php echo $offsetting + $on_page; ?>" >Previous posts</a>

That was simple, eh? This brings us to problem 3.

Problem 3: newer posts don’t work, for obvious reasons.

Going forward in time is a little bit more complex. We want to calculate how much less we should offset by. To do this we’ll create a function to calculate this. The function will need to know how much we’re currently offset by. Based on that, it’ll query 15 posts into the future, then loop through those posts in reverse order. If it can’t go 15 posts into the future (eg: on the first page, and perhaps the second), it’ll go as far into the future as it can. When looping through, it’ll record the category of each of the posts. Whenever it hits a post, it’ll increment the count we want to offset less by. When we hit a post that category isn’t an aside (category 429 in my example), it’ll increment a counter that determines how many real posts we’ve hit so far. So therefore we have two counters. When the real counter hits 6 posts, it’ll terminate the offset counter. This is because I want 5 real posts per page, and based on how we coded problem 1, we know that the last post of any page must be a real post, not an aside.

We can place this function in the functions.php file of our theme. Here is the function, of which lazy people can copy and paste:

function back_to_the_future($offset = 0) {
$new_offset = $offset-15;
if ($new_offset < 0) {
$new_offset = 0;
}
$diff_offset = $offset - $new_offset;
$future_query = new WP_Query(array(
'showposts' => $diff_offset,
'order' => 'DESC',
'offset' => $new_offset,
'do_not_terminate' => TRUE
));

$post_data = array();

while ($future_query->have_posts()) {
if ($diff_offset == 0) {
break;
} else {
$diff_offset--;
}
$future_query->the_post();
$cat_id = get_the_category();
$cat_id = $cat_id[0]->cat_ID;
$post_data[] = $cat_id;
}

return $offset - $count_total;
}

People who looked through the code will realise that we passed the do_not_terminate variable to WP_Query that we set up when addressing Problem 1. This is required because if we didn’t, we won’t get 15 posts into the future, instead we’ll just get however many posts starting from 15 posts into the future that include 5 real posts – which is totally useless.

To finish off nicely we’ll edit our “newer posts” link to use this calculated offset in our index.php file, but only display when we have a proper offset to show and we’re not on the first page.

<?php if ($future_offset != 0 || !empty($offsetting)) { ?>
<a href="http://yourblog.com/?offset=<?php echo $future_offset; ?>">Newer Posts</a>
<?php } ?>

Tada – all done! I hope that helped somebody out there, but if not at least I have it for archival purposes. If you’re using it, let me know how it goes!

No related posts.

I wanted to make E2 easy to maintain, easy to update, and most of all easy to switch between different ideas of what the site should contain. A CMS was a clear solution to this problem. E2 is the site I plan to use to showcase my portfolio in greater detail. Wipup is free to host my works-in-progresses, and thinkMoult is and always should be just a blog.

Being such a simple site with mainly static pages (perhaps a contact form) it was clear that the big poisons like Joomla, Mambo, Drupal etc were clearly out of the picture. WordPress is a CMS but a pain when you look at the source, and is mainly targeted at blogs. Some poking around led me to discover FrogCMS.

I downloaded the tarball, and had it up and running on my localhost within seconds. A quick tour around the administrator backend was enough to tell me this had all my needs covered. It supported markdown, templating, page hierarchies, and I think I glimpsed at some out-of-the-box SEO. Browsing their website also unearthed some useful plugins, although I think I will code for my needs manually.

The next step is to come up with a design. However, that’s not stopping me from using WIPUP to start tracking the upcoming upgrades on E2-Productions!

No related posts.

INTRODUCTION

Here is a nifty short guide to get people to use the CodeIgniter OpenID library to start using OpenID in your web application. Firstly I will assume you already have a registration system of some sort, and if you don’t, you should, because not everybody knows/cares about OpenID. What we have to do to spread OpenID is to provide a choice to people, not force them upon it – forcing people would simply get them to leave.

BRIEFING OF SYSTEM

So, let’s say you have a registration system that uses a table to store some sort of user ID (username/email/uid/whatever) and some sort of password. You also have a login form which all works fine, and now you want to allow people to use OpenID on that system.

Here’s the briefing on how it’s going to work. I’m assuming you know how OpenID is used already. I’m also assuming you are comfortable with PHP. What will happen is that in the place of the username field (or if you want you can make a separate form for it) people have the choice to just type in their OpenID URL, then ignore the password field. When they click the login button, firstly we will do a check for whether or not it is an OpenID URL.  If it is not valid, then we just continue checking if it’s a proper user account like our previous system and everything is fine. If it IS a valid OpenID URL, then it will perform the usual “please authenticate” checks with the OpenID server, and once that’s done, we’ll add an OpenID row to a NEW OpenID table which’ll store this stuff, and that table will also have a UID column, which allows us to bind an OpenID URL to a user account. Note that this is a one way bind, so many OpenIDs can refer to a single user account, but not the other way around.

This means you will have to create another table in your database, this depends on what type of database you are using, but in general you should have two columns:

Column 1) openid_url
This would be a varchar field to store a canonicalised version of the openid
url, for example http://foo.bar.com/

Column 2) user_id
This would be an INT that would contain the userid of the username this openid
url is binded to. This should be the key field as it must be unique.

Here is the SQL that should create this for you, but remember it only applies on SQL databases.

CREATE TABLE IF NOT EXISTS `user_openids` (
`openid_url` varchar(255) NOT NULL,
`user_id` int(11) NOT NULL,
PRIMARY KEY  (`openid_url`),
KEY `user_id` (`user_id`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8;

Now as a final note, what if a user already has account, but wants an OpenID to bind to that one instead of creating a new one? The simplest way to do this is to automatically create a new one, but have an option, perhaps in the user control panel or settings page that will allow them to “bind” to an existing account. They will have to provide that account’s user/pass to authenticate they are allowed to bind to it, and if they do, then the original account will be deleted, the user_id will change in the user_openids table, and the user will have to relogin to continue. Tada. Simple.

OK, let’s get started.

STEP 1: Setting up the libraries.

Alright, the first step is to get the library. You can obtain it from the CodeIgniter Wiki.  Now go and upload all the files. This library is … well … just a CI library, so that means it’s limited to CI functions and so it also needs the actual PHP OpenID Library to actually interface with OpenID itself. So go and download the PHP OpenID Library then upload the Auth/ directory in your system/application/libraries/ directory.  Note that this is the same place as the Openid.php file you uploaded from the CI OpenID Library. For those impatient folks who have already run the test controllers, it should’ve failed on you asking for mkdir permissions. Well, instead of chmodding our entire system, we’re just going to add those directories for it ourselves. Go to the CI root directory (the one that contains the system/ directory) and add another directory called tmp/. Go inside tmp/ and then add three more directories called associations/ and nonces/ and temp/. That should be enough to set up the library.

STEP 2: Testing if it works.

The next step, now that you supposedly have the files in the right places, is to check whether or not it works. Thankfully the CI OpenID library has already provided us with a test.php controller. So, what are you waiting for? Go to yoursite.com/test and put in your OpenID URL and see if it authenticates. Obviously if you don’t have an OpenID URL to test with, you need to go get one.  There are many providers available. If it works flawlessly (don’t forget to test with a non-valid URL to see if it catches that too) then skip the next paragraph. Or you can read it anyway.

OPTIONAL: If it doesn’t work?

Now, let’s say it’s mucked up for you. If you get nonce already used errors, try clearing out all the files in the tmp/ directory you made earlier on. Other nonces errors or authentication/redirection errors can be a problem with your CI configuration. Go to your system/application/config directory and edit your config.php file. Look for the uri_protocol option and try all of the options there. I find AUTO works fine for me but on my remote server apparently it only likes ORIG_PATH_INFO. Another glitch I encountered on my localhost is that the server would deny my authentication request. This is probably an Apache setting on my localhost but I played so much with my Apache settings it’s probably all my fault. Uploading to my remote server showed it worked perfectly there, but if you’re having problems testing it on your localhost, you might want to apply this very dirty hack. Go to your system/application/libraries/Auth/ directory and edit the OpenID.php file. The very first function is called isFailure($thing). Now screw them but right now I don’t care about authentication because I know it works on a non-mucked up server. So comment out the return is_a($thing… line and add a line after then to just simply return false;. You’ll get:

function isFailure($thing)
{
//return is_a($thing, 'Auth_OpenID_FailureResponse');
return False;
}

Note that I DO NOT RECOMMEND YOU DO THIS. IT IS A HACK IF YOU HAVE PROBLEMS RUNNING IT ON A TESTING SERVER. MAKE SURE YOU KNOW IT WORKS PROPERLY OTHERWISE.

Ok. Assuming now everything is working fine on the test controller, let’s start integrating it into our system.

STEP 3: Port the test controller to your own system.

Now we having a working test controller, but it isn’t part of our own system yet. Let’s say you have another controller which contains a Users class which deals with people logging in. Comment out all the code so that after they try to login using your existing form, it does nothing. Therefore, if your login form points to <form action=”foo/bar”>, you will comment out all the code in bar(). Now we are going to add the OpenID check.

Because a test controller already exists, this speeds up the reverse engineering process significantly as we already have a working example of use. All we have to do is do code reuse in the right places. This is a bit hard to guide because all of our user systems are different in terms of the code. So here you’ll have to use your own wits on if you need modifications to work for your own system.

Here is the system flow chart of how things are going to work – existing processes you should already have on your system are marked in dotted lines:

Firstly we want to look at section (A). This section deals with checking if it is a valid OpenID URL. This can be done by copying the test controller function exactly. I have also added at the beginning some code, so read the comments as to why. Put this code in the function where your login form would normally point to in the <form action=”foo/bar”>. So therefore you would put it in the bar() function. For the moment, we are going to disregard going to section (D), as this is covered later on in Step 4. Here is the code you have to put in bar():

// Before we check if the username is in fact an OpenID, we must secure
// the variable. OpenID refers to the url as $user_id, so be sure to assign
// the value of the inputted openid to $user_id. Here is have used
// $this->username but this might change on your system.
$user_id = trim($this->username);
$user_id = htmlspecialchars($user_id);

// Load the neccessary OpenID libraries as shown by the example.
$this->lang->load('openid', 'english');
$this->load->library('openid');

$this->config->load('openid');
$req = $this->config->item('openid_required');
$opt = $this->config->item('openid_optional');
$policy = site_url($this->config->item('openid_policy'));
$request_to = site_url($this->config->item('openid_request_to'));

$this->openid->set_request_to($request_to);
$this->openid->set_trust_root(base_url());
$this->openid->set_args(null);
$this->openid->set_sreg(true, $req, $opt, $policy);
$pape_policy_uris = array();
$this->openid->set_pape(true, $pape_policy_uris);
$this->openid->authenticate($user_id);

Now, to better integrate into your system (this is optional, but HIGHLY recommended) you should go into your system/application/config directory and edit the openid.php file. Edit it to fit your needs. openid_required is the required information you want to grab from the openid provider, and openid_optional is the optional information you want to grab. That’s all good and fine, but what we’re interested in is the openid_request_to variable. This is the link to the function that checks the authenticity of the openid URL.  Right now it goes to the test check function, but I would recreate this check() function in my own controller, as keeping it in a test controller is … stupid.

So if you change the openid_request_to option, you need to recreate the check() function. So it’s practically a copy and paste. Just copy the check() function from the test controller into the controller you want to store the check() function in. Here is the copy and pasted code, with some added comments to show where things happen:

/**
* Checks for proper OpenID authentication.
*/
public function check()
{
$this->lang->load('openid', 'english');
$this->load->library('openid');
$this->config->load('openid');
$request_to = site_url($this->config->item('openid_request_to'));

$this->openid->set_request_to($request_to);
$response = $this->openid->getResponse();

switch ($response->status)
{
// This is probably the most important bit of the check. The switch case
// statements. They're pretty obvious as to what they do. All the same,
// I have bolded part of their names for the hard of thinking ... haha.
case Auth_OpenID_CANCEL:
$data['msg'] = $this->lang->line('openid_cancel');
break;
case Auth_OpenID_FAILURE:
$data['error'] = $this->_set_message('openid_failure', $response->message);
break;
case Auth_OpenID_SUCCESS:
$openid = $response->getDisplayIdentifier();
$esc_identity = htmlspecialchars($openid, ENT_QUOTES);

$data['success'] = $this->_set_message('openid_success', array($esc_identity, $esc_identity), array('%s','%t'));

if ($response->endpoint->canonicalID) {
$data['success'] .= $this->_set_message('openid_canonical', $response->endpoint->canonicalID);
}

$sreg_resp = Auth_OpenID_SRegResponse::fromSuccessResponse($response);
$sreg = $sreg_resp->contents();

foreach ($sreg as $key => $value)
{
$$key = $value;
$data['success'] .= $this->_set_message('openid_content', array($key, $value), array('%s','%t'));
}

$pape_resp = Auth_OpenID_PAPE_Response::fromSuccessResponse($response);

if ($pape_resp)
{
if ($pape_resp->auth_policies)
{
$data['success'] .= $this->lang->line('openid_pape_policies_affected');

foreach ($pape_resp->auth_policies as $uri)
{
$data['success'] .= "<li><tt>$uri</tt></li>";
}

$data['success'] .= "</ul>";
}
else
{
$data['success'] .= $this->lang->line('openid_pape_not_affected');
}

if ($pape_resp->auth_age)
{
$data['success'] .= $this->_set_message('openid_auth_age', $pape_resp->auth_age);
}

if ($pape_resp->nist_auth_level)
{
$data['success'] .= $this->_set_message('openid_nist_level', $pape_resp->nist_auth_level);
}
}
else
{
$data['success'] .= $this->lang->line('openid_pape_noresponse');
}

// At this point, we have authenticated the OpenID COMPLETELY, and
// we have also grabbed whatever information we have requested. For
// example:

// $nickname is the nickname we have grabbed in openid_required. It
// may or may not be empty.
echo $nickname;
if ( !$nickname )
{
// If $nickname is blank, and we require it for our system, we
// should now execute some code that will ask them to fill out a
// nickname. This is for you to figure out. It will probably
// loading a separate view or redirecting.
}
else
{
// If we have all the required information we need, we can move on
// to section (C) in the flow chart.
}

// Remember we had to store the openid URL in a new table so we can
// bind them to users? $esc_identity is the variable you need. Note:
// it is canonicalised - that means that the format is standardized
// such as foo.bar.com becomes http://foo.bar.com/.
echo $esc_identity;

break;
}

$data['pape_policy_uris'] = array(
PAPE_AUTH_MULTI_FACTOR_PHYSICAL,
PAPE_AUTH_MULTI_FACTOR,
PAPE_AUTH_PHISHING_RESISTANT
);
// I have commented out the load->view because we want to use our own
// view. See flow chart. You will have to edit it so that it does what
// YOU want it to do. All I am doing is showing you how to set up a
// basic structure.

//$this->load->view('view_openid', $data);
}

Ok. After you’re sure you know or have a brief idea of what’s going on, also note that several other functions are referenced to. So you’ll also have to add the _set_message() function to this controller. Just copy and paste from the test.php controller. MAKE SURE YOU DO THIS.

Now we have a working check() function. So if we’re on the SUCCESS switch case statement, we now have the requested information we need and an open ID url. The requested information (in the example code above it’s $nickname) can be used in section (B) of the flow diagram, and the canonicalised openid URL can be used in section (C) of the flow diagram. So hooray! We now have a working OpenID system. How you are going to display the form to request for additional information is UP TO YOU on how you are going to add it, as it depends on your system.

STEP 4: Integrate OpenID check with normal usersystem checks.

We’re almost done here. Let’s take another look at section (A) of the flow diagram. Through reverse engineering the OpenID library, we can see that when it checks if it is a valid openid URL, and returns FALSE, it will use the _set_message() function to and give an appropriate error message. This _set_message() function can be found in the system/application/libraries/Openid.php file. If you look at it, it will echo the error message then call an exit(). Now, we don’t want to grudge our users with annoying error messages, especially if there is NOTHING wrong if they don’t provide an openid URL. (Remember, I am assuming you are merging your existing login box with your openID login box. NOT making a new openid login box – if you are making a new login box, you can pretty much disregard this step.) We also don’t want to call an exit(), because we want to continue with section (D). So comment out the echo and the exit line. After commenting them out, we want to replace the exit with something that will tell our script to skip the rest of our OpenID check and go straight to our usual account checks.

Here’s how we do it. (There might be alternatives, but this is what I think is the easiest) We will add a header redirect in place of the exit; line. Here’s what you should get:

function _set_message($error, $msg, $val = '', $sub = '%s')
{
$CI =& get_instance();
$CI->lang->load('openid', 'english');
//echo str_replace($sub, $val, $CI->lang->line($msg));

if ($error)
{
//exit;
header( 'Location: /foo/bar/0' ) ;
}
}

Where foo/bar goes to the same place as your <form action=”whatever”> we talked about in the beginning. Notice I pass a parameter ’0′ to the function. This is so that we can restructure the existing bar() function to follow this sort of pseudo code:

function bar($check_openid=1)
{
if ( $check_openid )
{
// Here you execute the OpenID check code (NOT THE check() FUNCTION)
// that you added in step 2.
// Note that successful OpenID logins/registrations will occur in
// the check() function, which is elsewhere.
}

if ( !$check_openid )
{
// Now you continue with the code the describes section (D) of the
// flow diagram.
}
}

… and that’s it! You should now have the basis of a system that accepts both traditional user logins and OpenID. Obviously you have a lot of extra to add in but if you’re here anyway you should know how to adapt it to your system and what else you have to add. Particularly in sections (B) and (C). I’m not going to guide you how to do those steps as it depends on what information you want, how you want to display your request form, and how your database is structured. I’m very sorry, but you will have to work it out yourself. (It shouldn’t be too hard)

I have tested this as this is a running documentation based on what I have done to integrate OpenID in my own CI run site. However of course there may be bugs and things I’ve missed out, any comments will be appreciated, and of course I will answer questions (just leave it as a comment)! :) Spelling corrections are also welcome.

Please do NOT copy this post. Just link to this page if you want to share it with others.

I hope it has helped! Please leave a comment as I love “thanks yous”.

No related posts.

Right now, being 00:18AM (and counting!) I’m going to continue this series to talk about a few hidden tricks and activities you could use your computer for that you might not be accustomed to normally.

RSS Feeds

It’s amazing how many people who don’t know what an RSS feed is. RSS stands for Really Simple Syndication (yeah, really) and is basically a format of a web feed. In technophobe terms, this means it’s a fancy new way you can access information. For example, you can access your emails through your email client, you can view web pages with your web browser, and now you can view RSS feeds with, well, an RSS aggregator (or reader). Ok, it’s more complex than that, but that’s all you really need to know.

Let’s use a practical example to explain the usefulness of an RSS feed. Let’s say you absolutely love the thinkMoult blog, and you want to keep up to date on it all the time without getting extra spam in your inbox notifying you of updates. Well, like most blogs, we offer an RSS feed (hint: that was a link to our feed URL) You can input that URL into your RSS aggregator (which is a program you can download), and you can now easily view each post just as it is: a snippet of information, instead of laid out in this bulky (though beautiful) webdesign. It allows you to quickly parse information from all around the web in bitesize pieces. Don’t read too many blogs? You can also use it perhaps for comics, such as Dilbert or XKCD. Now you don’t need to remind yourself to check those pages for updates every time you’re online.

Multiple IM Protocols

Now, that’s just a fancy and technical way of saying MSN Messenger isn’t the only thing that exists. You can use Skype! You can use Jabber (such as GTalk), Yahoo chat, and there are so many other popular IM services that people use, you might just need to sign in to those accounts to make sure you can contact all your clients or important whomevers you meet online. I personally use Skype, MSN, and GTalk all the time.

You might find it’s a hassle to manage the multiple accounts, but fear not! There are less handicapped programs than your Windows MSN Messenger that actually support multiple protocols! For example, I use Kopete on KDE, and I can sign into all my accounts (save for Skype) with just one client. It really makes life easier.

Also, I know it isn’t exactly IM, but you should also familiarise yourself with IRC. IRC stands for Internet Relay Chat, and it’s what the whole online community used before other things got invented. Right now it’s still a massively popular form of communication, though mostly populated by people of the more intelligent and technical sort. It’s basically a huge chatroom (think 800 people per channel) categorised by topic. There are many IRC servers, though the most common is arguably irc.freenode.net. What you’ll need is an IRC client (try HydraIRC on Windows or IRSSI on Linux), and connect to the irc.freenode.net server. Once in, you might want to try joining some channels related to what you’re interested in. For example, I can be found regularly in #gentoo, #gentoo-kde, #gentoo-chat, #blenderchat, #vim, and occasionally some others depending on what I’m doing.

Set up a Personal Server

Yes, you can easily set up your own web server, even on Windows. You don’t need to be a rocket scientist. There’s this nifty little prepackaged LAMP setup (that’s Linux Apache MySQL, and PHP) in the disguised form of XAMPP. The absense of the L means it probably works on Windows, eh? The extra P is probably for Python or Perl, but I haven’t poked too much in the package to find out personally.

What use is a personal server? You can dump your files in it, give others your IP, and then they can easily download files from you. If you’re on a network (even through your router), you can easily transfer files from one computer to another at speeds reaching up to 1gb per second (either that or the little notification window lied). If you’re into webdesign, or need an environment to run PHP scripts, that’s the perfect place to do it! Or even if you want to use PHPMyAdmin (oh, the extra P could be that too) to interface with your MySQL databases (if you use them, of course) a server is probably the most useful thing you could have.

Set up some transfer protocols

We’ve all known the popular protocols, FTP, SSH, SFTP, Telnet, etc. Why don’t you set it up on your own computer? Let people upload files to your computer. Let people connect to your computer and control it remotely! If you have an X server, let people do X tunneling through SSH so from anywhere you can access your GUI applications. Or if you’re braver, setup a VNC server too so that you can control it as though you were sitting right in front of it!

You’d probably have to do some research on how to set these up for your operating system (for Linux just check your package manager), but it’s worth it. The ability to remotely access and manipulate your data from anywhere in the world is priceless. It has plenty of uses too! You can access your files from anywhere (that’s the obvious one). You can debug applications or even your failing router. You can have two people connect to one computer and run tutorial sessions, or do Extreme Programming (a style which involves two programmers working at the same time).

A word of warning though, please learn how to secure these connections, you don’t want random people poking through your stuff.

Well, that’s it for this part of the series. I realise it’s turned ever so slightly more geeky, so I promise the next part will be a lot simpler. If you aren’t of the technologically savvy type and you are reading this, you have a huge amount of research to do before you can find out how to accomplish all these things. However, repeat after me: “It’s worth it.”

No related posts.

During the documentation, I will also teach you the do’s and don’ts of website creation. These are often overlooked, and you’d definitely pick up a lot of tricks that normally take years of experience to develop.

Understanding the resources around you.

Here’s a list of useful resources for the impatient: HTML, CSS, PHP, MySQL, Javascript, Ajax, Free scripts (yes, really), stock images, SVN, Git, Mercurial, Image editing applications (The GIMP), text editors (Vim).

OK, firstly I’m going to talk about setting up your mental and physical environment before you start a project. A lot of people who don’t develop with computer more than often disregard this vital step, and end up rushing or making a mess of things. The first step is to make sure you know what you want your site to do. Will it be a blog? Will it be your online portfolio? Will it be yet another youtube clone? If you know what it does, you should also know what type of person will use it, and what features it should have. You need to be clear on what features it should have, as that’s the bulk of any web-app.

Assuming that you now know what your site is about and what features it will offer, it’s time to make sure you really know what’s going on. Has it be done before? If it has, what can you offer that other sites don’t? What can you learn from existing websites? Are there useful javascript or ajax snippets that can give your webpage that extra zing that makes it stand out? For example, people developing a personal portfolio website might be interested in Lightbox, as that’ll improve continuity on the site and remove layout restrictions. It also makes things look cooler in general. (yes, I really said that)

The next step is to know your limits. You will need to know HTML back to front. Sure, you can forget tags, but as long as you know they exist, that’s fine. As the saying goes, the great programmer doesn’t need to remember it all. There’s really nothing wrong with using cheatsheets. If you do know HTML, make sure you know how to validate it. If you’re epically extreme about this, make sure you can get XHTML 1.0 Strict validation on all your pages. It’s all about discipline, and in the end it helps with cross-browser functionality and compatibility with newer devices like mobile phones. Just take the extra step, and please, oh please, validate your code.

Do you know CSS? Do you use CSS? Any site nowadays should only contain semantic markup and use CSS to effectively seperate design from layout. No matter what you do, do not use tables for layouting. It’s bad. It’s evil. It causes the folks in the #css IRC channel to condemn you to heck. It’s good practice. If you’re unsure what I’m talking about, read this handy guide. Of course, also don’t forget to validate your CSS code.

Do you know PHP and MySQL? True, this isn’t the only way to make sites, but it sure is popular, and hell powerful. How good are you at it? Do you know OOP, do you know MVC (or other framework styles)? If you answered no to either one, take your time to go and re-learn PHP. You’ll might find you’ve been doing it all wrong. Don’t disregard that warning, really, take your time and re-learn what it is.

How big is the project? Do you need version control for it? It’s quite comon for people to dump version control for web projects, even individual ones, as it really makes the developing stage less confusing. If you don’t know what version control is, try search it up, then search up CVS, SVN, git, and Mercurial. You should try it out on your system, get familiar with it and perhaps use it in your next project.

Are you good at design? This does not necessarily mean you have to be a wiz at something like Photoshop (ewww) or The GIMP, there are some really simple designs that look amazing. If you do follow the “Create graphic image” -> “Slice” -> “Create web-app” workflow like most do, do you know how to use CSS in the slicing stage? Do you know how to create a design that won’t break in flexible layouts? Do you know how to solve the never-ending battles with CSS and IE? (Yes, all those dirty coding hacks that are so troublesome)? Do you have good stock graphics? Most disregard stock graphics, but they really add shine to the page. Have you considered web load-times and optimisation when designing? There are hundreds of things to consider, and over time all these things become natural.

Don’t underestimate planning and protoypes.

Don’t underestimate the importance of this step either due to the shortness of this section. User Interface is almost the most important thing that exists on a webpage. Don’t get me wrong, I’m not saying that your backends and server-side scripts aren’t going to do the trick too, it’s just that your site is going to be used. To be honest, change the splash image of any application, and even if you don’t add any new features, it already looks as though it’s had a bunch of action packed updates over the last version. You want to have a clear idea of several things:

1. The homepage of the site. This is the very first page people see, and the most important of all. This is what gives them their first impression, this is the page that should explain what you do, why you exist, and how you can benefit the user in less than a minute. This will be the central template design (especially for large scale sites) that defines the organisational structure and navigation style used throughout. Do not ever be inconsistent with design.
2. Your databases. Yes, that’s right. You want to know what’ll be stored, where it’ll be stored, what’s the best way to store it so it can be used efficiently. The word that must be drilled into your head is modularisation. (Not a real word, but we aren’t learning English here, are we?) Basically, you want to use it one way, and any way you might think of in the future. I’ll cover this in more detail when I talk about setting up databases later.
3. The system and framework. Yes, I stress frameworks again. Too many a PHP script kiddy has spewed out nothing but spaghettic logic. It’s not a fate you deserve. What framework are you going to use? Build your own? Use a preexisting one? Any needed libraries? How should you divide the logic framework into modules?

Work, flow. Work!

The third and last topic I will cover in Part 1 of this series is workflow. This is VITAL. Read that again. That’s the acronym for Very Important Topic Aids Learning. I won’t go into much detail, because all my next parts will focus on workflow too. Some thing you might have noticed here. I did not mention servers or domains. That is NOT your concern. Too much worrying about servers and domains will leave you with a crappy system that’s up 100% of the time. Which nobody wants. You need to make your site? Need a server? Install Apache on your localhost and build it there. Don’t waste money on a half-baked-idea.com.

Workflow is amazingly flexible, but there are some one-size-fits-all that works. The first thing you want to get out of your way is the environment stuff I talked about in the first topic I covered. Know back to front what’s going on and how it’s going to go on. Assuming you have that all worked out, you’d want to create a design using an image editing program. Even if your site is something like Google or Yahoo that has a high text:image ratio, you want to visualise it first. No point playing around with CSS if you haven’t got a clear image in your head. Once you’ve got your visualisation done (good for the home page), create a valid HTML and CSS slice of the page. Split it up into template files and start organising and creating dummy filesystem structures in your framework. Create a couple static non-dynamic pages just to check the flexibility of the layout (stretches, different tags: forms, inputs, divs, headers), check cross-browser compatibility, and then when you’re done, make the home page and fill it with placeholders as necessary.

Now you can start working on the actual logic and system of the website (excluding previous framework setup). The first step is to create all your needed database tables, and choose the appropriate field types and set values. After this, since I use an MVC framework for most of my sites, I like to work pretty much … in that order. I build the models first, build the views, then just connect everything beautifully with the controllers. I generally like to start with building the user system, which is often the key and wire system of a website. This covers easy stuff like database input, form building, error and message templates, and general usability of the site. It’s the perfect “mini-system” to test the effectiveness of your framework, templating system, and helper libraries.

It all pretty much spins off from there, before venturing to code debugging, stress and user testing, hacking preventation, and advertising. Website creation is a huge topic, and unfortunately a text-heavy one too. Hopefully I’ll write part 2 soon!

No related posts.

<?php
include './inc/template/header.php';
if ( $p == '' )
{

include './inc/pages/index.php';

}
elseif ( $p == 'about')
{

include './inc/pages/about.php';

}

[... etc ...]

else
{

include './inc/template/404.php';

}
include 'footer.php';
?>

Well. Look familiar to anybody? (or even worse examples!) Hah! My good sir, you have just missed out on the programming epiphany of the century. Any script kiddy with the guts to program before learning OOP should have their guts removed, quartered, and stuck up as a warning to other coders. So, if you are doing PHP, but you don’t know what OOP or MVC is – here is your cue to fricassé your arse and get ready for some late nights of programming ecstasy.

This post is somewhat a half-rant about the disadvantages of coding without any OOP or proper framework, and also a sort of happy unrelated babble talk brought about by me recently opening up (g)Vim again to code some very simple PHP, then taking a look at POSE2. For those that don’t know, POSE2 was the project to basically make E2 as open as possible. It’s an MVC (Model-View-Controller) framework, with no built-in helper classes. It’s extremely minimalistic. It was used to construct VisionBin, and E2-Productions.com currently runs on it too.

Hilariously enough, I fell into the common programmer trap of recreating the wheel. That’s why now, instead of advertising my oh-so-awesome POSE2 system, I’m going to be recommending you CodeIgniter. CI is a fast, clean, superbly documented MVC PHP framework. Or so I say before trying it out properly. Let’s actually see how awesome it is. I will type this post out live as I convert the extremely simple E2 site from POSE2 to CI.

Ok, apparently my connection hates me as it keeps on failing to download the tiny CI source files. After several retries, I finally am ready to start …. ok, uploading onto E2. This is great as I don’t get a lot of extra unneeded files in the / directory (except for index.php, obviously!), so everything is nicely tucked away in the system directory. Ok, quite a lot of files being uploaded here, but compared to other frameworks, this is slim. Let’s try visiting it without bothering to read any installation documents. Yep, already, it’s working without any needed config. I don’t see any installation docs (perhaps I’m just blur) but I do notice a config/ directory. It’s wonderfully documented and there’s quite a minimal amount to setup. .htaccess is a pain to setup due to specific server configurations (took quite a bit of debugging, but the option to fix it was hidden in the configuration), but other than that, it worked flawlessly. Easy to create new views, models, and controllers. Lots of helper classes – perfect, looks like exactly what anybody needs. Embeddable views to enable for templating…perfect.

First impression: wonderful, fast, user-friendly and amazingly well documented. Will give future updates on how I find it as I use it more. Meanwhile, I definitely recommend it to people.

No related posts.

Ok, first we want a layout…Let’s be simple (just forget validation temporarily, this just an example):

My title.<br />
<a href=”http://site.com”>Home</a><br />
<a href=”http://site.com/asdf”>asdf</a><br />
content will go here<br />
Copyright.

Let’s save that file as index.php. Save it in a directory called “versionname” (you can change this, but remember to change the rest of the code as well) Now, replace “content will go here” with this:

<?php
if($page == “”) {
include “/home/username/public_html/versionname/home.php”;
} elseif($page == “asdf”) {
include “/home/username/public_html/versionname/asdf.php”;
} else {
echo “error”;
}
?>

Basically, it will see what the value of the variable $page is and accordingly, it will display the correct page.
Create a new page called home.php (you can put whatever you want in it), and save it in the “versionname” directory. Then create a new page called asdf.php and put whatever you want in it and save it in the “versionname” directory.

Now try and go to yoursite.com/versionname. It will display your home page. Then go to yoursite.com/versionname/?page=asdf. It will display your asdf page. Let’s say in the future you decide to change your layout…you only need to change one page…the index.php page.

Ok. now instead of ?page=asdf, lets turn it into just /asdf. Go into your public_html folder (or your equivalent of it) and search for .htaccess. Open it up. This is apache server scripting. Won’t go into much detail though. You’re probably annoyed because you want your homepage to be in yoursite.com and not yoursite.com/versionname. Simple, add this code in .htaccess:

RewriteEngine on
RewriteBase /

ReWriteRule ^/$ versionname/index.php
ReWriteRule ^$ versionname/index.php

Now, try to go to yoursite.com. Amazing! The URL didn’t even change! Now to change into /asdf. add this:

ReWriteRule ^asdf/$ versionname/index.php?page=asdf
ReWriteRule ^asdf$ versionname/index.php?page=asdf

Now, go to yoursite.com/asdf. Amazing! It showed the ?page=asdf page!
Ok, now that you’ve done all that, let’s say you want a new version, but you don’t want to delete everything and setup a coming soon page. Create your new version in a directory called “versionname2″.
Now, you want people to be able to access your new version, but not all people. So here’s what you do. Add this to the top of your versionname (not 2) index.php:

<?php
session_start();
header(“Cache-control: private”);
if( $_POST[beta] ) {
if( $_POST[pass] == “yourpassword” ) {
$_SESSION["beta"] = “1″;
}}
if( $_SESSION[beta] == 1 ) {
include “/home/username/public_html/versionname2/index.php”;
} else {
?>

And now, add the form below to wherever you want the verification to be:

<form method=”post” action=”"><br />
<input name=”pass” type=”password” class=”input”>
<input name=”beta” type=”submit” value=”betatest”>
</form>

So now, when you type in the password “yourpassword” in the form, you will be browsing your new version, with no edited URLs! Of course, to make it fully compatible you need to add the if $page=”" statements to your versionname2 index.php, but that’s simple to do.
Ok, you’ve finished coding your new version. Simple, just go to your .htaccess, and replace all the /versionname to /versionname2. Done! You’ve succesfully upgraded your site.

Note: this is very basic but I hope it has helped some of you.

No related posts.