boen_robot

If you need to have both PHP and HTML content in a file, the only way is from a PHP file (unless you configure your server otherwise, but... details, details...). To be more precise, if you need any PHP in a file to be executed, that file must be a PHP file (unless you con... you got the point).

Yeah, that's the difference between PHP and JavaScript cookie handling really... PHP automatically turns the cookie file's contents into an array, and sets cookies in a fashion compatible with that.JavaScript instead just reads the cookie file's contents itself, without turning it into anything else, leaving you to process that file yourself in whatever fashion you may want, not necessarily compatible with what PHP is doing.The "turning it into something else" (the term in this case being "parsing") is different, but the raw content is the same.

The ways to read them are different, but the contents of the cookies are the same.Things go like this:1. Open up a page for the first time.2. PHP may set cookies.3. Afterwards, JavaScript may set additional cookies (I think JavaScript has access to cookies set by PHP, but I'm not sure honestly.4. Open up another page from the same domain (or refresh the same page).5. PHP receives cookies previously set by PHP or JavaScript, and/or may set additional cookies (Note: Additional cookies become available on the next request).6. Afterwards, JavaScript has access to the previously set cookies by PHP or JavaScript, and may set additional cookies (again, I think JavaScript has access to the cookies that were set by PHP at step 5, but I'm not sure).

Funny you should ask that. Two days ago, a new tutorial on PHPMaster (an interesting, but young site for PHP articles, derived from the more popular Sitepoint) discusses that.The caveats section is an important one... it basically means to say "It's good, but may be allow stuff that may not be expected by your app further down the chain". This doesn't mean that any malicious data would go through - no. It means that it would allow exotic features of formats, which may behave weird when not supported by the app.For example, a "+" is a valid sign in an email address (when it appears before the "@"), but some SMTP servers fail to send messages to addresses that have it. Another example is host names, which can technically be not just domains, but could instead be intranet names or IP addresses, but unlike domain names, those depend on the location of the server, and can therefore have unexpected effect if the wrong computer uses them to connect to something.This brings me to another thing I forgot in all of the "ideally" stuff... sometimes, when you're aware of the limitations (such as the above cases), it's not enough to sanitize data, which is why "validation" is still a very important piece of the puzzle - if you know in advance that something will fail down the chain, even if sanitized (such as an email that has an intranet name after the "@", or an email field that's missing a "@" to begin with), it's best to forbid it, and just give error messages about it, like most sites do.

Google "pastebin".

In a word, the ideal middle ground is "sanitization", which basically means that you accept arbitrary data at all places, but always ensure that regardless of the context it's used in, it's escaped properly in order not to "leak".Sometimes, sanitization is not really possible, or is not feasible for one reason or another, in which case the best thing is to convert the input to something which can be sanitized (with the possible caveat of some data loss when people try to escape outside the boundaries), and sanitize that new format.

