Welcome to Geeklog, Anonymous Tuesday, October 15 2024 @ 09:11 pm EDT

Comments for Making GL Professional

Making GL Professional | 36 comments | Create New Account

The following comments are owned by whomever posted them. This site is not responsible for what they say.

If this is a feature request...

Authored by: Remdotc on Tuesday, July 02 2002 @ 09:01 am EDT

Features, that would be cool

I. Ablity to restrict user account creation, ie approved via admin
II. Karma for stories, articles and links
III. Add, more of a modular design, for front end. I.E. Allow users to insead of having to use a theme arround a fixed block engine (much like almost all portal wares) give users the option of just calling one parsed html page, with the options they want. This would allow anyone to quickly design a site they way they wanted it, without having to understand nested tables ectra, or use the current theme design
IV. Add more options to the conf file, so nothing is hardcoded
V. Add caching sparse system, ie rewrite index.php?=topic/sidXXXXX$pid=XXX to index/topic.XXXXXX,XXX.html. With an configurible caching time for Blocks and for main section. This would not only make the site use less resources and speed up page load time, but would also make dynamic pages search engine friendly

If this is a feature request...

Authored by: dreamscape on Wednesday, July 03 2002 @ 06:17 am EDT

I. Ablity to restrict user account creation, ie approved via admin

This has certainly been brought up on a number of occasions, especially by myself. Basically you're preaching to the choir. I plan to get (maybe do) the following implemented; a user authentication system with several methods, manual approval is one of them.

II. Karma for stories, articles and links

We've talked about this, and if you've got good ideas for karma we'd like to hear them as many many sites deal with this problem. I'd just say Karma for modules though and let developers / admins decide what gets karma.

III. Add, more of a modular design, for front end. I.E. Allow users to insead of having to use a theme arround a fixed block engine (much like almost all portal wares) give users the option of just calling one parsed html page, with the options they want. This would allow anyone to quickly design a site they way they wanted it, without having to understand nested tables ectra, or use the current theme design

Definitely a point of contention for a lot of people involved with geeklog. This comes from two places though, people developing themes and people developing interfaces. It's non-trivial but something I agree would make geeklog much nicer.

IV. Add more options to the conf file, so nothing is hardcoded

Yeah, we're way ahead of you on this one. Probably going to move the configuration to the database with lots of descriptive text around the options so people understand exactly how they can change things. And, being db enabled, we'll make this web based configurations.

V. Add caching sparse system, ie rewrite index.php?=topic/sidXXXXX$pid=XXX to index/topic.XXXXXX,XXX.html. With an configurible caching time for Blocks and for main section. This would not only make the site use less resources and speed up page load time, but would also make dynamic pages search engine friendly

You're actually talking about 2 issues here caching, and search engine friendly urls.

Caching is something that we have to think about long and hard. Tony and I had a discussion the other day about the scalability of geeklog, if geeklog is going to run a pretty decent site (something along the lines of slashdot or thinkgeek or freshmeat, you get my point?) it'll obviously need to be run on a farm of servers hitting one beefy database with all the niceties of load balancing and fail over, etc, etc. Caching is a function of the machine it's on naturally, but we can force cache through the filesystem. Some of this becomes difficult based on user preferences, sticky connections, good use of cache, nice timeout settings, etc. Definitely something to think about from a performance standpoint, and we are.

URL rewriting, aka, search engine friendly URLs is another issue that's come up quite a bit. (you should live in #geeklog with the rest of us) :) There are several issues/options with this:

First, the best method is probably some combination of apache's forceType and modrewrite functionality.
- For the uninitiated, forceType directives allow a user to configure their apache server to force the mime-type of all the files in a given directory. This would be useful in our case to forceType php on all the public_html directory files. Then we could have files like geeklog.com/users, stories, etc. No .php extension needed.
- Mod rewrite on the other hand allows you to take a url like geeklog.com/stories/1/2/3 and rewrite it to stories?storyId=1&something=2&this=3.
- Problems:
  1. You need to be running apache
  2. You need to compile apache with both mod-rewrite and forceType
  3. You have to be able to handle the configuration issues of both modules
  4. You probably need to be running your own server and not be in a hosted environment.
A second option is to use PATHINFO in php.
- There is a known bug with this and IIS.
- This does provide a decent crossplatform solution once the IIS bug gets worked out and doesn't require any server configuration

Search

Resources

About

Getting started

Support

Development

Topics

User Functions

What's New

Articles last 4 weeks

Comments last 4 weeks

Pages last 4 weeks

Links last 4 weeks

Downloads last 4 weeks