scootstah

You "refactor" it. Right click -> refactor -> rename.

To minimize bandwidth usage you can: - Only make the request when you have X chars typed (as fastsol said) - Only make the request after X seconds since the last keyup event - Use caching both server-side and client-side

You have to have a session cookie, otherwise the script doesn't know which session you belong to. Yes, cookies can be modified client side. And yes, there is inherent risk there. If someone else got hold of your session cookie, they could use it to impersonate you. But, there are ways to mitigate that - HTTP only cookies, HTTPS everywhere, no XSS vulnerabilities, etc. Also, any time a user gains elevated permissions they should re-authenticate using their username and password. For example, if a user goes from a normal page to a protected page, they should re-enter their credentials. You could be more strict on these protected pages, like limiting the elevated session duration to something small like 10-15 minutes, thus reducing the window that an attacker could gain a valid session. If you have to use this system for something mission-critical, your best bet is to use an existing framework/library where all of these things have already been battle tested.

You can leave the user ID, that's normal to have in a session. You just don't want anything that the general public shouldn't see. If someone sees a user ID... well, it's not a big deal. They shouldn't be able to do anything with a user ID. But, a password hash on the other hand, they could attempt to recover the password. Not good.

Does it? Huh, thought you had to do that yourself in the write handler. It's been a while since I've done that myself.

This one

I think that is a serialized array. serialize() PHP will not add those by itself. You must be calling html_entities() or htmlspecialchars() somewhere. What are you displaying the database results with? Yes. No. Do not store any sensitive information in a session. Ever.

I don't get to use that much... it doesn't play well with Doctrine.

Validate how? Just client side? AJAX? Are they already validating server-side?

A margin on the input works fine: https://jsfiddle.net/hm7hwgun/

That's not the same as what I did. The purpose of header() is to send an HTTP header to the browser. The browser is not required to honor the header, and can simply ignore it. Therefore someone who is not an authorized admin could still view the admin area by simply ignoring the redirect request. Therefore, it is imperitive that you terminate the script immediately following the redirect - that way, even if the browser ignores the redirect, your page is still inaccessible.

You need to terminate the script after your redirect, otherwise the rest of the script continues to execute before the redirect is done. header("location: admin_login.php"); exit;

Why not just have the developers configure their respective config files on their development environment? That is a fairly typical workflow.

Yeah i like the database stuff, although it's a bit limiting at times. I don't like the table/column editor. It's great to display some data or run some quick queries but that's about all I like it for. Navicat is so much better for DB stuff. And yeah, the IDE has a lot of features. You'll continually learn little productivity shortcuts that totally make your day. Once you start learning the shortcuts and customizing the live templates, you can totally fly.

Yes, I've used it for several years now. I absolutely love it, it beats the pants off every other IDE on the market. For your first issue: I'm not sure, as that's not my typical workflow. If you're using version control you can definitely integrate that and see exactly what has changed. But if you just mean with like FTP or something, I have no idea. Where are you looking for the color theme? Give their support a chance - they're good guys! You could try asking in the community forums as well.

You can't use a JS lint if you're getting the Javascript from PHP. You'd have to use lint on whatever PHP outputs. In a normal script, the PHP would have output a string before the JS ever ran.

It's going to be difficult to guarantee that you can do that in one second, every second. You can't even guarantee their server is going to respond within 1 second. If that requirement is absolutely critical you're probably going to want parallel computing.

No, because we've just established that your sessions are working correctly.

Your way is worse, because now you're tying up a ton of memory. You're basically pulling down an unlimited amount of data, which some people might not ever even look at. If 90% of people only look at the first page with like 10-20 records, but you're pulling down thousands, you're just wasting resources. Whereas, one extra query per page load is absolutely not a problem. Since it's just a blog with probably infrequent changes, you could make heavy use of caching if the database requests start becoming a problem.

Not sure what you mean. The LIMIT you provided can be used in his original query without needing to be in a loop. The start and end would be calculated based on the current page number.

Since view logic is not separated that doesn't really make sense here, you're just adding extra processing time.

I'd guess that your <div class="article"> should encapsulate each article, and thus should be inside the loop.

You're selecting many articles from the database, but only displaying one. You need to move all of your HTML inside the while() loop so that it displays each article. Also, your "read more" should be a <a></a> tag with a link to the specific post. Usually you'd use a query string or URI segments to link to a single article. For example: <a href="articles?id=<?php echo $row['id']; ?>">Read more</a>Then you'd fetch that specific article from the database with a WHERE clause.

Okay, so we have proved that sessions are behaving normally and your configuration is fine. The problem is with your code, then. We need to see more code to further help you.

That is correct. Every time session_start() is called, the session TTL is restarted. My test for you above will determine if you have some issue with your server config, or some issue in your code such as a logic problem or something else.