requinix

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']);

The only times I've seen people say to not use ETags are: a) Conflict between it and other caching headers - solution is to fix the headers, or use only one set of them b) Incorrectly configured backing information - solution is to fix the backing information c) Situations where ETags are not the best solution, or don't behave in the way that the caching requires - solution is, obviously, to use what's better With a quick search around I see a lot of people saying to use them, so... any specific arguments against that you'd want me to address?

ETags is built-into Apache. I'm surprised your server isn't configured to send them already, but whatever you can turn them on with that FileETag directive. As for more information... I really don't know. Wikipedia is generally pretty good (at least with technical information). If MDN or MSDN have articles on it then I'd recommend those. This has nothing to do with time. Time does not factor into any part of it. 1. The client requests the file for the first time. 2. The server calculates an identifier for the file. Like combining a few pieces of information together and hashing it. Make sure that information will accurately reflect whether a file has changed or not. 3. Server sends the file and the identifier. Client caches the file and the identifier. 4. Client requests the file for the second time, but sends the identifier it had learned previously. 5. Server calculates the identifier again; a) If the identifier doesn't match then the file has changed, the server replies with the file and the new identifier and the process starts over b) If the identifier matches then the file has not changed, the server replies without the file and the client reuses what it had cached previously Client always re-requests the file every time. Server always checks if the file has updated before replying. Client only receives the file if it has changed. Otherwise yes, you should be able to drop that code into a .htaccess and have it work.

Honestly, it's felt like that sometimes to me too. It's possible there's a problem somewhere but the configuration definitely says 15 minutes. At least where I saw - maybe there's an override somewhere I don't know about?

Expires sucks. The problem is that it instructs the browsers to not even try to retrieve content until the time has passed. Don't use it. Remove all that stuff. Use ETags instead. The server will send a hash with the content that (should) only change when the file changes. The client will keep trying to request the file, but will send the last hash it knew about. Then the server will reply with either (a) yes, the file has changed and here it is with the new hash, or (b) no, the file has not changed so use what you have cached. It doesn't save as much bandwidth as Expires does (there's still the overhead for each request to check the hash) but it saves you the hassle of dealing with query strings and such. <Files ~ "\.(css|gif|jpe?g|js|png)$"> FileETag All </Files> You may need to unset other caching headers, mostly just Cache-Control, Expires, and Pragma, if they're being sent automatically.

The window is 15 minutes. The idea is to have a long enough window for people to correct accidental mistakes, but short enough that someone can't go in and change the content of their post after people have read and possibly replied to it.

What are you using? Expires? Expires sucks. How about ETags? ETags are more-or-less perfect, provided the backing information is chosen well (defaults are normally fine). We're saying two different things. But I've tried to get us on the same wavelength and that isn't working, so I'm bowing out of this argument. I stand by my "not using the right directives" comment. And see above replies. A random number is more than you need. The time is sufficient. <?php $time = time(); $content1 = '<a href="http://example.net" title="Example 1" target="_blank"><img src="http://example.com/gallery/image-1.png?' . $time . '" alt="Image 1" width="300" height="250" class="gallery-image"></a>'; $content2 = '<a href="http://example.net" title="Example 2" target="_blank"><img src="http://example.com/gallery/image-2.png?' . $time . '" alt="Image 2" width="300" height="250" class="gallery-image"></a>'; $content3 = '<a href="http://example.net" title="Example 3" target="_blank"><img src="http://example.com/gallery/image-3.png?' . $time . '" alt="Image 3" width="300" height="250" class="gallery-image"></a>'; $content4 = '<a href="http://example.net" title="Example 4" target="_blank"><img src="http://example.com/gallery/image-3.png?' . $time . '" alt="Image 4" width="300" height="250" class="gallery-image"></a>'; $content = array($content1, $content2, $content3, $content4,); shuffle($content); ?> <?php print $content[0] ?>