Jacques1

You can make the webserver accept additional information after a physical path. It's basically a poor man's pretty URL.

Encrypt specific sensitive data, not everything. Then you don't have this problem. No, you cannot make the MySQL cryptographic functions compatible with your current script, because MySQL only supports the insecure ECB mode. Another major problem is that you would have to transfer the plaintext key to the database system over and over again, which massively increases the risk of exposing it. For example, if query logging is enabled, the key will appear in the log. So do the cryptography in the application. There are also problems with the implementation: You should avoid deserializing data at all cost, because this can be used for attacks like object injection. Use a standard data format like JSON, YAML or XML. AES-CBC only provides confidentiality, it does not protect the integrity of your data. This is particulary bad when data manipulation can have serious consequences (like in the case of deserialization). Unless you need compatibility with other parts of the application, you should consider switching to a high-level library like libsodium and an algorithm which provides authenticated encryption like ChaCha20-Poly1305.

The file() function by default always keeps the original newline character at the end of each line. So this has nothing to do with the particular file content. If you want to get rid of the newlines, you need the flag. In the long run, you should abandon those very fragile and limited plaintext files. Either use a proper file format (JSON, YAML, XML, ...) or an actual database system (MySQL, PostgreSQL, ...).

Forget about the main page and use the URL http://www.sportinglife.com/football/live/vidiprinter/all/ It provides a machine-friendly JSON representation of the data. In any case, make sure that scraping the website doesn't violate the terms of service. There may also be an official API where you can get the data from.

The value attributes of your options are unquoted, which means the value stops at the first space character, even if it's actually longer. Your strings from the file() call do contain trailing newline characters, so the submitted value no longer matches the real value. It's truncated. Quote your attributes and call file() with the FILE_IGNORE_NEW_LINES flag. How do you know that it's only accessible to a few people? In any case, hope isn't the right approach in programming. Learn the basics of security and make sure your code is actually safe.

This makes no sense. You're now assuming an alphabetical type followed by a numerical name, but your link above has the exact opposite (a numerical type and an alphabetical name). Again: You have it backwards. You tell us your the URLs should look like. And then we can tell you how to implement them. Guessing from your example, it seems you want this: /belts/45 So first the category, then the numerical type. Correct?

Designing the URLs is your job. “Pretty URLs” are just an abstract concept for URLs that are optimized for readability. How exactly your URLs should look like is something only you know. A good guideline is Cool URIs don't change from Tim Berners-Lee himself.

The option value isn't quoted, so any space will screw up the form. And the concept of security seems to be entirely foreign to you. You let the user choose an arbitrary file path and print the content straight on the screen, and you insert all input directly into your HTML markup. Do you not understand how dangerous this is?

You can also save a lot of code when you stop creating useless variables for values that are readily available through existing variables. For example, whenever you fetch a row, you somehow copy every single field into an extra variable. Why would you do that? You already have the row. This really looks more like a typing exercise than code. Programming is about avoiding repetition. When you find yourself doing the same thing over and over again for hundreds of lines of code, that means you need to stop and look for a smarter solution. This just doesn't happen in a proper script. And then there's the total lack of security. I haven't found a single instance of SQL-escaping or HTML-escaping. You just drop the user input straight into your queries and the HTML markup. Do you not understand how dangerous this is? Have you never heard of SQL injections and cross-site scripting?

// Moving to the right forum. This is not a math problem. Your mail headers look fudged up. There's no CR LF separator between the Content-Type header and the From header, so effectively none of them is valid. You also need to check the return value of mail() to give you an idea where the e-mail got stuck. Is it not even passed to your mail relay? Does Gmail reject it? But the real problem is that your code is ancient. I assume you've copied and pasted this from somewhere? Because this stuff is from the 90s; you shouldn't even know it when you've just started learning PHP. The mysql_* functions are obsolete since more than a decade and have already been removed from PHP. Nowadays, we use PDO. Nobody has to mess with the low-level mail() function anymore. Nowadys, we use PHPMailer (or an equivalent library). When you start writing code for the 21st century, a lot of your problems may actually go away.

You need to get rid of your inline scripts. Not only is it, again, spaghetti code. It's also a major security issue, because the browser cannot easily distinguish between legitimate inline code and cross-site scripting attacks. When all scripts reside on external domains (or at least external files), you can block inline scripting entirely and whitelist the external scripts. But when your HTML markup is cluttered with inline scripts, your only chance is to go through each one of them and either whitelist its hash or implement secure nonces. Both is a lot more difficult. So while you remove the HTML markup from your PHP scripts (which is great), you should also remove the inline styles and scripts from the HTML markup.

