And that’s where I screw up

On Monday it was a national holiday here in Japan (勤労感謝の日) and I had about 4 hours to kill while the wife was out on her daily walk. I decided to work on my site — and what I needed more than anything was a nice heatmap to log user clicks.

I used the amazing ClickHeat which is a free heat-mapping application written in PHP. It works right out of the box, is amazingly configurable, and runs quickly thanks to it being written in clear PHP.

Wouldn’t this be great as a CakePHP Plugin!

This is where things start to get messy.

I love CakePHP. It makes development easy, is rather fast, and is highly extensible. So, I decided to wrap the ClickHeat application in a cake plugin, make it “easy to integrate” and put it in the CakePHP Bakery, instantly receiving fame, fortune and the accolades of my peers!

4 hours later

I had a mostly-working prototype that logged the data beautifully (although I couldn’t decide how to group the data on a dynamic site),  but didn’t have any of the nifty functions of the ClickHeat software such as sorting by date, admin panels, etc. because I hadn’t built those views yet. But I was hopeful!

Then my wife came home and I stopped programming for the day.

The next day, in 10 minutes

I decided to install ClickHeat on one of my corporate sites at work.

1. Copy ClickHeat folder
2. Set Cache & Log permissions
3. Turn on Japanese Interface
4. Done

10 minutes. In ten minutes I had accomplished what I couldn’t complete in 4 hours, because I was prepared to use an out-of-the-box solution instead of trying the be the programming bad-ass and integrate it with CakePHP.

So this morning, I copied the folder to my CakePHP dir, made one change to the .htaccess file:

RewriteRule    clickheat/(.*)   -   [L]

And now I have working heatmaps on my site. (I also put them on my wordpress blog, so that you can see them in action for yourself).

See the amazing Japanese Programming Heatmaps! (User: demo / Password: demo)

The final Score

So, what’s the final score?

Being a “bad-ass” programmer

1. 4 Hours Development
2. 1 extra hour of planning before sleep
3. No Viewing Functionality
4. Installation NOT user friendly
5. Call time of 300ms per click for spinning up the cake processor
   
6. Logging Works

Being a smart programmer

1. 1 Change in my htaccess file
2. 10 minutes to install/configure
3. Call time of 150ms / click
   
4. Not following “best practices” for cakephp

I think it’s pretty obvious what the best choice here is.

While I adore CakePHP and the things it lets you do simply by following convention — it’s very easy to get sucked into the “Best Practice” mindset, and waste a lot of time working on something that honestly doesn’t need to be tinkered with.

Don’t re-invent the wheel

It’s amazing how many times you can read that phrase and still find yourself re-inventing wheel after wheel after wheel. If you have a tool that does a job — use it. Do not worry about your fiddly code, and your “it’s not made here” mentality.

If the application is LACKING you can always edit it. But it makes no sense to start with something that does everything that you want, and then try to hack it apart just because you can. (Although I have to admit, it can be fun)

With those four hours, I could have

• written 1 article for my site,
• uploaded around 10 flashcard packs
• added 2 tests to the site
• read a book
• played a lot of video games
• watched a movie
• watched four (4) episodes of Doctor Who or The Green Wing.

So Keith, this is a message to you:

• Don’t be a tool
• Use your time wisely
• If something works, do NOT break it just because you want to see how it works.
• (Eat your veggies — love mom)

The DebugKit is a standard plugin for CakePHP written by Mark Story. It provides a lot more information that the standard debugging features of cake (Errors, warnings, SQL Queries) and also keeps them in a nice contained collapsible icon at the top of your page so you don’t have to have error messages and sql queries appearing all over the page.

The Debug Kit Interface

DebugKit Icon

Click the Cake icon at the top of your page, and it expands to all the tools you’ll need.

DebugKit Expanded

If you click any of the titles there, it shows you various debug information such as the current Session information, how the Request was processed, the SQL Log, a timer for all the functions that were called, currently accessible variables and the current memory usage.

DebugKit Variables View

DebugKit Timer View

All in all, an amazing amount of information. And best of all? It stays out of the way so your designs don’t get cluttered with debug information while you’re testing.

