Jacques1

This is hardly MySQL syntax. When you look at the context of the query, I'm sure you'll find that it's actually a sprintf() expression with “%1$s” referring to the first argument. The negative sign in the ORDER BY clause might be a very odd way of getting a descending order (there's a DESC keyword for that). But then again, context is everything.

When you use the X-Sendfile technique, the webserver needs a physical file extension to figure out the MIME type. Without an extension, you have to do that yourself and set the right Content-Type header. This can be problematic. If you store the MIME type of each file in the database, an SQL injection vulnerability might be used to manipulate the type and turn the files into malware (e. g. by embedding JavaScript code into a PNG image and then setting the MIME type to “text/html”). If you have a hard-coded mapping from extensions to MIME types in your application, there's no such risk. But the webserver already has that mapping built in, so it's not really necessary. Appending the extension is also a matter of making the application foolproof: If a problem with the files has to be resolved by hand – maybe by somebody without a tech background –, a file with an extension will be a lot more usable than one without.

mysql_set_charset() sets the character encoding of the connection. mysql_connect(...); mysql_set_charset('UTF8');

There are dozens of potential and actual problems in your code, so you'll have to be a lot more specific. Check your PHP error log. Use var_dump() to analyze the behavior of your program. Where exactly do things go wrong? Your code contains the check if(is_resource($result)) { ... } But $result is an array, and it's completely unrelated to the query at hand. I assume that's a leftover from your old code.

OK. As I suspected, there's a character encoding issue. The data was originally serialized with the UTF-8 encoding, which means special characters like umlauts take up multiple bytes. In the serialized data, each string is declared with its physical length in bytes: s:19:"Kontaktmöglichkeit" (that's 19 bytes due to the “ö” taking up 2 bytes) However, when you retrieve the string, your application (or rather the database system) converts it to the ISO 8859-1 encoding, which means every character only takes up one byte. This leads to a mismatch between the declared string lengths and the actual string lengths. As a quick workaround, you could try to convert the string back to UTF-8 before passing it to unserialize(): // convert original serialized string to UTF-8 $serialized_data = utf8_encode($result['data']); var_dump( unserialize($serialized_data) ); This, of course, doesn't solve the underlying problem: Your database connection uses ISO 8859-1 when it should use UTF-8. What does the database connection code for this script (minus the credentials) look like?

What is SELECT ^ FROM article supposed to do?

I gave him that link already. When you set the ID attribute, make sure you're not overwriting an existing ID. This make break JavaScript code or CSS rules. So first check if the attribute exists.

You haven't read the answer. The only reason why you're stuck is because you're using a wrong approach (regular expressions). Use an actual HTML parser, and this will be done in 5 minutes and maybe 5 lines of code. Or you can spend a couple of hours on a buggy regex, but then you'll have to wait for somebody else.

Like I said, it's a bit silly. Either use a professional minifier and actually measure the benefit, or simply keep your original HTML. OK. Regular expressions are a very poor approach for HTML parsing, though. I'd use an actual HTML parser together with a slugifier to generate the IDs.

FIrst off: Why do you want to do this? None of what you've said so far makes a lot of sense. What are you going to do with all those auto-generated IDs? Which problem are they supposed to solve? And why on earth would you remove spaces from your HTML tags? Optimizing a website is a valid goal, but this is rather silly. Have you ever actually measured the performance gain? A much more effect approach, for example, would be to stop cluttering your HTML markup with inline styles and using a proper external CSS hierarchy.