Your reply is two weeks late, it doesn't have anything to do with the problem, and it makes no sense. When you need to insert one item with four categories, you don't insert four items. Either you insert one item and three category associations (this is the correct way, but it requires an extra table), or you insert one item with a comma-separated list of categories (this is how the OP does it).

What?

I see you've asked the exact same question in a different forum a week ago and got the exact same response. But instead of simply reading the damn tutorial and completing the site in maybe one hour, you wait an entire week and then try the exact same question here. You're wasting your time, buddy. WordPress is easy. It's specifically designed for non-programmers. If you cannot write a simple template, then you should probably just leave the site alone.

It's fine. Pretty much anything other than inserting the data into a script context is OK.

It's all explained in the Wordpress handbook, and there are countless step-by-step tutorials.

Like I said, why don't you create a new page based on a custom PHP template? The user enters their keywords, you fetch the XML data and show the results on the page.

WTF? First off, allowing arbitrary PHP code within posts is the absolute last thing you want, because this effectively turns every single post into a PHP shell with direct access to the server. Anybody who manages to add or manipulate a post can also execute any code they want. Wordpress is already infamous for its security problems. No need to make it even worse. And why would you process form values in a post? Isn't a post something like a blog post? My blog posts contain text, not PHP code. It seems what you actually want is a page. In the corresponding PHP script, you can safely do whatever you want to do.

Not with a proper ALTER TABLE statement. ALTER TABLE records MODIFY price DECIMAL(10, 2);

If you go with data attributes, use an existing element like body (but not html, because a long attribute list can prevent the browser from finding the <meta charset> element). But, yes, that's a valid approach.

json_encode() is not secure within JavaScript code. And I might add: It's also very poor spaghetti code. If you want to read data from the server, use Ajax or put the JSON-encoded data into a hidden HTML element. Do not generate dynamic JavaScript code.

The loop creates a long string of the kind addChannel("item1") addItem("item1", dateNow); addChannel("item2") addItem("item2", dateNow); addChannel("item3") addItem("item3", dateNow); ... And this is inserted into the main script.

If it's not possible to get additional XML data into the application, you have to carefully validate/escape the input and then insert it into the script: // *not* recommended; this can lead to syntax errors and code injections $channels_script = ''; foreach ($items as $item) { /* * TODO: validate $item and make sure that it won't interfere with the script * Ideally, it should be restricted to alphanumerical characters and spaces */ $safe_item = brightscript_validate($item); $channels_script .= ' addChannel("'.$safe_item.'") addItem("'.$safe_item.'", dateNow) '; } $cdata = $xml->createCDATASection(' function init() print "inside epg" m.content = createObject("RoSGNode","ContentNode") m.top.setFocus(true) dateNow = CreateObject("roDateTime") dateNow = dateNow.asSeconds() - 2000 '.$channels_script.' m.top.content = m.content m.top.translation = [50, 300] m.top.numRows = 5 m.top.duration = 10800 m.top.nowNextMode = false m.top.infoGridGap = 0 m.top.channelInfoColumnLabel = "Hello" end function'); But again, this is for the worst case scenario.

And you need to stop copying and pasting random code from the Internet. mysqli is poor, manual escaping is poor, and printing internal error messages on the screen is really not a good idea. Did you run the PDO code I gave you? Then you need to use a prepared statement and also catch errors which are caused by duplicate Bitcoin addresses: // process POST request if ($_SERVER['REQUEST_METHOD'] == 'POST') { $errors = []; // TODO: validate the $_POST input // try to insert input; if there's a duplicate value, this will fail try { $contest_insert_stmt = $database_connection->prepare(' INSERT INTO contest_submissions (btc_address, ip_address) VALUES (:btc_address, :ip_address) '); $contest_insert_stmt->execute([ 'btc_address' => $_POST['btc_address'], 'ip_address' => $_SERVER['REMOTE_ADDR'], ]); } catch (PDOException $contest_insert_exception) { // was the error caused by a duplicate value? if ($contest_insert_exception->errorInfo[1] == MYSQL_ER_DUP_ENTRY) { $errors[] = 'This Bitcoin address has already been entered.'; } else { // a different error, rethrow exception throw $contest_insert_exception; } } }

This is a bad approach in general. You shouldn't generate scripting code, because this can easily lead to syntax errors and security vulnerabilities. I have no idea how this “BrightScript” works, but the ideal solution would be to insert the items as XML nodes (i. e. as data) and then access this data with BrightScript: <items> <item>foo</item> <item>bar</item> <item>baz</item> </items> <script type="text/brightscript"> Each item in obtain_items() addChannel(item) addItem(item, dateNow) </script> You get the idea. Is this possible?