Thread

Is it possible to flatten an EE site to static HTML and publish only a completely static version of the site? 

Our client would prefer (for performance and security reasons) to publish only the generated content.

No, that is not a feature in ExpressionEngine.  However, we offer a wide array of caching options to assist in performance.  You can read about those at Data Caching and Performance.

On the Mac there are programs like WebGrabber, WebDevil, SiteCrawler that will crawl and download a site to static files and I’m sure there are variants for Windows. Would be a real pain to do this on a regular basis though I would think.
—————
Out of curiosity…
What performance issues are you having?
What security issues concern the client that a static site would solve?

Both the performance and security concerns are more ideological than anything.  It essentially boils down to the fact that nothing is faster and more secure than a hardened Apache instance serving static HTML.  Only works for sites without user-contributed content (e.g. comments, forum posts) but that’s a pretty large subset I think.

In that case, I’m not sure EE is the right tool. I guess I’d probably look at static page Dreamweaver type programs.

Actually, you could create a flattened site with static *appearing* pages.

You’d need to have a single entry template that you would use to display your “static” pages using the Pages module.

Example:

End result: /about.htm

Fed through: /index.php/site/info/about

about is the url title, site is the template group, and info is the single entry template.

Here’s a real world example:

http://www.eehowto.com/about-us.html/

There is no about-us.html file, it really is http://www.eehowto.com/howto/info/about-us

(I have EE set up to not use the index.php file via .htaccess.)

I’m with PXLated.  If you want the power of EE, but the end result you want is static-pages, what I would do is build it in EE, and then use wget or DeepVacuum to just mirror the whole thing, and post that.  It would also mean that you could change stuff in EE, then just re-mirror, re-post.

That said, if you intend on it being a static site from day 1, you might want to just consider actually building a static site 😉

There will actually be a fair amount of regularly updated content (anywhere up to 100 new documents in a batch, spread across 40+ authors with a range of technical skills) so a pure static site wouldn’t be the best approach.

This approach of “baking” the site to static HTML is actually more common than you think—it’s how a lot of high-end enterprise CMS tools work (Alfresco, RedDot and Teamsite all use this approach).

I know that EE is targeting a lower-end of the market, but having come from the enterprise CMS space I’ve seen many websites that could have easily been deployed using EE, with the end result of much lower cost of development and long term maintenance (plus happier content contributors!).  I think that as EE matures there will be more of us coming on board 😊

I’ll look into using wget/deepvacuum as an option.

This approach of “baking” the site to static HTML is actually more common than you think—it’s how a lot of high-end enterprise CMS tools work (Alfresco, RedDot and Teamsite all use this approach).

Yes, as does MoveableType. Works well for sites where once a page is created, it remains static never changing. If you’re content is changing, including your menus, links, etc. a fully dynamic system with cacheing tends to work better…of course the devil is in the details so generalizing is difficult.

I know that EE is targeting a lower-end of the market, but having come from the enterprise CMS space I’ve seen many websites that could have easily been deployed using EE, with the end result of much lower cost of development and long term maintenance (plus happier content contributors!).  I think that as EE matures there will be more of us coming on board 😊

Targeted only in price. Like you, I came from using Vignette and Interwoven. Other than their production/staging/live environment, I can pretty much accomplish 90% of what they did with EE and 1/100th the price. 😊

Have you investigated EE caching?  You’ll be amazed, its incredibly efficient, and if performance is your goal, give it a shot.

This approach of “baking” the site to static HTML is actually more common than you think—it’s how a lot of high-end enterprise CMS tools work (Alfresco, RedDot and Teamsite all use this approach).

As a person that has worked with and implemented large scale CMS systems in the enterprise I can tell you that the “baked” approach also has major issues in some ways as well.  Its one thing to make an update that affects only a page or even a few dozen, but once you have a change that affects something at the core of possibly 100’s of thousands of pages, then the “baking” approach has a lot to be desired as well.

The security angle is a double edged sword as well.  I think its far easier to audit changes to a few hundred files in an application like EE, and the auditing of database based content then trying to audit possible changes across say 100’s of thousands of static html files that must be tracked individually.  Any server, static or dynamic still has security concerns and should be treated the same way, not doing so, even with a “hardened” apache/static site is false hope for a security plan in my book.

