Jump to content

Template design - better route?


BrendonKoz
 Share

Recommended Posts

I have a website that will be converted from mostly static PHP/HTML to (hopefully) using ProcessWire. There are still a few things I have to work out (mostly the database-driven aspects to be converted) but this particular website pretty much uses a global site header and footer. Out of around 100 pages there are a handful of pages that have custom CSS and/or JS added to do specific things. Each of these pages' CSS/JS is custom to the page.

I've been trying to think of the best course of action in designing the template for this conversion. Many small sites can include the custom JS/CSS in globally included files and rely on caching. On the other hand even if it were cached it's additional KB that wouldn't need to be included on 90% of the site's pages. ProcessWire could be used to include a field for additional code (or additional js and css, respectively separated). I realize this could potentially be an extra hit on query time on the database, but ProcessWire also has some impressive caching, especially with regard to Ryan's PRO Cache.

I'm just curious how others might handle this type of situation, and why?

Link to comment
Share on other sites

My way of handle it was to create a textarea field and insert the code there directly. In the head.inc I had something like this:

<?php
if($page->additional_css != '') {
    echo '<style type="text/css">'.$page->additional_css.'</style>';
}
?>

So no extra files were needed.

  • Like 4
Link to comment
Share on other sites

Assuming I understand the need correctly, what I usually do add this to the <head> section of the main markup include:

<head>

<!-- all your typical <head> stuff -->

<?php
$file = "styles/$page->template.css";
if(is_file($config->paths->templates . $file)) {
  echo "<link rel='stylesheet' type='text/css' href='{$config->urls->templates}$file' />";
}

$file = "scripts/$page->template.js";
if(is_file($config->paths->templates . $file)) {
  echo "<script src='{$config->urls->templates}$file'></script>";
}

?>
</head>

Using this method, if you have a template named 'product', then it could have dedicated CSS and JS files in /site/templates/styles/product.css and /site/templates/scripts/product.js, when you need it. The nice thing about this is that it's just a system rather than hard coded file. If you determine you need something unique for the CSS (or JS) on pages using some template, the you can just create the CSS (or JS) file and have it start working automatically. 

You can take this further too. For instance, you could use the same technique with page IDs to assign custom CSS/JS files to specific pages. 

  • Like 11
Link to comment
Share on other sites

In this instance I think I'd want to use the same template file for all of the static files. With the exception of the additional JS/CSS to interact with the body content, everything else would be the same - though I do like that way of doing things.

Ryan, when you mention using the same technique with page IDs, you mean PW page IDs and not a body element property "id" value right? If so, at that point I think Nico's solution might be more versatile in that it can take advantage of other features, such as the "copy page" module, unless I'm just not understanding something.

Thank you both very much for your input though! I was leaning toward's Nico's way of doing it for this project, but just wasn't sure if it was the right way of doing this type of thing. There isn't always a right or wrong, but oftentimes there's a "best" - whether that's this or not, it's time to stop over-thinking and move forward. :) Thank you again!

  • Like 1
Link to comment
Share on other sites

Ryan, when you mention using the same technique with page IDs, you mean PW page IDs and not a body element property "id" value right? If so, at that point I think Nico's solution might be more versatile in that it can take advantage of other features, such as the "copy page" module, unless I'm just not understanding something.

The issues with specifying CSS at the page level (in the editor) are that it crosses a boundary between content and style. Ideally these things remain completely separate to ensure the long term portability of the content. As a best practice, styling is best kept part of the site's development files rather than it's content. It's also a security concern, in that you are allowing someone to inject code into a page. However, if all the editors are trusted and know how to use CSS styles in that manner, then only you can decide if the convenience is worth the tradeoffs. For instance, on your own blog site (or something like that) it might be totally fine and convenient. But on something bigger you'd want to be careful, as it is crossing a line. 

  • Like 1
Link to comment
Share on other sites

Something I am doing at the moment is a very basic theming system for posts on a blog.

Basically, all posts are wrapped in a nice obvious div class "posts" and there is a separate style sheet for all the markup within that div container.

Then, on every post, you can select from a theme. This just adds a style sheet where you can override anything in the posts.css file. You can create a whole pile of these and create matching selectors. 

I might also throw a few extra things in there like reversing sidebars and so on.

But at the end of the day, all the styling is in a style sheet and not inline - all the author is doing is selecting from a list determined by the developer.

(Note: I am also building in a site-wide version, though having added the functionality, I have yet to work out how I will use it! :) )

  • Like 1
Link to comment
Share on other sites

I'm still following this topic but don't remember getting email notifications. Both of your responses were well thought out and, I believe, are much better solutions.

Right now this conversion is a proof of concept so I won't worry too much about the security. After it's proven to be an effective way of managing content, I plan to redesign/redevelop the website, much of it from scratch. I will definitely be keeping this in mind as I build it out as I'd prefer not to solve the situation in the same way (and instead keep it outside the reach of content editors).

Thank you again for following up and making an excellent point.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...