The easy method is to put all your html in a separate view folder, and just do a

include $site_path . 'views/' . $myfilename;

at the end of each code file.

How robust of a structure you set up for yourself really depends on the complexity of the project.

I can understand you might want to avoid the use of some kind of 3rd party framework for continuity and/or dependency reasons, but that still leaves you with design principles to follow. In the end I would advise to your friend that it might be very beneficial for him to consider a framework which is well supported and which you are able to work with. It will likely cut back development time and catch many security holes you never even heard of.

Failing that, my guess is that you need to make a good overall design before you start coding to make sure you have at least a good overview of how you want to set up the relationships between the namespaces and the classes in those namespaces. (not necessarily in UML, it could just be a text document) Although it’s almost overused in this regard, MVC is a very good pattern for separating core logic from presentation and input handling (including the security side of input handling, like SQL injection and the like).

As in any coding, security is mostly by design followed up by good coding practices.
Make sure you have a good idea what the site should, and more importantly, should not be capable of so you can set constraints on what the system is capable of and what the users of the site are allowed to do.

BTW, does no frameworks also mean that you can’t make use of templating engines like smarty and the like? They can help you do a lot of stuff for you and improve your security for you.

The first question is – how big of a project is this? You say you are coding a “website” – but not what features you want. A “website” can be anything from a single page, through to a custom content management (like an image gallery), all the way to an e-commerce site and beyond. The project scope will have a definite impact on the answer to your question.

The second question – why does your friend not want to use third-party frameworks? Or is it a specific framework? Generally, frameworks are frowned on as “untrusted 3rd party” code – if this is the case, some education about where this framework is used and how it is managed could help. Another problem is the idea of “bloated” frameworks – the idea that they are stack full of functionality that will never be called on. Part of this is addressed in the scope question above, and part of this is addressed by picking a modular framework: code is only included when you need it, reducing “bloat”. The last one is complexity: people can see frameworks as needlessly complicated – there is a learning curve when maintaining or extending. What they don’t realise is, most frameworks are community developed (or at least, take a lot of direction from the community), and part of what the community wants is simplicity – so these frameworks get pared down over time.

So, that should address the perceived negatives of frameworks – there are also positives: community developed frameworks tend to be more secure, simply because a broader audience has reviewed and updated insecure code. Homegrown frameworks don’t get anywhere near the same kind of auditing. Similarly, homegrown frameworks can easily become complex spaghetti code – again, because of this lack of broader auditing.

That all said – there are times when a framework is not necessary: a relatively simple site (say anywhere up to an image gallery or simple blog) could be written without a third-party framework. PHP Objects, Patterns and Practices discusses various patterns that can be used for “non-framework” solutions, like page controllers and so on.

The short answer is: always use a framework. Don’t try to write your own (unless you do it for learning).

The long answer is more complex.

From my personal experience, I have seen that there are situations when you simply have no choice, especially when you have to work with people who are not familiar with OOP.

My suggestion is: especially if you are starting from scratch, try to convince your friend to use CodeIgniter. After all, he won’t need to be an OOP or MVC guru to understand which view is loaded by x controller.

Only if you can’t convince him, and if the project is very simple, write your own mini-framework, but don’t try to implement a complete MVC pattern. It would be the same thing as using CodeIgniter, but instead of the original you would have a bad copy.

Here are my suggestions:

Create a ‘main.php’ file as a single entry point to your framework, with autoloading declaration, session initialization etc.

Create a ‘classes’ directory to keep all your logic separated.

Create a View class (the simplest thing you can do is including the view file and extracting the array of data to be used inside the view):

<?php
class View {

    protected $view_name, $data;

    public function __construct($view_name, $data = array()) {
        $this->view_name = $view_name;
        $this->data = $data;
    }

    //Displays view content
    public function render(){
        //Extracts vars to current view scope
        extract($this->data);

        //Includes contents
        include $this->view_name;
    }

}

Create an Input validation library.

Then, inside your pages, include ‘main.php’ and you will have access to all your classes and views.

<?php include_once 'main.php';
$view = new View('view.php', array('var_name' => 'value'));
$view->render();

I am writing a very simple framework which is built more or less on this schema. I wrote it exactly to deal with this kind of situations. Have a look if you need inspiration.