requinix

Don't use WordPress as an example. Please. Their codebase features poor design and worse implementation. Foreign keys (in terms of design) are simply fields in one table that correspond to fields in another table. Constraints aren't strictly necessary so long as the application is coded perfectly; since that can be hard there are foreign keys (in terms of implementation) that enforce the rule that referenced fields actually do exist before you try to use them. Note that they can do more, like automatically update or delete rows. MySQL doesn't automatically relate things for you, if you're thinking along those lines. There isn't a "grab stuff in X table and all the 'related' stuff in Y table" function. You have to tell it exactly what you mean. Instead it gives you some tools for that, such as JOINs and foreign key constraints.

Does the wifi not have an ethernet out port? Do you know that you won't get nearly as fast a connection with wifi than with broadband?

One to four. Standard ASCII stuff (like you'd find on an en-us keyboard) is one byte and just about every other "common" character is two or three. That's for if you were compiling PHP yourself. Somehow I doubt you are. Just enable the extension if it isn't already.

You should use foreign keys whenever they're warranted. There isn't really a situation where you could use one but should not. Here's what my layout would look like, though I tend to overthink things and it may be more complicated than you need: houses: - id - address - rent per month - tenant (optional, FK to tenants, helps with queries) - notes (always useful) tenants: - id - name - phone number - date first moved in - date moved out (nullable) - forwarding address (nullable) - current lease (optional, FK to leases, helps with queries) - notes (always useful) leases: - id - tenant (FK to tenants) - house (FK to houses) - start date - end date - price - amount paid (optional, helps with queries) - pay due date - notes (always useful) payments: - lease (FK to leases) - date - amount - notes (always useful)

In my opinion yes, it is worth it. Windows-1252 is probably the best single-byte encoding. It supports standard ASCII, naturally, and quite a few accented characters - even more than ISO 8859-1/Latin1.

And their commercials are sleazier than Trojan's and Axe's. Hell, sleazier than commercials for 1-900 services. They still do, just not publicly.

You should keep them outside the web tree. public_html/ dir1/ dir2/ dir3/ index.php config/ config1.php config2.php config3.php If the web server is hosting stuff out of public_html then it won't host any of those config files. That's why you would put them in a directory outside public_html.

I bet you're looking for it in $_POST, right? That's not where uploaded files go. Look in $_FILES instead.

You mean with IIS? The operating system is irrelevant - what matters it the web server software. Use a web.config. But unless you want to learn that, do the right thing: store these precious files in a special folder not inside the website.

Either that or they're the right way around and the variable names are backwards...

I was going to. Wanted to say "well your first problem is using GoDaddy" but I held my tongue. But now that the question's answered: Well Little Guy, your first problem is using GoDaddy...

UTF-8 is fine. There are others but this one is the most common. As for how it impacts your code, I don't know. Functions like strlen() and substr() stop working correctly, HTML pages need the encoding specified, and your database tables have to change - for starters.

Right now, www.cleep.us "works" (does not show the GoDaddy page) for me. A CNAME says "this website can be accessed at whatever server [iP address] hosts X". So right now your DNS says The browser then has to look up where that server is (I get 24.179.144.72). Next the browser starts sending HTTP requests. It'll send a request for "www.cleep.us" to 24.179.144.72. If that server does not know how to host "www.cleep.us" then it'll probably (a) complain that it doesn't know how to host that website, or (b) show whatever it considers to be the "default" website. In this situation it does the latter, which is the most common choice. So, what are you trying to do? What do you mean "it should have to know"?

Spend a minute trying to convince them that it's a stupid idea. Because it is. I, for one, would not at all be surprised if said print button didn't always work in all clients. Imagine how frustrated users would be if they clicked this button and it did absolutely nothing...

Does the server hosting stats.weblyize.com know that it should also host www.whatever? Have you waited long enough for the DNS changes to propagate? Also, it'd help to know the domain name (means we could test it ourselves).

Probably. What do you mean by "load another form"?

This manual page covers everything. Also, whenever you're in the PHP manual, try to read the user comments too. They can give insights, workarounds, and explanations that the manual proper doesn't.

It's not suicide, but it is inadvisable to use limited character encodings (like Latin1). You might as well start using it now so you don't run the risk of having to switch to it later.

You are paraphrasing your problem. Please don't. What is the actual code that's failing? Could it be that you're trying to put variables into singly-quoted strings? Because that doesn't work.

That's not a URL. That's some HTML with a bit of PHP code sprinkled in. What is the actual URL that is failing? The one that shows up in your browser's address bar.

If that other PHP file is also on your server you can just include() it. It'll have access to $_POST and everything.

What is the URL that is failing?

Oh. Sorry about not getting around to this within the 35 minutes you had allotted me, but I'm sure somebody else knows what I was thinking of doing.

Well, I can reduce that big if block into two conditions to check and a bit of math, but I have no idea what you're asking for.

I've seen some arguments against it but most of them deal with distributed libraries using it (eg, Prototype), adding unofficial functionality that's added officially later (eg, getElementsByClassName), or sticking stuff into the "wrong" prototype (eg, Prototype and getElementsByClassName+each). In cases where the code is just for myself and I'm adding simple functionality to something that won't change or won't have a different implementation then I don't see a problem. Maybe I just don't see all of it? Take hiding an element. Node.hide() is very cut and dry: take this Node and hide it visually. A NodeList.each() is a bit iffier: the first argument is very likely going to be a function, except that function could run in the Node's scope and/or take an argument for the Node. But even then you can NodeList.prototype.each = function(obj) { var self = obj || this; It's extra coding but you gain a handy function.