Jacques1

Then your templates are full of cross-site scripting vulnerabilities. If you use plain PHP, you must HTML-escape every single variable, by hand. Forgetting it just once can compromise the entire application. Security is the biggest problem when misusing PHP as a template engine. A “PHP template” is technically a full-blown application which may do absolutely anything: issue shell commands, write files, communicate with other hosts. Why on earth should a template have this power? Its sole purpose is to generate HTML, so it shouldn't do anything other than that. PHP also lacks modern templating features like inheritance and custom syntax. You're stuck in the late 90s when PHP was a cute little language for your personal homepage. Last but not least, the PHP template syntax is just arcane. Don't tell me that you prefer this: <?php if (!$blog_posts): ?> no entries <?php else: foreach ($blog_posts as $blog_post): ?> <li><?= html_escape($blog_post['title']) ?></li> <?php endforeach; endif; ?> over this: {% for blog_post in blog_posts %} <li>{{ blog_post.title }}</li> {% else %} no entries {% endfor %}

Are you sure you're referencing the same view object in both locations and running the code in the right order? Which frameworks? Why should the controller choose JavaScript files? That's clearly a task of the presentation layer. But even if you somehow enncounter a scenario where the controller actually needs to make that decision, you could just pass an array of URLs to the view. I can't see the justification for spending such an enormous amount of time on those HTML helpers. They aren't very useful most of the time, they might actually distract you from better solutions, and they can always be emulated. Feel free to try this approach, especially when the framework is mostly for learning. But don't spend too much time on it. Instead of literally reimplementing the complete HTML standard, pick a few elements (scripts and styles make sense) and do a reality check before you continue.

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.

You cannot leave the algorithm open and then start setting algorithm-specific parameters like a “cost”. For example, Argon2 has no “cost” at all, it has multiple parameters for the time, the memory and the parallelism. So if you want to set the hash parameters (as the manual specifically recommends), you cannot use PASSWORD_DEFAULT. You must explicitly define the algorithm. Or in other words: If you go with PASSWORD_DEFAULT, you have to accept any choice made by the PHP core developers. And the chosen parameters are necessarily weak, because they have to work on even the weakest servers.

The manual says the exact opposite: http://php.net/manual/en/function.password-hash.php#refsect1-function.password-hash-notes Adjusting the cost is critical for security. If you skip this step, you give up a major advantage, namely the ability to dictate the effort required for an attack. And what exactly is the problem, anyway? You certainly have a configuration file somewhere. Add the hash settings, choose reasonable defaults according to how critical your application is, optionally adjust the settings when the application is deployed in production, and that's it. The chance that you have to update the algorithm within the lifetime of the application is neglectable. bcrypt has been around for almost 20(!) years, and it's still perfectly fine. In fact, I would not switch to a new algorithm until it has proven itself for many years as well. There's always a chance that the algorithm itself has fatal flaws, and the implementations will definitely have tons of bugs during the initial phase.

If you want to conduct a surprise beta test with all of your customers, feel free to try out Argon2. As somebody who knows a bit about the bug-ridden history of password hash algorithms, crypt() and the hash API, I wouldn't recommend that. And if you mean “out of date” as in “ext/mysql is out of date since 12 years, guys, please update your code”, relying on PASSWORD_DEFAULT means that people will run around with a cost factor of 10 for the next decade.

Don't use PASSWORD_DEFAULT. The whole point of modern password hash algorithms is that they're adaptable, allowing your to set the parameters specifically for your hardware and your security requirements. When you just go with the default parameters, you get the lowest common denominator, not the strongest possible settings. The bcrypt algorithm (which is currently the only available algorithm) also cannot handle long input. So a more reasonable setup would be: <?php /* * Adjust the settings to your hardware and security requirements. A high cost factor increases the hash strength, but * it also increases the waiting time for users and the risk of denial-of-service attacks. Targeting a one second delay * should be an acceptable compromise for standard user accounts. Critical accounts like administrators should have * more aggressive settings. */ const PASSWORD_HASH_ALGORITHM = PASSWORD_BCRYPT; const PASSWORD_HASH_PARAMETERS = ['cost' => 12]; // example const PASSWORD_MIN_LENGTH = 8; const PASSWORD_MAX_LENGTH = 56; // bcrypt is limited to 56 bytes of input $password = '3b4PSv1m'; // test if (strlen($password) < PASSWORD_MIN_LENGTH) { die('Password is too short, must have at least '.PASSWORD_MIN_LENGTH.' bytes.'); } if (strlen($password) > PASSWORD_MAX_LENGTH) { die('Password is too long, can have at most '.PASSWORD_MAX_LENGTH.' bytes.'); } $hash = password_hash($password, PASSWORD_HASH_ALGORITHM, PASSWORD_HASH_PARAMETERS); var_dump($hash);

