Jacques1

The function you're looking for happens to be called REPLACE(). So do an UPDATE query and chain as many REPLACE() calls as you need: UPDATE some_table SET some_column = REPLACE(REPLACE(REPLACE(some_column, '...', '...'), '...', '...'), '...', '...') ; I hope you're not doing this regularly?

I couldn't reproduce the behaviour you describe, but this sounds like the History API.

jQuery certainly does not require you to define a new variable for each element. It supports intelligent selectors to get child elements, sibling elements etc. And if that doesn't help, you can always store information within an HTML element using data attributes. If you describe the problem, I'm sure somebody will find a more intelligent approach than tons of numbered variables.

You should avoid mixing languages altogether. Use a sepate JavaScript file instead of stuffing inline code into your HTML markup. And put the HTML markup below your PHP code to avoid spaghetti code: <?php // your code goes here ?> <!-- Your markup goes here -->

Why exactly are you worried about somebody “stealing” your code? I'm all for proper attributation, and I despise plagiarism. But I don't see the concrete problem here. If you want to put limits on what people can legitimately do with your code, choose one of the many open-source licences. If you don't want anybody to see your code, then don't publish it. That's the standard approach, and it seems to work pretty well. Personally, I'm a big fan of exchanging code without any particular restrictions. I'd rather see my own work being plagiarized than live in a society where everybody locks their stuff away. I don't want to go back to the days of right-click blockers and “Thou shalt not look at my HTML markup” warnings.

Guys, this discussion isn't going anywhere. Nobody rolled their own crypto, and nobody makes a secret of the forum software. As you can see in the bottom right corner, this site uses IP.Board. There's no need to repeat that in the announcement. There's also no need for condescending lectures on security basics. Everybody who cares about this community is fully aware of the security disaster. And we've already had more than enough rubbernecks telling us that we all suck, that PHP sucks etc. I understand the schadenfreude, but it just doesn't help. If you want to provide actual help beyond the standard bcrypt rant, contact an admin.

You need to put the parameters into an actual array, not a comma-separated string. Probably the easiest approach is to assemble an associative array with the keys being the columns and the values being the values for the SET clause. You can then create your query from this array at the very end.

I've never used CPanel, so I can't guide you through the GUI. Generally speaking: The document root is the directory used by your webserver to store public files. It's probably “public_html” in your case, so you'll want to keep your database credentials out of this folder. Otherwise you risk leaking the data. Setting the permissions, again, depends on your specific configuration. If you're using the Apache webserver, it probably runs under the “www-data” user. So you'd assign the credentials file to the owner and group “www-data” and set the permissions to something like 0400 (meaning: read permissions for the owner, no permissions for everybody else).

Your $item variable is not an array. In other words, the arguments $livro and $quant don't contain what you think they contain. To figure out what the variable content actually looks like, use var_dump(): var_dump($livro); var_dump($quant); Your code is generally a bit weird. What exactly do you expect array_fill(count($livro), count($quant), "(?, ?)") to do? I mean the two count().

Since this is just a demo, it's enough to add a small delay between the queries and make a few Ajax requests. A more sophisticated solution would be to run cURL in multiple threads using the pthreads extension.

Your code does not work. Read the post I linked to. Web applications have to handle many requests at the same time, so you can run into the following scenario: Request A and request B both choose the same e-mail address, and this address isn't used yet. Your code checks the database, doesn't find the e-mail address and tells A that it may use the address. At the same time, your code does the database check for B and tells B that it may use the address. So now both A and B get permission to use the same address. In the worst case (you have no additional UNIQUE constraint), you'll end up with a duplicate address despite your check. This isn't just a theoretical problem. You can actually test this by sending parallel requests, and you'll quickly find duplicates in your database. Of course you may try to ignore your bug if you have extremely low traffic and don't care about data integrity. But I wouldn't recommend it. Write correct code instead of trying to get away with bugs.

You don't check anything. You set up a UNIQUE constraint on the e-mail column, try to insert the new row, and if that leads to a constraint violation, you know the e-mail address is already taken. See this post: Using UNIQUE constraints to prevent duplicate values. Also see my comment in your previous thread: Your code is wide open to SQL injection attacks.

