kicken

That's not quite right. The old mysql extension is already deprecated (as of 5.5.0). In the next major version of PHP it is likely to be removed entirely meaning you (or your host) would have to specifically enable it rather than it being "standard". The newer API's such as Mysqli or PDO are being actively maintained and also provide more advanced/useful features such as prepared statements, bound parameters, transactions, etc. The mysql extension on the other hand currently would receive only major security fixes, and probably soon not even that. There is a page in the manual describing the different APIs that you should read if you want to know more. It's in your best interest to convert to the newer API's now while you have time to plan, implement, and test the changes. Eventually you'll get an email from your host along the lines of "We are upgrading PHP next week. The Mysql extension is no longer and any scripts relying on it will no longer function." If you haven't already upgraded your stuff by the time that email comes then you'll suddenly be in rush mode to either 1) Update your stuff like you should have already done or 2) Move to another host that will still support the extension. All that said, even a new release of PHP were out tomorrow that excluded the extension, you're probably at least 3 years away from a host dropping support. Most hosts will continue to support it for a while because not doing so would be bad for business. Hosts already support multiple versions of PHP so keeping 5.5/5.6 around for mysql support wouldn't be a big deal. Essentially the threat of the mysql extension going away is not why you should be updating. You should be updating because the extension is old, effectively abandoned, and lacks support for what are considered critical features for modern applications.

error_log needs to point to a file, not a directory. Set it to something like C:\php_errors.txt. Make sure the file is writable by IIS as well.

It'd help if you posted the definitions of all the tables. Make sure that the column types match and you've set your ID column as the primary key.

Note that if you use a file approach you will need to take care to ensure you lock the file properly before reading/updating the content. Not doing this could result in a corrupt file due to multiple people hitting it at the same time. If you use a database this problem is taken care of for you, provided to do it right and use a single UPDATE like Barand demonstrated rather than a SELECT first then update later. There are plenty of ways you could track a counter. What you choose to use would depend mostly on what you need and whether you're already using a particular tech. If you're already using a database for your site, then using that for your counter as well would make sense. If you're not using database already, then a file of some type would work fine.

I use chrome day to day, but I tried Firefox and IE with regard to your copy/paste question. Firefox worked just fine, IE failed in this specific context but otherwise worked fine for the rest of the site. I've also never had an issue with a bunch of crap when installing Firefox. Sounds like maybe you grabbed some unofficial installer from a third-party that bundled a bunch of crap rather than the one official Mozilla one. Anyway, other than the IE pasting issue, it sounds like whatever problems you have are specific to just you and your machine.

Seems to be an IE problem. Disable Rich Text editing (click the switch icon) and CTRL+V to paste or use a different browser.

What I would do is just make common.php include whatever scripts are used on nearly every page. Then on pages that require additional resources you can do a second script tag with the traditional list of URLs. eg: <script type="text/javascript" src="/min/common.php"></script> <script type="text/javascript" src="/min/?f=/additional.js"></script> Or you could extend common.php to accept the same type of ?f= parameter and just do <script type="text/javascript" src="/min/common.php?f=/additional.js"></script> I don't bother combining scripts. I'll minify them using google's Closure Compiler prior to push things onto the production server but that's about it. Each script still has it's own script tag. I don't use a lot of scripting so it's not a big deal. For the most part all i have is jQuery, jQuery UI, a single site-wide script and sometimes an additional page specific script. jQuery/jQueryUI are loaded from a CDN rather than locally to take advantage of the fact that the CDN url is likely cached already. If I did do something that required more scripting, I'd likely still just do the minify and concatenation of scripts as part of the release process rather than dynamically using a library such as this. I use PHPStorm as my development environment and it has a feature called File Watchers where I can set it up to automatically run some program any time I make a change to a file. That makes it easy to do things like use SCSS or minified JS without having to use some server-side script to do the compilation on the fly. Any time I make a change PHPStorm will re-compile the files automatically so I can just reload the browser as normal. If you don't have such a system in place, then libraries such as this are good alternatives to make development easier. This one seems fine on the surface. I didn't go digging around in the source of it looking for problems but based on the examples it seems to be easy to use and flexible.

