I noticed that for some reason the 1.1 forms do not allow for the rich date input that many people like to use, so I just created a new widget that allows for rich date input. See below for the widget’s code. It uses the input_date_tag widget in the ‘Form’ helper.
So a few days ago Daum and I decided to try and “hackathon” our way through one of our symfony projects.
We were developing on our (mt) gs server which is usually a stable box (until Mediatemple’s whole cluster goes down). Things were going fine until our Symfony controller started to hang and not serve any requests. The gs machine is a shared box so we couldn’t do anything invasive to try and diagnose our problems.
We opened a support ticket and then I tried switching the enviroment off “dev” to “test”, things got better for awhile and then promptly began crashing again. The hackathon was looking more like a crashathon so we decided to try and switch development over to our (mt) dv machine.
To try and salvage the day, we used the DNS rollover delay to discuss our living situation Anyway, so we finally had the new DNS set up and the symfony project migrated over to the dv. And this is where the chaos began.
So first problem, everything we symlinked to “httpdocs” return 403 FORBIDEN errors. We figured it must be the symlinks right? We checked httpd.conf and everything was fine. Daum was getting antsy so finally called (mt) support who informed us that they would open a ticket and get back to us. We tried everything we could think of, symlinks in httpdocs, symlinking to httpdocs, symlinks inside the directory. Symlinks were only working for targets INSIDE httpdocs…
After this fracas, Daum stumbled across a KB ticket that described how to configure specific vhosts on a dv. It turns out PLESK places additional httpd.conf files inside the new vhost directory!?
Ok fine, so we edited up the Plesk http conf to enable our symlinks and mess with the directory structure a bit. Now Symfony was vomitting on require() failing – great. Back to httpd.conf and it turns out Plesk enabled Open_Base_Dir restrictions for php inside the vhost to restrict it to only files inside the document root…
WOW – so after something like 3 hours of yelling at support and messing around we finally transitioned a project from our gs machine to our dv. Things learned:
1. You can’t have a local PEAR install of Propel and Symfony with a different version of Propel
2. On dv servers Plesk installs custom http.conf files PER vhost that customizes Apache and PHP behavior – none of these settings are editable from within Plesk.
3. Moving DNS records within Mediatemple takes time – switching the domain from the gs to dv took at least an hour.
So I had some time (not really Daum just couldn’t get me to do any real work) so I wrote up a thin wrapper around Yahoo BOSS.
The code is available here
I mashed it into the where/what/when thing and made a swag front end ;)
The only search class implimented is the web one. I’ll probably try and do news/image later this weekend. I also haven’t tested ANY of the features so it’s very possible nothing works.
Today I was writing an administrator backend for a project we have. I had the code:
$old_feeds=RssFeedRelationPeer::doSelect($c);
if(count($old_feeds)>0){
foreach ($old_feeds as $old) $old->delete();
}
I was trying to remove some old foreign constraints before I deleted the main object, however, for the longest time the “$old” objects were not deleting, but no errors were being thrown. I did the usual debugging, added a die() statement inside the count, it was going there. I added a die statement in the foreach, it went there. I thought, “It must not be pulling the right ‘old’ objects.” I then added a $old->getName(); to see exactly what objects it was going through-they were the right ones. It made no sense. I next tired after the $old->delete();to add a $old->save();. The error I received was “You cannot save an object that has been deleted.” This didn’t make sense, since the object was still in the database. It hit me then, I had this problem in the past. Propel hates tables without primary keys. I quickly just added a simple primary key to the model, and the delete statements worked.
Moral: If dealing with Propel and you are getting some unexpected behavior, with zero errors, check to see if you have a primary key; it may save you hours of head banging.
A couple of weeks ago I ran across this article on Techcrunch.
Basically, a Yahoo! engineer used Yahoo Boss! and the Google App engine to make a “who,what,where,when” answering service. Since I want one I took a look at the code, but since its on the GAE the code is in Python for the GAE.
Anyway, since its like 50 lines of code I decided to take a look at BOSS and port it over to PHP. The quick and dirty PHP clocks in at 200 lines and is available for testing. The PHP returns JSON code with an optional callback specified with c=
Feel free to use it for whatever – just play nice
It might even make it into a super secret Wikia framework!
Code is available here.
Vik does a really good job of explaining how the process works. Unfortunately, its not particularly consistent or accurate. But it is pretty neat and considering its only 200 lines a good demonstration of thinking outside the box.