|Biggest html website (i.e. not CMS etc) you would consider. |
| 12:36 pm on Dec 10, 2010 (gmt 0)|
Just had someone say that a 300 page site in html is not advisable, it should be in a cms .... not at all sure I agree..
| 12:50 pm on Dec 10, 2010 (gmt 0)|
I'm with you in that regard. Static content which is evergreen... goodness, I've some sites that fit that description with page counts ranging from 1,700 to 20,000. That said, all navigation is via SSI or Frames so that any site wide change is limited to a few files. Site wide css controls basic displays, though some pages have internal css overrides for specific content.
| 2:11 pm on Dec 10, 2010 (gmt 0)|
I would agree it is "not advisable". Can it be done? Sure. Could it create a nightmare in maintenance down the road? Yes.
With today's technology you can have a cms based site that looks and acts just like a static site, but more flexible.
If cost is an issue, you could explore open-source products. If technical ability/limitations on a server is a problem, then I could see using html files with SSI headers, footers and ad slots.
| 3:02 pm on Dec 10, 2010 (gmt 0)|
I agree that SSI headers and footers can be good, also menu blocks possibly. But there is that old favorite "global find and replace" which can help on completely static sites.
| 3:03 pm on Dec 10, 2010 (gmt 0)|
I have one static site with about 600 pages, but I do squirt about 400 of them out of an access dbase directly into static html pages so I suppose that is cheating.
| 5:27 pm on Dec 10, 2010 (gmt 0)|
The recommendation of a CMS is only really valid if a requirement of the project is if non-technical personnel will be maintaining the site. Otherwise, from a coder/programmer standpoint, I don't agree either, and here is why.
I work in an environment where CMS-based websites are not a feature, they are an expectation, the norm, i.e., every client expects a web based administrative control (and in 99% of the cases, fails to do anything with it after deployment, deferring updates to us - go figure.)
But there's more. On a deadline, the simplest distraction can kill you with a CMS. A few times I've been in a hurry and updated the wrong page with another page's content, or when I thought I was in "add" mode I've actually edited an existing page. Once the database has been updated it's gone*, do it over, there is no undo, no backup copies, and it requires a different awareness than working with static files.
CMS's have a "black box" aspect to them. For example, Wordpress plugins, modX modules, and similar add ons for other CMS systems are awesome - when they work. When they don't, there is seldom any rich methods of debugging them. The support documentation is seldom complete or up to date, and when it is, it's only in respect to "when things are working." Most of the forums for these CMS's and their respective plugins are sometimes unresponsive, or responsive by elitists that point you to the documentation that you've already read - with a vengeance. :-) When things go wrong with a plugin, there's nothing I dread more than poring through hundreds of thousands of lines of someone else's code to figure out why.
<personal rant>Most of my "old clients" have required some form of protection from form abuse/spamming. I'm happy to say that for years, their inboxes have remained spam free without the use of CAPTCHA. I've many posts here on how I do this - but I have always felt that CAPTCHA, and even simple challenge/response in forms ("what is two plus eight?"), is an absolutely unnecessary barrier for your users. What bugs me most about CMS's is their code is so convoluted it's nearly impossible to apply these principles, and even if I could, it would get nuked with the next update. Which leaves CAPTCHA as the only solution, and I think that COMPLETELY sucks.</personal rant>
Then there's the added resources required. Just yesterday we'd planned to use a particular CMS for a new project, but the PHP version is outdated and the ISP is not willing to update it or add the modules required we will need. Sure, this ISP sucks, so let's move it to a decent one - but who's going to pay for that? Who's going to accept the added responsibilities of moving all their email accounts, going out to their office to set up their Outlook clients? All for a CMS they will likely never use? This is just one scenario where the CMS-in-the-middle is a pain we don't need.
Let's not forget security issues; I know, keep it up to date, act on the updates/upgrades, but still, these are targets.
I'm not saying CMS's are bad, I work with them daily, learning new ones as I go along, and for most users who don't know (and don't want to know) how to code, it's really the way to go. But if I had a choice - heck yeah, 600 pages static, let's do it. Solid, reliable, less security issues to worry about, not a single thing wrong with it.
*Some CMS's do have backup capabilities, but many don't; you get my point, I hope.
| 7:31 pm on Dec 10, 2010 (gmt 0)|
I prefer to build and maintain static HTML sites. What's not to like? There's less maintenance, no security concerns, no spammers, no broken scripts, no script upgrades, etc. Even a 300 page site isn't that bad.
Static HTML all the way ;-)
| 8:05 pm on Dec 10, 2010 (gmt 0)|
My site is over 6,000 static pages, almost all are evergreen and seldom need updating.
Even when I add a page in between two old pages all it takes is building the new page from a template and then changing one link each on the old pages.
You can always serve ads in an iFrame.
Any whole section or whole site changes can often be done with a global search and replace. Good planning in the beginning makes that seldom needed.
| 9:06 pm on Dec 10, 2010 (gmt 0)|
I think it is important to note that the term CMS does not need to mean a 3rd party "black box" software package.
I built my site from scratch 10 years ago and built in my own CMS feature. It is, for all intents and purposes, a custom CMS site. Completely flexible.
If I want to serve static content, I can have all my pages generated into static pages. If I want more speed than that, I can have all my pages served straight from memory (RAM). I can do anything since my site/data is stored in a database backend.
Ahhh, nevermind. Use what every you like and whatever you are comfortable with. To each his (or her) own.
| 7:02 pm on Dec 16, 2010 (gmt 0)|
I am an avid fan of using Drupal CMS for any size site. You gain so much functionality by using an open source CMS.
I used to be of the approach that static was easier to maintain etc. Until I found the full power of Drupal: CCK and Views. It took me about a year of maintaining 2 sites for the same business, one static and one Drupal to come to this conclusion. The first 6+ months I was hating the CMS site.
Peronally I wouldn't build a site in anything but a CMS at this point. Unless it was a static one page.
| 5:29 am on Dec 28, 2010 (gmt 0)|
My main site has been sort of cobbled together over a period of 10 years and has progressed from simply coded .htm pages to .php with SSI for menus and ad management. Granted, I have LOTS of include files, ie.; headers, footers, main menus (one for each section), section menus, sub menus .. even SSI files that serve Google ads .. different for each section and different locations on a page.
I also have a couple of small databases for very specific content snippets.
The site has reached 700 or so pages, much of it evergreen. The only security issue I ever had was when I tried to use WordPress on another site on my VPS. A hacker published some WP specific malware that compromised tens of thousands of WP sites. It was a nightmare, iframes inserted in every HTML page, including the HTML pages in Apache.
After that I decided that if I couldn't do something without using a CMS, I wouldn't do it.
| 3:11 am on Dec 30, 2010 (gmt 0)|
awesome response rocknbil. I agree alot with you had to say there.
300 pages is nothing for html if you have the right tools. SSI for headers and footers would make quick work of it. Given a good text editor like Editplus, you could load the whole site up into one editor and do a global search and replace on ever file in not time.
| 10:22 am on Dec 30, 2010 (gmt 0)|
Speak of the ..
|Posted December 29, 2010 by Matt Mullenweg. Filed under Releases,Security. |
Version 3.0.4 of WordPress, available immediately through the update page in your dashboard or for download here, is a very important update to apply to your sites as soon as possible because it fixes a core security bug in our HTML sanitation library, called KSES. I would rate this release as “critical.”
I realize an update during the holidays is no fun, but this one is worth putting down the eggnog for. In the spirit of the holidays, consider helping your friends as well.
If you are a security researcher, we’d appreciate you taking a look over this changeset as well to review our update. We’ve given it a lot of thought and review but since this is so core we want as many brains on it as possible. Thanks to Mauro Gentile and Jon Cave (duck_) who discovered and alerted us to these XSS vulnerabilities first.
| 10:44 am on Dec 30, 2010 (gmt 0)|
I am firmly with cms, I use third party cms and build my own.
Scalability is the word i associate with cms,
I found to be a lot of work in the past.
Increasingly, I am of the opinion that there will never be, and has never been enough time to do everything one has to do,Battling static pages manually has rarely been a beneficial use of my time, IMHO