roopurt18

I've been listening to him for a while, but I hadn't heard these songs I posted before a couple days ago. If you've not heard "Down to the old Pub Instead" or "Vanilla [ice Cream]", I'd look them up as well. There's a good in-studio version of Vanilla on youtube. Also, the forms seem to have died over the past few days...is everyone taking finals?

I'm a big fan of comedy, laughter is the best medicine after all. I Just wanted to share a couple of short videos I stumbled on lately that I consider to be some of Lynch's greatest material: Love Song http://video.google.com/videoplay?docid=4452058614015909947&q=lynch+love+song&hl=en Country Ditty http://www.youtube.com/watch?v=84EMgTvYdb0 Beelz (Hysterical)

My fiance is an accounting major. I haven't paid a bill or gone to the bank in...two years? Date one of them!

I'd have to disagree with your friend. I think it's obvious you put more time / effort into your layout than those sites.

The search by color is a fantastic idea, but I think you could improve upon having the search results returned in a more meaningful search order. That is to say, if I selected red as my color, I'd expect objects that are mostly red or pink to appear before objects that have very little red. The first time I clicked on "Zune Skins" it took forever to load. The second time it ran much more quickly. I also received the following Javascript error when searching or clicking on menu links. ccollect is not defined menu.js (line 77) Your three graphics below the navigation menu are mis-aligned. Overall it's very responsive. WinXP - Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3

I threw in a quick hack that limits the length of the textarea's contents to 100 chars; the performance should be much improved.

Well I just spent the last two hours testing and doing some research; it appears that Safari / Konqueror do not support the designMode property just yet. It is expected that Safari 2 will have support for this. I'm sort of glad as I was worried about how I could go about testing a graceful failure of the control. Related links: http://blog.solmetra.com/2007/02/22/safari-is-not-konqueror/ http://programmabilities.com/xml/?id=17 http://operawiki.info/TextAreaEditor

Just for reference, can you guys post which browser & OS you're using? Sorry I left that out of my original post.

You're missing the $ on query. After your last dot operator you have '"; where it should be "'";

To the best of my knowledge, string concatenation in Javascript isn't always the fastest operation. So doing something like reading the content of a textarea, appending to it, and rewriting to the control for each of keydown, keyup, and keypress, is going to bog it down. In reality, you want to put as little processing as possible in those event handlers and most of the time handling just one of them is sufficient. So my big concern is if everyone was able to type into it, which based on your responses you were.

You want to rely on globals and session values as little as possible. The best advice would be to stop pissing around with tutorials and spend $25-40 on a decent book. There's a book thread somewhere in these forums; use the search feature.

I'm playing around with creating a Javascript RTE control. I've got a bit more done on my local machine than what's visible here, but before I continued further development I needed to do some experimenting with the iframe. When the page loads, you should see a textarea on top and the iframe on the bottom. When the following events occur, they should update the contents of the textarea: mouseover, mouseout mousedown, mouseup click keydown, keyup, keypress select mousemove is turned off since it generates so much output so quickly and I don't feel like putting in a throttling mechanism. I'm still working out how to capture the change event. I've tried to write this to be cross-platform, so I'm really concerned if the events register correctly and if you're able to type in the iframe box. Simple test really, nothing fancy! The beta test: http://www.rbredlau.com/tutorials/richtext/part_ii/index.html Associated blog entry (aka shameless plug): http://www.rbredlau.com/drupal/node/7

Ok. That was painful enough. And with that we have my half-assed attempt at giving something back to the world: http://www.rbredlau.com/drupal/ Buahaha!

Jesus H. Christ. These things are a pain in the ass to set up and crash non-fucking-stop. Is there any CMS or blog that will allow me to post code, show me how many times the article has been read, and allow people to post comments? Is there one that you folks have used that didn't shit all over your head in the process?

Not while drunk, but definitely while buzzed. There's no difference in the code quality when I look at it later either.

No, safari has it's own list of quirks. If there is something specific in question you are worried about working, post it in the beta testing forum.

