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.
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)
The server was being unresponsive, and Larry Van Cantfort (the Director of Operations for PMI SFBAC) sent me this clue:
It appears that httpd has a lot of running processes and when I try to kill them I am unable to. THis is causing the server to sloooow way down. There are also error messages from mysqld with a corrupt table:
13110312:18:30[ERROR]/usr/libexec/mysqld:Table'./wordpress_2/wp_comments'ismarked ascrashed andshould be repaired
I couldn’t even get into the control panel to get things going, so the cleanest approach was to simply rebuild the server.
So I shut down the database and started to try and get it backed up so we’d at least save all the hard work of the volunteers.
So I tried to run the dump, with the following command that I got from the Parallels support site:
[root@u15893654~]# mysqldump -uadmin -p`cat /etc/psa/.psa.shadow` -A > dumpall.sql
But that gave me the same error:
mysqldump:Got error:145:Table'./wordpress_2/wp_comments'ismarked ascrashed andshould be repaired when using LOCK TABLES
That fixed the issue, and I was able to create the “dumpall.sql”.
Once I had ALL of the tables fixed, I simply rebuilt the server and migrated it into a new database as described in the Parallels KB article mentioned above (a lot more steps to make sure the backup was good, but once it was the newly imaged server was able to run without incident).
I’m a big fan of making people more productive by sharing data entry. In my current project, the tool we have for collaboration is Sharepoint 2007.One of our team members is really comfortable with Access development, and built a nice database for tracking the status of our document deliverables. The problem with this is that since Access is a local sort of solution, it doesn’t allow for people to make updates as they work, so we end up spending a lot of time with the database owner updating status.
The solution (in this particular environment) is to utilize Sharepoint lists. Access 2007 has a nice wizard driven approach to building Sharepoint lists, as long as the database is built correctly.
So here are the iterations I had to go through to make this work …
First pass: Diving right in, I loaded up the database to see what it looked like (how many tables, what sort of structure was there, etc). The designer did a good job of making a lot of the fields lookups, and had named all of the reference tables with the prefix of “REF” – so far so good:
So, thinking it would all work fine, I simply start the “Move to Sharepoint” button in the “External Data” tab of the Access Ribbon:
This starts the wizard, which walks you through the process of building the lists on Sharepoint. Once the task is finished, you are left with a new Access database that is linked to the newly created Sharepoint lists.
Looking at these lists I noticed something off: it didn’t appear that any of the reference tables were being used. They were there as linked Sharepoint lists, but when you looked at the data in either SP, or Access, there was no drop-down or choice to be made, they were simply text fields.
So digging a bit, and having a discussion with the developer, I found a few issues: Most of the reference tables weren’t actually setup as relationships in Access, and some of the reference tables didn’t have an ID column (an Autonumberprimary key).
The wizard requires the links between tables to be relationships on autonumber primary key fields, in order to build the field as a lookup.
Looking at the base relationships, it turns out that there was only one of the myriad of tables that actually had a relationship:
In order to get the Sharepoint lists to build fields that were lookups to the “REF” tables, I would have to create new fields that linked to the primary keys in those tables. To do that turns out to be relatively simple in this case.
First I open up the design of the main table, and look for the fields that are using lookups (in the case below, Contract_Task):
Then I simply create a lookup field that has the name of the table in question (in this case REF_Contract_Tasks). First step is to insert or append a new column :
Name the new column the same as the table in question:
Choose the table you are interested in (in this case REF_Contract_Tasks):
Pick which fields you want to display (typically this will just be a name field, but you can choose whichever fields you think would be helpful):
Choose the order you want things displayed:
Format the columns for lookup display (it’s recommended not to display the ID column):
Choose a name for the field (if you already typed this in, you don’t need to change it):
The wizard now asks you if you’d like to save the changes, which you should do:
Now if I look at the relationships, and hit “show all relationships”, I see the newly created link:
Right click on the relationship line to edit the relationship:
And I typically just check the “Enforce Referential Integrity” box to make sure it is an identifying relationship:
Once that is done, I can either build an update query, or copy the contents of the original row to the new one in datasheet view. For the purposes of this database, there aren’t that many rows, so a simple cut and paste works fine:
Hit ctrl-C or choose “Copy” from the menu:
Select the new row, and paste the data there:
Repeat for all of the other rows in the table that have some query in the lookup tab …
Now in a couple of cases, I got prompted for which field to use to establish the relationship. These are the tables that didn’t have an autonumber primary key. The fix for this is relatively painless (once you discover which tables have the problem).
Just add a new field to the table that has a Data Type of Autonumber, and make it a primary key.
The trick with this is that the primary key won’t likely have the same numbers as the original ID column, and you can’t create an AutoNumber column with data in it. So in order to get the new field updated, the easiest thing to do is create an update query and edit it to use the old join values.
Do query wizard, and choose the columns in question, in this case Deliverables, and REF_Projects. Since you created a relationship with the new REF_Projects field on the Deliverables table, you should end up with something like this:
In theory you should be able to edit the relationship in the GUI by dragging it around and/or right clicking on it. I’ve actually had limited success with this, so I tend to simply add the column I want to update (REF_Projects) to the query, then hit the button on the Design tab of the ribbon that says “Update”:
Then switch to SQL view in order to modify the join properties more easily:
The query so far will be something like:
UPDATE REF_Projects INNER JOIN Deliverables ON REF_Projects.newID = Deliverables.REF_Projects
SET Deliverables.REF_Projects = [REF_Projects].[newID];
And you want to update it with the old columns from the lookup query that was in the original table, so in this case it becomes:
UPDATE REF_Projects INNER JOIN Deliverables ON REF_Projects.ID = Deliverables.Project_Level
SET Deliverables.REF_Projects = [REF_Projects].[newID];
Then run the query and the values in the two fields should look relatively the same in the datasheet view (since they are now both pointing at the same rows.
Then another one that threw me off was one field that had a different column heading than the field name. When I got to the “Doc_Type” field, I didn’t see it in the Datasheet view. Turns out it had a value in the Caption area of the field definition:
So in the datasheet view it showed as “NDCP Standard”:
This field also has another interesting challenge – the values didn’t all match up with the values in the lookup table (REF_Doc_Type), so when I did my cut-and-paste trick I got the following error:
So looking at the REF_Doc_Type table, I was able to figure out that there is no row that is named “Standard” (likely it had been changed to “Program standard” at some point, and since this column stores the actual value, there is a disconnect).
So in this case, I chose to simply update the current column values to match the one I thought it should be with an update:
After that my cut-and-paste from the “NDCP Standard” field to the “REF_Doc_Type” field went without a flaw.
This same trick needs to be applied to any of the tables that will be worked directly with (typically those that contribute to forms) in order to make sure all of the proper links are built.
Once you have the links built, you want to rename the original table and build a view (in Access this is called a Query) with the same name that has all the joins you need in place. So after you rename the table, just build a simple query with that table in place (I use the wizard and make sure I include all of the fields):
I have been running my development for VolunteerCake with a database on my Windows box which sits in my office with my Mac. I went to meet some people at a coffee shop, and realized that I couldn’t show them the app running on my MacBook because I was no longer on the same subnet with my Windows box, so I decided to move the database to the Mac to allow me for this.
Since I had everything in place to run Cake on my Mac except for MySQL, the first step was to install MySQL. This turns out to be pretty painless. Just grab the DMG from the MySQL site, and voila, new MySQL running on my Mac. Checked everything out using the MySQL administration tools, and it all looks good (I can access the DB, set up users, etc.)
Next I need to put the data in the database, so I just do a quick export from the phpmyadmin page on the PC. I end up with a file that is the SQL needed to replicate the entire database on my Mac. I run this SQL into the Mac MySQL, and now I have an exact copy of the database on my Mac.
After that, I go to the SQL administrator tool and make sure I have the user set up to give access to that database and make sure the username and password are the same as I was using on the PC (if I were more of a DBA, I’d probably have done this with command line MySQL, but I like GUIs, especially for things I don’t do every day, and the MySQL tools are pretty cool).
Then I need to change my database.php to point at the local database in order for VolunteerCake to get the data from the Mac. This should be as easy as changing the name of the host name to ‘localhost’ from ‘monet’ since I’ve set up the user and access to the database exactly the same as what I had on the PC.
Finally, all that’s left is to fire up the same URL that I have established for my app on my Mac (http://test.lctd.org/VolunteerCake) and … wait, that didn’t work. It says it can’t find the table acos for the Aco model …
Weird, the table is there, I can connect just fine, what could this be? A quick trip to the IRC channel, and I get the suggestion of clearing my cache. OK, try that … But hit the URL again and no change.
OK, now I’m confused, so I try running ‘cake bake’ … Now something interesting: I get an error that tells me that it was unable to connect to /var/mysql/mysql.sock – what does that mean? I thought I was connecting with a TCP socket, why does it want a file? Is this some sort of file permissions issue ?
Back to the IRC chat for some guidance, thinking maybe it’s a common problem, a permissions issue or something, of course they tell me to do exactly what I’d tell somebody else to do: verify that you can connect from PHP first. Good idea – so I whip up a quick connection test page, and get the same error. So now I’ve confirmed that it’s a PHP problem, and not a Cake issue.PHP can connect to a remote DB, but not the one on my local Mac …
Now it occurs to me that I often have problems that end up being related to the open source software that came bundled with the Mac, so I do some Google searches on PHP connection to MySQL for Mac OS X, and with the connection error messages. Eventually I find what looks to be the issue: for some reason the MySQL configuration sets the socket file to /tmp/mysql.sock but the PHP that comes with the Mac is looking somewhere else (at /var/mysql/mysql.sock to be specific). So I basically have three choices, edit the php.ini, edit the mysql config file, or build symlinks to make the file accessible at both locations.
I decide to change the php.ini file, which turns out to be another excercise in hunting, since Mac OS X likes to hide the files you’d expect to find in the /etc directory. After some more Google searches, I find that the PHP5 install that comes with Leopard puts the php.ini file into /private/etc, so I edit that file, changing the part of the file that looks like the following:
;Defaultsocket name forlocal MySQL connects.Ifempty,uses the built-in
;Defaultsocket name forlocal MySQL connects.Ifempty,uses the built-in
In order to have PHP find the mysql.sock in the location that MySQL is actually creating it. Check my URL again, and voila, everything is working !!!
So, to make a long story even longer, I relearned that mixing actual open source with vendor open source is often problematic. It was suggested by at least one person (Mark Story) on the IRC channel that the best way to set up for Cake development on the Mac is to use MacPorts, since then you end up with matching versions of the software all in a “normal” open source location.