Enterprise Software

Converting a CMS-based site to static HTML

Developer Justin James describes the process and the advantages of converting his personal site from a CMS to static HTML in Expression Web.

I have maintained a personal website for as long as I can remember. One of the perpetual frustrations I have had with it is the matter of a content management system (CMS) underneath it. For the last few years, it has been running on top of the MODX CMS, which I like a lot. Unfortunately, what I don't like is the maintenance duties underlying a CMS, so I let things get really outdated, to the point where getting back up to speed will be painful.

For the last few years I've been using Microsoft Expression Web for some other sites, and I decided to take a step backwards and bring my site from a CMS to static HTML in Expression Web. The big reason I could do this is because Expression Web has an excellent templating system (Dynamic Web Templates, or DWTs) that give me probably 80% of what I was using the CMS for anyway: the ability to control the HTML output from a single file or source. With DWT, you define "editable regions" that can be changed on a per-page basis, while the rest of the page comes from the DWT. To make an editable region, put the following code into the DWT:

<!-- #BeginEditable "regionname" --><!-- #EndEditable -->

Be sure to change "regionname" to something sensible and unique for each editable region. Also, you can pre-populate the editable region with content if you want -- just put it between the opening and closing tags. Along the way, I made the site structure more sane for a static site, and split out some of the CSS into separate files. Also, I took the small amount of effort to move to HTML5 for the site; it was already adhering to XHTML 1.1, so a simply change in DOCTYPE did the job. Standards are good!

My first step in the process was to create a new Site in Expression Web, and then to make a new DWT. For the DWT, I copied and pasted my existing MODX site template, and where the MODX template had placeholders for content, I either used static content in the DWT, or I made an editable region, depending on the need. Once I had the DWT made, I re-created the virtual folder structure from MODX with a directory structure, and then created HTML pages based on the DWT. I quickly went through the MODX site, copying and pasting the content from each page into the "content" editable region that the template had. After about an hour, I had copied in all of the pages I wanted.

The last big step in replacing the CMS was the matter of a menu. For the time being, I turned the pages into ASPX pages and used the TreeView ASP.NET WebPart connected to a Site Map DataSource, but this "solution" is temporary. Frankly, I do not want to rely upon any particular server-side technology for this site right now, to give me a site that can be completely moved to another server via FTP in a few minutes without care for the type of destination site. Also, maintaining the site map XML file is just as much work as maintaining links within the DWT itself. I will be moving to a jQuery-based menu system; I just need to pick one and move ahead with it.

Once I move to deployment, I will need to make an URL rewrite map to ensure that my links aren't broken, and I might use an automated tool to generate an XML site map for the search engines, though the site isn't big enough or have enough hidden content to justify that step.

Overall, it took me about two hours to convert a small (about 20 pages) site to static HTML. The advantages I will be seeing from the move are:

  • Technology agnostic site;
  • No maintenance of underlying technologies;
  • Elimination of security concerns, both existing and potential;
  • Easier to create new content;
  • 100% control over the HTML; and
  • Easier to experiment with jQuery, HTML5, and other new technologies.

J.Ja

Keep your engineering skills up to date by signing up for TechRepublic's free Software Engineer newsletter, delivered each Tuesday.

About

Justin James is the Lead Architect for Conigent.

39 comments
Nibblers
Nibblers

Clients feel they need to be in complete control of their business online. CMS allows this illusion and is an easy sell. It can be updated whenever they wish, staff don't need much training, no additional user software, features can easily be added and if I go under a bus they don't need to come my funeral in an attempt to network with my potential replacement. The website can be up in hours, look great (Artisteer is really good!) and the potential for ongoing charging of the client for support, training and SEO is lucrative - all without the need to get bogged down in the day to day humdrum of someone else business activity. I use Joomla, which can be configured as simply or as complicated as the client's budget allows. From an administrative point of view it is a simple deployment, I can back up the entire website easily, restore or redeploy to any server at will even to an intranet. Static HTML might have general advantages in the community but does this solution really meet the aspirations and needs of the market as well as CMS does?

bhwong1
bhwong1

I disagree that It's easier to create new content on static html over CMS. With a proper CMS, you just focus on content and let the system take care of the coding and navigation. With static HTML, you will need to add coding and insert new menu manually. How is that easier?

