Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

1 Neutral

About JacobSeated

  • Rank

Profile Information

  • Gender
  1. Thanks, this is much appreciated. It actually looks like you are right, and this is the default behavior. Maybe this is better documented here, at least for PHPMailer: https://packagist.org/packages/phpmailer/phpmailer Use statements also seem to work. It looks like the vendor/project part is what is listed in composer.json, in the "require" section. I wonder if there is a "standard" way to include this in my index.php file, so I do not have to write all those use statements? I read somewhere else that the vendor/composer/autoload_namespaces.php is supposed to update an array automatically, but the array in my file is just empty. Not sure if that has something to do with it? In any case, this is not much different than how I do things in vanilla PHP, so it does not bother me too much; except, I have to sometimes guess at the right framework/path, since it does not seem to be documented in some cases. I can see that some other packages still mention writing new someName(), without clarifying the part about namespaces (vendor/project).
  2. Hallo, I have a strange problem with a freshly installed composer project that is not loading the dependencies as the documentation states it should. I just made a new directory (www/site/test/), which has a index.php file, and I want to be able to use composer-installed dependencies from within the index.php file, inside the test folder; is this the wrong way to do it? Do I need to place my project root somewhere else for it to work? Dependencies are installed like this: composer require phpmailer/phpmailer For some strange reason, the autoloader is not loading the dependencies, and I simply get a class not found, without any explanation as to why it was not found. The thing is, I can get it to work by resorting to crazy hackery like: new PHPMailer\PHPMailer\PHPMailer() But the documentation clearly states that I should be able to do new PHPMailer() - hope this makes sense. This is what I have in my index.php: ini_set('display_errors', 1); ini_set('display_startup_errors', 1); error_reporting(E_ALL); // define('BASE_PATH', rtrim(preg_replace('#[/\\\\]{1}#', '/', realpath(dirname(__FILE__))), '/') . '/'); // require BASE_PATH . 'vendor/autoload.php'; require __DIR__ . '/vendor/autoload.php';
  3. You do not have to redirect the user after submitting a form (handling a POST request). An easier, and often better, way to show the user whether the data was accepted would be to tell them on the submit location itself. You could also add a back button to allow the user to safely return to the previous page after reading the status message. I know this is probably just a basic example, but you should also remember to validate your POST fields.
  4. XMLHttpRequest may be old, but it is not going away anytime soon. The main problem I had was the asynchronous "callback" hell of JavaScript, especially coming from a PHP background. You can not easily return the result of a HTTP request to the calling script. Instead, you have to use a callback function to deal with the response data. Afaik, fetch makes this easier, since it can wait for a "promise" to be fulfilled (a server responding). I Have not really used it much, but now that I got XMLHttpRequest working with callbacks, I am not planning on changing it. Probably should look into it.
  5. You will probably not get a complete answer on a forum, as this is a fairly large and complex topic. People are writing entire books on OOP best practices and design patterns, and many of us are still learning about these things while trying to develop and maintain existing projects. I think you will find that Dependency Injection is hugely beneficial, even just on personal projects, at least this is my experience after I started using it. At first it is not very obvious, but it should become more obvious as you continue using it. The thing is with OOP, it kinda forces you to consider the overall design of your application, and if you also follow DRY (Don't Repeat Yourself), then you will almost automatically force yourself into thinking about the design patterns. Do not expect perfection from the start. It is hard avoid writing ineffective code while learning, but don't stop thinking about your solutions and best practices. You can always re-organize things as you learn. What I personally found, is that inheritance (extends) are bad, because it couples your code and makes it harder to re-use. Instead, I am now using DI almost exclusively. Chances are that you will regret using "extends" because of following DRY, and when later realizing that you could re-use that code somewhere else. If you want to re-use a class that extends another class, then you are forced to instantiate the whole object. Not only is that ineffective, it is also not always possible, since some of that code might connect to a database or API which you do not need.. Another thing that is bad, which you pointed out yourself, is instantiating dependencies (classes) inside the class that relies on them. I used to do this for a very long time, thinking it made it easy to instantiate the classes without having to worry about instantiating the dependencies from my composition root. This is true, to a certain extent. But, it also creates a hard-coupling which makes it impractical to maintain and re-use the code as your project grows—even within your own personal project. So, no usage of new inside other classes, unless you use it in a factory class 🙂 When your dependencies themselves have dependencies, it will be impractical to instantiate them inside the constructors of classes, since you will have to update every single class if one of the dependencies changes its dependencies. Finally, it also takes more mental energy and time to assemble an object if you need to run tests on it. If you must have code duplication (usually a code-smell), then you can also consider using traits. A trait is basically a copy/paste of code that is shared by multiple classes. Now we are just discussing the code aspect, but your file system structure is just as important in keeping things simple. Hope this helps, and please note I am no expert, I am still learning about all this myself.
  6. Also, escaping in and out of HTML like this is kinda old fashioned. These days you may want to keep your HTML separate from PHP. Personally I limit myself to placing only variables in my HTML. So, no conditional logic in the HTML itself, which makes it very clean and easy to maintain. If using heredoc, you can use curly brackets around variables. I.e.: $tpl_content = array('title' => 'test', 'article_body' => 'hallo world'); $template = <<<_TEMPLATE_ <!doctype html> <html> <head> <title>{$tpl_content['title']}</title> </head> <body> <article> <header> <h1>{$tpl_content['title']}</h1> </header> {$tpl_content['article_body']} </article> </body> </html> _TEMPLATE_; // End of Template I wish I had learned this early on myself, as it could have saved me many hours of spaghetti hell.
  7. Wordpress has its own file handler (wp_filesystem), which is the official way to deal with the file system in WP. However, WP developers will often recommend you use the database to store things – probably because they feel it is more secure. But, the file system is sometimes a better choice. Many WP developers will not like it if you use bare file- functions such as file_get_contents in PHP. I personally do not mind. In fact, I would like to warn against wp_filesystem, since it does not seem to handle concurrency and file locking, which means data can be lost if two users tries to access a file at the same time. Reading is typically not a problem, but can be if someone happen to write to a file at the same time as a file-read. wp_filesystem also introduce other problems, such as prompting users for credentials to upload files via FTP if they do not have write permissions on the server. That's not a desired behavior, so you should first check for write permissions, and then present users with an error if permissions are insufficient. Instead of using functions.php, consider making a plugin or using the Code Snippets plugin, as it will be easier to maintain.
  8. Try changing this: $query = ("SELECT * from videos"); to this: $query = 'SELECT * from videos'; Also, you should really avoid escaping in and out "<?php" and "?>" of PHP like this. Instead, keep your HTML in separate template files, and load them via require. This is also known as "views", but I prefer to call it "templates", since that makes more logical sense to me.
  9. Nope. I am talking about HTTP/1.0, HTTP/1.1 and HTTP/2.0 part that people often incorrectly hard-code in their scripts when using the header function. If you google things to do with headers, people will even tell you it does not matter which use, which is clearly incorrect. I did not know about the defaulting behavior when sending the Location header, however. I still got some old PHP code that uses the header function for sending status codes, and this code selects the protocol depending on the SERVER_PROTOCOL variable. It is a neat little DRY complaint function, so I do not have repeated header statements all over my code—that would be annoying to maintain in the long run. But thanks for letting me know about the default. Moving forward, I should probably replace my code with http_response_code though 🤣
  10. Well, if you can use the product option as an ID in a URL, you could do a simple server-sided redirect with PHP: // You could also use URL parameters. I.e.: ?product_option=real-estate $destination_url = 'https://example.com/product-option/real-estate'; http_response_code(302); // Set the status code to "302 See Other" header('Location: ' . $destination_url); // Instruct the client to perform the redirect Afaik, http_response_code automatically handles selecting the right protocol, depending on the client request. If you used header to set response codes, you should remember selecting protocol yourself. It is not enough to simply hard-code the protocol. Also, make sure to validate input on the server-side as well before communicating with the database.
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.