Note: I haven't used this library, so the following is just based on what I've gathered after spending a few minutes reading the docs. What you can do is rather than putting some absurd URL like that into your HTML pages, you make a PHP page that consolidates your scripts and serves them minified. By doing this you can not only include static files (like you do now) but also dynamic contents (which you want to do). Look at the script they have under 'Performance Considerations' on the page I linked above for an example. <?php // myServer.php /** * This script implements a Minify server for a single set of sources. * If you don't want '.php' in the URL, use mod_rewrite... */ // setup Minify set_include_path('path/to/min/lib' . PATH_SEPARATOR . get_include_path()); require 'Minify.php'; require 'Minify/Cache/File.php'; Minify::setCache(new Minify_Cache_File()); // guesses a temp directory function src1_fetch() { return file_get_contents('http://example.org/javascript.php'); } // setup sources $sources = array(); $sources[] = new Minify_Source(array( 'id' => 'source1' ,'getContentFunc' => 'src1_fetch' ,'contentType' => Minify::TYPE_JS ,'lastModified' => max( filemtime('/path/to/javascript.php') ,filemtime('/path/to/javascript_input.js') ) )); $sources[] = '//file2.js'; $sources[] = '//file3.js'; // setup serve options $options = array( 'files' => $sources, 'maxAge' => 86400, ); // handle request Minify::serve('Files', $options); Where they have //setup sources is where you'd list out your files as well as a dynamic source. For example: function getsomeconstants(){ return 'var CONSTANTS='.json_encode(array( 'blah' => 'blah' )); } // setup sources $sources = array(); $sources[] = new Minify_Source(array( 'id' => 'constants' ,'getContentFunc' => 'getsomeconstants' ,'contentType' => Minify::TYPE_JS ,'lastModified' => 123 )); $sources[] = '//lib/plugins_3rd/jquery/jquery-1.11.2.js'; $sources[] = '//lib/plugins_3rd/jquery-ui/jquery-ui-1.11.2.custom/jquery-ui.js'; $sources[] = '//lib/js/general.js'; $sources[] = '//lib/components/back/common/js/common.js'; //... Save that script as a PHP file somewhere, maybe in /min/common.php then in your HTML files just do: <script type="text/javascript" src="/min/common.php"></script>

Custom Source Read that page, it shows you how you can setup a source that is dynamic. Basically you'd just make a function that does whatever your current getsomeconstants.php file does and return the result as a string. Set that up as a source then include whatever the appropriate URL is for that source in your HTML files.

Use the --skip-extended-insert option.

If you have the ID's of the rows you want to update to 1, then you'd just specify them in the WHERE clause. UPDATE table SET annual_leave=1 WHERE id IN (1,2,4) You can do a single update query that includes the calculation also. UPDATE table SET annual_leave=CASE WHEN hours >= 10 THEN 1 ELSE 0 END

That code is just an example of how to generate a signature for the API request. There will be more code necessary to actually perform the request. Keep looking over their examples or ask their support for the rest of the code.

Given that your code is using the mysql_* functions, I am going to assume you are actually using MySQL and not Microsoft SQL Server which is the forum where you posted this question. First things first, you need to know that the mysql_* functions are old, deprecated, and slated for removal in some upcoming PHP version. You should forget these functions exist and switch to using either PDO (Recommended) or mysqli. PHP: The Right Way has some information about using PDO and there is also a good PDO Tutorial for MySQL Developers provided by the freenode ##php folks. Secondly, if you want to ensure that the mobile number does not exist before inserting it, you need to handle this by creating a UNIQUE constraint on that column in the database. Then you will simply attempt to insert the value and see if it fails with a constraint violation. The code (using PDO with exceptions) would look something like this: $username = 'example'; $password = 'example'; $mobile = '123456789'; try { $stmt = $db->prepare('INSERT INTO users(username,password,mobile) VALUES (?,?,?)'); $stmt->execute([$username, $password, $mobile]); echo 'Data inserted successfully'; } catch (PDOException $ex){ if ($ex->getCode() == 23000){ //Check if it's a duplicate key violation. echo 'Mobile must be unique'; } else { throw $ex; //Rethrow other errors } } You'll want to make sure you normalize your mobile numbers so that someone inserting the same number but with different spacing/separation is correctly caught by the system as a duplicate. For phone numbers I store them in a VARCHAR column with all non-digit/letter characters removed.