The code you've copied and pasted is very poor and insecure. I suggest you throw it away, learn the basics of secure file uploads and then write your own code. This should also clear up the confusion, because you'll actually understand the procedure. This topic has been discussed many times on the forum, and there are plenty of resources all over the Internet, so this is just a quick overview: Validate the file extension with a whitelist of permitted extensions. Generate a purely random filename and append the validated extension (make sure you don't end up with a double extension). You may store the original filename in your database, but do not actually use it, because it won't be unique. Store the file outside of the document root so that it cannot be accessed directly. Then write a simple proxy script which serves the files upon request. It's recommended to use the X-Sendfile technique instead of reading the file content with PHP. If possible, create a separate subdomain like uploads.yoursite.com for the proxy script. This will isolate the potential insecure uploads from your main application. Use Content Security Policy for additional protection. It's very important to understand that letting people upload files to your server is inherently risky. A cursory file extension check like in the script above is not enough and may leave both your server and your users wide open to various attacks. So don't just copy and paste code your found somewhere on the Internet. Learn and understand the procedure.

I'm talking about the serialized string. An array is not a string, trying to get its string length obviously makes no sense. This back-and-forth is getting tedious, so I suggest you write the serialized string to a file and attach it to your post: $serialized_data = $result['data']; if (unserialize($serialized_data) === false) { file_put_contents('/path/to/file', $serialized_data); exit; } The file path must be writable by the webserver, so make sure that's the case (when in doubt, use something like an upload directory). Please attach the file, don't just post its content. Also check the PHP error log. It should say exactly where the deserialization failed (“Notice: unserialize(): Error at offset ...”). So I need two things: A file containing the erroneous serialized string (which you get from the code above). If available, the corresponding notice from the PHP error log.

What's the strlen() of the serialized data? What does mb_detect_encoding($result['data']) say for the serialized data? Can you deserialize the file I attached? wp_serialized_fixed.txt

There's a string which is incorrectly declared to have 21 characters but only has 17 due to some kind of truncation: "i.oppliger@....ch" I assume you did that to anonymize the data? Since you have an umlaut in the string (“Französisch”) there could be a character encoding issue. What's the exact strlen() of the encoded data? It should be 1952. Which character encoding does your database connection use? Execute this query within the Wordpress script and post the output: SHOW VARIABLES LIKE 'character_set%';

Take one of the records that yield false and attach the complete record (assuming it doesn't contain any sensitive data).

This is too vague. Reduce $result['data'] to a minimal example and post it here. Then show the result you got and explain why that isn't the result you expected.

What exactly do you not understand? Start with the form: <input type="checkbox" name="sr_list[<?= html_escape($row['genid']) ?>][sr]"> <input type="checkbox" name="sr_list[<?= html_escape($row['genid']) ?>][pr]"> <input type="text" class="form-control input-sm" name = "sr_list[<?= html_escape($row['genid']) ?>][comment]" value="Receive"> This gives you an associative array under $_POST['sr_list'] where the keys are the genid numbers and the values are the corresponding form parameters: // assuming 42 and 50 are genid numbers [ '42' => [ 'sr' => 'on', // the exact value of the checkbox is irrelevant; if the parameter exists, the box has been checked, otherwise not 'pr' => 'on', 'comment' => 'Receive', ], '50' => [ 'sr' => 'on', // no "pr" parameter means: not checked 'comment' => 'Hallo' ] ] There's not much more I can do. I know nothing about the platform/framework you're using, and the cryptic names aren't helpful either.

Since unchecked boxes are completely omitted from the request, you can't use implicit indexes with “[]”. PHP has no chance of figuring out which of the remaining parameters belongs to which group. Use explicit indexes: <input type="checkbox" name="check_one[<?= html_escape($id_of_target); ?>]" value = "1"/> In fact, I strongly recommend you avoid implicit indexes altogether, because it's rather fragile and can lead to nasty surprises (as you just saw). Then replace your vulnerability-ridden query with a proper prepared statement (as already pointed out by ginerjm) and use isset($check_one[$i]) ? 1 : 0 to get the right SQL value.

Your test script currently shows a complete dump of all customer requests. I suggest you take that offline immediately.

No, that's the exact same button as in the user profile (I'm talking about “Find content” in the top right corner, not “Recent Posts”). Anyway, most user content certainly fits into the 40 pages limit, so that should be good enough. The only reason I mention the limit is that I occasionally had trouble finding older posts myself.

Restart Apache and then check the script again. You're running PHP as an Apache module, which means changes in the PHP configuration won't take effect until you reload the entire webserver.

No SOAP in there.

It's also in the user profile in the top right corner. The button still only shows the most recent posts, though.

What's the output of phpinfo() when executed through the webserver? That is, you need to create a script and request the URL with a browser. Are you sure you've reloaded Apache, PHP-FPM etc.?

The point of generating random filenames is to prevent new uploads from overwriting previous uploads. Your users won't choose globally unique names, so that's your job. When the files are served, it makes sense to use the original filename. Use the above mentioned X-Sendfile feature so that the webserver can handle range requests for the file.