Jacques1

How many cases are there in reality? You definitely don't want the admin to mess with the document encoding, so the charset attribute is out of the question. Setting arbitrary HTTP options also isn't recommended, so http-equiv is irrelevant as well.
 
That leaves you with exactly two cases: <meta name="..." content="..."> (HTML) and <meta property="..." content="...">  (RDFa). 

You shouldn't replace the error setting. You should have both: Turn off emulation, turn on exceptions. Also consider setting the default fetch mode (e. g. to PDO::FETCH_ASSOC).
 
 
 
 
Now you need two separate MATCH conditions (as explained above):
WHERE MATCH (items.item_title) AGAINST (:title_query IN BOOLEAN MODE) OR MATCH (brands.brand_name) AGAINST (:brand_query IN BOOLEAN MODE) You need two parameters :title_query and :brand_query, because the same parameter may not appear more than once. But of course you can bind the exact same string $search_query to both parameters.

It does match in PHP:
<?php const PHONE_REGEX = '/\\A(?:\\+?234|0)?(?:704|803)\\d{7}\\z/'; $input = '2347048134704'; var_dump( preg_match(PHONE_REGEX, $input) ); Every regex engine has its own syntax flavor, and those backslash escapes won't work well outside of a PHP string. So test this with PHP, not some regex site.

<?php

$raw_data = ...;

$structured_data = [];
foreach ($raw_data as $entry)
{
$structured_data[$entry['state']][$entry['county']][] = $entry['zipcode'];
}

var_dump($structured_data);

The code is OK, but it relies on implementation details and may break when libsodium changes its default algorithms.
 
Since the encryption function simply concatenates the nonce and the ciphertext to produce the output, the only way to tell those substrings apart is to rely on a specific length of the nonce. But this length may change at any time. When it does, your application won't be able to decrypt anything until you've figured out which libsodium version you need for your legacy ciphertexts.
 
A more robust and future-proof solution would be to store the nonce and the ciphertext in separate fields and add an extra column for some kind of algorithm identifier (or the libsodium version):
\Sodium\version_string(); Alternatively, use a specific algorithm so that you're not dependent on any defaults.
 
If you need a single string, choose an unambiguous format. For example:
<version identifier>:<Base64-encoded nonce>:<Base64-encoded ciphertext>

We've proposed three different solutions. So what exactly is wrong with those?
 
And as a fourth option, PHP has a statistics extension with a function for calculating the Poisson distribution.

The offset is 0-based, so starting at 1 will skip the only row.
 
A GROUP BY clause only makes sense when you're using an aggregate function like SUM() or AVG().

We don't hand out code.
 
If you look at the manual, you'll see that there's a third parameter for a context which can be used to supply additional data. And the HTTP context has a header option for custom HTTP headers.

The code is currently too trivial for any kind of meaningful feedback.
 
You have an HTML form, hard-coded dummy credentials and a few session values. That's great, but it doesn't really show anything. It would be a lot more interesting if you had an actual log-in system with a database and password hashes.
 
Until then, all I can say is this:
Learn and apply the basics of security as early as possible, especially when you write a log-in form. This includes HTML-escaping values before you insert them into your HTML markup so that an attacker cannot inject malicious JavaScript code. Keep PHP and HTML separate. It makes no sense to do session management in the middle of the body element. You should have a block of PHP code on top of the script and then all HTML markup at the bottom. The only time you use PHP within HTML is when you need to display dynamic data (like the username from the session). The register button which changes the location through JavaScript is odd. Use a plain old link instead. When you redirect the user with a header() call, you must stop the script with an exit statement. Otherwise the code will keep running, which can have dangerous side effects. Don't use spaces in URLs (or other characters which have to be encoded), and don't mix lowercase and uppercase letters. “Rede%20Social” is difficult to read and just ugly. Why not “rede-social”?

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.

Your output doesn't make any sense at all. The XML declaration is fudged up, the tags are wrong (since they've been changed to all-lowercase), and the output shouldn't even be formatted.
 