TimmyMakesInternets
TimmyMakesInternets

I came to the conclusion some years ago that most CMS progs are like killing houseflies with atom bombs. There's more to them than most people need for a small business website. I recall one project where I spent almost as much time bug-hunting one misaligned text box as I would have spent just hand-coding the whole site. I finally realized that server-side includes did everything I needed, if I was working with a smallish site. I just created a series of small HTML files to include (left sidebar, right sidebar, top menu, footer, logo space, etc.), then one master SHTML template (with a big hole in the middle for changeable content) to call all the includes necessary. Need a new page? Open the master template, paste the new content into the big hole with whatever text formatting is necessary, then Save As new_file_name.shtml. Then open top_menu.html, insert the link code for new_file_name.shtml, and Save. FTP both files to the server. Need to change the logo temporarily every year for something seasonal? You can do that by date-checking with SSI which logo file to load depending on the date. Set it and forget it. The best part about it was (and still is), your code just worked. It ALWAYS worked, because it didn't depend on crossing your fingers and hoping your end-user didn't have an eight-year-old version of Opera running on Ubuntu, with Javascript disabled, without Flash, viewed on a 640x480 monitor. Used to be, everyone warned you against using a lot of SSI because, "Oooh, you don't want to cause too many page-load delays for the end user, and SSI can really slow things down." Well, yes, that's true, if your end user happens to be stuck in 1999 with a Win98 machine on a 56k modem, and you're trying to push 80 different files down his intertubes. Of course, that guy is probably still waiting on the Hampster Dance page to load. But 5 or 6 include files, in the modern age? Piece o' cake. SSI inside an otherwise static (S)HTML page is da bomb.

apotheon
apotheon

Static HTML is too much effort for me when I'm adding content, so a site I need to update often won't do with static HTML for me. Bloated content management megasystems, on the other hand, have all the problems you've identified and more. I've gotten to the point now where if I need a "real website" -- that is, something with more than a couple pages of content, plus a consistent navigation scheme and appearance theme -- I'll just write the back-end code myself to minimize reliance on code written by other people for third parties whose needs are radically different from mine. That back-end code might be a dynamic server-side content management microsystem (in fact, it usually is, in my case) or it might be a site generation tool that builds static HTML pages out of parts I have specified somewhere. In general, in either case, I tend to include a Markdown parser so that I can maintain the content separately from everything else in a clear, human-readable form uncluttered by a bunch of fugly markup, but then when pages are dynamically presented to visitors or built by the site generator I've written, they get marked up properly as HTML in what gets delivered to the visitor's browser. It took me quite a while to get to the point where I decided this was the right approach for my needs, and I'm finding that it is the right approach for my needs in basically every single case. Most of my work in that area involves creating simple Ruby libraries and simple eruby templates -- a few hours' work for an entire "blog" site, less for simpler stuff. I came up with the first page's worth of content for a new site [1] a few days ago and decided I needed some kind of content management; my needs were simple enough that I ended up with a dynamic back-end that takes Markdown formatted content and automatically organizes it within the site's navigation scheme, all in under an hour. In fact, I'd be surprised if the entire process, involving writing an essay, designing the site (including CSS), writing the dynamic back end, and sticking everything on the server took more than 45 minutes. It then took about ten minutes to generalize it enough to be usable on another site [2] that is associated with the new one, so they have a common codebase for most of what they do, look the same, connect to each other, but organize things behind the scenes subtly differently. It takes longer than that to get WordPress installed and working, not even counting all the stupid crap that has to be done to make it into the site you want. It takes about thirty times as long (literally) to get Drupal to the same level of "well, it's not ready, but it's technically installed I guess". Screw that noise. --- NOTES: 1. http://nap.univacc.net 2. http://univacc.net

dustinsc
dustinsc

