kicken

You can only have one altField. Why do you think you need all these different input's anyway? At most you'd just need two inputs. One with a user-friendly format for display and the other hidden with a computer-friendly format. You can use the computer-friendly format to construct a date object and extract all the information you'd need for your other uses.

A unique constraint would prevent the duplicates, sure. However, rather than both users having their data saved successfully, one of them would be successful and the other would get a constraint violation error. Sure, you could write your code to detect this and re-try with a new random ID but why create that extra work for yourself? Since neither Mysqli or PDO is listed as available options you will need to get them enabled. The ability to do this may be in your control panel somewhere, or you may need to edit your php.ini file to load the extensions. You might have to install them first through the system's package manager.

Use javascript to check the server in the background and see if there are any updates, then only update the UI if there actually are updates. So, something like: $.get('/script.php').done(function(html){ if (html){ $('#thediv').html(html); } }); script.php would query the database for any updates since the last check. If there are updates then generate the HTML to be rendered as the response. If there were no updates, do not output anything.

Something like this seems to work: Assign a random number 0..1 to each record. Used to order the results in the next query UPDATE players SET randOrder = RAND() Generate a team number by just using a counter / 5. Order by the previously generated random number in order to randomize the players when generating the team number. UPDATE players INNER JOIN ( SELECT player_id, FLOOR(@row/5)+1 as team, @row := @row + 1 FROM players CROSS JOIN (SELECT @row := 0) counter ORDER BY randOrder ) teamGen ON teamGen.player_id = players.player_id SET players.team = teamGen.team I used this test script to generate some random data and try it out: <?php $generateRecords = isset($argv[1])?intval($argv[1]):0; $db = new PDO('mysql:host=localhost;dbname=', '', ''); $db->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION); if ($generateRecords > 0){ $db->exec('DROP TABLE IF EXISTS players'); $db->exec(' CREATE TABLE players ( player_id int(11) NOT NULL AUTO_INCREMENT, name varchar(45) NULL, team int(11) NULL, randOrder NUMERIC(10,10) NULL, PRIMARY KEY (player_id) ) '); $sql = 'INSERT INTO players (name) VALUES (?)'; $stmt = $db->prepare($sql); function randomName($len){ $letters = range('a','z'); shuffle($letters); return implode('', array_slice($letters, $len)); } for ( $i=0; $i < $generateRecords; $i++){ $params = array(randomName(6)); $stmt->execute($params); } } //Assign a random number 0..1 to each record $db->exec('UPDATE players SET randOrder = RAND()'); //Assign a team based on an increasing counter $db->exec(' UPDATE players INNER JOIN ( SELECT player_id, FLOOR(@row/5)+1 as team, @row := @row + 1 FROM players CROSS JOIN (SELECT @row := 0) counter ORDER BY randOrder ) teamGen ON teamGen.player_id = players.player_id SET players.team = teamGen.team ');

There's not going to be any fixed calculation you can do to tell you exactly how much bandwidth you'll use. It varies depending on things like how many users (obviously) and what items they allow to be cached vs what is loaded every time. To do a rough estimate, start by figuring out what you site's average page size is. Chrome will tell you how much data was transferred as part of a page load in it's developer tools on the Network tab. Make sure you disable cache when checking, there is a checkbox in the same place to allow you to temporarily disable cache. Load your site and click around a few pages while recording the total data transferred for each page, then average the results. Next multiple that by the number of main requests you estimate you'll have each month. To estimate the # of requests, first estimate the # of users you expect and multiply that by the number of pages you expect each user to view. Alternatively, since you know you have 3TB per month you could divide that by your average page size to determine how many requests you could serve before you exhausted your bandwidth. As you can see, everything is pretty much just estimates until you actually launch the site and can start getting some real statistics. So the question is, how good are you at estimating?

Emphasis added. Basically it's the percentage of the duration given by animation-duration property. So if you had a animation with keyframes at 0%, 25%, 50%, and 100% and animation-duration: 4s then 0% = 0s 25% = 1s 50% = 2s 100% = 4s If the duration were instead 10s then you'd have: 0% = 0s 25% = 2.5s 50% = 5s 100% = 10s If you want further help with whatever image animations you're attempting to create, you'll need to post the css and associated HTML you are using and a description of what exactly you're trying to do.

