So, the first way most of your document is HTML with PHP stuck in, and the second way most of your project is PHP with the HTML being echoed out.

I see both mixed into projects all the time, and I'm learning as I go. Should I expect that it will always be mixed? Will a well laid-out project choose one style? WordPress seems to be mostly the first way, but I've heard time and time again how WP uses bad PHP practices.

I've learned either "only do it the first way, never the second way!" or "only do it the second way, never the first way!"

    I don't think there's one always correct answer, at least for me. It sort of depends on the size and type of project, and how much PHP and HTML code there is (and whether you're using a framework with a templating language for the views). However, I do try to avoid lots of switching back and forth within the same file, where possible. To that end, it can be useful to put some of the HTML into separate files and/or functions/methods. Then at least the main file can be fairly straight-forward PHP, making readfile(), include, and/or function calls where needed.

      I remember working with OSCommerce years ago and it was a very poorly-written open source project then. Every PHP file would start with the <HTML> tag and all the HTML markup and stuff and this made it very hard to maintain the project. There was so much redundant HTML markup inextricably tied up with the PHP code.

      It's been my experience that it's a good idea to keep your HTML markup and PHP code as separate as reasonably possible. There will probably always be some intermingling -- like you need to output a value from php as a variable in your HTML or quite frequently you need to loop through an array of PHP values, outputting a repeated HTML pattern for each element. If you're smart, you will avoid redundant code. Software projects are a lot easier to update, maintain, and patch when you reduce code redundancy. Like, ideally, you might have one header and one footer file for your entire site.

      The Model-View-Controller programming pattern aspires to this separate of markup and server logic. It's kind of a messy and abstract idea, and in practice it's never perfect, but it does encourage practices that make your code tidier and easier to maintain.

      Consider adopting a framework like CodeIgniter or Laravel. These don't offer a lot of user-facing functionality straight out of the gate, but they are popular and help streamline a lot of the operations common to most PHP projects.

      If your clients have simple site requirements and you want to install something quickly for them, you might get away with WordPress or Drupal or Joomla or something. In my experience, clients get excited when you set these up for them, but they quickly become a handicap when the client starts asking for customized features or starts complaining about the features they have built in.

        Cleaning up code and systems is almost always h̶a̶r̶d̶e̶r̶ more time-consuming than creating them in the first place, so you're wise to consider things like this. However, there's no such thing as "perfection" and there's really even no such thing as "finished", although their certainly is such a thing as working code. (Anyone recall my avatar "DONE IS BETTER THAN PERFECT", the FaceBook sign?)

        I generally try for the latter option, but will little use of echo, preferring include or require-based on logic in the PHP but using a templating-type approach at times, where PHP will get the contents of some HTML file with special tags in it that are replaced with dynamic content and then echo takes over.

          Separating the concerns of gathering the data to to display and of rendering it is good practice. Way back in the day, when hardware and software weren't as advanced as they are now, decent performance could only be achieved if one did try to start pumping html out to the client even before knowing what was going to be in the page. So you'd get lots of tag soup mixed in with database queries and looping over result sets and jumping back and forth between PHP and HTML.

          I was at one job where this had been done years ago. The customer wanted the same information to be available as a PDF document. The only way to do that directly would have been to replicate all the query and business logic while trying to disentangle it from the decisions that were made solely because the existing code generated HTML on the fly (e.g. every table was generated from a distinct query, even when the tables and much of the data were the same from one table to another).

          When I came along a few years after that I found the solution that had been implemented: a PDF request could cause a headless web browser to be fired up and told to request the page itself, along with some extra parameters that would indicate that would ape the original request parameters plus one meaning "this request is for the purposes of generating a PDF". The headless client would request the page through the normal HTTP/server mechanism and then run its "print to PDF" command, saving the file, and passing back the filename to the script that had originally launched it, so that it could retrieve the file and serve it to the person who wanted the PDF in the first place. Needless to say, those extra parameters now had to be checked and handled in multiple points throughout the page generation script even when it was being requested normally.

          If the "collect underpants" stage had been separate from the "profit" stage from the beginning, that whole "???" could have been avoided.

          Meanwhile... remember I said there were several tables in the page? If you needed to reformat those in any way you had to grovel through the entire script looking for places where the HTML was generated, and change it in each place. CSS would take care of much of that these days, but even so: imagine instead having a single function you could just throw an array at and get back a block of <table>HTML</table> to stick into the page. That way lies componentised templates.

            I don't think there's one always correct answer, at least for me. It sort of depends on the size and type of project, and how much PHP and HTML code there is (and whether you're using a framework with a templating language for the views). However, I do try to avoid lots of switching back and forth within the same file, where possible. To that end, it can be useful to put some of the HTML into separate files and/or functions/methods. Then at least the main file can be fairly straight-forward PHP, making readfile(), include, and/or function calls where needed.

            thankyou !!

              Do you have anything constructive to add or are you just going to continue parroting reddit threads and posting random links?

                Write a Reply...