I have been developing DNN sites for 4 years and have worked on other various CMS platforms. I found this really cool, super cheap tool that templates websites; Artisteer. I think it may also work well for what you are talking about here. They recently beefed it up to include a way to generate static HTML that is content managed from the tool itself, kinda like other desktop HTML authoring tools out there (Dreamweaver, etc.) The big difference is that you can design nearly the exact same looking site in just about whatever CMS you want, DNN, Drupal, Joomla, WordPress, etc. The code it spits out is super lean and clean. And once you figure out how to design with it, you can make some really decent sites with it, FAST. The downfall is that it is limited with what kind of layouts you can generate, but if you are really creative, you can still make some pretty cool templates. As a designer and developer, I really turned my nose up at it, at first, until I had a project where I had to get something up fast. I have made static sites from scratch with it from start to finish in just 3 hours of billable time. The best part about that is when the client says, "Can I switch my site to CMS?" I already have their template created. I swear I don't work for them, I just really like the product: www.artisteer.com. The trial is definitely worth installing to play around with.

smiller
smiller

Justin, I already use Expression Web - so many things have been deprecated as many sites which I developed and maintain for clients have been moved from Windows 2003 Server to Windows 2008 server, specifically, anything that might have relied even a little bit on the old FrontPage extensions. Are DWT supported in IIS7 and beyond?

bradleyj
bradleyj

I can see the relief of having my own site and static sties converted to just HTML but for customer sites where they want to maintain content I think a CMS is the only way to go.

Raad@C
Raad@C

I can see some people looking this approach with scorn, but if it works for you then great. I worked with DreamWeaver for quite some time (it uses virtually the same templating approach as Expression), not for static html but for ASP/PHP dynamic pages, and it was really quick and easy to whip up new pages. Now that I'm a little more coding-savvy, I can see it's not actually the best approach, and I hand-code pretty much everything. There are definitely a couple of real advantages here (technology agnostic, reduced vulnerability) and it will be interesting to see how things develop and if any requirements emerge over time given this approach (e.g. being able to repeat the same non-static content in several different places). @JJ It's an interesting exercise at a time when web server CMS frameworks are de rigueur - do keep us up to date as to how you get on.

TimGummer
TimGummer

You probably ended up doing this becuase A: you're code savvy so don't have the same absolute need as most publishers and B: because ModX is pretty lame ?????compared with real CMS's. ModX was my first CMS but I moved to drupal - it has a steep learning curve for designer developers, but there are a gazillion things that it will do, that I specifically couldn't do in ModX, that I now take for granted and that I could never do with Dreamweaver (like expression web)'s templating system. Particularly with my own site, where I was able to use a taxonomic organisational system for my portfolio.

TimmyMakesInternets
TimmyMakesInternets

I guess maybe it's just the clientele I have, where a simpler HTML or SHTML solution works best. I tend to be drawn to clients who have very little in the way of office skills. For instance, the client might be the owner of a welding and metal fabricating shop, and the closest thing he has to an office staff is one older lady who answers phones and does the bookkeeping, whose idea of using the Internet is checking email and updating her Facebook -- at home, because the shop doesn't even have a connection -- so she can keep in touch with her nephew and her daughter and son-in-law. The client understands vaguely that he needs a website to put a polish on his business image, and that it's something his vendors and customers care about, much to his annoyance, but he personally couldn't care less otherwise. He looks at the work you've done from his home, checks the emails for his business from there once a day after dinner, and that's the extent of his involvement with his website. Neither of these people have the slightest interest in updating the website, and truthfully, the main body of the site rarely needs updating. For example, once you put together a page about what sort of process is involved in arc welding and what it would be used for, it's not necessary to change it. But I did talk him into letting me put together a "recent projects" section, containing some pictures of some of his recent fabrication work. I just pop by the shop every couple weeks or so, get some pictures of whatever is waiting for customer pickup, get the back story on the piece, and go write it up. And since I'm the one doing the updating, it's much quicker for me to just hand-code the body of the page since the SHTML template is already there. Now, if I dealt with companies that had an office staff of some sort, and an opinion on every little thing that should be on their website, I would agree with you. In those cases, you need to just hand the reins over to them, and a CMS is a good solution. But for the folks I deal with - people who can't be arsed to monkey around with a computer when there's work to do around the shop - simple HTML/SHTML is just fine for them.

apotheon
apotheon