Yes, you will have to use something with more resolution than time(). Unix timestamps / time() cannot identify periods of less than 1 second, so you'd have either 1 second or 2 seconds, 1.7 seconds is not possible using timestamps. microtime() would work, or if you're mysql server's version is new enough using native datetime type and functions will give you fractional seconds as well.

echo "\n"; or echo PHP_EOL;

I've not really used mysql's or sql server's full text capabilities as I haven't tried building a general search engine or anything like it. However I'd probably say if one was going to do that, they are probably not the right tools for that job. There's likely a reason why google doesn't use a relational database for it's search engine.

Those are both things that you should be doing anyway when dealing with large amounts of data. You want to avoid ever having to do a full restore as that process would take a long time. With drive mirroring and replication the need to dig in your backups should be minimal. To make those backups though you'd have data replicate to a dedicated backup node which can be archived in offline mode without interrupting normal operations. If you combine proper indexing with partitioning you can query extremely large table without issue. I had a table at one point with near a billion rows and was having slow queries even with an index. Once I discovered partitioning and set that up, queries were back down to around a second. In my case I was using MySQL not SQL Server, but the concept and performance is likely the same. Use InnoDB, it does row-level locking so inserting/updating doesn't cause issues with reading. If you've got multiple servers going with replication, do your select queries only on the slaves and your inserts/updates on the master. If you know how to properly use a relational database system they will take you a long way. That said, yes they are not always the best tool for the job, which is why other options exist. In the OP's situation though, a relational database is perfect. A single database for all their client's will work fine. With proper indexing and partitioning it will be very snappy. Keeping everything in a single database will allow them to easily do some aggregate reporting across all their clients if they want in the future. All it'll cost is a single extra field on some tables and indexes to identify which client a customer belongs to.

Option 3, except you use Replication to copy the data rather than a cron job. The master is usually treated as write-only also, all the reads are done via the slave servers. So your scripts would have separate read and write connections. The read connection would go to one of the possible slave servers. The write connection goes to the master server. Whenever you need to make a change (UPDATE/INSERT/DELETE/etc) use the write connection. If you're just reading (SELECT/etc) use the read connection. If you end up with multiple slave servers, then you can balance across them by either just choosing one at random, or use another separate balancing node that will cycle through them.

Whether the column is unique or not probably affects how mysql finds and retrieves the rows. Without the unique column it probably just does a table scan, thus you get them in the table order. With the unique index it probably uses that index which will be ordered to provide quick searching. That's just speculation. It doesn't really matter why it does what it does though. If you don't specify a ORDER BY clause then any ordering of the results is just as valid as any other ordering.

Simple method is just to float them all left and either let them naturally wrap in the parent or use a new row class that clears. For example: http://www.cssdesk.com/p395c Natural wrapping. <style> .gallery { /*200px for the images + 30px total margins*/ width: 230px; height: 230px; background: white; border: 1px solid black; } .gallery img { display: block; float: left; margin: 10px 0 0 10px; } </style> <div class="gallery"> <img src="http://lorempixel.com/100/100/abstract/1"> <img src="http://lorempixel.com/100/100/abstract/2"> <img src="http://lorempixel.com/100/100/abstract/3"> <img src="http://lorempixel.com/100/100/abstract/4"> </div> Using new row class: <style> .gallery2 { height: 230px; border: 1px solid black; background: white; } .gallery2 img { display: block; margin: 10px 0 0 10px; float: left; } .gallery2 img.newrow { clear: left; } </style> <div class="gallery2"> <img src="http://lorempixel.com/100/100/abstract/1"> <img src="http://lorempixel.com/100/100/abstract/2"> <img src="http://lorempixel.com/100/100/abstract/3" class="newrow"> <img src="http://lorempixel.com/100/100/abstract/4"> </div>

So rather than just take 5 seconds to copy and paste the location given by find into your favorite editor and open the file, you post here and wait for an answer? Anyway, I'm not aware of any 'open' command. You'd have to choose which editor you want to open the file in and use the proper command for that editor. For example: find ./ -name 'blah' -exec vim {} \;

If you want to be sharing data between sessions, it would be better to create your own session back end that will allow you to open arbitrary sessions without having to involve PHP's session handling functions. Calling session_start() multiple times may cause issues since it emits various session related headers and initializes $_SESSION. Create your own session handler class and use that as your session back end. Then when you want to access another session instance just construct a new instance of the class with the given ID.