Installation

Installation is easy.

Download

Download the debug kit from ohloh. http://www.ohloh.net/p/cakephp-debugkit

Install

Place the DebugKig in the plugins folder of your application:

/app/plugins/debug_kit/[INSERT ME HERE]

Connect

Add the DebugKit Toolbar component to your app_controller, so it will be available to all your controllers.

// app_controller.php
var $components = array('DebugKit.Toolbar');

Then set the debug mode to at least 1.

Problems

DebugKit isn’t a perfect system (or maybe my understanding of it isn’t quite perfect). In any case, these are some problems I’ve had with DebugKit, but even they’re not enough to really gripe about.

Speed

DebugKit does seem to take a lot more processing power to run it than the standard Debug functions of cake.

This is easy to understand, though, as with the timers, reporters and everything, it’s doing quite a bit more than the standard Debug functions, and gives you a lot more information. I’ve had my dev-laptop exceed the 30sec execution time limit quite a few times while running DebugKit, but nothing like that has ever happened on my dev-server, so I doubt it’s anything major. It does make navigation a bit slower though, so when testing user flow, I would recommend turning it off by setting the Debug level to 0 for the duration of the session.

And remember, if you switch your debug to 0, then the DebugKit isn’t run at all, so there’s no worries about it eating precious resources on your live server.

Ajax Reporting

Ajax doesn't seem to be affected

When you make a request with Ajax, the DebugKit doesn’t seem to get spun up like it should — which results in it reverting to the standard CakePHP reporting, which (while not bad) is definitely a grade down compared to the glory of DebugKit. It would have been nice to have the reporting fed into another icon inside the div that displays the ajax result, or something to that effect. Perhaps there is a way, and I just haven’t found it yet. Always a possibility.

Conclusion

Really, there isn’t much else to say except: why are you waiting? Go download this thing now!

Ippatsu's Flashcard FaceBox

Where things went wrong: IFrames

I was fairly forthcoming about it when I released version 1.1, but my FaceBox had a major problem: Loading full HTML pages (as opposed to html snippets) borked the system. It was a combination of the <head> and <body> tags along with all that excess Javascript and CSS being loaded into an inline div that pretty much did it in. IE6 would display it (poorly) while anything else just gave up and displayed an empty box.

So I fixed it.

Starting with version 1.2 you can set a facebox to load in an IFrame by simply adding the tag “iframe” to the rel tag of the link.

So
<a rel="facebox" href="mypage.html">My Page!</a>

becomes
<a rel="facebox iframe" href="http://google.com">Google</a>

and now you’re cooking with crisco. The page will be loaded in an IFrame, and any links will be self-contained within that iframe unless you specifically break out of it.

Breaking backwards compatibility

So, I am a big believer in backwards compatibility, but unfortunately adding the iframe option, along with my desire to adhere to better HTML coding practices has made me break backwards compatibility with version 1.1.

But wait!

It’s simple to change over, and you can change over almost all your code with a simple search/replace! So let’s get to it!

New way to handle classes

The old way of handing classes was to simply put all the classes you wanted to use after a hyphen after the facebox tag, like so:

<a href="mypage.html" rel="facebox-class1 class2">My Classy Page!</a>

This brings about the problem that now “iframe” is just thought of as a class. (It’s also not very contained, and rather messy). So I changed to to be more self-contained by putting the classes in square brackets []:

The new Code

<a href="mypage.html" rel="facebox[class1 class2]">My Classy Page!</a>

Now you know exactly what is a class, and what is not, and it’s easier to use it in conjunction with the IFrames option above.

<a href="http://google.com" rel="facebox[class1 class2] iframe">This loads google in its own classy iframe</a>

Simple as pie.

New way to handle styles

Originally, my way to handle styles (useful for setting the height and width of a Facebox for a single message or page) was to put the data in the rev tag and just pass that through to the FaceBox. However, with the new class syntax, I had a chance to change the way that the styling works.

