This technical FAQ will eventually cover some of the nuts and bolts behind the construction of this website. I should concentrate on getting the site itself up and running first, me thinks! (^_^)v This FAQ is intended for people who know a little bit about "web design" (whatever that means) but are still wondering how to make certain things they see on other people's sites. Let me just state this: I am NOT a professional web designer. I'm just a guy who's picked up a few things here and there. If you're a power user, you can pretty much feel free to skip over this entire section (as is, you're probably laughing at my crap code/layout already!). I don't write my own scripts, nor do I have knowledge of any programming languages besides a teeny tiny bit of php (enough to change prewritten scripts to modify some of the features).
You're probably wondering why I'm even writing this so called "Technical FAQ" then, but the answer is simple: I learned so much from sites on which people were kind enough to post explanations of how they made certain things - simple explanations aimed at beginners which were probably frustrating for them, as professionals, to write. Without this kind of user-to-user explanation, it'd be virtually impossible for anyone to learn how to make good websites (not that I'm claiming michaelpanda.com is "good", mind you! *laughs*), so I want to repay the web karma and do my part to help out those beginners where I can.
If this sounds like it appeals to you, then read on!
Nulla tempor fermentum neque. Suspendisse ante. Morbi tincidunt convallis arcu. Cras sem erat, sollicitudin at, ullamcorper eu, molestie eget, leo. Mauris fringilla odio sit amet leo. Ut a odio eget nunc lobortis interdum. In est. Sed eget arcu eget neque tempor sagittis. Cras rhoncus. Aenean ut leo.
The Moblog is basically a sideblog set up to automatically receive pictures I've emailed from my phone and post them as new entries, which show up both in the "moblog" section and on the front page of the regular blog. Now, there are several ways to do it: the easy way, and the hard, but better way. The easy way is simply to visit a site like Flickr.com which will have stuff all set up for you to do mobile blogging and a little snippet of code you can copy and paste into your blog to get a "live photostream" or whatever to show up. That's all fine and good, but it does have a certain "amateur" feel to it - everyone who looks at your site will know how you did it, plus you're pretty much at the mercy of Flickr/etc.'s terms of service and random whims. Also, since you don't write the scripts, what you can actually do with your photos is extremely limited. You can't, for example, set up an entire section for them like I did on this site, archive them (except on the external flickr site) or really even integrate them in any meaningful way into your site. All you can do is show them. Hrm.
Now for some that might be fine, in which case I heartily advise you to follow that course of action, because the next way is a bit harder. However, for those of you who want to do it yourself, read on. You will need the following things:
- Access to your own hosting service (which, if you're even interested in this page, I assume you already have). This will NOT work onfree sites like blogger, geocities, xanga, etc. You MUST own your own server space on a webhost somewhere. It's not expensive, so get out there and get you a web host! I personally recommend hostmatters, but you are of course free to use whoever you want. I would, however, urge you to make sure they have excellent and responsive tech support, because you may need them for this!
- A working installation of movable type. I'm sure you can make this work for other blogging software like wordpress, etc. but I use Movable Type, so I'm afraid that's the only one I can explain the details of.
- A script to automatically receive your e-mailed photos and post them to your blog. This is where most of the issues center around. The one I recommend is Michael and Cate's "MT Pop2Blog". It's an updated version of the mentioned below and the one I use for all of my moblog postings. Unfortunately, MichaelandCate's site has been recently redesigned and the mtpop2blog script appears to have disappeared along the way. However, I have mirrored a copy of the original script, which you can download here. Also available is a text version of the webpage that originally accompanied the mtpop2blog script on michaelandcate's site and the debugging version of the script.
- A cell phone capable of taking pictures and e-mailing them. Of course you can just e-mail them from a regular e-mail account as well, though that sort of takes the "mo(bile)" out of "moblog".
Now I could sit here and try to explain to you how to get this to work, but the always entertaining Easterwood (who sadly seems to have stopped posting these days) has already written a detailed step by step explanation of how to get this all set up. Go over there and read all the sections about how to set up a separate moblog, sit back, and then read it again before coming back. Go ahead. I'll wait.
Are you back? Good! Easterwood pretty much laid it all out for you. However, his method requires you to use a separate external service called MFOP, which is fine, but I'm assuming you want to host your own script. For that reason, download the MTpop2blog script listed above, read the documentation and install it accordingly. Then come back and below I'll go over a few things that I suspect you may need more explanation about:
Perl modules: The MTpop2blog script requires you have several perl "modules" installed. If you open the script itself with a text editor like notepad, you will see them listed near the top. The relevant section reads (I've bolded the module names):

The easiest way to check if you have these perl modules (if you use "cPanel" to interact with your website) is simply to login and look in the lower left hand corner at the box entitled "Server Information". Look for the box entitled "Installed Perl Modules" then click on the link to the right to view a large list of all the perl modules you can use. Search this list for the required modules above (exactly as written, including colons). You need to have all of the modules present. Please note some of these modules are not always installed by default.
In my case I was missing the modules Mail::Box::Manager, Net::Blogger and file:: Basename, so I had to contact my web host and ask them to install them for me. This is one of the reasons why it's important to look beyond just a low discount price when searching for a host - easily accessible and responsive tech support will make an issue like this trivial, whereas bad tech support will cause you no end of headaches. At any rate, if you're missing any modules, send off an e-mail to your web host's technical support listing the names of the modules you're missing asking them to kindly install them for you.
Configuring the settings: Looking down further at the script, you will run across an area where you need to input the specific settings for your configuration. You can see it below:
Most of these are self-explanatory. Some things to be careful of are:
- The path to $imgdir must be the absolute server path - not the absolute path from your web root. This means it should start something like " /home/usr_name/public_html/ " where you substitute your user name for "usr_name" (public_html remains the same. your images directory must be "above" the public_html directory, which means it can be accessed from the internet). Simply typing "/images/" for $imgpath won't work.
- $imgpathmust reflect the web path to your images. Start with the webroot (not the server root like above), so for example /moblog/images/
- $blogid can be tricky to find out. The easiest way to find out your blog id is to log into your movable type control panel, click on the blog you will be using for your moblog, then hover over any of the links for your blog entries etc. When you look down at the status bar at the bottom of your screen you will see the URL to the entry with the blogid=xx affixed to the end. The number after blogid= is your blog id number.
- $popsite varies depending on the exact configuration of your server. Common settings would be pop.yourdomain.com or www.yourdomain.com, where, of course yourdomain is the actual domain name of your site. If one setting doesn't work, try a few different versions, or else contact your technical support for the exact settings.
- $popuser also varies depending on your server setup. However, it should be the address of the mail account you set up to deal with images you e-mail to the mtpop2blog script, for example moblog@yourdomain.com.
Cron Jobs: A cron job is something you set up to have your server run a script automatically every set amount of time. The traditional method of configuring a cronjob is pretty user unfriendly. Fortunately, if you're using the aforementioned cpanel to interact with your server, you will see an option on the front page called "cron jobs". Clicking on this will give you the choice between "standard" and "advanced (unix style)". I strongly suggest you choose "standard". You will get a window that looks something like the picture off to the left. Most of the settings are pretty self explanatory - simply click on how often you want the script to run and you're almost all set. Also, since running a script takes some server power (not much, but it adds up, especially if you're on a shared server) be nice to your provider and don't set the script to run every minute or so. Every half hour should be more than enough, unless you're some sort of mad moblogging fiend ;)
One thing to watch out for. In the highlighted section entitled; "Command to Run", you need to enter the full path from perl to your script. You can find the path to perl by looking at the "Server Information" box shown above and accessible from the front page of your control panel in the field next to the label "path to perl". Usually it begins something like "/usr/bin/perl/". So one example might be: "/user/bin/perl/home/user_name/public_html/scripts/mtpop2blog.pl" or something, where "user_name" obviously, is your user name and other directories are changed according to your individual setup.
You can test whether your cron job is working correctly by inputing an e-mail address into the appropriate box on the configuration page. You should get an e-mail sent every time the job runs notifying you whether it was successful or else detailing any errors. As these get annoying after a while, it might be a good idea to delete this address (i.e. leave the field blank) after everythings up and running to avoid getting innundated by hundreds of "successful" e-mails.
If you're stuck setting up cron jobs using the old school unix style, well, good luck. A brief glance around the internet should yield some rather competent explanations - unfortunately they are beyond the scope of this article, but you could start with unixgeeks and adminschoice, both of which offer excellent (but dense) introductions to cron jobs.
Rewriting your .htaccess: An important caveat of Easterwood's method is that since you need to use a little bit of php in your main blog page to "include" the moblog feed, the extension on your index page will need to be changed from .htm/.html to .php in order for the server to know it has to parse the php bits of your site before spitting them out. Unfortunately, if your visitors don't know that you've switched your webpage extension, they will get a 404 "Not Found" error unless they specifically type "index.php" after your domain name. This is no good, so as Easterwood mentions, you will need to change your [LINK] .htaccess file to include the following line:
The easiest thing to do is to use an FTP client (like cuteFTP, etc.) to open your website - navigate to the folder containing your blog webpage with the .php extension. Look for a file called .htaccess. If you find it, download it to your computer, open it with any text editor (like notepad), add the line above, save the file and then re-upload it to your server.
If you don't see an .htaccess file, you can create it yourself. Just open a plain text editor (again, like notepad), type the line above and then select "File - Save-as". Under file name type ".htaccess" exactly like that, including the quotes. You should see the file sitting on you desktop/wherever you saved it. Grab the file and upload it using your ftp program to your webserver in the directory noted above. All set!
You can do a lot of neat things with .htaccess files - to read more about the possiblities, be sure to check out webmasterhelp's useful pageas well as devwebpro. Finally, if you're really up for it, pop over to alistapart for a more advanced usage of the .htaccess file (preventing hotlinking).
Lack of Japanese input support: This may only apply to a small subsection of people, but the output from the MTpop2blog script as it currently stands doesn't display Japanese characters sent from Japanese mobile phones correctly. I suspect this may be due to the fact that the Japanese portions of messages sent from Japanese phones are usually encoded using a Shift_JIS character set, while the page encoding on my blog (and presumably yours as well) are set to something else, (in my case UTF-8). While I'm not 100% sure, I suspect that setting your page encoding (in the header declaration: "<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />") to "Shift-JIS"instead of "UTF-8", etc. might fix the problem. Of course, then you have to have your page set to that character set which will likely cause problems for many of your western readers (especially those on older browsers/OS's) so in the end, this may cause more headaches than it solves.
I guess the best solution would be to edit the script to process japanese characters are sent by japanese mobile phone and switch the encoding to their UTF-8 counterparts, however I haven't the foggiest notion of how to do that. So for now, the only thing to do is either a) avoid using Japanese characters in your moblogs sent from Japanese mobile phones b) manually encode them in the message using their UTF-8 entity codes (pretty much impossible unless you're some sort of savant), c) only post messages containing Japanese from a regular UTF-8 (or whatever encoding scheme you're using) capable e-mail client or d) Post them, and add the Japanese later by editing the entry through the movable type control panel.
Editing the script: As the script currently stands it does three things to the images:
1. Asks you to explicitly set the desired height of your thumbnail image ($thumbht)
2. Asks you to explicitly set the desired height of your pop up (original) image ($popht)
3. Resizes both the the pop up (original) image and the thumbnail image according to the heights you input.
However, in my case I wanted to do three things differently:
1. Keep the original image unresized
2. Specify the width as opposed to the height of the thumbnail image)
3. Resize the thumbnail image generated based on the width of the original image.
I wanted to keep the original image unresized because I the way I figured it, there's no point in paying for a cellphone capable of taking 1.8 MP images if you're not going to use it to the fullest capacity. Also, since my cellphone is capable of taking pictures in a variety of different sizes (240x320, 352x288, 640x480, 480x640 (what I usually use), 960x1280, etc.) I might occasionally post images at different aspect ratios/sizes, depending on the subject matter - but if you hardcode the pop up size in the script, that defeats the purpose and takes away this flexibility.
My reasons for wanting to specify the fixed width of the thumbnail and derive its appropriate height (i.e. the height that would maintain the correct aspect ratio) from the original image might not seem obvious until you consider the context in which a moblog is usually used. The most common implementation of a moblog is running vertically within a sidebaroff to the side of the main content. This is the preferred method I use for displaying moblog entries on my main page (not within a sidebar persay, but still running vertically alongside other content). The layout of a sidebar generally means that content contained is free to expand/contract vertically, but not horizontally. In my case, the way the script originally fixed the height of the thumbnail but allowed it to change size horizontally was unacceptable, since if the thumbnail image grew too "fat", it would interfere with the horizontal width of the containing div and break the layout (by making it too fat to fit where it was supposed to/escaping the div and pushing other content out of the way). Thus I need to change the script to fix the width of the generated thumbnail and derive the height - which is allowed to expand/contract - from the original image.
The first thing to do is to change the variable $thumbht to a variable which will allow us to specify the desired fixed thumbnail width ($thumbwidth). I changed the first bit of the script as follows:
Of course, you can specify whatever size you want (in pixels) for the desired $thumbwidth. You can leave the variable $popht alone, as we won't be using it, but there's no need to comment it out either. Next, scroll down in in the script until you see something that looks like the following section:
There's a little bit of math going on here. The line:
($globe_x, $globe_y) = imgsize($basepath);
uses a function to read in the size (in pixels) of the original image, storing the width in $globe_x and the height in $globe_y. Next, the line:
$ratio = ($globe_x / $globe_y) * $thumbht;
divides the width of the original image by its height to get the aspect ratio of the image. You need to get the aspect ratio in order to make sure your thumbnail image doesn't look "distorted" or "stretched out" when you generate it. It then multiplies this times the thumbnail height you specified up above in the beginning of the script ($thumbht) and stores the results in $ratio - you can actually think of $ratio as being the same thing as the correct thumbnail width for the image.
Since we no longer have a variable called $thumbht having replaced it with the explicit width above ($thumbwidth) we need to "flip" this line above around, and instead use the aspect ratio from the original image to derive the appropriate thumbnail height from our specified thumbnail width. Change the code to read:
Make sense? We just inverted it the aspect ratio since we're now multiplying by the width instead of the height. As an aside, the variable $ratio2 is similarly what the the "correct" width for the popup image would be if we were going to resize it. However, even though we're not going to resize our original image, we can just leave this line alone, though you can comment the line out if you wish.
Speaking of which, the next thing is to do away with the resizing of the original pop up image. Immediately after the code you just changed you should see the following:
Either delete or comment out (by putting a # symbol in front of every line) this entire block of code to prevent resizing our original image. Now the last thing to do is change the following code:
to read:
Which reflects the changes we made above to the thumbnail size calculations and generates the thumbnails accordingly. Voila! All done!
DISCLAIMER: I didn't write the mtpop2blog script and I'm not an expert programmer by any stretch of the imagination. Make these changes at your own risk (not that anything bad's gonna happen, it's just silly moblogging script), and be smart enough to keep a backup copy of the script in case you screw up and can't get it to work. If you need help, feel free to drop me a line and I'll see if I can give any advice - but no promises! Good luck and happy moblogging!
Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Duis placerat nisi et dui. Cras sapien. Donec sit amet massa in tellus convallis vehicula. Cras interdum pretium neque. Phasellus auctor ipsum nec tortor. Duis fringilla mauris cursus urna rhoncus condimentum. Ut congue. Morbi eget elit ut erat pharetra sagittis. Nam consequat, tellus sed elementum molestie, augue libero venenatis lacus, vel interdum eros sem non justo.
Wondering how I set up the QR code generator over on the features page? It's relatively straightforward. The first thing you'll need is a script to make the QR codes. One of the easiest to use (which has the added benefit of being completely free) is Swetake's QR code generator. You can download it from their homepage, or else grab a mirrored copy from here. Once you download the file, unzip it, then read the "README-e.txt" file and follow the instructions carefully. If you use the perl version of the script, you might need to know the path to perl for your server - you can find that information out either by asking your web host technical support, or else looking in the section of your server control panel pictured above.
The instructions are similar, but I used the php version of the script, so that's what we're going with. Open up the subfolder entitled "php" and then open the file entitled "qr_img.php" with any plaintext editor (like wordpad). Scroll down a little ways until you see the following entry:
Change the path to reflect the directory in your server where you intend to upload the script. So for example: $path="http://www.yourdomain.com/qrcode/data" where "yourdomain" is of course, the address of your web site. Change the $image_path similarly (so "http://www.yourdomain.com/qrcode/image"). Make sure to leave off the trailing " / " (forwardslash) in each case. Once you've done this, save the file with the same name and reupload it, along with all the other stuff you unzipped into the appropriate directory on your server (so "/qrcode/" in our example above). Make sure to keep all the subdirectories (like "data" and "image" intact.
Now that you have the qrcode uploaded, the next you need to do is set up a way for people to pass information to the script using a web browser. The easiest way to do that is to to use a standard HTML "form" in conjuntion with a textbox and submit button. The basic framework is as follows:
You can basically copy and paste the above into your html document wherever you want your users to input the information for the QR code. There's a few things to review briefly:
- Where it reads [action=http://www.yourdomain.com/qrcodefolder / php/qr_img.php], make sure to substitute the actual path to the script for your particular setup. Also, if you're using the perl version of the script, you will obviously need to change the path to reflect that (qr_img.pl) rather than the php version above.
- Where it reads [input type="text" name="d" size="30" maxlength="45"] you can change the values of size and maxlength to change the actual size of the textbox displayed and the maximum number of characters users are allowed to input.
-Where it reads value="Submit" and value="Rest", you can change these to whatever text you want the "submit" and "reflect" buttons to be labeled with. You can also replace these standard form buttons (generated by the user's web browser) with custom images, by changing the input type to "image" and adding the parameter "src" like in the example below:
<input type="image" src="/images/youricon.gif" value="submit" />
Of course /images/youricon.gif should actually be the path to, and the name of, the picture you want to use for the form submit button. The last forward slash "/" you see at the end is neccessary to close the img tag so that the page will validate according to W3C standards.
And that's all there is to it! Now you've got your very own working QR code generator!
Wondering how the banner keeps changing everytime you load or refresh a page? There've been countless ways created to solve the problem of (randomly) rotating an image on a page, but the easiest way I've seen yet is Automatic Lab's simple (and free) php script. Of course you'll need access to a server with php installed, but unless your site is on a free host like geocities, that probably shouldn't be a problem.
You can download the script and read all about how to use it over at alistapart's article on image randomization.
Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Duis placerat nisi et dui. Cras sapien. Donec sit amet massa in tellus convallis vehicula. Cras interdum pretium neque. Phasellus auctor ipsum nec tortor. Duis fringilla mauris cursus urna rhoncus condimentum. Ut congue. Morbi eget elit ut erat pharetra sagittis. Nam consequat, tellus sed elementum molestie, augue libero venenatis lacus, vel interdum eros sem non justo.
Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Duis placerat nisi et dui. Cras sapien. Donec sit amet massa in tellus convallis vehicula. Cras interdum pretium neque. Phasellus auctor ipsum nec tortor. Duis fringilla mauris cursus urna rhoncus condimentum. Ut congue. Morbi eget elit ut erat pharetra sagittis. Nam consequat, tellus sed elementum molestie, augue libero venenatis lacus, vel interdum eros sem non justo.
Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Donec interdum pulvinar velit. Duis interdum fermentum nisi. Nullam tincidunt, orci et sagittis blandit, elit nibh mattis odio, vel feugiat sapien nulla in dolor. Aenean risus orci, iaculis a, hendrerit in, commodo nec, lorem.
Vestibulum ante ipsum primis in faucibus orci luctus et ultrices posuere cubilia Curae; Proin ut nibh. Nullam leo. Sed mattis rutrum dolor. Integer massa sem, posuere ut, rutrum eget, pharetra pharetra, justo. In hac habitasse platea dictumst. Sed sagittis turpis nonummy enim. Integer ultrices pede