Either you haven't provided your real code, or there's something which messes with the XML output.
 
This is the raw output of $xmlHandler->SaveXml() after enabling formatted output:
<?xml version="1.0" encoding="UTF-8"?> <RootNode> <NodeLevel1>Text1 - This node one has text</NodeLevel1> <NodeLevel2>Text2 - Next node Level3 level is not gonna have text<NodeLevel2_1>Text2_1 - This node will be a child of Level2, everything fine</NodeLevel2_1></NodeLevel2> <NodeLevel3/> <NodeLevel4>Text4 - This node should be on same level like 3, 2 & 1, but instead it's a child of Level 3 (?!?!?!?!)</NodeLevel4> </RootNode> If you get something else, save the return value of $xmlHandler->SaveXml() in a file on your server and inspect that file.

When the owner of a file is root:root and the permissions are set to 0640, then by definition nobody other than root can read the file. This is how Unix permissions work and have always worked.
 
In general, scripts should never be owned or writable by the webserver, because this makes them vulnerable to malware infections. They should be read-only. Set the owner to root, the group to www-data and the permissions to 0740.
 
 
 
5 means read + execute. You need write + execute, i. e. 3. But don't allow the webserver to create files within the main application directory, because this again can lead to the injection of malicious scripts.

What exactly is the problem? As far as I can tell, the function definition is just hard-coded text, so all you have to do is put that text into a string (preferrably with a nowdoc):
$cdata = $xml->createCDATASection(<<<'INIT_DEF' function init() print "inside epg" m.content = createObject("RoSGNode","ContentNode") m.top.setFocus(true) dateNow = CreateObject("roDateTime") dateNow = dateNow.asSeconds() - 2000 addChannel("ABC") addItem("ABC Show ", dateNow) 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 INIT_DEF );

Why do you need to get data back into the form? If you use Ajax, the form content doesn't get deleted at all (unless you do that yourself).

After 6 years, it's about time you meet Bobby Tables.
 
And what's the matter with all those variables? Why can you not use $_POST directly?
<?php // create and execute a prepared statement to prevent SQL injection attacks $registerStmt = $dbh->prepare(' UPDATE register SET fname = :fname, lname = :lname, -- ... WHERE id = :user_id '); $registerStmt->execute([ 'fname' => $_POST['fname'], 'lname' => $_POST['lname'], // ..., 'id' => $get_id, ]);

You're trying to call $this->prepare() within your SPOP object (whatever that may be), but it doesn't have a prepare() method. I'm sure you actually meant something like this:
$this->db->prepare(...) ^^^^ or whatever the attribute with the PDO instance is called

You need to narrow the problem down. Right now, there are way too many classes and methods involved, most of which we don't know and don't need to know. Where is the problem? In Head? Script? Placeholder?
 
In a properly designed OOP infrastructure, objects can be tested individually. Do that, preferrably with automated unit tests.
 
Your code is also bloated and relies too much on magic. Why on earth does the Head class need 20(!) lines of code to instantiate two classes? And is that all the class does, hold two unnecessarily hard-coded class references which make it impossible to use any other script class?
 
The whole approach seems questionable. You're appearently trying to reinvent HTML in an object-oriented manner, and the only thing which sets you apart is that Destramic-HTML requires 10 times as many lines as plain HTML. Have you considered using an actual template engine like Twig? OOP is great for many tasks, but it's horrible for describing the structure of a document. That's what declarative languages like HTML are for.

When you skip the HTML-escaping, then, yes, the code is vulnerable.
 
Never insert input directly into an executable context, be it an SQL query, an HTML document, a shell command or whatever.

A 404 error means that a file could not be found. So either your jquery-3.0.0.min.js script doesn't exist on the server at all, or you've put it into the wrong location. To match the URL, it must be located next to the index.html file:
src="jquery-3.0.0.min.js" If you want it to be in your "js" folder instead, you must adjust the URL:
src="js/jquery-3.0.0.min.js"

