Jacques1

I'm having a déjà vu. You had almost the exact same broken code two years ago. Several people went through all the mistakes and explained in great detail how to solve them. For a while, you actually managed to write halfway correct PDO queries. And now you've somehow decided to unlearn everything and become a newbie again? That makes no sense. Surely the correct PDO queries still exist somewhere in your project. Use those. Not the broken stuff you had before. The new queries. If you don't remember anything, then go through your old forum posts. You also need to start thinking about the code you write. Right now, you seem to randomly combine syntax elements without any understanding of what the code actually means. This doesn't work.

If you look closely at the data in front of you, I'm sure you can at least get a basic understanding of the structure. JSON deals with hierarchical data just like XML, but it's much, much simpler. If you know JavaScript, then you already know JSON; otherwise, there's an official description which takes just a few minutes to read. The indentation alone tells you that “sender” is definitely not a top-level entry. You have to navigate through multiple levels of objects and arrays. See the “features” key? This points to an array of objects. The first object has a properties key, and this key points to another object which contains your values. $data['features'][0]['properties'] Hint: You'll make things much easier if you decode the data as an associative array rather than an object.

That still tells us exactly nothing about what – is – wrong. Why is it so hard to understand that we aren't sitting in front of your screen? Anyway, forget about it. This code should be rewritten from top to bottom, because the 90s are over. Replace the shady mail() stuff with a proper mail library like PHPMailer. Get rid of the stupid refresh. It's annoying and violates the accessibility guidelines. Do a redirect with the Location header. Stop injecting unfiltered values into the URL. Validate the input and make sure it is in fact a domain. Chances are this was just the tip of the iceberg, so don't expect it to be a quick fix.

What is better: A pickup truck or a sports car? And if it's a sports car, is a Porsche 911 the best one? Nobody can give you a serious answer to that, at least not without some basic parameters. Sure, we could all list our personal preferences, but that tells you nothing about the appropriate choice for your specific case. What a framework does is provide a basic application infrastructure. The benefit is that you can skip a lot of the boring low-level PHP code you usually have to write (request processing, database interaction etc.). The downside is that frameworks come with their own overhead and restrictions: You have to learn it, you have to install it, you have to configure it, you have to follow its rules. The right choice is going to depend on many different factors: the size of the project: You wouldn't use a framework for a two-script homepage, but you may benefit from it if you have a more complex application the nature of the project: Is it standard stuff which can be covered with a general-purpose framework? Or do you need a specialized solution? your skillset: If you don't know any framework and aren't familiar with any of the concepts they use, you'll have to invest a lot of time learning it. your personal preferences: Some people just don't like frameworks, some people don't like plain PHP, some people will go with whathever is appropriate. The same is true for the framework itself. … Laravel is a decent general-purpose framework. If you like it, and if it suits your need, go ahead. But the same can be said about Symfony, Yii, Phalcon etc. When in doubt, try them.

Use the DOM API to change attributes and element contents instead of messing with the raw HTML markup -- which is not only ugly but also dangerous. There are also dedicated JavaScript template engines like Handlebars.js, so all the repetitive search-and-replace can be replaced with a single function call.

We already had that. Twice.

What's more important, though: Your code is wide open to SQL injection attacks. Either learn how to use mysqli correctly (which means spending a lot of time on the PHP manual) or switch to PDO.

Think about this: How is a script running on a webserver supposed to write files to your PC? If that were possible, we would be screwed, don't you think? But there's absolutely no reason for saving the file anywhere. If you simply read the QrCode example, you'll see a writeString() method. And as I said above, PHPMailer has an addStringAttachment() method. Surely you can figure out how to combine the two.

??? All attachments must be embedded as strings into a multipart message. The concept of "attaching files" only exists on the server, and it just means that the server has to do the extra work of reading the file content into a string. Once the mail has been sent out, it's the same mail. It's not like the mail contains "real" file references, so that the mail client could browse around in the server's filesystem -- that would be disturbing.