Also, the rev tag is used to describe how the current document applies to the link, so it really isn’t a good place to put the data syntactically. It’s much better to put it in the rel tag along with the class information.

The new code

So where you used to use the rev tag:
<a href="mypage.html" rel="facebox" rev="width: 500px; height: 300px">My Stylish Page!</a>

You'll now use curly brackets in the rel tag:
<a href="mypage.html" rel="facebox{width: 500px; height: 300px}">My Stylish Page!</a>

And we can combine that with the iframes and classes above, to further customize our facebox

Class and Style
<a href="mypage.html" rel="facebox[class1 class2]{width: 500px; height: 300px}">My Classy Stylish Page!</a>

Iframe Class and Style
<a href="http://google.com" rel="facebox[class1 class2]{width: 500px; height: 300px} iframe">This loads google in its own classy and stylish iframe</a>

Download the code

You can download the code right here! It’s Open sourced under the MIT License.

If you find any problems or bugs, feel free to drop me a comment!

Download FaceBox v 1.2 (Open sourced under the MIT License)

Their newest article about CSS is aimed at the CSS beginner, but has a few tricks that I wasn’t even aware of.

Floating and Overflow

The first, I want to point out is something that has always bugged me: the fact that a floated image is not completely contained within its parent container. Apparently this can be fixed simply by adding overflow:hidden to the div (autoflow:auto also works).

Floating and Double Margins (ie6 Bug)

Additionally, Internet Explorer 6 seems to double the margin of floated elements. So your 5px margin becomes 10px in IE6, and is the cause of all of my perfectly aligned floating divs crashing to the ground when I test the page in IE6 (grumble grumble hate hate)

This is also easy to fix: just add display: inline to your floated element.

.floated_element {
     float: left;
     width: 200px;
     margin: 5px;
     display: inline; /*--IE6 workaround--*/
     }

Deserves a once-over

There were alot of other great tips and points that even seasoned CSS-ers should look at — you never know when you might find something new, or an easy way to do something you had been futzing with. If you get a chance, it’s definitely worth a look.

Did you know that if you make a change to your database (for example: adding a column) and the caches haven’t been updated, it will neither SAVE nor RETRIEVE any data relating to those changes?

Did you know that cake won’t tell you that your models might be out of date, and that you can easily waste 2-3 HOURS of your life on something stupid like that?

Do yourself a favor: When you change your database, delete EVERYTHING in app\tmp\cache\models

And thankyou for the heads up, Snook.ca

I was looking for some good syntax-highlighting plugins for WordPress, but so many of them were hard to use, required configuration or just plain mangled my code.

So then I found Syntax Highlighter Evolved. Set it up in 5 minutes, easy as pie to use, and no more code mangling. Definitely recommended.

Syntax Highlighter Evolved is recommended by some guy in Japan!

Now that’s a tagline that will sell products if I ever heard one!

So, first of all, we all know what a remember me function is, right?

Yup, that's it (Wordpress)

And there it is again (google)

The “Remember me” function is a little checkbox that the user checks when they log in so that they don’t have to bother logging in again as long as they keep visiting the site every XX days where XX is the number of days that the site will remember them for.

Sounds easy! Let’s do it in cake!

Great idea! Cake should make it super easy! And if you search for cake and remember me functions, a lot (or rather a lot of variations based around 2 or 3 guys’ code) of sites will pop up. I personally recommend the RememberMe component from the Neutrino CMS, as it’s small, lightweight and doesn’t take much configuring. (And don’t believe the page that comes up when you enter “CakePHP rememberme” into google. That’s what got me off on the wrong foot)

And if you plan on something really simple with your site (i.e. logged in or not logged in) then it’s really easy to set up.

1. Get the component that you’re going to use (I used RememberMe)
2. Plop it in the components.
3. Set your references to it in your users/login function, and
4. (The most important part) attach the component’s cookie checking function to the app_controller’s beforeRender function.

Now, why’s the last step the most important? Because the “remember me” cookie needs to be checked for every time a page is visited, otherwise it can’t do it’s job. The first version of the remember me code I had used when I first started CakePHP had the cookie management in the users/login function. Like this:

function login() {
//-- code inside this function will execute only when autoRedirect was set to false (i.e. in a beforeFilter).
if ($this->Auth->user()) {
if (!empty($this->data) && $this->data['User']['remember_me']) {
$cookie = array();
$cookie['username'] = $this->data['User']['username'];
$cookie['password'] = $this->data['User']['password'];
$this->Cookie->write('Auth.User', $cookie, true, '+2 weeks');
unset($this->data['User']['remember_me']);
}
$this->redirect($this->Auth->redirect());
}
if (empty($this->data)) {
$cookie = $this->Cookie->read('Auth.User');
if (!is_null($cookie)) {
if ($this->Auth->login($cookie)) {
//  Clear auth message, just in case we use it.
$this->Session->del('Message.auth');
$this->redirect($this->Auth->redirect());
} else { // Delete invalid Cookie
$this->Cookie->del('Auth.User');
}
}
}
}

Makes perfect sense, right?

NO

The problem is that users/login only gets called when there’s a login to be processed (which is not explained very well in the documentation). This becomes a problem when you are using the Auth->allow() array to let people access parts of the site, and not others. (Even more of a problem when the same page has different data for logged in and non-logged in users)

What happens is that since the action is allowed, Cake decides that there’s no reason to check for a login, so even if the login cookie exists, it doesn’t get checked because the Users/Login function never gets called.

So, in most cases, this is not a problem — just put the RememberMe->check() function into the AppController’s beforeRender — but what if you want do something more after a user logs in? Something like increasing their login count, setting login time, getting info about them, etc etc.

Custom Functions and Remember Me

Most RememberMe components and solutions have a provision for callbacks after a successful cookie login (much like isAuthorized) however (also like isAuthorized) the function has to be in either:

• The AppController
• The Current Controller

Because the component only has access to the controller that’s currently calling it, you’re confined to either the code in the AppController or the currently viewed controller. And if your current controller is Articles (because your user is looking at an article) then we can’t directly access the users controller to run our little _after_login function. (With Models you can get to from almost anywhere in your code through skillful use of relations, but Controllers are a bit trickier)

So, what do we do? We take a little hint from the cake library, and use the wonderful App:import function to forcibly bring the Controller to us. Now this is an expensive call, because it’s essentially ringing up an entire new controller with all its associated models, et al. So we need to be sure to do this only when the user is logging in through a cookie. That way, it’ll only happen once for the user’s session, and we can quickly get rid of its memory-eating load on the next page view.

So, let’s look at some code:

The Original RememberMe component

<?php
class RememberMeComponent extends Object
{
var $components = array('Auth', 'Cookie');
var $controller = null;

/**
* Cookie retention period.
*
* @var string
*/
var $period = '+2 weeks';
var $cookieName = 'User';

function startup(&$controller)
{
$this->controller =& $controller;
}

function remember($username, $password)
{
$cookie = array();
$cookie[$this->Auth->fields['username']] = $username;
$cookie[$this->Auth->fields['password']] = $password;
$this->Cookie->write($this->cookieName, $cookie, true, $this->period);
}

function check()
{
$cookie = $this->Cookie->read($this->cookieName);

if (!is_array($cookie) || $this->Auth->user())
return;

if ($this->Auth->login($cookie))
{
$this->Cookie->write($this->cookieName, $cookie, true, $this->period);
}
else
{
$this->delete();
}
}

function delete()
{
$this->Cookie->del($this->cookieName);
}
}

?>

So, this check function has got to go

We need to be able to load the UsersController so that we can get to our _post_login() function to do all our login magic like checking how the user’s subscription is going, how long many times they’ve logged in, etc.

function check()
{
// If you want to change the cookie name, change it here
$this->Cookie->name = 'rememberme';
$cookie = $this->Cookie->read($this->cookieName);

if (!is_array($cookie) || $this->Auth->user())
return;

if ($this->Auth->login($cookie))
{
$this->Cookie->write($this->cookieName, $cookie, true, $this->period);
if (!App::import('Controller', 'Users')) {
return false;
}
$className = 'UsersController';
$Ctrl =& new $className();
$Ctrl->constructClasses();
$Ctrl->_post_login($this->Auth->user('id'));
}
else
{
$this->delete();
}
}