You certainly don't want to open a new database connection for every instance of your classes. In fact, you're currently opening a new connection through the inherited constructor and then yet another connection whenever the getAll() method is called. That means a single object will flood the database server with lots of useless connection requests when it really just needs one connection.
 
Instead, create exactly one PDO instance outside of the objects and pass it to the constructor:
<?php class Model { protected $databaseConnection; public function __construct(PDO $databaseConnection) { $this->databaseConnection = $databaseConnection; } } <?php class User extends Model { public function test() { var_dump($this->databaseConnection); } } <?php $databaseConnection = new PDO(...); $user = new User($databaseConnection); $user->test(); And again:
Don't use prepared statements for purely static queries. That's what query() is for. You must disable emulated prepared statements when connecting to PDO, otherwise you're not safe from SQL injection attacks.

You're trying to compare a number (0) with a string (ufo::LARGE). In a strongly typed language, your code wouldn't even run. In a weakly typed language like PHP, the values get converted.
 
And the integer value of "LARGE" is in fact 0:
<?php var_dump((int) 'LARGE'); var_dump(0 == 'LARGE'); If you don't want this to happen, don't compare apples and oranges. I wouldn't even allow invalid values for the $mp_size attribute. Write a proper setter which rejects invalid values.

The problem of the above database layout is that it doesn't implement any of the rules, thus allowing nonsense data. For example, a single staff member with an arbitary rank (let's say the janitor) can recruit, pre-approve and approve an assistent manager.
 
You can try to fix this with lots of application-side checks, but then you may still end up with nonsense data. What if the data is inserted or edited directly? What if one day there's a bug in the ever-changing application code? You'll never know if the data you're relying on is actually valid.
 
I'd do this the other way round: Spend a lot of time on a proper database layout which will only accept correct data. This will in turn save you a lot of code and bugs.
 
I see three different recruiting cases:
The manager can recruit a person as an assistent manager or deputy manager An assistent manager can suggest a person as a deputy manager or executive, which must then be approved by the manager A deputy manager can suggest a person for an executive role, which must then be approved by both an assistent manager and the manager (or just the manager, I assume) Possible relations:
staff(staff_id, last_name, first_name, ...) assistant_managers(staff_id) deputy_managers(staff_id) applicants(application_id, last_name, first_name, ...) manager_recruitments(applicant_id, role) assistent_manager_recruitments(applicant_id, role, approved_by_manager) deputy_manager_recruitments(applicant_id, role, approving_assistent_manager_id, approved_by_manager) You can simplify the relations with views. The physical layout isn't necessarily the layout you have to use when accessing the data.
 
Note that the above data model allows an applicant to have multiple roles at once. If you want to prevent that as well, you'll need an additional table for all applications (which consist of an applicant and a role).

Why do you need a physical column for the AND operation when the value can simply be derived ad hoc? Precalculating the result is actually a bad idea, because you need to update it whenever any of F1 or F2 change. And if you forget to update it just once, you'll end up with garbage data.
 
Simple calculate the AND result in the query. You could also use a view which contains a virtual F1_F2 column that is calculated from the physical F1 and F2 columns.

What do you mean by “impersonating”? Phishing? This cannot be fixed with code, because phishing attacks happen outside of your application.
 
However, you can do something about other attacks:
The entire site including the reset pages should be delivered over HTTPS so that e-mail addresses and passwords cannot be intercepted. Use a CAPTCHA on the request page so that an attacker cannot automatically make you send a large amount of e-mails to an arbitrary address. Make sure the request page doesn't reveal if an address is registered or not. Either ask for the public username instead of the e-mail address. Or send out an e-mail for any address (if it's not registered, simply say that in the e-mail itself).  

So what is line 19 in your password.php script? There's no opening brace on line 19 in any of the official versions.
 
Is it “namespace {”? Then you're appearently running an ancient, long-abandoned PHP version (something prior to 5.3).