Jacques1

mysqli::set_charset()
 
Also make sure that your HTML documents are declared as UTF-8 (with a Content-Type: text/html;charset=UTF-8 HTTP header and a <meta charset="UTF-8"> element).

You can't override a method and then change the signature entirely. This wouldn't make any sense, because one of the core principles of OOP is that you can substitute superclasses with subclasses. You're trying to violate this principle, because $obj->display() would work for instances of Base but not for instances of Editor.
 
What you can do of course is make the parameter optional in both classes and throw an InvalidArgumentException when null is passed to the method of Editor.
 
Or try to set up a less confusing architecture (e. g. two different methods).

First off, I would not use a global pool of IDs, because this is complex and makes it very difficult (if not impossible) to set up a proper database layout with foreign keys. Right now, your ratings don't point to any real entities, you're just storing arbitrary numbers. If I wanted to “rate” the ID −456, I could do that, which is obviously a problem.
 
A far better approach would be to have plain old per-table IDs and different tables for the different ratings. Even a single table with a type column (i. e. no referential integrity) is better.
 
If you absolutely must have global IDs, use random UUIDs (MySQL even has a function for that). Your uniqueness checks don't work.

The benefit of using composer is that you get automatic dependency management. If you rely on a phpunit.phar file, you have to manually download it on every system and make sure it's the right version.
 
To get started, you can read existing tests of (simple) GitHub projects. If you don't like the PHP-specific resources, you can also switch to Java unit tests which work very similar.

I have no idea what a “classified post” is, but if you want an actual countdown, you need JavaScript.
 
For example: Make an Ajax request, use PHP to calculate the number of seconds until the next possible submission, then start a JavaScript timer which shows and counts down those seconds. There are thousands of example scripts.

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.