So, here’s my code as it stands now. What I’ve done is if there is a cookie, and you can successfully login with said cookie (Through $this->Auth->login($cookie) ) then we’re going to spin up the Controller called Users through the App:import function. If it can’t load, then we return false, but if it DOES load, then we create a new Controller and construct it so that we can then call our post_login script with the Auth->user Info. Everything else is set up just how the instructions on the RememberMe Component Page say.

Conclusion

Getting a RememberMe function working in CakePHP really isn’t that difficult, but the problem (like a lot of CakePHP) is that the signal-to-noise ratio of those who know what they’re doing and those that don’t is incredibly high. I don’t profess to have all the answers, but hopefully just some of the problems that I’ve had will help others who are struggling with the same issues.

Till next time!

This article will teach you how to:

Open facebook-styled modal windows in both alert box and full ajax-styled version, using the FaceBox modal window script and Prototype.

I wanted my signup page for Ippatsu, an online Japanese learning application, to use a modal window for the sign up dialog. This allows me to use most of the visible area for copywriting, while not requiring a page transition to load the signup form.
You can also create modal windows like these with Prototype and the OSS code I’m releasing below.

Ippatsu's Flashcard FaceBox

A little history

Originally these modal boxes were used mainly for photogalleries and whatnot, and took up the entire screen with a cool faded out background and had a lot of animations. Probably the nicest and most well known was PhatFusion’s lightbox and multibox which are written on the MooTools javascript library.

As time went on, people wanted simpler boxes that did away with all the animation and crap and so extremely simple boxes like Particletree’s Lightbox Gone Wild which is a simple box with no animation over a 70% black border. It’s small, simple and gives a rather nice effect.

So what’s the problem?

Well, the problem with animation should be obvious: It’s slow and can be jerky on certain browsers. Definately not something you want to use for a UI Element.

And the issue with the background is that when you have your entire site blacked out, while you gain focus on the window you’ve just put up, it’s not very useful for information that you want to give the user without preventing them from seeing the rest of your site. In other words, we want a Modal Window instead of a lightbox type thing.

So Bring on the Modal Windows!

As far as this discussion is concerned, I’m going to be ignoring the windows-like full modal windows that allow dragging and dropping and whatnot, and only focus on simple Modal Boxes that can be used to display data. In particular, FaceBox.

Get to the Code Already

Ok, so FaceBox is a JQuery based modal window that is pretty much copied from the facebook site where they use it to display small bits of ajax text. It is amazing. You can get it at http://famspam.com/facebox . However, it only works with JQuery, whose existance I was not aware of at the time of creating my site, so I had to find a Prototype version.

FaceBox Prototype in google gave me a couple of good links, the most popular being Phill Burrows’ blog in which he ported FaceBox from JQuery to Prototype. Unfortunately, the post (and code) is rather old, and did not work on the newest version of Prototype that I was using (1.6.0.3).

Eventually I came to two guys who took Phill Burrow’s code and updated it: Robert Gaal and Scott Davis. Both seem very nice, but I was having some problems with the slightly older Robert Gaal version, and so decided to go with JetViper’s version, as it also proposed to have class support.

Unfortunately there were a few large problems with the FaceBox code as it as written:

1. The code did not support class definitions of the FaceBox like it purported to (because of a coding error)
2. There was no way to set the size of the FaceBox from code
3. If the page being loaded was really long (such as having cakephp debug information) the window would stretch to fit all the contents height-wise, without scrolling
4. No iframe support, so loading a page with javascript borked the load.
5. No Close on Escape button

So I dug into the code and made some changes, and was able to fix problems 1-3 and 5 (and am still working on 4). The entirety of the code can be downloaded at the bottom of this page.

Fixing the classes

Looking at the original .js (line 175), you can see that Scott’s code says that you can add a class to the FaceBox content by changing the rel tag in the link to “facebox[.my_class]”

