A lot of us really do need to just RTFM sometimes.
View full article »
Tag Archive: coding
Another boring tech post, but I found it so difficult to find a simple, straight answer online that I have to post this.
All I wanted to do was make sure that when editing a record in Symfony using a page created using the admin generator, that it didn’t crack the shits if you didn’t edit an image that you’d previously uploaded. What if you just wanted to change the name of a recipe, but not the photo?
That’s a pretty simple request, right? I’ve seen posts advocating javascript and ajax, checkboxes that turn the input boxes on and off, extending the base Doctrine/Propel classes… wow.
Want to allow users to keep the existing file? Modify your *Form class and set the sfValidatorFile ‘required’ field to $this->isNew().
Eg.,
$this->setValidator(‘banner_file’, new sfValidatorFile(array(
‘required’ => $this->isNew(),
‘mime_types’ => ‘web_images’,
‘path’ => sfConfig::get(‘sf_upload_dir’).’/',
)));
Done. If the user edits the file, it will save. If they don’t, the original file will remain. If they create a new record, they’ll be forced to upload the file.
Well, that wasn’t exactly the most fun I’ve had coding.
I evaluated a couple of jQuery scrollbar plugins and found that Tinyscrollbar was one of the better ones. So, I threw it into my template, messed around and got it looking right, and then discovered that in some instances it wasn’t actually scrolling all the way to the bottom of the div, leaving 1/5 to 1/3 of the div missing from view.
Wracking my brain for hours, searching solutions on Stack Overflow, hacking the code to pieces… nothing. Moving to another page and then hitting back fixed the problem; I could scroll all the way through. Not really a nice work around for users though. In desperation, I went back to the drawing board and found another plugin that wasn’t quite as good (so I won’t mention the name) but that might serve as a replacement.
Same. Fucking. Problem.
Okay, so, it couldn’t have been the plugin’s fault. It was obvious that it was a problem with the page rendering, be it timing or just a bug; I was going to have to delve deeper using up a bunch of time that I didn’t really have up my sleeve. In order to bolster my sagging spirits, I wandered downstairs, grabbed a Lucky Beer, hugged the dog, and decided to look at the rendering issue.
What could it possibly have been? I was running the javascript after the page was loaded, so everything should have been kocher, but the evidence suggested that something wasn’t set properly in the DOM. Height had to be wrong. Maybe it was a floating element… I threw in a bunch of clear:both divs around the place, tried putting the child content into a single div instead of multiple, tried some P tags just in case… and then it dawned on me… oh, did it dawn on me.
The fucking images. All of the headings and sub-headings are being generated on the fly using GD and the client’s preferred font, cached, and displayed on the page. Shouldn’t really be a problem, but in our jQuery case it was. I modified the function that was generating the image tag to explicity state the image height and presto! — the scrollbar suddenly allowed me to scroll all of the way down!
Long story short: the problem was resolved by drinking Lucky Beer. Not only did I discover and fix the issue, but Nell also brought me the best apple crumble I’ve ever tasted!
Thank you, Lucky Beer!
Luckiest Beer Ever
Nell's Apple Crumble