Total Visitors

• 8,282 Visits (98% New Visitors)
• 8,104 Unique Visits

Now at a glance this seems to be a decent surge in traffic but it’s not that black and white. Here is why:

The amount of new visitors is, as expected, quite high, though how many of them actually read the content, commented, and will be returning?

The Bounce

The bounce rate is determined by taking the amount of visitors that go to a single page and exit on the same page. Essentially this means they visited our single post, and didn’t bother to see if there was anything else on the site. Now once again this is to be expected as the majority of the traffic came solely for the purpose of reading that single article.

• 93.67%

So roughly 7,595 of the visitors we received never left the original blog post, while 513 of them clicked off to another page.

Time On Site

Now this is a fairly obvious metric, though it means the average amount of time people spent on your site.

• 14 Seconds

That’s right, 14 seconds. Now I’m not sure the average reading speed of reading for internet users, though this would seem that it’s a little on the short site. I’m lead to believe a large portion of the visitors simply skimmed the page rather than fully reading and understanding the content.

*NOTE* The last sentence may be interpreted wrong: I believe the majority of people quickly glance / speedread the content and if something catches their eye, they’ll go back and try to absorb the information. Obviously our post is somewhat niche since it deals with phpMyAdmin which is popular, though it still interests a small portion of the internet community as a whole.

Page Views

This is another obvious metric, and somewhat of a obsolete one, though interesting nontheless.

• 9,047

Now if we take this number and subtract the total amount of unique visitors we arrive at 939. Now the astute person would notice that this is almost double of the above number I arrived at regarding the bounce rate. This just simply goes to show you that statistics obviously aren’t 100%, and depending on the mechanism used to measure the statistics these will vary. Regardless I find it interesting to see an almost 100% difference – any one have any idea as to why?

Traffic Sources

This metric is simply tells us what percent of visitors came from where (direct, referring, or search engines)

• Direct Traffic: 12.90%
• Referring Sites: 87.09%
• Search Engines: 0.01%

Now this is clearly wrong – this blog literally has no real traffic. Unfortunately if a browser doesn’t send referral data, or a website redirects in a way to not send the data it’ll count it as direct traffic. What somewhat surprised me is how large of a margin of error this is.

Referrals

Now this is the fun metric – where the heck did all of this traffic come from. Obviously being on the front page of /r/programming and Reddit caused the majority of traffic, though not all of it:

• Reddit.com – 6,060 visits
• Direct (none) – 1,070 visits
• Popurls.com – 316 visits
• StumbleUpon.com – 307 visits
• Delicious.com – 142 visits
• Google.com – 106 visits
• Wired.com – 68 visits
• Jimmyr.com – 40 visits
• Twitter.com – 18 visits

Keep in mind we only posted this on Reddit, everything else came organically by word of mouth, aggregator, and so forth. This also shows the discrepancy in the referral / direct reporting, showing 1,070 direct visitors.

*NOTE* Since this site is so new and lacking content, all references to Google are from their applications such as Google Reader, GMail, etc.

Conclusions

If you get on the front page of Reddit / submit a popular story you will receive a surge in traffic, though a large portion of those people will simply glance / exit right away and will likely never return.

Also you need to take your statistics with a grain of salt – there is a fair margin of error when you start trying to dissect the statistics.

What may be less known is that phpMyAdmin comes with a variety of features that aren’t enabled by default.

Enabling the features

To enable these features, you will first need to create a database called “phpmyadmin”.

Once that’s done, execute the SQL file “create_tables.sql” found in “/scripts”.

Afterwards, open up the phpMyAdmin configs file: “config.inc.php” and uncomment the following lines:

$cfg['Servers'][$i]['pmadb'] = ‘phpmyadmin’;

$cfg['Servers'][$i]['bookmarktable'] = ‘pma_bookmark’;

$cfg['Servers'][$i]['relation'] = ‘pma_relation’;

$cfg['Servers'][$i]['table_info'] = ‘pma_table_info’;

$cfg['Servers'][$i]['table_coords'] = ‘pma_table_coords’;

$cfg['Servers'][$i]['pdf_pages'] = ‘pma_pdf_pages’;

$cfg['Servers'][$i]['column_info'] = ‘pma_column_info’;

$cfg['Servers'][$i]['history'] = ‘pma_history’;

$cfg['Servers'][$i]['designer_coords'] = ‘pma_designer_coords’;

$cfg['Servers'][$i]['pmadb'] = ‘phpmyadmin’;

You should now see a couple of new buttons in the horizontal menu after selecting a database:

Designer Mode

The designer mode allows you to visualize your database structure and create table relations on the fly.

You may not be able to create the structure of a database with this tool, but it does a good job at creating a diagram out of an existing structure and allowing you to trace relations. With only two clicks you can create a foreign key relationship between two tables.

The “Save position” button is great for saving your diagram for later use.

The designer mode also allows you to print and export the diagram. This feature can be really useful when there is more than one person on the project or when you need a paper copy of the diagram.

Query History

Another great and underestimated feature is the query history.

I can’t help but think of the numerous times I ran queries in phpMyAdmin and had to re-run them again at a later moment.

The query history tool allows you to view a list of all SELECT queries you executed.

Unfortunately this SQL history is only available for the current session. The next time you login or if you are booted out of phpMyAdmin, you will lose the content of the query history.

To access the query history, simply click the “Edit” link after executing a query.

Clicking the “SQL History” tab will bring you to the query history window:

Query Bookmarking

The query bookmarking feature complements the query history feature. In essence, it allows you to save a query for later use.

You can bookmark a query in the previous dialog window as well as the “SQL” tab in the database view.

After bookmarking a query, you can execute it from the SQL tab.