I talked my parents into buying a Mac because they're notorious for breaking their PC, which caused them to never have enough faith in their home computer to do much with it. Myself, I was quite impressed with it and I think the next full computer I buy will be a Mac. One day, I'll have an actual office in my home where I can use a Mac or linux box for work and then a PC just for testing.

People that are willing to lie to themselves are dangerous indeed.

A combo box is a different entity than a select control. I'm fairly certain there is no built-in support for them and that you'd have to create your own control using an input[type=text] in combination with a select and a fair amount of Javascript. If you're just wanting page elements to change as a user selects different items in a regular select box, you're in the wrong forum as you'll need to use Javascript.

You want mod_rewrite then. http://www.phpfreaks.com/forums/index.php/board,50.0.html

PHP looping structures are: foreach for do / while while

Until last month I was forced to program on our live site used by our clients, much against my wishes to do so. I created two scripts for handling a "debug" cookie; one script requires a password and creates the cookie, the other deletes the cookie. Next, whenever I wanted to heavily modify a section of our website, I'd copy the original file with an additonal .NEW in the file name. file.php would become file.NEW.php. Then, at the top of the old file.php, I'd check for the existence of the debug cookie; if the cookie is set then redirect to the new page, otherwise stay on the old page. I only did this for files that I was heavily modifying and constantly making changes to during an update. Files that contain libraries or helper functions I didn't bother with since I rarely had a need to change them or the changes were small. I think this eliminated the majority of instances where I might have introduced a syntax error while an actual user was visiting the same page, preventing them from getting a blank page. I still had to be very careful when modifying the database. Each of our clients has their own database on our server and I work in a test database. To make the database changes, I would save all of the queries in a .txt file that I was using to modify the database. When the update was ready to be applied I'd do a one time application of the queries to all of the existing databases. Much to my happiness, we finally got ourselves a test server. Both our test and live servers are VPS packages offered by ServerPowered. Now all of my programming occurs in the hosted test server. Part of the process of setting up these servers was to write a bunch of shell scripts. I have scripts that copy a client's database from the live server to the test server for debugging purposes; I also have scripts that copy a client's file data, i.e. the files they've uploaded to the server, from the live server to the test server. This enables me to more easily try new things in debugging their data and making significant database design changes because I know it won't affect any of our clients if I screw up. The two most important scripts are the ones that synchronize the source code between the servers. Both of these scripts are run from the test server and modify a file on the live server named sync.lock. The first script creates sync.lock and enters a timestamp into the file. On the live server, the entry page checks for the existence of this file; if it exists, a warning is displayed on every page of the site that the site is about to go down for maintenance and everyone should finish up whatever they're working on. The second script modifies the contents of sync.lock to indicate that a sync is in progress; when the live site detects this content, all users are redirected to a static .html page. After modifying sync.lock, the second script then creates a local backup of the test server's source code, a remote back up of the live server's test code, a copy of the live servers code on the test server, sends the code over, and then deletes sync.lock. The scripts I've written fall into three groups, those that can be run on only the test server, those that can be run on only the live server, and those that can be run on either. Every script detects the server it is being run on and exits if the server is inappropriate to the script. Lastly, I still use the debug cookie when making changes on the test server because I still want to test their functionality privately after moving them to the live server, in case there are environmental differences.

Another vote for changing the color scheme. How about a toned down background and then a darker font overall? I get what you're trying to convey and it's very appropriate for the site, there just isn't enough contrast between the elements.

An extended approach if all request for your site go through a single entry point is to create a user_activity table. In that table, store the URI of every request and attach it to the user. Additionally, you can store any $_GET, $_POST, $_SESSION, and / or $_COOKIE data as well. A good way to see how people are using your site. To clarify, the benefit of this approach is not only do you know when they logged in, but you can see the order in which they browsed your site. "Hmmm...how come a guest is viewing an administrator page?"

For that purpose, why don't you just add a column in your users table named last_login_dt and every time a user logs in, update it to the current date / time? As a general rule, you should be storing as little data as possible in your sessions and I think there are very few real reasons to save a user's session between visits to the site.