What you have basically is Crockford's Base-32. His version just excludes commonly confused letters and 'U' to prevent accidental obscenity which is what you appear to do as well. I use the eloquent/encdec package to do the base-32 encoding and wrote an encode/decode class for it that implements crockford's alphabet. They can do both. The email I send out is worded roughly as: Following the link will complete the verification process. Going to http://example.com/verify-email/1234 presents a form that asks for the token and also a button they can use to generate and send a new token. After I send the initial token I redirect them to the form that asks for the token. In the form that asks for the token I apply the text-transform: uppercase; style to the input box so that as they type the code it will appear in upper-case automatically. I surround the token in the email with *'s because that is a common convention for emphasizing text and some plain-text mail clients will bold-face that text as a result. I make sure that I trim() the *'s and spaces just incase they accidentally copy/paste those along with the token.

The third case is basically the same as how you'd handle a "Forgot Password?" page. You generate a random token and send it to them, then store the hash of that token in your database. Give it a limited duration and make it one-time use and that's about it. So long as you use a strong randomness source and a decent size sample size then you're fine. For my verification tokens I pull 12 bytes from the system's random source. The random bytes are the encoded using Crockford's Base-32 to create the token value. The tokens may seem a bit long but since most users will just click the link it the email, or copy-paste the value I don't see it as being a problem. I always provide the token in the email's both as a link that can be clicked/copy-n-pasted and as an individual item so they can copy just the token if need be.

It's possible (and generally preferable) to create a database user account which can only work with a specific database, and not create new databases. This is what we are saying you need to check for. Whatever username you specify when connecting to mysql will need to have the proper permissions to create a new database. As mentioned though, you really should re-consider your layout and keep things in a single database and link things together in the tables by ID rather than trying to create a separate database (or table) for each end-user.

The cgi-bin directory is a bit of a "the old days" thing. It was a location that would be configured to allow scripts or executable to be run via CGI. Files outside this directory typically had to be static or only use server-side-includes. These days you can usually put your scripts anywhere and the cgi-bin is obsolete. As far as chmod, it depends on what you're referencing. Again, in "the old days" your scripts that lived in the cgi-bin needed to have the execute bit set in order to run, so they were typically set to 755. These days this is unnecessary so you would typically just leave them at their default which is usually 664 or 644. You may need to change them for other reasons such as to allow writing to an uploads directory or similar. There are other ways to handle those situations typically as well.

If you only care about the local timezone and you can output a unix timestamp then it's relatively simple. Example fiddle var timestamp = 1423419743; //Have PHP provide this value. var dt = new Date(timestamp*1000); var formatted = (dt.getMonth()+1) + '/' + dt.getDate() + '/' + dt.getFullYear() + ' ' + dt.getHours() + ':' + dt.getMinutes() + ':' + dt.getSeconds(); console.log(formatted); With a little extra work you could remove the need to output the timestamp and use the date string instead:Example Fiddle var datetimestr = '2015-02-08 18:22:23'; //Have PHP provide this value somehow var matches=datetimestr.match(/(\d{4})-(\d{2})-(\d{2}) (\d{2})\d{2})\d{2})/); var dt = new Date(); dt.setUTCFullYear(matches[1]); dt.setUTCMonth(matches[2]-1); dt.setUTCDate(matches[3]); dt.setUTCHours(matches[4]); dt.setUTCMinutes(matches[5]); dt.setUTCSeconds(matches[6]); var formatted = (dt.getMonth()+1) + '/' + dt.getDate() + '/' + dt.getFullYear() + ' ' + dt.getHours() + ':' + dt.getMinutes() + ':' + dt.getSeconds(); console.log(formatted); You'll probably want to make formatted a little nicer, but it's generally not a lot of work/code. If you want to get more elaborate and be able to do easier formatting, multiple timezones, etc then you'd want to look into a library such as moment.js and moment-timezone.js

There is nothing in a standard HTTP request that will tell you what the user's timezone is. You either need to ask them for it then save it somewhere, or you need to use Javascript to query for it from the browser. I tend to just output all dates and times in UTC and then on page load use Javascript to convert them all into the user's local timezone. If they have JS enabled, they will see the proper time. If they don't, they will still see the UTC time at least. If you also display the current time somewhere on the page, they will be able to see what the difference is between the time displayed and their local time.

