requinix
-
Content Count
12,518 -
Joined
-
Last visited
-
Days Won
276
2 Followers
About requinix
-
Rank
Three-Headed Administrator
-
*puerto rican sad face* "Abbreviation" or "Abbr". Please. How is it wasteful? In this particular example, the state abbreviation is short and so I wouldn't mind it being the primary key (in which case don't have an ID column at all), But the abbreviation and full name are both "lookup"-able values. BUT I would not make a table that has only US states. I would pretty much always have to think about Canada, or maybe Mexico, or Australia, or some of the other countries that have states/provinces. In which case the abbreviation is no longer unique by itself - you'd need a country FK, and while country + abbreviation would be unique, I would not have the two act as the primary key (mainly due to the awkwardness of a composite PK).
-
The length of the session ID isn't even remotely as important as what you do with your sessions in code. Focus on that instead.
-
Then... maybe Yahoo isn't being very nice and isn't automatically creating the link for you. Sounds like you'll have to switch to HTML emails. They don't have to be very complicated messages. In fact for simple emails you can probably just get away with <html> <body> Thanks for registering with {$server}. Please click this link to complete this registration:<br> <a href="{$url}">{$url}</a> </body> </html> Now sending the email, that's potentially complicated. But only a little. Depends on your application.
-
It's weird because... ah, well, doesn't matter that much. Yes, you can include() a file wherever you want and it will have access to all the same variables at that point. It will have $discountApprovalStatus (set a couple lines earlier) and $highestannualvalue (don't know where that's coming from but apparently it exists). It also has $_GET and $_SESSION and all the other "superglobal" variables that are already available to everyone, everywhere. But, and this is going to take a fair bit of work but I promise it's worth it, You're touching on a good design pattern that not many people ever hear about, let alone know. This one is called "MVP". It's like MVC (if you've heard of that) but works in a slightly different way. The key is that you have two places with code: one that does display (project_status.php) and one that has processing logic (project_status_app.php). One big change that you should make is that the app.php should not simply run everything inside it. You should use it as a place to store functions. For example, a function that handles updating the remarks in the database. This function does not check REQUEST_METHOD or grab values from $_POST. It takes all the values it needs as function parameters. Looks like function updateRemarks($remarkstxt, $pidForApproval) { What does the form send data to? It submits to the same file that started this process: project_status.php. That file is where you put the stuff about REQUEST_METHOD and $_POST. <?php if ($_SERVER['REQUEST_METHOD'] == 'POST') { include('project_status_app.php'); updateRemark($_POST['remarkstxt'], $_SESSION['pidForApproval']); // updateRemark should only update the remark - it shouldn't care about doing redirects too header("Location: project_status.php?id=" . $_SESSION['pidForApproval']); exit(); } include 'inc_fn_header_and_menu.php'; // ... With that updated, there's one more set of changes to make: not using $_SESSION, like I complained about earlier. And it's really, really easy. The pidForApproval is coming from $_GET to start with, right? Just keep doing that. Have the form submit to project_status.php?id=$pid and inside your new if block (seen above) you grab the pid from $_GET once more. Better yet, you can merge some of the new code with some of the old code: <?php if (isset($_GET['id']) && $_GET['id']!="") { $pid = $_GET['id']; $query = 'SELECT * FROM `profile` WHERE pid ='.'\''.$pid.'\''; $result=mysqli_query($db,$queryToRetrievePP) or die("There are no records to display ... \n" . mysqli_error()); foreach ($result as $row) { $status = $row['status']; } if ($_SERVER['REQUEST_METHOD'] == 'POST') { include('project_status_app.php'); updateRemark($_POST['remarkstxt'], $pid); header("Location: project_status.php?id=" . $pid); exit(); } } include 'inc_fn_header_and_menu.php'; // ... -
Or? If you need technical help from people with technical knowledge then you need to be very, very specific with your questions. What does "not opening" mean? What is happening and what did you expect would happen?
-
There's been a bit of a push in recent years for better email security, including showing people URLs they can copy and paste if they're not sure about authenticity, but virtually everyone is capable of handling actual links. It's one of the most basic principles of HTML emails. Anyway, if you don't want then don't. You can put a plain URL into an email. But it has to have a domain that looks real for a client or email service to automatically link it for the user.
-
1. There is a syntax error in what you posted for project_status_app.php. What's your real code? 2. Don't use the session to shuffle short-lived data between pages like this. You already have a (weird) mechanism to give data to another file. Use that for the pidForApproval too.
-
Don't do that. For one, it takes much more space to store whole strings like that. For two, there's a chance the slug may need to change in the future (like expanding the section to "database-design-and-development") and that would mean having to update all the tables using it. Use the number. That's the whole point of why it exists. Make it the PK with auto-increment and make the slug unique. There's no point in making this unique: (1) the uniqueness doesn't actually matter, and (2) the slug is basically the same as the name and it's already going to be unique. No, but if it isn't in the first couple columns then I would be suspicious. I would also be suspicious if there was a numeric "ID" column and it was not the PK. (And while not being the PK.) Just about. Just about. At least when there are better alternatives. Database doesn't care.
-
Do I have to create a new page for every single category?
requinix replied to imgrooot's topic in PHP Coding Help
One browse.php that handles /browse/whatever. browse.php?city=123 If the page is valid (city #123 exists) then the next step is to figure out what the canonical URL for the page should be. Namely /browse/city-name. If there's a category then that too, which you can handle as just ?category=123 because people don't care about query strings. If the canonical URL does not match the actual URL then redirect. -
Do I have to create a new page for every single category?
requinix replied to imgrooot's topic in PHP Coding Help
Answer it this way: What is the hierarchy of the actual data? /browse/apples?city=new-york suggests the person is browsing apples and wants to see the ones for New York. /browse/new-york?category=apples suggests the person is browsing things about New York and wants to see the ones about apples. Only one of those should make sense - or at least make noticeably more sense than the other. ...which is why sites use IDs. But labels are nice for people to read (SEO doesn't care about URLs but humans do), which is why sites don't use just the IDs but also the labels too. Such as /topic/311294-do-i-have-to-create-a-new-page-for-every-single-category/ Use the ID, but verify that the rest of it matches (and redirect if it does not). -
Do I have to create a new page for every single category?
requinix replied to imgrooot's topic in PHP Coding Help
SEO doesn't care about the URL. It's a myth. The second one looks better. Either way you never create "hundreds of pages". Every single one should use URL rewriting to go through a single PHP script. For example, you can tell your web server that /browse/thing should map to /browse.php?city=thing (and append the ?category=apples). Then all you need is the single file to handle everything. -
If you send text emails then it's up to the email client to decide whether to convert the URL into a clickable email. Nearly all of them do. Yours aren't links because you're linking to localhost. If it was a .com or .net or one of the usual types of domain names then it would (probably) be made into a link. Switch that, or send HTML emails.
-
If you're using mysqli then look here. If you're using PDO then look here.
-
Ah. Judging by the description I thought you needed this script for you personally to run the occasional database query. You need to think of this as an API instead of a "bridge". Each IoT device has a key to identify it. Your script takes the key it receives and verifies it is valid and good for whatever action. Only then does it insert data. Make sure all of this is over SSL. It needs to be. You also need to switch to prepared statements instead of using that test_input thing you have.
-
POSTs don't follow the same rule because POSTs don't follow the same rule. It's written into the standards, and with the comment that the user might not want the site to redirect their data somewhere else. And I didn't say to give up. I said that you cannot automatically redirect like this so you have to do something else - such as support the old POST endpoints until you can be reasonably sure that all consumers have been updated to go to the new site.