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)
If you read my previous post (WordPress Recovery), you know I’ve been writing some code to recover my old posts. It occurred to me I could take a small segment of what I’ve been doing with that code to demonstrate my approach to TDD.
Since I’m a hacker from way back, and also because I was in semi-panic mode about losing the content, I didn’t approach this task with testing in mind. Now that doesn’t always result in bad code: I’ve been doing this long enough that I can usually think through a fairly good model and code something that isn’t one long method full of inline code.
In this case however, once I had started coding, I realized again that this was an opportunity to practice coding the “right” way. I had already begun with a Maven project, and generated unit tests as I went through the process of starting to build the code, so I had at least some good functioning unit tests.
Well, I have the basics of my blog recovered now, so almost all of my posts going back several years are once again available.
In my last post titled Lesson Re-learned: Backups !, I admitted that I had committed the cardinal sin of making changes to my web site without doing a backup first (walking the tightrope without a net).
Luckily for me I had installed the WP Super Cache plugin, so all of my content actually still existed as static files, and being a bit of a hacker, I was able to throw together some code to effectively recover my posts.
So when I finally got my blog set up to host the few static pages I had, I just changed the directory on my server to have a symbolic link to the directory where wordpress.accuweaver.com had it’s content:
Removed the directory httpdocs from /var/www/vhosts/accuweaver.com
Added a link in that folder to /var/www/vhosts/accuweaver.com/subdomains/wordpress/httpdocs.
This actually worked really well, since the content was only in one place, and all I had to do was change the host name in WordPress. Continue reading →
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.