Making radical changes to a large number of pages on a website.
December 21, 2008 10:40 PM   Subscribe

Let's say I have a website with a very large number of pages and I want to be able to change the structure at any time in the future. How can i go about that?

I know colors and attributes of elements can be changed via css, but i want to be able to add and delete divs--to have the possibility to radically change the pages in the future. Anybody have any ideas?
posted by zorro astor to Computers & Internet (14 answers total) 1 user marked this as a favorite
 
If I understand you correctly, I believe you are looking for a template based Content Management System (CMS). Something like Wordpress, Druple or TYPO3 might be your answer. There are actually many different flavors of CMSs depending on what you want to do. The actual content is stored in a database and, based on templates you set up within the CMS, the pages are dynamically generated when they are requested.

If all of your pages are currently static, it might be a lot of work getting them into a CMS involving lots of copy and pasting and reformatting. This all depends on how your content is currently stored. If your content is stored in some kind of database, you may be able to export it in a format that you can later import into your chosen CMS, but that probably won't be easy.
posted by chillmost at 11:45 PM on December 21, 2008


chillmost is spot on, you need to do it on the backend. The simplest way would be via SSI (server side includes) but that's a total hack. A CMS would definitely be your easiest option.
posted by jedrek at 1:32 AM on December 22, 2008


but i want to be able to add and delete divs--to have the possibility to radically change the pages in the future

programmatically generate your HTML via PHP or other server-side scripting languages, and/or if you're really adventurous, client-side JavaScript.
posted by troy at 1:45 AM on December 22, 2008


As already suggested, a CMS is the way to go. Check out Drupal, it has tons of additional modules for adding various functionalities, and it is super easy to move blocks around, and change layouts, etc. Drupal is also well configured for Search Engine Optimization.
posted by Redruin at 4:34 AM on December 22, 2008


Piling on with the CMS advice. Wordpress is great, but there are many others. Here's why content management systems are so great.

I am far from a CSS expert, so my explanation may be iffy, but basically a content management system (or hand-built CSS) allows you to keep the layout and content separate. So, the code says "Hey, put the text and photos from the 'Read this great story' part of the content database right here. And put the "Wow what an awesome photo!' content right over here." Then, all the content (text, photos, media, etc.) lives in a database, and when the page is served the layout code grabs the content and slaps everything in the right place. Changing the layout code to move things around makes the applicable content follow it to the new location. No need to move all the content yourself; it sits there comfortably in the database waiting to go to the right place.

As far as adding and removing DIVs and other layout elements, all the pages get their information from a style sheet. So, removing a DIV in the style sheet removes it from all the pages that reference that style sheet for their layout, whether it's one page or a million. So, if properly set up, radical changes can be made to unlimited numbers of pages just by chaning the style sheet code. Keep in mind that there can be different kinds of pages, with different layouts. Each type of page points to its own style sheet, so no need for the whole site to be uniform if you don't want it to be.

This is why content management systems are so popular. Not many of us are experts in building all the code from scratch, nor do most of us need to. A content management system lets you get up and running very quickly by using one of the many "themes" for that system, but also allows complete control to customize your design by editing the style sheets. Editing the style sheet takes some mucking with the code, but many of them have instructions built in to the code itself, such as "change this number to make your center column wider or narrower."

(Yes I know these are not the correct technical terms.)

Good luck!
posted by Fuzzy Skinner at 6:31 AM on December 22, 2008


I mean this in the gentlest possible way: if you weren't familiar with CMS's before this, you will probably find Drupal enormously convoluted and difficult. I recommend a slightly more friendly CMS, such as Joomla or CMSMS.
posted by DLWM at 6:58 AM on December 22, 2008


While everyone above is correct, of course, there exists the possibility that you already have a very large website which is not managed by a CMS. In this case, you have two options when it comes to modifying the structure of the page in later design changes:

1. Become familiar with regex, and change the pages by literally doing a bunch of search-and-replaces against the html. This is fussy and error-prone work, especially if the HTML was originally produced by hand (which means there will be just enough extra differences in the code to mess up most of your searches.) If you do go this route, you're best off using it not to update your HTML but to reduce the pages to bare content, which you then put in a database and use in a CMS so you never ever have to do it again.