// support for rel="facebox[.inline_popup]" syntax, to add a class
var klass = elem.rel.match(/facebox\[\.(\w+)\]/);
if (klass) klass = klass[1];

Unfortunately, due to the way that FaceBox searches for FaceBox-enabled links, it will not recognize “facebox[.my_class]” as a FaceBox, as it looks for a direct match with rel=facebox.

So, I fixed that bug by changing line 93 in the watchClickEvents from

$$('a[rel=facebox]').each .....

to

$$('a[rel|=facebox]').each .....

The |= selector is a CSS Selector (valid in prototype) that allows you to define that The attribute’s exact value is “facebox” or starts with the word “facebox” and is immediately followed by “-”, so it would be “facebox-”. You can read more about Attribute Selectors at Smashing Magazine’s Taming Advanced CSS Selectors. It’s an amazing read. You can also learn about ~= (whitespace seperated) ^= (starts with) $= (ends with) and *= (contains) all of which are valid types of CSS selectors.

But wait, you say! How does “facebox-” translated to “facebox[.my_class]“?!?

It doesn’t.

I find facebox[.my_class] to be really unwieldy, so I changed it to facebox-my_class. This way, you can also put additional rel data in the link if you need, as long as facebox comes first.
All of these are valid:

rel="facebox-my_class help"
rel="facebox-my_class"
rel="facebox"

So, in light of this, we have to change the regex match in the click_handler from:

// support for rel="facebox[.inline_popup]" syntax, to add a class
var klass = elem.rel.match(/facebox\[\.(\w+)\]/);
if (klass) klass = klass[1];

to

// support for rel="facebox-inline_popup" syntax, to add a class
 var klass = elem.rel.match(/facebox\-(\w+)/);
 if (klass) klass = klass[1];

And then in your CSS to use the class:

#facebox_content.my_class{
 height: 300px;
 width: 500px;
 }

Done and done!

(As a smaller bug fix, I noticed that the original code never deletes previously added classes — only appends them, so I added this line to the reveal function to make sure that the classes were reset each time you opened a FaceBox

contentWrapper.className = 'content';

Stylize that Sucker!

So, problem 2 is that FaceBox has no way to stylize the lightwindow contents on a per-link basis — you have to define a whole new class for each type of lightwindow that you want. This in itself is not so bad, but it would be nice to have that slight extra amount of customizable power.

So, what I did is just add a “style” variable to each of the reveal/ajax/etc function calls, and had it append that style to the facebox_content div.

reveal    : function(data, klass, style){
....
//Set H/W or any other styles (also clears styles)
 contentWrapper.writeAttribute('style', style);
....

If you’re calling the lightbox from code, you just add whatever style attributes you want to the call

facebox.ajax('mypage.html', 'my_class', 'height:300px;width:400px;'

If you’re using the automatic calling from the rel tag, then you have to add a rev tag, and put your stylesheet in there. Anything you put in the rev tag will be copied to the style attribute of the contentWrapper

<a href="mypage.html" rel="facebox-my_class" rev="height:300px;width:400px">Link</a>

Simple as that!

(It should be noted however, that the height and width of the content_window does not take into account the borders, padding and footer of the FaceBox, so be sure to leave yourself a little margin of error)

No Scrollbars?!?

You still with me? It’s been long, I know, but just hang with me a little more. This is the last point.

So, as I said earlier, there’s a problem(?) with FaceBox wherein long content just makes the FaceBox longer until all the content is shown. As this system is made for display quick banners and small ajax pages and what not, it’s understandable that it would be left out, but why not put it in when it’s so damn simple?

So how do you do it?

//facebox.css
#facebox_content{
 overflow: auto;
 }

That’s it.

What this does is allows the FaceBox to extend to show all the content normally, but if you decided that the FaceBox needs a certain height (through a class or styling) then the FaceBox will be set to that height, and anything that goes over that height will be scrollable.

That Damn Simple.

In Conclusion

Not much of an “In Conclusion.” I’ve pretty much said all I want to say, so all there is left is to check out the codes~

If you find any problems or bugs, feel free to drop me a comment!

I’ve updated my code with a newer version: Version 1.2 which includes such awesome things as full IFrame support and better support for classes and styles! You can check out the Article, or just download the code from here! The way the code is used has been changed, so be sure to read the README!

Download FaceBox v 1.1 (Open sourced under the MIT License)

Now, I’m perhaps the worst pundit of designing before creating (as I’ll delve into in another post) especially when I’m trying to learn a new system at the same time (as was the case with cakePHP and Ippatsu). However, I’ve noticed that even the most anal-retentive planners and system designers cannot foresee exactly what features and what data will be necessary for their users.

We can all make grand ideas about what would be a) cool to have or b) necessary for our users. But in the end, without actually having the system move, and have those desired functions come to the forefront, there’s really no way to figure out everything that you’ll need right from the get-go.