I know that EE is targeting a lower-end of the market, but having come from the enterprise CMS space I’ve seen many websites that could have easily been deployed using EE, with the end result of much lower cost of development and long term maintenance (plus happier content contributors!).  I think that as EE matures there will be more of us coming on board 😊

And I would say this is only viewed as “targeted” if you take the price at face value, though you can also take the view that $100k CMS solutions are targeting the once typical corporate mindset that for something to be “good” it has to be expensive.  There is a large and growing collection of enterprise, educational institutions, and government agencies that are using EE to power, in whole or in part, highly visible and high traffic (and likely “targeted”) web sites.  A few that have been mentioned in the site announcement forums would be sites like bmi.com, gov.ca.gov, and others.  There are a number that I can’t share in a public forum that are also well know, household names, but the bottom-line is EE is far from a low end solution.  Believe me, I have a data center filling with more large outsource corporate clients weekly.

I do understand if its current corporate policy to have only a static website in the corporate dmz, but I still stand by the fact that security by “static” concept is never a great argument.

Just wanted to add my two cents.

HI,

I am moving from a Movable Type Enterprise environment, and used therefore to a static publishing environment. We ran comments and sidebars though fastcgi and cached like hell using Apache’s Cache module.

Anyway, this is one of my questions about EE so I thought I’ll post here instead of going for a new pre-sales thread.

My questions:

1. Does EE caching work along with eAccelerator and Zend Optimizer? For our high traffic PHP based sites, we rely heavily on eAccelerator, so it’d be great to hear experiences.

2. We are huge on cruft-free URLs. I will have a tough time selling URLs like this to our management:

  http://oursite.com/index.php/category/page

We will definitely need:

  http://oursite.com/category/page

We don’t mind if the “page” in this proposed ideal URL is a php program by itself, as php is our DefaultType in httpd.conf. How easy is this to do with EE?

3. About templates, does EE come with any beautiful three-column templates?

4. Another pre-sales thread talks about multiple site manager. About this—can these multiple sites have very different designs and templates completely for each other, with custom fields and all?

5. Even within just one website, for different categories, could I have different custom fields, and can these custom fields be SELECT menu (html), or image upload button, or textbox and textarea, or checkbox etc?

6. For commenting and such, how does EE perform with spam? (This is one of the main reasons we’re considering moving from MT).

Thanks.

I can answer #1 and #2 really quickly, others can tackle the rest 😊

1. Does EE caching work along with eAccelerator and Zend Optimizer? For our high traffic PHP based sites, we rely heavily on eAccelerator, so it’d be great to hear experiences.

Yes, it works fine with both.  Likewise EE works extremely well in a load-balanced web server environment to assist with larger traffic loads too.

2. We are huge on cruft-free URLs. I will have a tough time selling URLs like this to our management:

  http://oursite.com/index.php/category/page

We will definitely need:

  http://oursite.com/category/page

We don’t mind if the “page” in this proposed ideal URL is a php program by itself, as php is our DefaultType in httpd.conf. How easy is this to do with EE?

Everything in EE passes through the index.php so you will not have separate php “pages”.  You can either rename index.php or there are also ways to remove index.php from your URLs.

I’ll tackle a couple…

#3. About templates, does EE come with any beautiful three-column templates?

There are a bunch of templates available… Templates ...beauty is in the eye of the beholder so you’ll have to be the judge there. But, any template you find on the net (or create yourself) can be used with EE so the world is your oyster. EE templates are just straight html/css with EE tags thrown in to pull the dynamic content.

#5. Even within just one website, for different categories, could I have different custom fields, and can these custom fields be SELECT menu (html), or image upload button, or textbox and textarea, or checkbox etc?

Yes, unlimited fields and unlimited number of weblog field groups. Unlimited categories also. Not sure about the checkboxes, think there is a plugin for those though. You might want to read this Wiki entry… Categories/Weblogs ...All of the above are assigned to individual weblogs.

...can either rename index.php or there are also ways to remove index.php from your URLs.

Thanks Nevin, but the methods listed there (such as including htaccess into the template!) sound from kludgish to downright scary. We can only have Rewrite and other directives in our httpd.conf, no .htaccess files and such allowed for security/performance reasons. Is there a httpd.conf way to get rid of the ugly index.php bit in the URLs?

While we’re at it,

Q#7. Will EE work with PostgreSQL? I’d rather not bother with MySQL on our live servers if we can do without it.

Thanks