I think Justin's point wasn't that content is easier. In fact, I don't think he said anything about the ease of creating content in one case versus the other. It's the management of the infrastructure of a CMS that frustrated him, and I agree that managing an install of WordPress, Drupal, and any of dozens of others (it's even worse for commercial CMSes, in my experience) can be a huge pain -- especially because the CMS rarely does everything I want so that I then have to either manage a local fork that needs to be reforked every time there's an update or manage a new module or extension for it that needs to be updated every time the CMS is updated. That's aggravation I don't need. On the other hand, I definitely agree with you that adding markup to all of your content and managing elements that must remain constant across all the pages of the site like a menu is a huge pain, which is why I have taken to basically writing my own content management micro-systems lately. If it's simple enough that it does nothing I don't need, but dynamic enough to make the usual hassles of static HTML go away, it's perfect. Sometimes, as "TimmyMakesInternets" pointed out above in "Remember server-side includes?" a couple of server side includes will turn out to be exactly what you need. Other times, a content management micro-system approach as I described in "minimal content management" above then actually implemented and explained in "I dunno man . . ." after that is a better way to do things. Big, heavy, painful-to-manage infrastructures like you get from popular CMSes is usually a case of spanking a baby with a sword or washing your hands with sulfuric acid: it's far too much for the task at hand, where the "cure" is worse than the "disease". If I need more than two pages I'll never need to touch again, I generally consider hand-coded HTML to be too little.

apotheon
apotheon

I've built sites with SSI in the last few years, too. There's a pretty small niche where they're appropriate, but within that niche using anything else is quite stupid -- and frankly, the niche would be bigger if people didn't love bad design so much.

Justin James
Justin James

... but my needs are so insanely minor for sites at this point, I can't even justify doing it like that. My approach is similar in that it lets me use a hand-coded template to spit out static HTML, I just don't have the custom code/libraries etc. to assist. It's interesting, with the right tools, static HTML is not much more work to deal with than a CMS, and now that there are all of these various AJAX scraps of code to deal with a lot of the interactivity (like Disqus... not a big fan, but it *does* address the need...), you don't need nearly as much server side work as you used to. It's possible to put together a site with all of what a CMS would do for most sites, with static HTML and none of the hassle. J.Ja

Justin James
Justin James

The DWT's are used by Expression Web to generate static HTML. Updating the DWT updates all of the pages that depend on it. So it doesn't matter where you deploy to, that's one reason I went this route. J.Ja

Justin James
Justin James

For professional sites... CMS is almost always the way to do it. I've been trying to force a CMS on my personal site for years now. I've tried literally dozens of 'em trying to find one that really meets my needs and wasn't a hassle. MODX came really close, but at the end of the day, the maintenance of it (not just MODX, but the dependencies too) drove me up a wall. A lot of the blame, incidentally, goes to BSD, not MODX. The portupdate system does not handle PHP well. J.Ja

mattohare
mattohare

Since there is no code to run on the server, I think the speed and soundness of the page load is a big advantage too. I thought long and hard when I went to a dynamic model from static pages on walladb.com. Even now, I try to keep the code and database calls to a minimum.

Justin James
Justin James

About a year ago I implemented a site with Drupal because I wasn't too sure if I wanted to commit it to MODX... and I really do not like Drupal. Drupal, and many like it, aren't "real CMS", they are better described as "content management frameworks" in my mind. Out-of-the-box they aren't so great. In fact, the maintenance on Drupalis significantly worse. With the Drupal site I had, I found myself constantly being told, "this module needs an update". It was practically a part-time job just keeping the modules updated and re-tested, it felt like! Also, the maintenance issues of a CMS are much deeper than the CMS itself... you have a database to deal with, and the PHP language. Without going into too many details, I've found that keeping PHP up-to-date on my BSD server to be quite problematic. Too many times, an innocent "portupdate php5" turned into a night of anger and frustration. It just wasn't worth it. J.Ja

Justin James
Justin James

Most of the small businesses that I've done freelance Web work for felt utterly out of their depth when confronted with a CMS. Their eyes just glazed over. It was much more worth it to them to just email me and have me do their 1 - 2 small content changes a year and write me a small check for the hour of work than to try to work with the CMS. If they had more frequent content change needs, though, I suspect that learning the CMS would pay off for them. Then again, paying me to maintain their CMS and keep up with all of those updates would get VERY expensive, VERY quickly. J.Ja

Justin James
Justin James

I have no problem creating content in CMS's, and in fact, it's easier to manage in some ways (especially if you want to use URLs other than the file name, and menu creation is a lot simpler). My objection to the CMS's is indeed the management of them. Between keeping them up to date (which you have to do for security) and dealing with all of their modules, dependencies, etc. etc. etc., it's just a lot of time to invest on an ongoing basis. With static HTML, all I need to do is worry about my Web server itself, which is easy enough to maintain and needs to be done anyways. J.Ja

apotheon
apotheon

QUOTE: my needs are so insanely minor for sites at this point, I can't even justify doing it like that I think having three pages of content is about all it takes to make my approach worthwhile. Check out this, for example -- written just for purposes of this comment, so you have a complete content management micro-system: http://paste.apotheon.net/?p=cmms There you go. It's an open source content management system written from scratch in maybe twenty minutes just for you, free of charge, minimalistic and flexible, so easy to maintain that you shouldn't actually have to ever update anything at all unless you decide it's not complicated enough to meet your needs. Of course, if your needs are met by static HTML, chances are good that this is easily complicated enough for you, apart from the actual HTML in it. In fact, this is in some respects simpler and easier than creating just *one* page of HTML with content. Hell, it's probably easier than installing Dreamweaver. QUOTE: I just don't have the custom code/libraries etc. to assist. Do you really think my "custom code" here is too much work? QUOTE: It's possible to put together a site with all of what a CMS would do for most sites, with static HTML and none of the hassle. The hassle with static HTML is when you decide you want to change something -- and have to change it for every single page. I wouldn't even want to add another page to the site, because of the updates I'd have to make to the menu on each individual page of the site. That's a pain in the fourth point of contact that I don't need, and it's exactly the sort of thing that CMMS (that open source project I whipped up just for a TR comment -- hopefully the name isn't already taken; checking on naming conflicts would be more work than writing the code) perfectly addresses. It's like a CMS without the hassle of a CMS, or like static HTML without the hassle of static HTML. It's the best of both worlds, because it does only what you need, and not one whit more. edit: updated the URI to the new location

smiller
smiller

Appreciate the feedback. I've been using a template that I have to manually apply to each new page. Scott

apotheon
apotheon

What does the ports system do wrong? (Simple Answer: Use something other than PHP. It's a disaster area of a language anyway.)

lastchip
lastchip

I sort of got roped in to becoming a joint administrator of a non-profit Drupal site, and the damn thing's a nightmare. Fortunately for me, my co-admin knows a lot more about Drupal than I do, but even he struggles. And this is a guy that's been coding since mainframes started in the fifties! For me though, hand coding a personal site is the easiest option of all. Absolute control of what you want and hopefully, really tight code to achieve the result. Although I've never used MS Expression, so cannot comment on it's efficiency (or not), my limited experience with Dreamweaver was not good and found it produced bloated code that in the main was pointless and did nothing to render the site any better, than if I removed the excess code. So these days, I have a set of hand coded templates I use and modify as required. Works well and doesn't require hours of coding from scratch. Everyone to their own I guess.

apotheon
apotheon

That expense must be why there are so many "Drupal professionals" out there -- and why they push Drupal so hard.

apotheon
apotheon

Yeah, that was the point I was initially trying to make. I figured it would be more clearly made if I just wrote something to demonstrate it. I'm glad that turned out to help me clarify what I was saying. Enjoy, with my compliments. edit: I replaced BlueCloth with RedRug.

Justin James
Justin James

That's an *awesome* piece of work, thanks! It's even easier than the DWT's in Expression Web, because it handles the menus too. The tradeoff is a VERY small dependency (eruby, BlueGem), but it's one I can live with because 1) it's not a big deal and 2) the exposure to user input is so minor that there is no fear of security attacks, so it's not necessary to stay on top of the maintenance of the dependencies. J.Ja

Justin James
Justin James

... but I wanted to give PC-BSD (another) fair evaluation. I tried it a few years ago. Buggy, but I blamed a lot of it on Microsoft Virtual PC (it was right around the time when MS VPC was the only OK, free VM system for Windows). Tried it for a few days in Virtual Box... it's still buggy. It's not all PC-BSD's fault, of course. But after even a light amount of usage it was clear that I would be wanting to poke my eyeballs out after a week of constant usage. For example, I was trying the "Amorak" application for media playing. Never mind the obtuse UI, I got it to add things from Last.FM... but they never actually played. So I tried opening last.fm in Chromium, and there was something wrong with how the system worked because it sounded like Alvin & the Chipmunks. Tried various songs, all the same result. Tried playing songs in other players, worked fine, so I knew it wasn't the sound system goofing. I then tried it in Konqueror, and it wouldn't work at all. Chromium itself displayed bugs that I've never seen in Chrome for Windows. I couldn't set it as the default browser, I kept clicking the button over and over again, it still wasn't the default. Rebooted, same thing. If I can't even set my default browser to be what I want it to be without ripping apart some configuration file, I don't think I am going to live terribly happily with a system. Again, I doubt this is PC-BSD's fault, it feels like the applications for it just stink. I'm sure the issue with Last.FM was something like a bad Flash implementation or codec or something. Honestly, though, I don't care. This is the kind of thing that should, and needs to "just work" for a system and I to get along. The first time I tried to use Control Panel and the System Manager, it locked Control Panel so badly that only a reboot could kill the task! I'm guessing that a kill -9 would have taken it down too... but seriously, when using a desktop manager, having to kill tasks via command line is just... 1995. It's a shame, because the overall progress compared to my last run with PC-BSD is good. The system is slick and quite usable. It was different from Windows (and could have been a LOT more different from Windows and I would have been fine), but it was sensible and easy to get acclimated. The application choices were decent. I will take a look at Catalyst at some point, and GhostBSD as well. I fear that my experience with GhostBSD will not be much different from PC-BSD, due to the issues seeming to reside at the application level. J.Ja

apotheon
apotheon

QUOTE: the part of the Windows market that they are chasing (the Windows desktop) I see as a model with a limited future as a mainstream model I guess that depends on what you mean by "desktop". If you mean "end user usability", then it makes sense to try to address that niche. If you mean "mid-tower sitting on a desk", then I guess that's not as important -- but I'm not sure how addressing the needs of laptops (for instance) would specifically avoid the "mid-tower sitting on a desk" needs as well. The problem, as I see it, is not that someone's trying to address the needs of someone sitting in front of a computer (such as a laptop or development workstation), but that someone's trying to do so by mimicking an OS that does it poorly. QUOTE: Why not make an OS with a shell that is perfect for managing servers (yeah yeah, I know, it's called "bash")? Oh, hell no. Bash is garbage. If you have to write shell scripts, write them in sh, for standardization and portability purposes if nothing else -- and if you need more than sh use a programming language for Pete's sake, not an interactive command shell syntax. If you have to have a feature-rich interactive shell, use something like mksh or zsh. Bash is too bloated, dependency-heavy, and perverse in its design to ever be mistaken for an elegant piece of software, and too short-changed, emasculated, and poorly conceived to fill the needs of someone who actually wants real interactive command shell convenience and flexibility. I can only hope that "wink" smilie in your comment is meant to indicate facetiousness. QUOTE: Microsoft's got a huge gap there, and with their constant investment in PowerShell it seems like they recognize it. PowerShell is a platypus. Its designers seem to have been confused about what they were creating. It has some features obviously designed for interactive command shell use that make its suitability as a scripting language pretty suspect, and it has some features obviously designed for admin scripting and programming purposes that make its suitability as an interactive command shell syntax pretty suspect. QUOTE: BSD gives me lots of reasons to stay... but if I want to break out of the Microsoft ecosystem (and I keep trying to!), I need a system that I get pick up and run with and not trip over the details. Have you tried PC-BSD or GhostBSD? I think the latter is probably less mature, but I mention it because some people swear by it. QUOTE: I keep slowly increasing my exposure to Ruby/Rails/Sinatra/Python/Django/etc. in an effort to find an open source, *Nix-y development experience that re-captures the joy of Perl while being modern and letting me fill the needs that I have. Have you looked at Catalyst? It's an MVC web framework for Perl. I haven't used it, but if Perlishness is what makes it fun for you, Catalyst might be worth a shot. QUOTE: erb18 does the same, though, which is "wrong", it should be calling /usr/local/bin/ruby18, to ensure that it always calls Ruby 1.8. File a bug with the port maintainer. Check the ports pkg-descr file to see if the maintainer's email is in that, or check freshports online. You could file a bug via pr, too, but I suspect you would find it an aggravating experience. QUOTE: And erb19 also always seems to call /usr/local/bin/ruby, which is "wrong" for the same reason. Same deal as with my bug filing suggestion for erb18. In either case, if there's actually a problem there, it may get fixed pretty quickly. I'd just change the default Ruby from 1.8 to 1.9 if it was me, though.

Justin James
Justin James

... I was just throwing it out there as an alternative to FreeBSD. I'm kind of saddened by the *Nix world right now. I love FreeBSD in so many ways. Stability is one of them, and licensing is another. It seems to have the most similarities to real, hardcore, "big iron" *Nix; not that it is relevant per se, but it is comforting in a way. The Linux's keep going farther down a path of Windows imitation that makes no sense to me. Why chase Windows, especially since the part of the Windows market that they are chasing (the Windows desktop) I see as a model with a limited future as a mainstream model? Instead, they should be concentrating on their strengths, the server room. Why not make an OS with a shell that is perfect for managing servers (yeah yeah, I know, it's called "bash" ;) )? Microsoft's got a huge gap there, and with their constant investment in PowerShell it seems like they recognize it. The BSDs seem to understand this very well, and focus on the basics and "must have" tech innovations under the hood. If it isn't UI, it will be on BSD before Linux more often than not. BSD gives me lots of reasons to stay... but if I want to break out of the Microsoft ecosystem (and I keep trying to!), I need a system that I get pick up and run with and not trip over the details. I am wide open to any suggestions on this front, I may add. I keep slowly increasing my exposure to Ruby/Rails/Sinatra/Python/Django/etc. in an effort to find an open source, *Nix-y development experience that re-captures the joy of Perl while being modern and letting me fill the needs that I have. The erb issue annoyed me, because there are three erb's on the system: erb, erb18, and erb19. Here is what SEEMS to be happening. The behavior of erb is to call /usr/local/bin/ruby, which makes sense. Leave off the version number and get whatever the system default "ruby" is. erb18 does the same, though, which is "wrong", it should be calling /usr/local/bin/ruby18, to ensure that it always calls Ruby 1.8. And erb19 also always seems to call /usr/local/bin/ruby, which is "wrong" for the same reason. I may be mistaken, I just found a couple of items in the erb diagnostic switches that made me think this. I know that erb19 displayed the 1.8 behavior, though, which is definitely not right. :( J.Ja

apotheon
apotheon

QUOTE: erb was using Ruby 1.8, not 1.9, and 1.8 requires a "requires 'rubygems'" to allow gems to be loaded Oh, I somehow had a brainfart. Sorry -- I should have realized right away that you were probably dealing with default setup for Ruby and an eruby implementation from ports. Yes, in 1.8 you need "require 'rubygems'" to get gem paths. QUOTE: I think I just need to move on from FreeBSD. I've lost too much time in my life over these exact kinds of issues. I hate to say it, but maybe Ubuntu does these things right. FreeBSD doesn't do anything wrong in this case -- it just defaults to Ruby 1.8 for reasons that make plenty of sense. For instance, I think portupgrade (one of the two most popular port system front ends) has only really been fully tested with Ruby 1.8. There's a fairly simple way to get FreeBSD to default to Ruby 1.9 if you like, though. Don't blame the OS for my brain fart, and don't assume that using the most recent version of something is always doing it "right". We're talking about an OS that is designed with stability in mind, here, and not Ubuntu or Firefox (both of them being projects whose developers appear to have abandoned the idea of making stability a key goal).

Justin James
Justin James

... for whatever reason, erb was using Ruby 1.8, not 1.9, and 1.8 requires a "requires 'rubygems'" to allow gems to be loaded. I have no clue how to "fix" erb, but I put in that requires and I'm now getting different error messages, so it seems like that roadblock is done with. :) Unfortunately, I've not sunk way more time into debugging issues with the way FreeBSD and Ruby and Apache interact than this script will ever save me. :( I think I just need to move on from FreeBSD. I've lost too much time in my life over these exact kinds of issues. I hate to say it, but maybe Ubuntu does these things right. J.Ja

apotheon
apotheon

http://codepad.org/sQmgn0Qr Use that to check your gem path. If it doesn't work, use the complete, absolute path for "rubygems.rb" instead of just "rubygems" in the require statement. That, at least, should tell you how your gempath looks so you know exactly what's in there. You might also want to check where your gems are getting installed.

Justin James
Justin James

Yeah, I know their filter is over aggressive. I'll try the steps you list, though my problem isn't Apache, it's even happening when I run it through erb in the shell. That's why I'm so baffled! I'd have less difficulty understanding why the user www can't access libs installed by root... perhaps there's an environment variable not being set, or permission to the lib path is blocked. But when root can't run it, I start scratching my head. BTW, duckduckgo is a very nice tool. I've exchanged a few emails with the guy running it (he still has a "day job" believe it or not!) and he's very nice. I keep meaning to take the time to give it a full evaluation to see if I should make it my default search engine. J.Ja

apotheon
apotheon

Well, TR has decided I can't paste a link to a page I found that has some information on it that I thought might be of some use to you. Try using duckduckgo (it's a search engine) to search for "freebsd ruby library and path locations" (without quotes), following the (probably first) link to a site called "zytrax", and going to the part of the page called "Ruby Library and Path Locations". It might help; I'm not really sure. I don't remember exactly what I did to get stuff working here. It just works; I haven't touched it in a long time on my local setup, precisely because it just works. I think Apache is just kind of a perverse pain in the arse in general, frankly. I think my next webserver will be using something simpler to maintain -- maybe nginx or something along those lines -- unless I end up having to tackle something where someone else sets the requirements, of course. I'll let you know if I think of anything else.

Justin James
Justin James

Tried to run your stuff last night. Spent *hours* trying to make it work (not your fault). I am so frustrated. erb won't run it because it can't find the BlueCloth gem... the one that I installed both from the ports system (portinstall rubygem-bluecoth) and from the gems system. I tried some other erb scripts that I found, and their "requires" do not work either (like erubis). And this is me running it logged in as root, the same user I installed the gems under, so if there's any environment variables pointing to the gem path it should be the same. Totally maddening, to the point where I'm going to try IronRuby instead, my only other alternative is to put up a Linux VM. Instead of writing an article last night, I was monkeying with this... This is the kind of garbage that makes me forget the amazing uptime and rock-solid stability of my FreeBSD server. This is the kind of problem I should not have. J.Ja

Justin James
Justin James

I have not tried portmaster. At this point, the server is in a "stable" condition, once I get this site put up with URL rewrites to the new URLs there will be no need for PHP on this server anymore... I'm going to call it a day. :) Using make install clean etc. is usually how I have to un-mangle the issues. It's been a while since I put myself through it (I innocently typed "portupgrade php5" and cost myself a night of my life...), but I think that the fundamental issue is the dependencies that get built into the PHP extensions, like it never gets them right and I need to manually build everything out of the ports tree. It's definitely not the way things are supposed to go. J.Ja

apotheon
apotheon

Have you tried portmaster instead of portupgrade? I've been using portupgrade all along, but I'm finally switching to portmaster because it is evidently better supported these days. Have you tried maintaining your PHP ports by using cd to go to the relevant port directory, then doing a "make install clean" directly from there, and otherwise doing it more "manually"? I wonder if there's something particular to portupgrade here, though it should be the opposite really -- portupgrade should handle the whole process better. It's just worth considering. Do you check the /usr/ports/UPDATING file before doing any upgrades? If there are special instructions that need carrying out for a port when upgrading it, they should be listed in there. If you aren't checking that already, I'm about 98% sure that starting to check that will solve most if not all of your problems -- though take it for what it's worth, because I don't deal with PHP on FreeBSD (or anywhere else, these days, if I can help it) at all.

Justin James
Justin James

Whenever I use portupgrade on PHP, it mangles the PHP extensions (as expected), then I try it on phpextensions and it NEVER works right for some reason. So I have to try them individually. And sometimes they don't work right either. Next thing I know, I'm popping into individual directories doing make install and make clean... or make deinstall then make install make clean... it's a mess. I know it isn't the ports system specifically, since I don't have these problems with anything else. It's something specific to the PHP extensions and the ports system, they don't get along. J.Ja