requinix

If you do a WHOIS lookup on one of those IP addresses then you'll see they all belong to one CIDR (IP address range) block: 52.32.0.0/11, which translates to 52.32.0.0 - 52.63.255.255. While whoever is running the servers could change their IP address at basically any time, they'll still end up with something in that range. Probably.

Do you know that the new users' emails are unique? They don't already exist in the database you're inserting into? If that is true then you can do this an easier way: do one mass INSERT...SELECT into the user table with the new user records, then do four more INSERT...SELECT queries where you JOIN in the new and old user tables to get the user IDs. (If that's not true then you need to resolve that regardless, but it doesn't make this much more complicated. A temporary table of just the new users would be a really quick solution.) Example? Here's the user table after you insert the new records. -- INSERT INTO users (email, username) SELECT email, username FROM old_users id | email | username ---+-------------------+--------- 1 | [email protected] | Alice <- existing 2 | [email protected] | Bob <- existing 7 | [email protected] | Cindy <- new 8 | [email protected] | David <- new7 and 8 are new. Here's the profiles table before adding new records. user_id | name | age --------+-------------+---- 1 | Alice Baker | 19 2 | Bob Smith | 25The query to add to it: INSERT INTO profiles (user_id, name, age) SELECT u.id, op.name, op.age FROM old_profiles op /* old profile data */ JOIN old_users ou ON op.user_id = ou.id /* get the email address to look up the new user record */ JOIN users u ON ou.email = u.email /* new user record has the new user ID */

That's the code where you generate the dates. Apparently that's working? The dates themselves are right? So where's the code where you display the attendance table?

You got the replacement part done right, but all you're doing is grabbing the current value and sticking the modified value into a variable. Nothing else. Want to fix the values with Javascript? (Why can't you fix it server-side?) Fix all of them, and do it when the page loads. $(function() { $("#model option").each(function() { this.value = this.value.replace(/\s+/g, "-"); }); });

Alright, I think I see a workaround: don't use Phar for the compression. It doesn't seem to clean up temporary files if you've enabled compression? Wouldn't expect it to use temp files in the first place... Instead use it to write out the tar archive and compress it yourself manually, such as by using one of: `gzip {$tar_file}`; // creates $tar_file.gz $in = fopen($tar_file, "rb"); $out = fopen("compress.zlib://{$tar_file}.gz", "wb"); // name.tar.gz; use a combination of dirname and basename to get just name.tgz stream_copy_to_stream($in, $out); fclose($out); fclose($in);

Hmm. Report it as abuse to Amazon, then block the IP range (52.32.0.0/11).

Are you destroying $a when you're done with the compression? Try that. If that doesn't help, destroy it and then call Phar::unlinkArchive.

Or you can set a path for the session cookie according to whatever directories you're using for the two projects. Like /project1 and /project2.

You aren't setting $hashed. Get the value from $rows, or do a bindValue+fetch instead of a fetchAll.

You have to name the elements as defid[]. Without those brackets, each value will overwrite the previous and you'll end up with just 2. The brackets mean $_POST["defid"] will be an array you can loop over.

That latest conf file won't rotate stuff immediately. Only if the file is at least 100MB. The rotate won't happen as soon as the file hits the limit. It's just a precondition to rotating. Could it be that there just were a ton of errors within the rotation timeframe?

Except for the trailing .hotel-banner02, that validates. Do validation on the source, not the minified version.

Can you confirm that logrotate is running? Check its logs to see when it last ran.

Not without knowing where the space went. If it happens again, use (Linux?) df to see how much space various directories are taking. And you can always ask your hosting provider for support - at least with identifying where the problem is, if not also fixing it.

You can compare a) A date/time formatted as Y-m-d or Y-m-d H:i:s or H:i:s. Anything else probably won't work. The rules are complicated (I'll explain if you want) so stick to just those three formats. b) Unix timestamps c) DateTime objects

What's the rest of the CSS around there?

What happened to using onblur?

Variables don't work in single-quoted strings. Anything you can think of that doesn't try to do it should work. The '"' method is easiest.

Glad to see you're going with JSON. By the way, when you write to the file you'll get "minimized" JSON. It's fine technically but can be hard for a human to read. If you want it readable, use the JSON_PRETTY_PRINT option to json_encode().

I'm so going to regret this. I agree in principle, but OP isn't generating code. It's about storing data in a file. It just happens that data is being represented with a PHP array. Putting aside the stupid "fairly likely" exaggeration, if someone has the ability to edit files then they wouldn't stop at this one file. Crazy easy to protect against. You might as well say not to use JSON files in case there's a syntax error. Good advice. OP won't be doing that. Yup. In that case the configuration changes would not be saved. I can't imagine any believable way that would happen with file_put_contents(). 1. Configuration files are unlikely to have concurrent write operations. 2. file_put_contents() is atomic. Except for when you need configuration to connect to it. Or when you don't have a database. Or when the database connection is expensive. Or when there's a risk of database problems. Or when you expect configuration to rarely ever change.

JSON would be really nice. { "subTitle": "Welcome to the Site" } // read $site = json_decode(file_get_contents("/path/to/file.json"), true); // write file_put_contents("/path/to/file.json", json_encode($site)); You do lose some of the PHP caching, though. To write out the array to a PHP file, use var_export.

There is no best. It depends on your needs. That answer hasn't changed in the last five years and it never will.

You have those pieces of data in your database, right? booking_id | doctor_id | date -----------+-----------+----------- 1 | 1 | 2016-03-23Then combine those into the ID that you show to people. You can get the zero-padding with sprintf. $friendlyid = sprintf("%03u-%s-%04u", $doctor_id, date("m-d-Y", $date), $booking_id);Unless you're thinking of the auto-increment number being a per-customer number? Okay, but you have a problem now: these are not unique anymore, and if someone has a problem and emails you their ID then you don't know which person it corresponds to. Couple other considerations: - Four-digit number only allows for 9999 bookings. Surely you want to support more than that? - An auto-increment ID will be easy to spot. You should probably (a) not start at 1 and not increment by 1, or (b) not use the auto-increment ID directly and instead do some math on it to get a "random" but still unique number.

It looks like you missed the very first sentence of OP's post.

$user = mysqli_real_escape_string(GetDbConn(), $en['user']);