Several things: Your PHP code makes no sense (which is why I suggested extensive tests), because there's no realistic way for you to ever retrieve the data again. You cannot JSON-decode the file content, because it's a sequence of JSON documents, not a single JSON document. You cannot split those documents either, because you have no idea where they begin and end. So the data you're collecting will be pretty useless -- unless you want to manually sift through the entire file. You cannot pull the received data out of $_POST, because you aren't sending regular form data. You're sending a JSON document, and PHP has no idea what to do with that. You have to pull the raw HTTP body out of the php://input stream and parse it yourself.

Not at all.

There's not a single line of code to get a row count, and a row count doesn't provide any useful information here. You two are reading something which doesn't exist into the code. Pick any of the queries: SELECT times FROM ips WHERE ip='$ip' The OP wants the value of the times column which is a counter of the number of requests, as you can clearly see in the next query: UPDATE ips SET times = times+1 WHERE ... The only row count you would get is “1” over and over again. If the OP had a different data model where a row count were in fact needed, I would happily accept that (though the row_count attribute is usually the wrong approach). But he just doesn't.

None of you addressed the problem. What the OP wants is to fetch a value. Not get a row count. There is just one row with a counter (the times column). To fetch a value from a row, you use a fetch method. And I think I made that very, very clear in my reply: If you think the OP is too stupid to look those fetch methods up, I respectfully disagree.

None of this has anything to do with the problem. As I already said above, the solution is to scrap the current code and use one query to simultaneously increment the IP counter and get the new value. <?php const IP_REQUESTS_LIMIT = 5; /* * First try to insert the IP. If it already exists, increment the counter. In both cases, call LAST_INSERT_ID() with * the new counter value, so that the value can then by fetched by PHP. Alternatively, you could use a MySQL session * variable, but that would require an extra SELECT query. */ $ip_requests_stmt = $database_connection->prepare(' INSERT INTO ips (ip, times) VALUES (?, LAST_INSERT_ID(1)) ON DUPLICATE KEY UPDATE times = LAST_INSERT_ID(times + 1) '); $ip_requests_stmt->bind_param('s', $_SERVER['REMOTE_ADDR']); $ip_requests_stmt->execute(); // get the counter value passed to LAST_INSERT_ID() $ip_requests = $database_connection->insert_id; if ($ip_requests <= IP_REQUESTS_LIMIT) { echo 'Limit has not been reached yet (number of requests: '.$ip_requests.').'; } else { echo 'Limit has been reached'; } Of course this requires the ip column to be a primary key or have a UNIQUE constraint, but I hope you've already done that.

Learn SQL. I understand that copypasting random code from the Internet is the new programming, but when you've reached the point where you cannot even copypaste, then it's time to actually learn the language.

You clearly don't understand how HTTP works, so I'll make this very, very simple for you. When the server successfully authenticates to another website, then the server gets a session cookie. The server. Not the client which triggered the server-side script. The server. Redirecting the client doesn't get you anywhere, because the client has no cookies. They're on the server. The server cannot “transmit” the session cookie either, because a website isn't allowed to set cookies for another website – for obvious reasons. Even if you had the webserver echo the page content (which, according to your confused reply, you don't want), the client still wouldn't be able to “browse” the site, because as soon as they click on a link, they either a) make a request to the original site where they have no cookies or b) make a request to your server which doesn't have the requested file. Long story short: What you want is conceptually wrong. Of course there is software which can act as a middleman between a client and another website (namely a proxy), but this has nothing to do with PHP web applications.

Then you're not doing what I said. I said: Take hard-coded test data. Do not send anything. Just write the data directly into your code. Write – it – down. OK? When your goal is to test file operations, but you spend all your time trying to get some form to work, then there's something wrong with your priorities.

As I already explained to you, I'm not interested in kindergarten code. Come back when you're desparate enough to switch to real programming. Right now, you ask a lot of questions, but you clearly don't listen to answers.

Yes, you should change the code. Learn how to use PDO correctly, in particular how to safely pass PHP values to queries through prepared statements. Also learn when and how to apply HTML-escaping. Never trust user input. Always expect invalid or even malicious data. This applies to the Internet, an intranet and even local applications. All of them must behave reasonably under all circumstances.

