Respectfully chopping up index.php

  • I’ve been playing with the WP templates and I like how for instance a “header.php” placed in the WP dir will automatically overrule “wp-header.php.” This is going to make custom templating much easier, kudos!
    However, here’s my take on how to respectfully chop up index.php.
    1) If it’s going to be made so easy to drop in your own header.php replacement, we’re definately are going to need to be able to drop in a “body.php” replacement. The thinking here is that you don’t really want to replace index.php as a template author.
    If you can make a set of template drop-ins (header.php, body.php, footer.php, sidebar.php, layout.css), you want to offer the enduser an easy option to roll back. If you have replaced the index.php that is going to be slightly more difficult. If the enduser just has to remove the files you have added to return to the vanilla WP install, that’s going to that much easier.
    Eventually I can see a theme manager for WP that will drop a set of template files into the WP dir for the user, but will also remove them again when the user wants to roll back or install another template set.
    2) The way the template files are currently cut up goes against my neatness grain. What I mean is that index.php itself should be a well formed HTML file. Right now the doctype and the html tag reside in the wp-header.php file, as does the body tag and some assorted divs.
    While this works, it’s far from neat and organized, so I propose the following (simplified) layout for the index.php file:
    <?php require for wp-blog-header.php>
    <doctype>
    <html>
    <?php include wp-header.php>
    <body>
    <?php include wp-body.php>
    </body>
    </html>
    As you can see, the minimal (theoretical) form of a html page is retained: it has got the html tags around and the body tags go around the body. What is actually inside those tags is up to the included files.
    3) As you can also see, the index.php doesn’t call wp-footer.php or wp-sidebar.php. These are called recursively from wp-body.php: wp-body.php would look like this:
    <?php include wp-title.php>
    <?php include wp-content.php>
    <?php include wp-sidebar.php>
    <?php include wp-footer.php>
    I can see how this last recursion might appear superfluous, but by making body.php call a number of content ‘modules’, you offer the template author the possibility of not including some of the standard modules.
    Say you would put those 4 modules straight into the index.php and I wanted to create a design without a sidebar, I would have to go into the CSS and set the sidebar div to display: none, while bloating my html with stuff that’s not getting displayed. If I have the possibility of creating a drop-in replacement for the body.php, then I can choose to omit a call to the sidebar.php in the first place.
    4) As a visual illustration, here’s a tree-view of the proposed structure for the vanilla WP layout. All items, except the index.php itself, can be replaced by drop-ins by the template author:

    • index.php
    • wp-header.php
    • wp-body.php
    • wp-title.php
    • wp-content.php
    • wp-sidebar.php
    • wp-footer.php

    Let me know what you think ??

Viewing 6 replies - 1 through 6 (of 6 total)

  • Have you looked at the nightlies ? cvs ?

    I am following this and it is very much inline with my own thinking and the work I have done for 1.3. We are not only going to upgrade our templates for 1.3 but we are going to add additional functionality. I am thinking of plug-in template packs and an admin interface based switcher. As a further ehancement it might be possible to call the CSS with php as well givibg reuseable code. Eg php call for layout, color and everything else. Just my 2c but these are exciting times. Thanks for sharing your thinking Muffinboy.

    As I currently use a template system I would like to make some suggestions here. I would follow Muffinboy’s basic system but I think the inclusion of templates within templates will confuse people. I also think that the placement of opening and closing div tags for one template in another template is the wrong direction. Each template should be totally self-contained i.e. it should have it’s opening and closing div tags within it.
    So my suggestion would be that you have a basic “page” template which would contain all the “head” stuff such as page type, title, calls to various CSS etc. then the opening “body” tag and “rap” tag. From then on you call the separate templates such as “header”, “content”, “sidebar” and “footer”, then the bottom of the “page” template has the closing “rap”, “body” and “html” tags. Each of the templates would contain it’s own opening and closing tags so people don’t have to go looking for them somewhere else which is the current (3 days ago) situation with the beta.
    It would also be handy if there were some kind of “template creation” tool so people who wanted, say, a horizontal navbar could create a template for it easily and then include it where they wanted in the “page” template. Another useful idea would be the ability to modify the “page” template and save it as something else so people who wanted to create “static” pages or pages with single posts with no “commenting” etc. outside their blog could create specific templates for them. Just my 2c worth.

    That anon was me. Just noticed I wasnt logged in sorry.

    I should add I am a couple of days behind in the CVs and the hackers list which I have now just read up. As far as I can see – and for my 2c this all looks very cool indeed. I have had my issues but I think it right that I should thank Matt and the guys for doing a terrific job. This new interface stuff is just what a lot of end users are looking for. The 1.3 release could be the killer app of the century. ??

    I second Stuart’s point: the included files must have self-contained markup. It’s just too much of a danger of not closing a <div> somewhere, esp. since many people don’t comment their closing divs.

Viewing 6 replies - 1 through 6 (of 6 total)
  • The topic ‘Respectfully chopping up index.php’ is closed to new replies.