If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Maintaining Large Websites (input wanted)

There is a debate regards to the best way to maintain a large website with 10,000 + web pages (school related) how to maintain the site to allow global changes (header, menu, footer).

All of the pages are currently designed in htm built using Dreamweaver template. The downfall of maintaining the site using this system is that when you make changes to Templates (Master or nested) templates on Dreamweaver, you have to upload every file on the site using the template.

I am looking for other alternatives (if possible how to maintain the site with global change option) keeping the htm file extension.

Ideas? If you would prefer to use serverside includes such as asp, php, or shtml do share, and tell me why.

Well, that's why a CMS is used for a lot of sites -- generally what I've been doing lately on sites that are pretty much static content is instead of using a database driven CMS, I use what's called a "poor man's system" -- mine is actually pretty complex as it uses the 'one index to rule them all' using a htaccess whitelist and a real templating system...

The 'normalExtras.php' file would simply be the content you have in your sidebars. I do it as separate files so that sub-pages can have their own unique sidebar content instead of the same as every page.

That's in essence a very basic poor mans -- and can easily be done in PHP, ASP, PERL -- even SHTML (an Apache only built-in SSI system)

As to keeping the HTML extension, I'd set up a 301 "moved permanently" redirect handler to point at the new versions of the pages. A "one index to rule them all" system might be better suited to handling that -- particularly since you could then use a rewriterule to use "friendly" uri's... so instead of "/faq.html" it would just be "/faq". No extension needed. You could even keep the HTML extension if you parsed $_SERVER['request_uri'] server-side instead of trying to use some fancy htaccess parsing.

Now that is interesting. I have always just used the php extension name but then again, I have always built the site first using php (includes) or other.

This does answer my question regards to our concerns keeping the html extension for the pages. However, I have to keep in mind regards to google search, search, and people that have already bookmarked the html pages. Every page would need the php (include) command line meaning, saving every page as .php. So if the htaccess file, do you have to add every single page or just index?

As for the CMS, they have chosen one, which they build the template into the system. There is a lot of discussion using xml and sxlm working with the html extension pages. I have to say, that is out of my league, I have never actually seen this system in action. My hope is, that the CMS will allow global changes even with the pages as htm extension. So far I believe it does.

Originally Posted by deathshadow

Well, that's why a CMS is used for a lot of sites -- generally what I've been doing lately on sites that are pretty much static content is instead of using a database driven CMS, I use what's called a "poor man's system" -- mine is actually pretty complex as it uses the 'one index to rule them all' using a htaccess whitelist and a real templating system...

The 'normalExtras.php' file would simply be the content you have in your sidebars. I do it as separate files so that sub-pages can have their own unique sidebar content instead of the same as every page.

That's in essence a very basic poor mans -- and can easily be done in PHP, ASP, PERL -- even SHTML (an Apache only built-in SSI system)

As to keeping the HTML extension, I'd set up a 301 "moved permanently" redirect handler to point at the new versions of the pages. A "one index to rule them all" system might be better suited to handling that -- particularly since you could then use a rewriterule to use "friendly" uri's... so instead of "/faq.html" it would just be "/faq". No extension needed. You could even keep the HTML extension if you parsed $_SERVER['request_uri'] server-side instead of trying to use some fancy htaccess parsing.

I am a Linux server and PHP fan myself. Unfortunately, the school uses Windows Server which isn't too bad, not my preference but have limited knowledge and practice in ASP. I have always just used PHP.

I did google, I did not see any options of using ASP without saving the pages as ASP and running it at HTML.

Originally Posted by NogDog

I would assume so, but have never tried. ASP usually (always?) runs under Windows Server, and I have no practical experience with it, just Apache.

It IS theoretically possible to run ASP.NET files on Apache -- even on linux -- using the MONO library. There's an apache module you can add called "mod_mono" that allows it to work. Mono lags slightly behind bleeding edge .NET, but M$ has actually been supporting Mono (mostly to get Silverlight over to other platforms) so that gap has narrowed a lot.

Note that's .NET versions, not old-school ASP. Old-school ASP compiled to actual binaries, so you'd have to like tie-in WINE or something. .NET compiles to something akin to p-code, so in theory it's portable since it's not actually native code.

Though really at that point, I'd use server-side Java... which is another option. Both Java and .NET runtimes are basically p-code interpreters. Those of you who call them a "virtual machine" can inhale my nether regions -- we didn't call it that with Pascal in the '70's so in the words of my generation... That's as stupid as the re-re's who call XML a "machine readable format"; which invokes a response akin to relating a tale of being inverted over a Mig-29 to Kelly McGillis.

Though I'd just go with PHP -- PHP makes good glue. It's a lousy general computing language but that's not what it was built to do. All PHP is really for is gluing together bits of markup and database operations. Doing complex computing with it, or even getting fancy with processing the markup just isn't what it does well.

See "templating engines" like smarty -- PHP is a templating engine, so what in the name of the infernal is with people making templating engines IN it?!? (again though, usually the people using that nonsense don't know enough about HTML and CSS to be making templates in the first place)

Really though, what makes me like PHP over other options is that it's available on just about every host I've ever heard of (Windows, Linux or OSX) and is RIDICULOUSLY WELL DOCUMENTED

Those two things greatly outweigh any objections I have to how PHP works (like encouraging insecure scope practices, the stupid 'php tags', etc). That over the past four to six years most of my objections (the insecure mysql_ functions, sql connections global in scope, lack of proper object modes) have effectively disappeared (in theory, too bad most people are still crapping out bad outdated code) hasn't hurt matters much. It's maturing into a much better language.

Though it's going to be fun when PHP 6 drops and people run around like chickens with their heads cut off since so many people are still effectively sleazing out PHP 4 like it's still 2004.