Yeah, about that... this reminds me of another more general principle - Ideally, providing security should NOT come at the price of convenience or harmless power. But that's exactly what one is doing when going to extremes like that - security, yes, convenience, no.I mean, sure, people might email you with the problem if it's really important for them that your site works (like, if you were their bank or something), but generally, the majority of people would instead simply not do whatever it is they originally wanted to do. E.g. if posting a comment is too restrictive (what? I can't have any "<" because this might be "HTML tag start"? I don't even know what that means! I'm out of here!), people won't comment, if your contact form is too restrictive, they won't contact you, etc.

SQL injection - despite all the red flags in almost every PHP tutorial and the manual - is still one of the most common types of attack attempts. It's not always successful, but it's the one everyone tries, mostly because it's very easy to detect if you're vulnerable - add an ' to every possible form field (trying them one by one)... does anything weird happen at any point? If yes, you're definitely vulnerable. If not... you could be vulnerable, although the stuff that an attacker could do is now more limited.The other stuff, as you said, depends on what the site is for, but mostly, on what you're using.If you're at any point allowing file upload, the most common type of attack is for attackers to upload a file that would be interpreted by the server in some way, which would in turn provide a gateway for something more malicious - it could be an .htaccess file, a PHP file, etc.If you're at any point sending emails, a common attack is header injection, used to trick your server into sending (spam) messages that the attacker wants you to send.If at any point you're accepting "fancy" text from users in any form (such as how this forum has ways to let you bold, underline, etc. content), XSS attacks - ones that try to trick your app to display raw HTML "script" elements - is the most common type of attack. The more complex stuff you allow users to do, the more potential stuff for attackers to target.BTW, it should be noted that even in .htpasswd files, passwords are encrypted... the problem is they're encrypted with MD5, for which now it is easy to brute force the original string. But if you somehow end up opening the door to this file, that's actually the bigger problem anyway.

Check your torrenttable() function.

There you have it: The files that contain the code that sends the mail is not there => you have no email sent.Get PEAR_Mail and PEAR_Mail_Mime, and upload them to your host in a way that makes them accessible to your script.

No. I mean you should have said "I shall pay you", as in something like "I shall pay you X as soon as we go public with the initial (working) site, and if you stick around to help maintain and improve the site further, I'm willing to share some of the profits with you". I'm not sure if I would personally take that offer (if X is too high, I'll be scared of the responsibility to deliver something that matches it, and if X is too low, I wouldn't feel it's worth my time), but I'm pretty sure that even if X is a low number, you'll find people willing to take the offer. Details, details... the whole point is NOT to think of them so early, but get something that works, even if it's far from perfect. It's a kind of evolutionary process if you will - start with the minimum required for the goal (and publish THAT!), play out different things that feel like might improve it further, pick out whatever feels like it works, and repeat.The only thing you need is a list of (medium resolution?) images with a "buy (in high resolution?)" button that lets you receive orders. Start with that, and think about the rest later.

Yeah... those are PHP stuff... it's where cookies make most sense anyway.All cookies for a domain look like a single string. Browsers store one cookie file per domain, and send the contents of this file on every HTTP request to that domain. In JavaScript, you have the whole file in "document.cookie", and the very page you linked to shows how to parse the contents in order to get a particular value.In PHP, you don't need to parse the file. It's automatically parsed into the $_COOKIE array in a fashion similar to what the W3Schools page shows.

Yeah, it's next to useless... PHP will automatically eliminate files above the size specified there, but since this is part of the HTTP request, you must do a check "manually" anyway. Otherwise, someone could fake this value, and thus upload files up to the php.ini value.

Since PHP 5.3.0, if you're using (F)CGI, you can use .user.ini files OR (if you want things to work regardless of SAPI) in the main php.ini file, you could use a PATH section.If you want to support earlier PHP versions and make things work regardless of SAPI, you can only do so with the method in your first post.

Try to upload some (small) files, and var_dump($_FILES) to see for yourself.It's hard to explain it better than the page that birbal linked to. My best attempt would go something like this...The $_FILES array contains names (as defined in the HTML) as keys.Each value in the $_FILES array is itself a "meta data array" for the file, where the key is a certain name for a meta data about the file (name, tmp_name, size, etc.).Each value in that array is EITHER the value of that meta data OR (when there are multiple files sharing a name attribute as above) an array where the keys are whatever is specified in the HTML.If the value for the meta data is an array, the value of the array will be the meta data value for the file with this index.

Interesting exercise indeed... to avoid similar problems, I tend to recall PHP's scoping rule whenever I introduce a new (pseudo) variable into a large piece of code. The rule is simpler than in most other languages, and yet is the source of much confusion, since it's different (and this is also a hint for people who haven't looked at the spoilers yet):All variables within a function/method share the same scope, and variables outside of a function are all in the same scope. Constructs like for, foreach, if, etc. are not adding their own scope.Combine that with references (which I almost get a panic attack from, every time I see one in PHP, because you just know this will be a problem, if it's not already a problem), and there you have it.

Promoting yourself as a web designer is, I believe, even harder than promoting yourself a web developer.A developer only needs to make things "work". This means that clients asses yours skills by the amount and complexity of the work you've done, and nothing more. It's "craft" if you will.A designer needs needs to make things "look right", which is not craft... but art instead. And "art" is subjective. There are certain things which are known to work better than others in certain scenarios, but even those are not absolutes, and if taken to an extreme (or taken for another scenario), they fail. For example, most people like rounded corners, but if you make a site that doesn't have any sharp corners anywhere, you've made a site for kids where adults would feel uncomfortable.Whether you're a "web designer" or "web developer", you still need to know HTML and CSS.You don't need to know PHP and SQL to be a web designer, but in their place, you need to know how to work with a powerful graphics program (not necessarily "Adobe Photoshop"; "Corel Draw" and/or GIMP work too), and some talent (just like with any art form)...

