I created a WordPress site for a client who needed to support both English and Español versions of their content, which involved using a plugin called MultilingualPress that creates relationships between sites for each language.
I developed the site locally on my server, and then after they created some content, migrated it to their hosting service.
I was setting up a temporary WordPress site for a client as a placeholder for their business. All they wanted was their logo, a link to an existing product page, and a message about the site being under construction.
Since they were going to have some design ready shortly, I set them up with a WordPress site, and found a simple theme (Decode by Scott Smith) that their logo would work with.
The owner then told me she wanted to see the site running with SSL (aka HTTPS), so I grabbed a certificate and installed it.
First step is to log in to the cPanel, which is typically at some arbitrary port on your server, and log in with your admin credentials. If you go to the right URL, you’ll be prompted with something like:
Type in your user name and password, click the “Log In” button, and you’ll see the cPanel home screen. In my case I see something like:
So, just like any WP installation, the first thing you need is a database, so you look for the Database Wizard (in the Databases section):
This will bring up the Wizard which will ask you for a name. In this case I’m creating a test wordpress, so I type in “WP_test” just so I know which DB I’m using. This can really be anything, just has to be unique.
If you’re on a shared host (which I am) this name gets prepended with your admin account name (this is how the server knows which databases belong to you and keeps you from seeing other people’s database schemas).
Going to the next step, you’ll be asked to create the database users. Again this can be anything, but also needs to be unique to the schema you’re creating. At this point the database has been created, but there are no users. The user name also gets prefixed with the account on a shared host system:
You can give the user any name and password you want, you will need those along with the database name once you are ready to fire up WordPress. I believe it is possible to use the same user for multiple databases by skipping this step and manually adding them to the newly minted database later instead, but it’s probably not the most secure way to set up access.
In my particular setup, I want to attach this new WordPress to a specific host name, so the next thing I do is my Subdomains panel in order to create the directory and tell Apache where to send the users. The default behavior is for the directory to be a folder under public_html with the same name as the subdomain, so in my case “WPtest” causes a folder named /public_html/WPtest to be created:
In my case I prefer to keep them separate physically, so I remove the “public_html/” part and call the folder something more meaningful. Depending on your setup, you may also need to add this new host name to DNS, although for testing you don’t even need that (more on this later).
The next thing to do is to get the latest WordPress binary and upload it to the newly created folder, which you can do using the cPanel folder manager:
I next see a popup that asks me where I want the File Manager to start, so I pick my new subdomain:
In reality it displays all of your folders, just starts up opened to that particular one which might save you a click or two. At the top of the file manager, you’ll see the menu bar where you can choose “Upload”:
You’ll get the typical button to choose the file with, and a status bar that will tell you when the upload is complete:
Once it is uploaded, go back to the file manager and with the file selected, click the “Extract” icon, or right click on the file and choose that option:
You can actually choose to extract it somewhere other than where you uploaded it, which could be useful for creating multiple copies or updating WordPress into multiple folders:
Now this ends up creating a wordpress folder under the one where you really want it, so I do a bit of cleanup that involves moving the contents of that folder up one level. I use the File Manager’s drag and drop to move the files, and then delete the empty folders and zip as shown in this video:
After that, the rest of the configuration is a standard WordPress setup through the browser (see: http://codex.wordpress.org/Installing_WordPress#Famous_5-Minute_Install)
First, if you already have a Google account (like a GMail address), you will want to log out of by clicking on your name or icon up in the upper right corner of any Google app, and then click the “Sign Out” button:
One of the moves I made in my first year with them was to migrate our event calendar to Eventbrite and Meetup. One of the gaps I found with Eventbrite is that it doesn’t have a way to provide a feed of events that can be used to update an external calendar, so I embarked on a little programming effort to create one.
Most calendar programs allow you to pull external events using the iCalendar (ics) format, and Eventbrite actually has a pretty decent API to allow you to pull the events, so I decided to write a simple PHP script to allow me generate an iCalendar feed.
Looking at the code, you can see it’s pretty basic, just a few PHP classes, some unit tests, Netbeans project and data.
Once the code was working, I used the iCalendar validator at http://severinghaus.org/projects/icv/ to make sure the results are good, and (at least for PMI-SFBAC) they are.
Eventually this results in a URL that I used as a feed into the All-in-One Calendar from Time.ly which lets me show events on my site’s calendar along with any other iCalendar feeds I choose to add.
To configure the All-in-One calendar, I just go to the Events in the WordPress admin panel, and add the feed.
After I add the feed I click the “Refresh” button to make sure the events show up on my calendar immediately. The events then get updated on a periodic basis (daily by default), and should keep you up to date.
Another use I put this feed to is to add the Eventbrite calendar to my Google Calendar. I have a calendar feed from Meetup, and several of my friends so that I can quickly see what is going on that day.
The same basic idea for Google Calendar: you go to your Google Calendar, click the drop down on “Other Calendars” and choose “Add by URL”.
This gives you a nice view of events so that when you are scheduling things you can see what’s coming up that you might be interested in.
The first thing I did was to run over to the MX Toolbox site to see what was going on with her servers. A quick look and saw that her mail servers were pointing to mail.athenskconsulting.com, which resolved back to her WordPress blog.
Her DNS and email were previously hosted at GoDaddy (along with her old web site), and all she was really trying to do was to get her company URL to point at the blog site that she’d set up on WordPress. The instructions I mentioned before give a way to accomplish that, by repointing the domain DNS servers to be the ones that WordPress provides.
The unfortunate thing about that approach is that in order for this transition to happen smoothly, you have to transfer all of your DNS records into the WordPress settings so that things like your mail server will continue to work (following the instructions at http://en.support.wordpress.com/domains/custom-dns/
Now this might be OK if you are a geek and know what MX and CName records should look like, but typing in a DNS file in the format that WordPress expects it is much more difficult than using the GoDaddy DNS control panel (which helps prevent you from making mistakes).
I got on the phone with her, and the first thing I had her do was to switch her DNS servers back to GoDaddy. This is done by going to the Domain Manager page in GoDaddy and looking for the section that says “Name Servers”.
Clicking on the link that says “Set Nameservers” brings up a dialog that allows you to set the DNS (which had been set to the WordPress servers per the instructions mentioned previously):
This of course fixed the mail problem (along with other URL’s), but broke her web site again (which I expected it would).
We then clicked the “Launch” link on the same Domain Manager page by looking for the section that says “DNS Manager”:
This brings up the actual DNS zone editor that I talked about previously. Now the first thing you should do is to back up the zone records by using the import/export button on the DNS manager:
This gives you the basic information that you might have needed if were you going to follow the instructions on the WordPress site. It creates a text version of the information of the DNS Zone records in a standard format.
But unless you really need to move off GoDaddy for some reason, you don’t want to do that. Instead, you just need to set up a wildcard CNAME record for the WordPress blog, and make sure to remove any old A records that might be pointing to the wrong place.
So for Athens, we needed to delete all of her “A” records (since she no longer has a physical server), and add a CName that looked like:
I’m doing some work on a project that is using PHP, and have been working on setting up some continuous integration build scripts to make sure that we have a shot at catching errors before they make their way to production.
Recently some unit tests were added for the “forgot password” code, which uses the mcryp
t libraries which are not installed by default on Mac OSX, so I was seeing this error:
Call toundefined functionmcrypt_get_iv_size()
So some quick Google searches, and I found a couple of blogs with “how to” install the library (links at the end of this post), and proceeded to get this done.
I recently attended the Google Technology User Group Campout at the Googleplex in Mountain View. This was a three day sprint to build something interesting with the latest Google product: Google Wave.
Google Wave, as it turns out is a very interesting experiment in social interaction. Google is trying to reinvent collaborative communication with a piece of software that is one part chat, one part Wiki, and one part WebEx.
The demo included things like interaction with blogs, Twitter and other web technologies, as well as interesting programming doing things like on the fly grammar checking. I signed up for a sandbox account the day of the presentation (using my iPhone of course), and got set up a week or so after that.
Wave was written by the brothers Lars and Jans Rasmussen, who are the architects of the Google MapsAPI. In some sense, this is an experiment in building software caused by the lessons they learned with the immensely popular Maps API. By giving the developers access early in the build process, they hope to build a more solid platform that will serve the developers needs.
So Friday came and I drove over to Google with Bennett Fonacier (a friend I met through Job Connections some time back). After the 50+ people got through with their 5 minute pitches, we networked for another hour forming teams. There were many ideas that were very similar, and for the most part these groups joined up into a combined team. Bennett and Steffen Frost (CEO of Carticipate) both came up with the idea of matching people for ride shares using the Wave.
I’d originally thought I would join a team doing something health related, but since my goal was to get a working piece of code, and I was sitting with the car pool team, I joined that effort. We became one of the roughly 50 projects teams, and quickly talked through what we’d be building over the next 48 hours or so.
The other members of the Wave Rides team were:
Steffen Frost was a great concept guy, and had an existing product we were going to try and emulate.
Bennett Fonacier has some development background, but he was short a computer, and would be doing QA.
Andreas Koll who had some experience with the Google Maps API volunteered to build the Gadget for our interface.
Hannie Fan offered to provide some design expertise and CSS coding.
Robert Herriott was a quiet supporter, offering constructive criticism
I took on the task of writing the Robot, which is the part of the Wave that would take the input from the Gadget and match the participants with ride partners. Andreas had a working Gadget in short order, and was able to embed it in a Wave.
While he was doing that, I was working on getting a Robot built using the guidelines in developing Wave extensions slides. I got a working “Hello World”, built the extension.xml file, and with help from the Google crew, got it so we could create a new Wave with my Robot added.
I got the icon from the Carticipate site, added a bit of code, and the Robot was adding the Gadget to the Wave. So far I had gotten a working Robot, and Andreas had a working Gadget. Now all we needed to do was clean them up a bit and get them talking.
This turned out to be a bit tougher than expected. The current state of the world is that the Robot can add a Gadget, and send data to it when it is added to the Wave, but can only read the state from the Gadget, and not actually set anything after the Gadget is running.
Anyway, I eventually got some debug code going in my Robot that would dump out the properties of the Gadget, which helped Andreas to debug some issues he was seeing with the state of the users accessing the Gadget.
Our original plans for the WaveRides robot was that it would behave roughly the same way as the Carticipate application does: ask the user a few questions about where they are going, if they are driving, and then show a list of everybody who is travelling in the same area and time. So as we worked, I kept prototyping closer and closer to that goal.
By the late Saturday night, we had a working prototype that launched the map gadget, and displayed back the data from the users interacting with the gadget. The gadget was displaying the location of all of the users on the map, and we were feeling pretty good about the progress (especially considering none of us had ever built anything with the Wave API before). Bennett and I headed home, expecting to finish up the next morning, leaving Andreas coding away on his gadget.
The next day we arrived at the Googleplex and found that Andreas had solved some of his remaining problems, and the gadget was looking good. I went to work on the Robot, trying to get it to match up the user data. Of course, since there was little time left, the Wave kept misbehaving (probably due to all of us pounding on the sandbox with untested code), and we kept running into walls.
My original design had been to add a blip with the map gadget and gather my data from there. I soon realized that it was difficult to keep track of the gadget that way, so I changed my code to add the gadget to the root blip, and started removing debug code. At some point, we decided to put the code up on code.google.com for safekeeping, so I spent a few minutes figuring out how to do that (you can see the code at http://waverider.googlecode.com).
It was still fairly early on Sunday morning, and Andreas had been up until the wee hours of the night, so he wasn’t around for us to ask him to make changes to his gadget. We had separated the development of the gadget and the robot, so they were actually being served by two separate app server applications. The gadget only provided input for one point, and to complete the robot to the point we could demo something interesting, we needed it to have a “from” and “to” for each participant.
So rather than reinventing what Andreas had done, I decided to change the robot to create a “from” and a “to” gadget in the Wave, and use that. Interestingly this turned out to be fairly painless. I was able to add the second instance of the gadget, and give them each a name. The Wave kept track of them separately, so I got the data from both separately.
I spent the last few moments before we were supposed to present, trying to get a simple match working. The nice thing about this was that I could version the app on the Google App engine, and keep a known working version deployed while continuing to test. As other teams presented, it became obvious that this had been a good decision, and I eventually dropped back to one of the earlier working versions for the demo.
We got to demo the concept, and explain what we would have liked to have done. I accomplished my goal of learning how to code a basic robot, and learned a lot about the API. We were by no means the slickest or coolest app there, but we had fun building it.
We’ve got the start to an open source project that could eventually be used to match people locationally, and used for all sorts of purposes, and we got to see some of the challenges in building apps for a piece of software as new as Google Wave.
From left to right above: Steffan Frost, Fannie Han, Rob Weaver, Andreas Koll, Bennett Fonacier.
Since I’ve been blogging for a couple of months now, I have friends who are asking me “how do you blog?”.
Seems like a simple enough question, so I figured I’d blog about it (seems a little redundant blogging about blogging, but here goes).
The first step of course is to set up your blog.
This for me was very simple, since my hosting provider (1and1.com) includes a Blog widget in their web site tools. This seems like a straightforward approach if you have a hosting service since most of them have blog software already setup, and you don’t need to worry about any installation or maintenance issues. So in the case of a provider like mine, you just find the websiteapplication on their control panel, and walk through a few steps to set it up.
Setting up the blog on 1and1 (at least on my package) you get a control panel page that shows you what blogs you have set up. You click the button “New Blog”, and you get sent to a screen that asks you to name the blog, and choose a domain.
This was my first gotcha in setting up the blog: I chose my accuweaver.com domain, and instantly my home page became an empty blog.
Apparently the wizard just changes the virtual host to point to the blog software, which would be OK for a brand new web site, but wasn’t what I wanted.
After that stumble, I created what 1and1 calls a subdomain of blog.accuweaver.com to point to. This let me keep my existing site, and created a separate URL for the blog. The blog setup also lets you create the admin user, and decide which email notifications should go to. Then all you have to do is choose your template, and start blogging.
Google hosts this service, and it works pretty much the same way as the WordPress version that I use, but it isn’t tied to a hosting provider. This is probably the best approach for most people, and it also has the same flexibility of hosting on your own web server if you want to.
I use GoogleReader to follow industry blogs about things like PHP and Java. One of the nice things that Google Reader does, is to automagically translate the page into English when the post is in a different language.
This is very helpful especially with blogs in subjects like these, especially since the international community is very active. Reader will give you a brief translated version of the feed, and when you click the link to go to the page, it typically forwards you through http://translate.google.com so you can read the page. For the most part, this yields a very understandable page that represents the subject the author was trying to convey very well.
To set this up in Google Reader, you just set the feed to automatically translate the page by clicking on the “Feed settings” button:
Notice that with the “Translate into my Language” checked, you’ll see “Translated by Google” at the top of the page. The link to go to the post is now run through the http://translate.google.com with the appropriate languages so that you can read it, and if you click the “View original” link, you’ll see the summary in the original language.
In the above example, the feed looks like this, when I choose original language:
So this got me to thinking: it should be a relatively simple thing to add a link to your page to send it to Google translate, to allow somebody to translate into their language, since it’s basically just an HTTP GET with parameters of the page, source language and destination language.