Yes. A form using the POST method. Links aren't meant to change anything.

This has nothing to do with variables. It's simply that you can use the index notation to access characters in a string (which is a well-known feature).

Anyway, I agree with Psycho that trying to “validate” text causes more harm than good. The English language is much, much more complex than anything a regex could cover. Of course we can check the basic structure, but this will exclude a large amount of perfectly valid text. Who are we to decide that a text is “invalid”, anyway? People use all kinds of nonstandard language constructs, and that doesn't mean they're all wrong. Assuming that words only consist of a-zA-Z is already a misconception. What about “Raison d'être”? What about “O'Neil”? So unless you have a good reason why you want to annoy your users and force them to use some primitive subset of the English language, just forget about it.

Your problem isn't the refresh, it's understanding the basics of HTTP. GET requests are not supposed to have any side effects. They are meant to get a resource (hence the name). So when you use URLs to change data, you're already doing it wrong, and it's no wonder you run into all kinds of trouble. Fix this by using POST requests and the PRG pattern, and a lot of those problems will actually go away.

Your code is wide open to SQL injection attacks and leaks critical information about your database system by showing all internal SQL errors to the user. I strongly recommend you learn the basics of MySQLi before you even think about writing a complete application. How to safely pass PHP values to a query with prepared statements. How to report SQL errors.

This is, again, nonsense. Please learn the basic syntax of regular expressions before you try to give advice. The \w character class includes the underscore and digits, which means you consider “_ _!” or “123 123.” valid English sentences. This obviously makes no sense. What's the point of “{1,}”? I guess what you're looking for is the + quantifier. Why are you escaping characters that don't require any escaping in the first place? Characters like “,” or “;” or “:” can be written down verbatim, you know? They don't have any meaning in regexes. Why do you require more than one word? “Go!” is a valid sentence, don't you think?

That regex makes absolutely no sense. For example, this will match aaaa< but not This is an English sentence, definitely. And what is the quantifier combination “{1}+” supposed to do? Sentences look more like this: <?php $word = '[a-zA-Z]+'; // a single word $words = "$word( $word)*"; // a sequence of space-separated words $sentence = "$words([,;:] $words)*[.!?]"; // a sentence $sentences = "/$sentence+/"; $testInput = 'This is an English sentence, definitely. And another one.'; var_dump(preg_match($sentences, $testInput));

Besides that, handling “large” amounts of data efficiently is the whole point of a database system. If you experience performance issues, that's most likely due to poorly written queries or missing indexes. What does “large” even mean in this context? 1,000 rows? 10,000 rows? 100,000 rows? That's laughable.

Don't use w3schools as a reference. This site is infamous for spreading wrong information, dangerous code and plain nonsense. They seem to have improved their tutorials a bit, but they still output unescaped variables and display internal error messages all over the place. A much better resource for anything HTML-related is the Mozilla Developer Network.

Place it outside of the document root and make sure it's not readable by anybody but the webserver.

Did you read my explanation in #22? I'd suggest that you forget about your current code for now and start with two fresh PHP scripts. The first script generates a token, sends it by e-mail and stores the hash in the database. Try it.

Apart from the problems mentioned above, there's nothing inherently wrong with including the password hash in the WHERE clause. The only reason I could think of is that one might want to distinguish between a nonexistent account and a wrong password. Or maybe it was considered some kind of micro-optimization.

All modern password hash algorithms use salting, so it's impossible to recalculate the hash from the user-supplied password alone. bcrypt actually has three input parameters: the password the cost factor the 128-bit salt The cost factor and salt are encoded within the bcrypt hash. To verify a password, you need to load the entire hash into PHP and use password_verify(). This function extracts the original parameters, hashes the password with those parameters and compares the resulting hash with the original hash. Some database systems like PostgreSQL have bcrypt built in, so you theoretically mimic the old-school queries by providing the username and the plaintext password: SELECT user_id FROM users WHERE username = :username AND crypt(:password, password_hash) = password_hash ; However, this is not advisable, because sharing the password with the database system increases the risk of leaking it. For example, the password may appear in the query log, or it may be caught by an eavesdropper in case of a remote database.