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.
Once in a while, I run across a situation where I need to import data from a spreadsheet into a database.
If the data is to update a single table, this is pretty straight forward. On the other hand, if the data is modeled as a set of tables it gets a bit more messy. Continue reading
I manage a small application that is hosted on a single Linux virtual machine and have noticed some occasional performance and stability issues.
The server runs CentOS, MySQL and a GlassFish server. I chose GlassFish several years ago because at the time it was the only EJB3 container around, as well as being very well integrated with the NetBeans IDE.
Like most JavaEE containers, it also makes clustering and scaling easier. Continue reading
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:
|
1 2 3 |
; Default socket name for local MySQL connects. If empty, uses the built-in ; MySQL defaults. mysql.default_socket = |
To be:
|
1 2 3 |
; Default socket name for local MySQL connects. If empty, uses the built-in ; MySQL defaults. mysql.default_socket = /tmp/mysql.sock |
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.
I ran into an odd problem with the way Cake is coded that tripped me up for a couple of days. Because I hate it when things don’t work the way I think they should, I spent way more time debugging this than anybody should.
I got my basic RESTful service working for the VolunteerCake project, and everything was working swimmingly, until I needed to turn on debug to figure something out …
When I had the debug level set to less than two (2) calling the action I was interested in with an extension of “.xml” was working fine. I got back the XML representation of the data in the action I was interested in returned with content-type of “application/xml”. In Cake, if you turn debug to 2 (or 3) it will dump out the SQL that was run in an HTML table.
The problem is that this HTML table is actually spit out after the rest of the view, meaning that my RESTful service no longer has a well formed document to display. Additionally (for reasons I’ve yet to isolate), when this happens, the document is returned with a content-type of “text/html” instead of “application/xml” as expected. Neither of these things would be acceptable if the site is to provide web services, since it would mean the web services would be broken as soon as somebody needed to debug.
The workaround for this is to manually reset the debug level when the extension of “xml” is detected. Since the debug data is useful, and it’s just the SQL that appears to break the XML, I asked on the IRC channel what the last place I could set the debug might be. The suggestion was to put it either in the afterFilter, or the end of the view itself.
I found that if I put the following code into the beforeFilter method, I could prevent the problem with the price of losing my debug output:
|
1 2 3 4 |
if ($this->params['url']['ext'] == 'xml'){ Configure::write('debug',1); $this->RequestHandler->respondAs('xml'); } |
That same code placed in the afterFilter method gave me the debug output in a well formed XML document (excluding the SQL table), as did placing it in the view itself. This leads me to believe that when debug > 1 there is some code that happens after the beforeFilter that is not setting the content type to “application/xml” as would be expected from our routing rules.
Being the bulldog that I am, I dug into the Cake source code to see if I could figure this out. I found the spot where the SQL table was being built, which turned out to be in the showLog() method of the dbo_source.php, which is called by the close() method. Since the close() is called after the view is finished, and the showLog() method simply prints the data, that explains why it breaks the XML. It definitely breaks the MVC encapsulation, since the data gets dumped into an HTML table and spit out after the view is complete.
On the IRC channel, it was suggested that I try creating a data source that would override the showLog method and spit that table out to a table, which might be worth trying.
I posted my question on the CakePHP Google Group and got the useful suggestion to use the FirePHP plugin which basically writes the log data to the FirePHP plugin so it can be displayed in FireBug. So my approach will be to write a dbo_mysql_firephp.php class that does just that. This will at least resolve the MVC encapsulation issue and keep my view relatively clean.
I still want to figure out exactly why the content-type isn’t getting set properly, but for now I have a workaround that I’ll use, and I’ll add the FirePHP debugging to solve the well-formed XML issue if I ever do figure out the content-type problem.
Off to set up my FirePHP plugin and build the dbo class now …