This isn't funny. We're talking about a business website here. Your code will turn the server into an open mail relay which can be used by anybody to send spam and malware to arbitrary addresses, and the OP clearly doesn't have the competence to recognize that. If the code is actually uploaded, quite a lot of people are in deep trouble: the victims of the spam/malware the business which is seemingly responsible for sending those e-mails the OP, because he's the one who uploaded the script we, because it's coming from this forum you, because you've suggested it It's great that you want to help, but do it responsibly. Don't just post code you found somewhere on the Internet when you have no idea what it does. This may cause actual harm. For now, I've deactivated your post. If you want to continue the discussion, a moderator can move your posts into a new thread.

Then either learn it, or stop telling your customers that you can create dynamic websites for them.

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.

This doesn't make any sense. You cannot switch into PHP mode within a string, because a string isn't a script. It's a bunch of text. You can theoretically insert variables into strings, but then you'll quickly end up with cross-site scripting vulnerabilities (or in less technical terms: people will inject malicious JavaScript code into your page). Use HTML-escaping and string concatenation: <?php function html_escape($raw_input, $encoding) { return htmlspecialchars($raw_input, ENT_QUOTES | ENT_SUBSTITUTE, $encoding); } $name = 'Joe'; $msg = 'Hello '.html_escape($name, 'UTF-8').', welcome to my site.'; echo $msg;

Stuffing comma-separated values into a single column is wrong, and trying to do anything with this dabase layout is pretty much hopeless. Learn how to normalize your database, create a keyword table with one(!) keyword per row, and then we can help you.

You can cURL every single picture with PHP if you want to, but this is obviously the worst possible solution in terms of performance and bandwidth. Setting up a reverse proxy is trivial. Before you jump to hacks, simply ask the people who run the server.

This is a standard reverse proxy setup, and the configuration for your specific webserver should be in the documentation (or on Google).

For some reason, you first create a single <option> element for the selected option and then iterate over all possible options (including the selected one). This necessarily leads to a duplicate option.

99% of the time, you shouldn't do anything with exceptions. Catching exceptions is only useful in edge cases like testing the uniqueness of a value with a UNIQUE constraint or manually rolling back a failed transaction in a database system that doesn't do it automatically (MySQL does).

So you're freelancing as a web designer, but you have no idea what you're doing and now want us to help you out for free?

That's a bad idea. First off, you'll have a hard time figuring out if the error was actually caused by wrong input (as opposed to a server-side error), and it will be even more difficult to tell what exactly is wrong. Secondly, that's just not the job of the database system. Validation happens in the application, right after receiving the input. The statement “The input might be malicious, so I send it straight to the database system to see if anything blows up” also worries me. Sure, you appearently use prepared statements (hopefully not emulated ones), but don't push your luck.

Why do you need to know that? Are you using the database system to validate the input? Don't do that. The input should be validated before you use it for any queries. And to give you a literal answer: By not putting everything into one try statement.

What does this have to do with any of the suggestions? We've offered two possible solutions, you've instead picked an approach which makes no sense. Now what?

No, because this calculation is simply wrong. When you're on page 2 with 100 items per page, you'd get an offset of 300 (when it's actually 100). There are two options: You explicitly check if there are no records (i. e. 0 pages). If that's the case, you display a single empty page, possible with a message like “No items found”, You make sure the page(!) is always at least 1, e. g. with the max() function.

Let me be honest with you: I think programming just isn't for you. I've read several of your threads in different forums, and you've never made any progress. You cannot ask questions, you cannot talk about problems, you cannot learn. In the end, it's always “I don't understand”. I think your only chance is to find somebody who literally sits down with you and shows you what you need to do.

42

You cannot have a negative offset, so you need to fix your calculation or add a special case to prevent the offset from becoming negative. The page is currently calculated as $page = min($pages, filter_input(INPUT_GET, 'page', FILTER_VALIDATE_INT, array( 'options' => array( 'default' => 1, 'min_range' => 1, ), ))); If there are 0 pages, the page is calculated as 0, and the offset $offset = ($page - 1) * $per_page; becomes negative. I'd say the $page needs a minimum value of 1.

The code you claim to have “written” is copied and pasted from another user without any attribution. If this is homework, you're now screwed.