|Wanted — someone to do some web stuff.
||[May. 18th, 2008|05:14 pm]
The OpenGuides website needs an overhaul, and I've been blocking on it for so long that I decided it was time to try and throw some money at the problem. Not a lot of money, because it's coming out of my pocket; I was thinking of about £50, so obviously we need someone who'll do it at mates' rates rather than market rates.
The problem with the current site is that it's too hard to update (as you can see from the date of the "Latest project news"...) It's overcomplicated, for one thing, and it assumes that it lives at the server root, so it's a pain in the ass to check out, modify, and test. What we'd like is for someone to rewrite it using nothing other than HTML and SSI; no Perl, no PHP, etc.
- No duplication anywhere; menus, footer, navbar, etc should be defined exactly once and then included with SSI where required.
- It should always be possible to check the site out of svn and amend and test it without it necessarily being at the document root.
- Any design/appearance stuff should be done with CSS, and the CSS classes should be compatible with those used by OpenGuides itself so when we start shipping a default CSS file with the OpenGuides distribution we can have a consistent look with the OpenGuides website.
The svn repo for the current site is at http://dev.openguides.org/browser/website.
Note: I'm not looking for someone to work on the OpenGuides application (well, I'm always looking for new OpenGuides developers, but that's not what this post is about). I'm looking for someone to overhaul the website at http://openguides.org/ which describes what OpenGuides is about, links to the various Guides, and has project news etc.
Hello Kake! I can hack away at CSS and HTML till the cows come home, but I don't have much experience with the SSI side of the business (but would love to get some!)
I don't really need the money though - if someone who does need some cash wants to have a go (or you find someone who is more experienced!) then no problems. Otherwise we can spend it on cocktails :)
Edited at 2008-05-18 07:16 pm (UTC)
The SSI side isn't very complicated. At least, it can start very simple. Basically, you just try to design your pages with a reasonably templated layout in mind - header include here, page name here, menu include here, body here, footer include here. The three includes get shuffled off into separate files, and you shove in an "include this file here" command in the HTML. If you've ever used an old-style ASP include or PHP include, it's the same.
Most of the time, you don't get much cleverness, turning bits and pieces on and off in code. However, you can simulate quite a lot of that with CSS and a slightly slapdash attitude to code compactness.
e.g. imagine you want an expanded menu for each subsection. In a "proper" programming language, you might have a piece of code that spits out a customized menu for each section. With a fairly simple SSI-based system, you could have one menu with *all* the subsections expanded, and use CSS-styles to set all the subsections to invisible. Then each page in any given section has a <body id="section_name">, or something similar in an outer div, and you can turn on the menu for a particular sub-section using the extra style. So each page has to download the whole menu for the site, but you get what you want.
2008-05-18 09:59 pm (UTC)
Well it would be a handy way to get experience! As caramel_betty
says, it's not that
complicated. The part I got stuck on was the requirement to not rely on the position of the site in the document root, e.g. if I can't assume my included files are at e.g. /includes/navbar.shtml — it's too long since I did anything with static websites.
I'll give it a few days to see who's interested and then we can figure out who's actually going to do it.
You can have relative paths for SSI includes. However, they are relative to the current page, so includes within includes get tricky cos you don't know where they're being included from. But if you can avoid that, then changing from absolute to relative include paths should be a doddle. See here
and I'd be happy to give you a hand with it.
I wasn't 100% sure if nou
was referencing the fact that you have to be careful when using relative paths within the SSI.
e.g. SSI header lives in /includes/header.inc
, and you want to include a logo from /images/logo.png
, so you include a bit of code that says <img src="../images/logo.png">
. This would work fine for /index.htm
, but wouldn't when it was included for /news/archive/2006.htm
I may have misunderstood and/or be on crack. Your country may be at risk if you rely on this information.
2008-05-19 03:28 pm (UTC)
Yes, I think the problem was something along these lines.
Would a solution that involved playing evil games with
<!--#exec cmd="..." --> be acceptable?
2008-05-20 10:26 am (UTC)
I think Dom (who'll be hosting the site) would consider SSI exec to be a security hole.
Would a solution that involved running a perl script (or even a shell script) after doing a
svn export be acceptable? i.e. is it ok to run code if it’s not in response to a web request?
2008-05-31 03:00 pm (UTC)
If that's the least complicated solution that would work then yes, that's fine. katstevens
has the job now though!