This is a 5-minutes job and standard procedure even on the cheapest personal home pages. I'm actually surprised that those home-made bad-words checks are still a thing. I thought they died in the 90s. Either way, if you're going to keep the mail() stuff, then you might as well surrender. This is like putting up a sign that says “I've left the front door open, plz don't break in”.

Split the project into small parts instead of writing one big block of code only to find out that it doesn't work and that you cannot debug it either. If you're mostly interested in the PHP part, then forget about JavaScript for now. Write a minimal PHP script which JSON-encodes test data and writes the result to a file. <?php $test_data = [ 'foo' => 'bar', 'qux' => 'quux', ]; $encoded_data = json_encode($test_data); // file handling code goes here You can easily var_dump() every single step and test the code until you know it's correct. Note that writing JSON data to files is a very nasty and cumbersome approach, especially if you want to do it correctly (i. e. without messing up your data). As soon as you got past the Hello-world stage, you should look into actual database systems.

If you're talking specifically about databases, the Wikipedia article is actually a good start, because it provides an overview, many examples and lots of keywords for further research. The MariaDB developers have also published several tutorials which explain the basics in a very practical manner. If you prefer books, I can recommend the introductions from O'Reilly. And then there are countless online tutorials which usually aren't too bad. For learning SQL, it doesn't really matter that much what you read. The important part is to read at all, think critically and try to get a feeling for what is right and what is wrong. As a concrete example: In your above one-table layout, you keep repeating the information that the F-150 is a truck from Ford over and over again. This should make you doubt the whole thing. Isn't this a waste of space? What if you end up with conflicting information? What if you have to update or delete all the data? Those questions more or less naturally lead to the concept of normalization. But the most important insight is that the relational model works in a very specific way and is designed to store data unambiguously and efficiently. It's not like an Excel spreadsheet where you store anything you want in any way you want as long as human readers can make sense of it. Again a concrete example: You want actual booleans, not informal, unrestricted strings like “Y”/“N”. If the application code has bugs (which happens) or Jimmy touches the database, you quickly end up with empty strings, nonsensical strings and plenty of variations: “Yes”/“No”, “y”/“n”, “0”/“1”, ...

You should definitely do an extensive performance analysis (benchmarks, checking the query plans, maybe profiling) before you jump to the conclusion that a hack is needed. There are many ways to improve query performance, and there are just as many ways to screw it up (bad indexes, poorly written queries etc.). This has to be objectively checked. MySQL also isn't the only database system. If the data specifically falls into the big-but-dumb category, chances are there's a better solution. That would be the second step. Only if you've maxed out absolutely everything and still can't get a decent performance, then you might consider breaking the rules. But right now, I'm not convinced at all.

Let's turn that into <a href="<?= html_escape('events.php?'.http_build_query(['id' => $event['event_id']]), 'UTF-8') ?>">Link text</a> /** * HTML-escapes a string, so that it can safely be included in simple HTML contexts * * @param string $raw_input the string which should be escaped * @param string $encoding the character encoding of the input string * * @return string the encoded string */ function html_escape($raw_input, $encoding) { return htmlspecialchars($raw_input, ENT_QUOTES | ENT_SUBSTITUTE, $encoding); } The http_build_query() function takes care of turning a set of parameters into a syntactically valid URL query HTML-escaping makes sure the URL can be inserted into an HTML context without breaking anything Following standard naming conventions (e. g. snake_case instead of CamelCase) avoids confusion and interoperability trouble

I like people who are trying to learn. What I find irritating is to see somebody run into the exact opposite direction after I just explained an approach. If you need clarification – no problem. You're also welcome to criticize my ideas and come up with better ones. But you actually suggested the two-table layout yourself, I confirmed it, then you suddenly decided it's the wrong approach and went to something which doesn't even look like a database table. It also seems to me that a lot of programmers (definitely not just you) skip the basics, jump straight to complex applications and then expect to get the job done with a few ad-hoc fixes. As a result, an enormous amount of time is spent on going through the same basics over and over again instead of actually discussing the application – which would be a lot more interesting for everyone.