If you want to prevent them from re-using upto x passwords, then what you'd want to do is save the prior hash values and compare the new value with them. Storing the unhashed password would mean that anyone who gained access to the database would be able to see all the user's current (and prior) passwords in plain text. Since people often re-use their password leaking a user's password not only gives the attacker the password for your site, but potentially many over sites the user also uses. I personally wouldn't worry about anything beyond checking their new password isn't the same as the current password (if even that). If they want to re-use some password let them. There's nothing I hate more than a site telling me my chosen password is no good, regardless of the reason why they think it's no good.

You could install X Windows and a desktop of your choosing on any linux server. It's just not typical as having a GUI is entirely unnecessary and those resources would be better spent doing what the server is supposed to be doing (serving your website). For a staging server the GUI wouldn't really hurt things too much since it'd only be used by you presumably, but for a production server it's a waste. The command line version of various source control utilities are not that difficult, especially for the basic stuff like checkout/updating of a repository which is all you'd really need to be doing on your servers. Everything more complex would be handled on your development machines which will have the GUI to help you. Learn the basic command line interfaces (make a cheat sheet if necessary) and forget about a GUI for the server work. I'm not sure what exactly you'd be wanting to pay for vs doing it yourself. A lot of people only do production hosting (either shared of with a VPS) and just self-host their staging/development environment (which might be the same thing). I'm not sure if you're clearly understanding what "staging" is, so here's a brief rundown of the terms: Development Environment This would be the environment you do all your development work with. It has all the fancy debugging and version control tools for you to test and develop your code Staging Environment This would be a server that is as close to identical to your production server as possible. It should use the same Webserver version, the same PHP version, same configuration options, etc. Use a copy of the real database, or have a specific test database that you can load (same structure, but will fake data). Production Environment The environment that actually hosts your live site for people to use. It's common to combine what would be Staging and Development. They just have their local development environment on which they do their work and test things. Once everything it working then push the changes to production. For smaller/less complex products this typically is fine and saves on costs some. If you want to have a more proper staging environment but don't want to spend money on extra hosting or a separate machine, you can run a virtual machine on your computers. This is typically what I do for projects where I feel it is worth while. As for pushing to production, there are choices to be made here as well which depend on how large of an update is required, and how much down time you're willing to accept. For small updates with minor changes (eg, simple bug fixes) then you can usually just copy files in place. It's still best to upload them separately then copy them over via the command line rather than try and FTP directly over the existing. That minimizes the delay by removing the network operations from the process. If you don't mind down time, you can throw up a maintenance page (or just stop services) for the duration of the update to prevent people from accessing the site while an update is in progress. Whenever you finish, then you can take down the maintenance page (or restart services). If you want minimal/no down time then you'd be updating a copy and once complete switch the server over to the copy.

If you want to try and re-implement a select box then you'll have to use Javascript to actually make it functional. You cannot re-create a working select box using just HTML and CSS. What exactly are you trying to accomplish?

See the page on Storage Requirements for the details of how data is stored and how much space is required for each data type. So if you have a VARCHAR(30) but only store a 10-byte string, then the actual space required is 11 bytes (1 (length) + 10 (data)). VARCHAR(255) is a good generic if you're not sure how long a particular string might be.

It'd be inefficient to use TEXT. Data for a TEXT column is stored separately from the main record, so when you need to read that data the database will first have to locate which records need to be read, then separately locate and read the actual value for a text column. VARCHAR/CHAR values are store in the main record directly so there is no need for that second read operation. Essentially you should stick to VARCHAR and only use TEXT for values for which you want to allow an exceptionally large value. In modern Mysql versions a VARCHAR will work for up to 65535 bytes (subject to various conditions).

As has been said before, talk to a lawyer. In the US at least, you'd have to deal with the COPPA law if you allow anyone under the age of 13 to sign up and use your site. That is why most places set their age limit there. As you already indicated though, a person can just lie about their information and bypass whatever kind of filter you try to implement. That is why you'll want to talk to a lawyer to find out what you'd be liable for in those situations.