Try setting the domain parameter of the cookie as well to your base domain name. According to the RFC for cookies:

$('.button').click(function(){ $(this).hide(); }); Within the callback this is a reference to the element that the event was triggered on. In this case, it is a reference to the button that was clicked. Pass it as the argument to $() to get a jquery object and then you can call .hide() to hide it.

Don't use a Email to SMS gateway. Use a real SMS provider such as Twilio.

Not exactly. The * there means "any interface" meaning if your computer had multiple network interfaces/IP addresses apache would listen and respond on all of them. To setup a virtual host to allow a wildcard subdomain you'd use ServerAlias. For example: NameVirtualHost *:443 <VirtualHost *:443> ServerName u.domain.com ServerAlias *.u.domain.com That would respond to requests for u.domain.com or anything.u.domain.com. Just setup your application the parse the domain name and configure itself accordingly. If you wanted to give users the option of using their own full domain rather than a sub-domain then you'd just add additional ServerAlias lines for each domain and ensure the app can handle it.

The way you would handle the sub domains is by just configuring a wild-card vhost and then in your application code you inspect which request the domain was made with. list($subdomain,$domain) = explode('.', $_SERVER['HTTP_HOST'], 2); //Assumes only a single level of subdomain //use $subdomain to load the appropriate configuration I have no idea if that is how wordpress has their system setup, but I would assume it is similar at least. Having a separate copy of your application for every user is unnecessary, just have a single copy that is multi-domain aware.

Each user should have their own sub domain, for example bobs-site.mydomain.com. That way there will be no possible confusion as to which cookies apply to which site by the browser. As for using separate sessions for the administration area and the main site, don't. Use a single session and just manage the credentials appropriately in the code. For example you could store all the administration related session data in $_SESSION['administration'].

Timer would be best. If you do it every n key presses then you may end up with someone sitting there waiting for results but nothing coming up because they haven't hit enough keys. I my self in many instances where there is an auto-suggest feature will consistently type three or four letters quickly then just pause and wait for the results to select the item I want. If what I typed wasn't enough of a filter, or the result didn't show (wrong spelling perhaps) then I'll just type one or two more letters or backspace a couple and try again. Basically, the best user experience would be to: - Search at each pause in typing - Force search when enter is pressed - Allow keyboard selection of results - Keep feedback unobtrusive

realpath Use that to resolve any path given into an absolute path, then verify that the result begins with an allowed prefix. $prefix = $_SERVER['DOCUMENT_ROOT']; $path = realpath($_GET['path']); if ($path && strncmp($path, $prefix, strlen($prefix)==0){ //ok } Something like that.

Rather than create a new system you could use something like Selectize.js. Other than that, looks like you have the process down. I don't think it's necessary to alert the user if they try and re-add an already added tag, or at they very least make the alert unobtrusive so it doesn't interrupt their flow. Likewise I don't think it's necessary to alert them if they press enter with an empty text box, just ignore it and wait for some value to be entered. An improvement on the work flow might be to load the tags as they type rather than waiting for enter to be pressed. With each key press you'd start a timer which will load the results in x milliseconds. If another key is pressed before the timer is triggered, reset the timer. Once the timer triggers, make the ajax request to load tags matching the current value of the select box. The reason for the timer is so that you're not making a request for each individual key press. Instead you wait for a short pause in the typing. A value around 250ms-450ms works well usually. Prevents requests for quick typers but is not a real noticeable delay between when typing stops and the list loads (assuming a quick request/response). Here's an example of using a timer and processing while typing.

If you're going to do a single page with both the HTML and the processing, then the way to structure it would be: <?php //All your processing ?> <html> <body> <p>Only basic template stuff like <?php echo $variables; ?></p> </body> </html> All your processing goes at the top. Then you exit PHP mode and have your HTML at the bottom. Within the HTML you do only basic view-relates things like echoing variable, simple conditionals and loops, etc. Enter and exit PHP mode as necessary, don't just echo massive strings of HTML. The only time you might do a string of HTML is if you just need a small tag between two variables, such as <?php echo $name.'<br>'.$email;?>. There is no good reason to be using massive strings of HTML within your code at any point. Keep the HTML separate and out of PHP mode. This makes it much easier to work with both from a developers perspective and a development tool's perspective.