For example, suppose we have this table:

CREATE TABLE `user` (
`id` INT( 10 ) UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY ,
`active` TINYINT( 1 ) UNSIGNED NOT NULL ,
`username` VARCHAR( 32 ) NOT NULL
) ENGINE = INNODB ;

We can bookmark the following query so that we can have easy access to active users:

SELECT * FROM user WHERE active = 1

A neat feature included with the bookmarking tool is the variable option. This option lets you dynamically add a variable or a statement to the query when executing the bookmark.

For example, we can bookmark the following query:

SELECT * FROM user WHERE active = 1 /* AND username = ‘[VARIABLE]‘ */

When we execute the bookmark with no variable, the second part of the query will simply be sent as a comment.

Suppose I execute the bookmark with the variable value ‘chris’, the query will become:

SELECT * FROM user WHERE active = 1 AND username = ‘chris’

Many other features are available after enabling them. It’s really a matter of browsing through phpMyAdmin to find them. That being said I hope this will help people increase their productivity when using phpMyAdmin.

- Christian Joudrey

If you are looking for a fast way to implement a membership system without the hassle of programming a registration and login module, Sign in with Twitter may be your best bet. Not only will you be saving development time, but in the long run you may actually get a lot more members than with a normal registration form.

Think about it… How many times have you visited a site and landed on a registration page to find an endless form and an e-mail activation at the end of all of it.  Speaking for myself, this is a major turn off. I find myself registering to more websites that have the social sign in feature than those that don’t. After all it’s a matter of a few clicks and I am registered on the site.

As of today, Twitter has 23 million unique visitors per month. Most of those visitors have a Twitter account, hence would automatically have an account on your website as well.

The sign in process cannot be any easier for the end-user, it’s really a matter of:

1. Clicking the ‘Sign in with Twitter’ button
2. Allowing the application to gain access to your information
3. That’s it! You are now logged in!

Not only will your visitors be able to register with a few clicks, but they will not be obliged to remember an additional username.

For obvious reasons, if time isn’t an issue you should still program the typical registration and login form. After all, you still want the people that do not have Twitter to register.

Another interesting option would be to allow existing users to associate their Twitter account. By doing so, the user can either login using his Twitter or with the website’s login.

The idea is to add a twitter_account_id column to your existing users table. When someone tries to login with Twitter OAuth, you attempt to load the account linked to that Twitter account and proceed to the normal login process.

You could also do something a little bit more advanced and add a Many-to-One table with the following columns:

• user_id unsigned int(10)
• site ENUM(‘twitter’, ‘facebook’)
• account_id unsigned int(10)

In essence, this would allow each user to have multiple social website accounts. This could be interesting for the person wanting to link his Twitter as well as his Facebook account to their account.

You can speed up queries by adding a UNIQUE index on all 3 columns and a foreign key from user_id to the primary key of your users table.

-Christian Joudrey

nc -l -p 12345 < pipe | tee outgoing.log | nc server 12345 | tee pipe incoming.log

Now this may seem a little cryptic so I’m going to dissect each portion to explain how it works. Keep in mind the “pipe” references an actual pipe. You can make a FIFO pipe by running “mkfifo pipe” or “mknod pipe p” – the former is the most usual way. If you’re not familiar with named pipes I recommend reading up on them before continuing with this post as you may get a little confused.

nc -l -p 12345 < pipe

This portion simply has netcat listen on port 12345 and send anything from the pipe to the connected client. If you’re not familiar with the pipes think of it as a simple file with the word “hello” in it. When someone were to successfully connect to the netcat instance it would send the “hello” to the client.

| tee outgoing.log

If you’re not familiar with tee this may seem a bit obscure. Tee prints the things piped to it to stdout as well as writing it to a file. In this instance any traffic from the connected client will get printed to stdout and to the file “outgoing.log”. An example of how this would work is if I connected to the netcat instance and simply typed “hello” it would print it out to the screen and log it to the “outgoing.log” file.

| nc server 12345

This is the server that you would normally want to connect to. Remember the goal is to make a quick intercepting proxy to see how the client reacts to the server. This is the server.

| tee pipe incoming.log

Here is where the magic happens. This completes the relay so the client and server can communicate across the proxy. What this does is takes the network traffic from the server and using tee prints it to stdout while piping it to our “pipe” and “incoming.log” files respectively.

Now all of this may make sense individually, though how they work together might be slightly confusing.

If you recall the first command sends all data from our “pipe” to the client – and at the end we pipe all data from the server to the “pipe”. See now? We’re simply taking all data the server send and sending it to the client completing the relay and allowing for normal operation.

Now in this case Chris needed this for a quick look at how a normal IRC client interacts with the server since the RFC is lacking – so here is a real world example of where this was used (though there’s likely infinite better ways to do it):

nc -l -p 12345 < pipe | tee outgoing.log | nc irc.freenode.net 6667 | tee pipe incoming.log

You’ll notice when you execute the above command you’ll start seeing some traffic from the server instantly:

NOTICE AUTH :*** Looking up your hostname…
NOTICE AUTH :*** Checking ident
NOTICE AUTH :*** No identd (auth) response
NOTICE AUTH :*** Couldn’t look up your hostname

Now we connect to the netcat server – in this case localhost on port 12345 and if everything goes as planned it should connect like normal to Freenode. If you take a peak at the netcat server you’ll see a bunch of activity!

The cool part is the logs – we can see exactly how this particular IRC client (IRSSI) and server (Freenode) interact.

incoming.log
outgoing.log

Once again this isn’t the best way to do this – tcpdump, wireshark and infinite other choices are available. That being said it’s fun to fiddle and learn.

-Cody Robertson