2. Serve out the html pages as is, but use jQuery (or another javascript library) to change the html after the fact, inside the browser. This is actually easier than it sounds: jQuery makes it pretty simple to add (or remove) html, change css classes on the fly, and so forth. Definitely not an ideal solution, but can be an acceptable way to dig yourself out of a hole.
posted by ook at 7:11 AM on December 22, 2008


You're basically correct that CSS only affects the formatting of your content, and cannot alter the structure. If you want to be able to change the structure and content of your pages, you have three options (that I know of): XSLT, server-side scripting, or a content management system.
  • XSLT:this language specifies methods for transforming XML (of which HTML is (sortof, usually) a subset). I'm pretty sure this is a more complicated solution than you're looking for.
  • server side scripting: this means using PHP, perl, server-side includes or some other similar method for "building" your html pages on the server before it is sent to the end-user who requested it. It can be as simple or as complex as you want: you're programming it yourself. There is a great deal of flexibility but it's not user-friendly unless you are comfortable mucking around with code. I presume that since you are using HTML, you are not completely code-adverse. You can get started by learning the "include" statements for your chosen language; it's easy to build a basic site this way that can take variables like "site name" or blocks like "sidebar" and put them on any or all pages on the site.
  • content-management systems: these are server-side software packages that can perform most or all of the tasks you would build yourself using server-side scripting (including some relatively advanced stuff that you would be unlikely to program yourself) and also provides a friendly user interface for working with pages. Most CMSes have their own template language for building the pages, so you still have to learn some code. Textpattern, Movable Type, Wordpress and Drupal are all fairly popular CMS options; there are many others, free and otherwise. There are some potential downsides: once you build the site in a given CMS, it may be a pain to transfer the site to a different CMS or other setup in the future. Also, if the CMS you use doesn't have a given feature available through the interface or a plugin, you'll have to live without it. Still, I would say that a majority of personal websites and blogs today use some flavor of CMS to manage the site.

posted by Chris4d at 7:15 AM on December 22, 2008


Response by poster: I mean this in the gentlest possible way: if you weren't familiar with CMS's before this, you will probably find Drupal enormously convoluted and difficult. I recommend a slightly more friendly CMS, such as Joomla or CMSMS.

Thanks for being gentle, im only a little over beginner's level programming :) i know what a cms is, but they are large and complicated and I don't really have to time to learn one (the coding i mean). I am building a simple link directory--which is in effect a CMS--but I can't seem to find addin that suit my needs.
posted by zorro astor at 11:02 AM on December 22, 2008


Another approach would be to go the regexp route but with tools that are more adapted to HTML processing than regexps are. You could, for example, write a perl script that slurps in all your pages (or even page fragments), does something to them with one of the perl HTML modules, and spits them back out in a new structure. Keep the originals around, and if you want to change something, just change and re-run the perl script to get a new structure. Conceptually this like a CMS, but it's run as a big batch operation once, instead of being run piecemeal each time someone visits the site.
posted by hattifattener at 12:34 PM on December 22, 2008


chillmost is spot on, you need to do it on the backend. The simplest way would be via SSI (server side includes) but that's a total hack.

Speaking as a ten-year veteran of professional web development, this is utter nonsense. It's not a hack; it's what server-side includes are for (among other things), and it's a far simpler and more elegant solution than installing some bloated CMS like Drupal or Joomla, which try to do everything (and consequently do nothing well). They're like Swiss Army knives—handy in a pinch, but would you rather do carpentry with a Swiss Army knife, or a proper screwdriver?

If all you're looking for is the ability to change the "shell" of your site (i.e., the stuff that appears on every page—the header, the footer, the nav, whatever) without having to edit every page, here's what you do:

1. Make sure PHP (any version) is supported and enabled by your webhost. If you're not sure, simply create a file named "phpinfo.php", containing the following single line of code, upload it to your site, and pull it up in your browser. If you see a big blue-ish grid with a PHP logo and information about modules and such, then you're good to go:

<?php phpinfo(); ?>

2. Create your HTML template as per usual. (Consider using root-relative paths for images, stylesheets, and other linked resources—e.g., <img src="/path/to/file.jpg" />. The reason for this will become evident in a moment.)

3. Identify the spot in your template where the content for each page will go—the place where you'd put "PLACE CONTENT HERE" if you were going to distribute this template to a bunch of other people to use as a basis for content pages.

Copy and paste everything above that point (from the DTD to right before "PLACE CONTENT HERE") into a file named header.php. Copy and paste everything below that point (from right after "PLACE CONTENT HERE" to </html>) into a file named footer.php. For the sake of organization, you might want to put these files in a folder called "includes".

4. Now start building out content pages. Thanks to the glory of server-side includes, you can now construct pages dynamically by pulling in chunks from other files. For example, here's a simple home page:

<?php require_once 'includes/header.php; ?>

<h1>Welcome to My Awesome Site!</h1>

<p>I think you'll agree that it's the best site ever. Give me money.</p>

<?php require_once 'includes/footer.php'; ?>


Copy this into a file, give it a .php extension, and upload it to your server. (This will not work if you view the page in your browser from your local hard disk; it must be uploaded to a PHP-enabled web server.)

Note that the paths specified in the require_once statement should be relative to the location of the page. For instance, if your includes are located in /includes/, and you're editing /some/dir/page.php, you should use ../../includes/header.php.

Or, if you do this, you can copy-and-paste the same require_once lines on every page, without worrying about paths:

<?php require_once $_SERVER['DOCUMENT_ROOT'] . '/includes/header.php'; ?>
<p>PLACE CONTENT HERE</p>
<?php require_once $_SERVER['DOCUMENT_ROOT'] . '/includes/footer.php'; ?>


When your browser requests an ordinary .html file from the server, the server just blindly streams the contents of that file back to the browser—it's literally just copying the file from one place (the filesystem of the server) to another (your desktop's filesystem).

On the other hand, when the server gets a request for a .php file, it notices the extension and thinks "hey, I don't want to just copy that file; I want to evaluate the PHP code inside it first". So the stream from the server's disk gets passed through the PHP filter before it gets sent to the browser. That filter tries to execute anything it finds between <?php and ?> as PHP code; if that code produces any output, it simply gets inserted into the page in place of the PHP code.

require_once is a very PHP simple statement which simply means "insert the contents of this other file at this point in the document".

And the practical upshot of all this, of course, is that you can now edit header.php and footer.php and instantly change every page on your site, whether there are ten or ten million.

Included files can contain PHP code also (as long as they have a .php extension); you can even nest includes (i.e., one included file may include another).

There are all kinds of things you can do, but this should be plenty to get you started. Have fun, and let me know if you get stuck.
posted by greenie2600 at 12:45 PM on December 22, 2008 [2 favorites]


Here's an idea: open a free account at wordpress.com and muck around. You can choose from many themes, many of which allow a custom image header. You can't mess with the style sheets without paying, but it's under $20 a year to have editable style sheets. No hosting fees either.

Playing around with your site there will give you an idea of what's possible, and who knows, it may be all you need.
posted by Fuzzy Skinner at 1:20 PM on December 22, 2008


Response by poster: Thanks for the advise. I'm going to go with Smarty
posted by zorro astor at 6:13 PM on December 22, 2008


I have to note that Fuzzy Skinner seems very confused, and is indeed confusing two completely different kinds of technology, CSS and server-side code: "removing a DIV in the style sheet removes it from all the pages that reference that style sheet"? Er, no.

Next time you need to bookend your post with two disclaimers that your explanation may be "iffy" and you know you're not using the right terms, maybe that's a sign that you shouldn't be answering at all?
posted by AmbroseChapel at 7:31 PM on December 22, 2008 [2 favorites]


« Older vocabulary question: African and Australia/Pacific...   |   You say lat-kee, I say lat-kuh... Newer »
This thread is closed to new comments.