Is your structure perfect? Probably not. But it is a good start! Frankly, the idea of looking at your pages and determining that there is a common structure with unique pieces... and then module-izing these pieces into different files you can include with PHP is generally a good idea. It makes updating incredibly easy.
Once easy mistake using this include-method is that often people have URLs like "profile.php?page=comments" and to display 'comments', they use an include like:
include("{$page}.php");
Problem with above is that it opens the user to try and inject things into your script without your control. (bad)
Your approach (using IF's and ELSE's to look for what you EXPECT to find) is a good initial approach. But you'll eventually find this to be cumbersome with updates. What I tend to do a lot now is along the lines of (roughly):
if (file_exists($page)) { include("{$page}.php"); }
else { echo "<p>Error: Requested page does not exist.</p>"; }
Though in most of my own sites/projects, I'll usually append the full server/file path to the request and include the file by the full path, ie: /home/mysite/public_html/pageparts/profile_aboutme.php (instead of just 'profile_aboutme.php'; etc) But specifically, your idea of having a top level page like "profile.php" and then having a folder (/profile/) with specific "parts" of profile in their own files, is a good approach. My only thoughts are, why is the file named "comments_html_php.php"? Why not just "comments.php"?
It seems weird to me to append 'html' and 'php' into the filename. If it is because you have different "comments" files for different things, then I would suggest further differentiating, ie:
/profile/
/profile/html/
(contains HTML/content files for comments?) /profile/php/
(contains PHP files for comments? like functions, classes, etc?) Bottom line As you continue to develop, you'll always learn and discover newer/better ways of organizing your content and backend. Frankly, there is no "right" way. Some ways are just "better" than others. In my opinion, anything that resembles organization is A+++. I've worked on too many sites that someone else has developed that are an organizational nightmare on the backend. :(
My Structural Choice (FYI) On my own projects where I have content mainly in files (not in a database, because I have to for some reason or another), I tend to have a ~general~ structure like:
/index.php = master file
/core/ = powerhouse of site backend
-- /core/java/ = all javascript files
-- /core/php/ = main and primary PHP files/modules/classes
-- /core/css/ = all css files
-- /core/proc/ = processors (forms)
-- /core/x/ = components (3rd party stuff, large groups of stuff, etc)
/images/ = all images of sites, with subfolders to organize
/pages/ = PHP files of content to pages
/shells/ = master templates (shells)
/templates/ = page templates
/files/ = download-able files (PDFs, etc)
Where Apache URL rewriting sends all requests to '/index.php'. This file includes all necessary PHP parts and determines "what" the user wants (routes the request internally). Based off what the user "wants", it will determine what 'shell' to load, what 'template', and what 'page'... ultimately to deliver the right HTML to the user.
On these sites, "shell" is a master template: it defines things like headers, footers, etc and all main structures that are constant across the site, and specifies a place where "content" loads; which is usually either a template or a page file. 'Template' files are similar, they get loaded into the content area of the shell (if a template is needed); templates might define a banner area, a sidebar, a sub-level navigation, and a place for their "content". Finally, the 'page' file is loaded into the "content" area of the template file (or the shell content area if a template is not specified); and page file is basically what you'd expect a web page to be, it has links, paragraphs, images, etc... but just the content, no headers, no footers, no major structural components, etc. It seems confusing, but essentially: shell -> template -> page file.
I like the approach so far because it allows me to rapidly change major site structures with ease while not having to modify real content. I use this same approach in file and DB driven systems. In a file based setup, everything is in files that are loaded; where as in a DB based setup, all of these things are stored in a database. To ease handling this, I have functions/classes that handle all of this manipulation/setup.
On these types of sites, all URLs are in the form "/aboutus/", "/profiles/", "/members/", "/library/presentations/", etc. In the 'pages' folder I'll have pages arranged as: "/pages/aboutus.php", "/pages/library_presentations.php", etc. Essentially, the filename will dictate the URL. On file based setups, I'll usually have metadata in a text file that is parsed (ie: "library_presentations.dat", which defines things like page title, template, etc); where as in a DB system, such info would simply be in the DB. Because I have the centralized system built, adding pages in such a file based setup is as simple as creating a new "/pages/newstuff/mypage.php" file with content and adding a new metadata file. Voila. However... it took me a bit of work to build up the system to make this easily do-able. I initially did it for a file-based system because I wanted to develop a framework that would allow me to rapidly build functional sites without need of a database. I eventually expanded it to be database-based as well. Of course, most sites/projects I work on are 'small' in terms of pages and content. Looking back on it, I could easily have used something like a CMS... but I find most/all CMS's bloated beyond what I need or want. But everyone as their own style/interests.
