Best Practices concerning Includes and SQL Connect Strings

Question

I'm just starting to learn PHP. I have three random questions about PHP and one question about Code Review. None of them are technical questions ("will this work?"); they're best practices questions ("is this the best way to do this?"). Can you offer advice?

1. I put commonly used data in separate files and use include to insert them into other pages. This avoids typing the exact same code into dozens of files. Is that considered a best practice? Is there a better way to organize common page elements? An example: A file named footer.php:

   <?php echo "<p>Copyright Michael</p><p><a href="index.html">Go home</a></p>" ?>
   

   And a snippet that's in all my other files:

   <div id="footer"> <?php include "footer.php ?> </div>
   

2. What's the best way to store a MySQL connect string? I saved it in a separate "util.php" file. It reads something like:

   <?php $con=mysqli_connect("localhost","admin","password","devDatabase");
   if (mysqli_connect_errno())
   {
       echo "Failed to connect to MySQL: " . mysqli_connect_error();
   }
   ?> 
   

   All files that connect to the db have:

   <?php include "util.php" ?>
   

   Is than an efficient and/or secure way to store the connection string?

3. What PHP frameworks do you recommend? I'm trying to get a solid understanding of PHP/Javascript/MySQL for basic web design. After that, should I select a particular PHP framework? Or should I skip PHP and move to a newer language like Ruby on Rails?

Finally, can I get feedback by posting my URL here? If I list www.mynewsite.com and post the code for the main PHP files, could I get general feedback on the site?

Answer 1

1.) What you do here is to extract code used in several locations into a shared file. Instead of describing what do to you refer to a building block to use here (the footer building block). This is a technique commonly used in other engineering areas as well (e.g. construction). This approach greatly boosts re-usability. In my opinion it helps to see software as a set of building blocks to combine (of course those are composed of other smaller building blocks as well). Many software architecture diagrams and techniques use this view.

Other principles this approach relates to are:

• Modularity: Decompose your system into modules. Each module represents one functional aspect of your application. Related is the separation of concerns: each building block has one dedicated responsibility., i.e. the rendering of the footer.
• Information hiding: Hides the detail how the footer is actually rendered and how the information is retrieved.
• Don't repeat yourself: Probably the most generic one applicable for all of real-life as well: Don't repeat the footer, refer to it.

These principles usually are applied at another level of architecture. Yet it really helps to practice them in a smaller scale. These principles (and others not mentioned) are the foundation of software development. They are very generic though and in my opinion you really can't learn them but do experience them by applying them gradually while refining your projects.

2.) For smaller projects it is probably a good idea to keep all configuration in one location. How to actually store passwords and other sensitive information is really up to your use-case: either store it in a file, in environment variables and others. Especially for web-sites it is very common to store all configuration in one file (including passwords). Of course this file should not be accessible by visitors ;).

3.) I won't give a recommendation on any particular framework or language. With experience it mostly doesn't matter. The common principles and patterns are the same for most languages and frameworks. Yet I highly recommend to have a look at other projects and try to understand them. Learn by observing how others solve problems. Start with some smaller projects (can be as simple as a single function or class) and gradually approach more complex frameworks. Among the complex frameworks written in PHP are the big MVC-Frameworks (e.g.. Symphony, Zend Framework... ) or Doctrine. The important thing really is to understand and work with those frameworks, yet abstract their approach and not just learn how this is done in this particular framework. Of course this requires a lot of research and experimentation :).

A final remark: the stackexchange sites works best for one new question per (unrelated) question (e.g. one for each, 1 & 2).