So, as I launched my site last week, and have finally started getting users coming in, I’ve noticed that there is some admin-only information that I really want.

1. User information pages — At current, I can’t see how many flashcards each individual user has, and what they’ve been doing lately. I can only see how many times each flashcard has been registered, but not by whom.
2. User login numbers — I currently have the login times of each user logged for security reasons, but it would be nice to also have the number of times each user has logged in. I could conceivably use this in the future for a “most active users” contest or widget or something.
3. Full news pages — My top news page only shows excerpts, much like my grammar article pages (because they use the same template) but since I’m planning on having a lot more consistent and necessary data on that page, I think we need to show the full news articles, or at least until the “More” tag.
4. A more complete messaging system — At current, I have a rather anemic messaging system that just logs a message to the DB with a topic, and who sent the message. I really need to pump that up a little so that I can have a full messaging system and then be able to extend that to the users.

So, within a week of opening, I already have a load of changes and fixes that to be perfectly honest, I should have had to start with, but never even noticed the need for.

Next time I’m going to delve into some programming issues, and talk about generating automatic sitemaps with CakePHP. Till then!

I’ve never been much into blogging, even though I have to my credit: a livejournal page, a shared facebook account, a mixi account, a blogger account, and whatever microsoft was using for their blog system 2 years ago.

Suffice it to say none of these have ever been really updated with anything resembling regularity.

But I’m hoping that this blog will be a bit different. I’ve been inspired (or beaten around the head, whichever way you want to look at it) by my friend who runs BingoCardcreator.com and is also the owner of the increasingly popular small business blog MicroISV on a Shoestring which in fact was so popular that he even got interviewed for a book called Blog Blazers (Which I have a copy of, but still have never read).

In any case, he started out with the dream of making bingo cards for English Teachers in Japan, and got sucked in to the wonderful world of website optimizations and internet marketing. He’s surprisingly done very well for himself almost to the point that he makes about as much as I do at my day job by selling bingocards to school teachers.  Part of me is always glad that he chose to focus his diabolic marketing energy into something like bingocards instead of say, world domination, otherwise we’d all by singing hail to the Patrick.

So, back to the main point, I took his idea and decided to try my hand at some marketing / site-design and try to learn some new systems that I never knew before. The experience has completely changed the way that I view programming and design. Bingocard Creator is run off of RubyOnRails, the newest-and-greatest technology to ever hit the web (apparently), but as I am a dyed-in-the-wool PHP programmer I decided to try and find some sort of framework that could match the “it just works” methodology of RubyOnRails while not leaving my comfortable niche of PHP.

After checking out a lot of frameworks, I finally settled on CakePHP which is a framework for PHP based on RubyOnRails. It took a lot of getting used to, but a few months later, I feel that I am fully confident to actually use CakePHP for projects in the future, and hopefully erase some of the evil code that plagues my main site ( Ippatsu @ JapaneseTesting.com ) in future upgrades.

So, after a long and windy introduction, I lay out the purpose of this blog:

To share with anyone else who is thinking of making their own CMS-based site, the trials, tribulations and resources that helped me to get my site up and running.

Essentially I’ll be sharing programming tricks that I’ve found, marketing ideas, design resources, etc. Pretty much anything that I think that’s useful to people trying to make their own site.