There are currently drafts that would allow you to do just that - specify a content as non-selectable, while still allowing users to interact with it.The guys who bring you this... interesting... feature... are the same guys who brought you right click prevention: Microsoft. Read this blog post for details.

Your footer is outside your container, while your content is in it... at your container, you've set min-height:100%;. That probably ends up messing the footer up... try to set the min-height equal to the margin, i.e. 250px.

Engines are per table... and you can switch the engine like ALTER TABLE `posts` ENGINE = InnoDB;

It would be a lot more efficient if you use foreign keys. See this tutorial for details on how to apply them.P.S. You'll probably need the SET NULL action, and this also means making the rest of your app aware that NULL means "no category".

A centralized VCS serves exactly as a single file manager that ensures you won't overwrite each other's stuff and/or lets you merge/resolve conflicts and/or restore previous versions of a file (or the whole thing).If certralized is what you want, try SVN. TortoiseSVN is the client I'd reccomend (which can create a file system for itself; You'll only need a server when you want remote devices join into your file system). I suggest you try it out on your computer first to get a feel of the workflow.Note that when I say "file system", I don't mean "file system" as in "file manager"/Winbows, I mean it as in "a set of files and folders".

So be it. Goodbye Eduard, and good luck with everything! (especially with solving your current hostel crisis)The next forum you try to look for answers, try NOT to bring up the wheelchair, and see if there's any difference in the way people treat you. I bet you won't see any difference, because, as we (and for the first time, "we" includes people not from this forum) keep telling you: The problem is not your situation, it's your behaviour. You could be a filthy rich olympic sprint and marathon champion who doesn't even know the meaning of the word "wheelchair"... but with that behaviour of yours, we'd treat you the same way.Since you're done here, I'll go ahead, and lock the topic.

So.. you mean you have something akin toD:\USBwebserver v8_en\root\website1\index.html that you then access in your browser with http://localhost/website1/index.html and the question is if PHP files must be in the folder called "root" or the folder called "website1"?PHP files can be in either place. If they're in "root", like at D:\USBwebserver v8_en\root\insert.php they'll be accessible from http://localhost/insert.php and if they're at "website1", like: D:\USBwebserver v8_en\root\website1\insert.php they'll be accessible from http://localhost/website1/insert.php

Since version control systems (VCS) need direct access to the files, they are not typically tied directly to any web naming, whether that's a domain, subdomain or something else. I say "directly", because with the right organization, you can make it appear as if they're somehow tied to it - do so indirectly if you will.You need to think about this from a file system perspective first, and expand from there... how do you do things when you're alone? You have local copies of files, and you upload those over FTP to your host. You then make further changes locally, ideally you test before you upload, and finally upload the new files.Here's the thing... VCS can only deal with files up to the moment before you decide to upload them.You may ask "But where's the point then? My team mates work on different computers, and we all need to be up to date...". There are two different answers to this question, depending on the kind of VCS you're after:- Centralized: You all share the same file system over a network. That is, you all connect to a single remote server, and that remote server's file system is the authoritative one. You check up with updates from it, you commit changes to it, and in cases of attempts at modifying the same file, you could (potentially) merge changes from both parties, or resolve conflicts in favor of one commit.- Decentralized/Distributed: Each team member gets their own file system, where they do whatever changes they want, independently from each other. One of these file systems (not necessarily one owned by a member of the team: could be a server like in the centralized system) is agreed to be the authoritative file system, to which everyone can merge their file system, and resolve conflicts at that point (again, either with a merge, or with one version being favored over another). Every team member can, at any point (with permission), check for updates from an arbitrary remote file system (either owned by a team member or the authoritative one).No VCS "comes with hosting" - you can always install a client and/or server on your computer, and not bother with any hosting. But most VCS have a host that offers them. The "host" in this case is simply someone who lends you a file system that your VCS program can connect to. There are both free and paid ones.SourceForge is a popular free hosting platform for open source projects that lets you use systems like SVN, CVS, Git, Mercurial, and others. GitHub is probably the most popular Git hosting service, and they (again) offer free space for open source projects, and in addition to SourceForge also let you host non open sourced (i.e. "private") projects for a fee.