All configuration options should be stored in the database as well.

I understand there is "some" performance issues with this but there are ways to minimize the impact of doing this.

I usually add the Canadian Provinces to the list of static locations for registrations. This is something I have to do everytime I update geeklog. I am sure some people don't want the US States at all. Others might like to have different countries.

Also it would be nice if the administrator could turn on or off trackbacks, and toggle topic icon locations from the control panel (or from the theme). Everything but paths in every config file should be at least updateable from the control panel, except of course authentication for the database server.

Also upgrading tends to be a pain because things like lib-custom.php are included in the gzipped distribution. This might be better to be included as lib-custom.php-orig and have people manually rename it the first time they install. Or have PHP check to see if lib-custom.php exists, and if not copy lib-custom.php-orig to lib-custom.php. Also for those of us without shell access, we have to pick and choose directories to FTP because ftp will overwrite everything else. Maybe take those directories that are just geeklog (docs, fckeditor, help, javascript, language, admin**) and put them under a customizeable directory off the root (say "gl" for default). This entire directory could be dumped and copied. ** The admin plug-in directories should go under the actual plug in. (Why put part of it in the admin directory when we could just check for something in the "admin" directory of the plugin??? Just more places to move stuff and forget to do things me thinks. Same goes for the stuff we don't change in the "geeklog/path" config directory. lump all the sql, and pear, language, system files into a gl directory and leave the dynamic stuff backups, logs, plugins, config.php to a "site" directory.

This part is way out of scope for this thread, but I thought I would throw it out there for Geeklog V2.0 or something to keep in mind.

With these changes we could host multiple geeklog sites (as I do) from one geeklog install. Additional instances of geeklog would use the same base geeklog install. Each instance would only require a "backend" directory, a images directory, a config directory (for logs, and config.php, and lib-custom.php only), a layout directory, even plug-ins ideally could ideally be pulled off of the "base" install but that would be up to the plug-in developer to make it work.

Obviously this system would require that all sites run the same version of geeklog and be upgraded at the same time, it wouldn't fit for a site that runs with an adjacent development site (though the plug-ins could be development) layout could be completely different, config options completely different, URL completely different.

Right now your thinking.. wow this is way too complicated, but most of it could be done with a config.php that checked the URL and redirected to a secondary config-sitespecific.php so www.benjudson.com (and benjudson.com) could be redirected (perhaps a regular expression) would both use config-benjudson-com.php. Which has different paths than www.othersite.com.

path-to-geeklog/config.php
path-to-geeklog/config-benjudson-com.php
path-to-geeklog/config-othersite-com.php
path-to-geeklog/public_html/lib-common.php
path-to-geeklog/public_html/images-benjudson/
path-to-geeklog/public_html/images-othersite/
path-to-geeklog/public_html/docs/
path-to-geeklog/public_html/othersite/docs/

(You get the idea I hope)


OR somethinglike http://www.benjudson.com/gl.php?file=/docs/changes.html (which is alot messier, though more flexible, while messing up logs, and stats and stuff yeah I know).

I would be open to any implementation that would allow for a single installation of geeklog with multiple instances (or sites) running off one installation.

indeed because the solution is already here:
http://www.geeklog.net/forum/viewtopic.php?forum=1&showtopic=62511

~~~~
May I suggest two more things: This forum needs a section where feature requests are being "bread" and discussed and no feature request should be accepted which has not been discussed thoroughly. This has nothing to do with bjudson it is more that some feature requests are being ill explained and rather taylored for only 1 person from one point of view. A discussion is usually more fruitful.

I have been using URL Rewrite for a while now on IIS 6.0 and PHP 5+ with no problems.

---

One of the Geeklog Core Developers.

Open ID support. Geeklog as a client (identifying visitors to my site via their OpenId URL) is a higher priority for me than Geeklog as a server (allowing my Geeklog to identify me as an OpenID user to other sites).


I have also been thinking about hosting multiple Geeklog instances from a single installation, as bjudson suggests. I haven't gotten a chance to test my theory, but I think it could be done fairly easily with existing code.

If I'm correct, each instance just needs a unique config.php file, which would point to either a unique database or a unique table prefix within a common database. So you just need to invoke a different config.php file for each instance.

That could easily be done (I think) by changing the line in lib-common.php that specifies the config.php path to generate the config file name from the URL. So you could have multiple URLs which all point to a common Geeklog directory, via symlinks or aliases or whatever. The lib-common.php in that single directory would read different config files depending on the URL. Am I missing something? Is it harder than that?

yes, the solution. As I said above it is here:
http://www.geeklog.net/forum/viewtopic.php?forum=1&showtopic=62511

You may want to check out (and possibly join) the recent discussion on the geeklog-devel list then.

bye, Dirk

The only flaw with this is the various instances must share their plugin/config.php files. The plugin's config.php is usually loaded from its function.inc. So you'd have to have all the uploads for filemgmt go to the same directory, for example, and if they didn't share a database there is a chance for collision of filenames. (slim chance really)

I agree with Bjudson: there needs to be away to edit all non-critical Config things in the admin control panel. Its not difficult to change the config file through FTP, it is just time consuming.

Kinda away from the realm of this thread:
I would like to see polls integrated into the forums. Just something that users can use for fun in their threads. On my site, I have a general forum, and it would be great if people could use the poll for their personal enjoyment. I know many a time, people run threads about sporting events, and it would be cool if they could just do a little poll at the beginning of their threads asking about who is going to win. I know some other forums already have this, and I would like to see that in geeklog forums

Yeah, that would make me very happy! With Tagcloud?

---

Dutch Geeklog sites about camping/hiking:
www.kampeerzaken.nl | www.campersite.nl | www.caravans.nl | www.caravans.net

[#404] Weblink subcategories

I'm going to take the category management out of Glinks and submit it as a patch for Links. Then the Glinks plugin can be killed off.

Cheers,

Euan.

---

-- Heather Engineering
-- No job too small

Author field would be highly appreciated. It will allow the admin to enter an author for each article or story entered by the admin.


Right now, when the admin enters an article, the article is shown as contributed by the admin.
With author field somewhere in the story editor, the admin should be able to enter the author of the article.

This is useful for my site, where I cull MANY articles from different international sites, each article having different author(s).

I currently use the "changeowner" hack to change admin's full name to the name of the actual author of the article. But this is cumbersom as I have to first create a user with the author's name as the full name. There are many auhtors, and some authors write once in a while.

I have been a GL devotee for a while now and ususally do not build a website without using it as the framework.

I must say that the list I am about to give is a lot shorter with the newest 1.4.1 version of GL. the developers were thinking about the same issues I was and really cleaned up a couple of areas.

Here is my list of ideas

Link CSS for HTML editor to site CSS
Change the FCKeditor CSS to reflect the site CSS so that styles and formating carries over to the Advanced Editor

Fix Blank Block Issue
If you leave the title of the block blank, it works fine, but then you need to put a space in everytime you save the block in the future

Improve Backup
Add Page history to SP
The backup page needs to have an option to download backups, zip backups, and download selected sections. Also if there could be a version of the static pages created so you could roll back SP changes, that would be great as well


Create error message if user is not yet activated and needs password resent
If a new user is not yet activated and trys to have their password resent, there is no error message, just a blank first page.

Calendar repeating events
It would be great to be able to add an event that happens every monday for example.

If there is anything on here that the core GL team would like to add, I would be willing to code it, if it would be included in the core distrubution.

I used to change the core code, but now I do that less since I have so many GL installations to support.

Thanks for such a great project,

---

I work for a Wilmington NC Attorney

You can fake this by taking the existing SP and duplicating it, giving it the same id with _backup or _ver_1 appended to it. remove all permissions and save. Now go back to the original and modify it.

Easier Theme Upgrades (Core & Custom theme file separation)

Along the lines of lib-custom.php, which separates custom code from core files, all themes should have a "custom" or "local" folder in each theme directory where edited copies of theme files are kept, and used from preferentially, if present. This minimizes the effort of having a laundry list of backup files, or doing a diff with old template files each time you realize that the theme has to be upgraded.

With this format, one downloads the latest core theme (say professional) with all the right admin files etc, and just copy over the custom directory from older versions.
1. Is it going to stop one from having to redo style.css, header.thtml and other usual suspects with files from the new template? - Probably not.
2. Does it make sure you have all the latest admin templates? Yes.
3. Does it make changes more traceable when multiple admins are changing templates? Yes.
4. Does it make theme development easier? Perhaps.

(There seem to be quite a few theme updates with recent versions - I recently gave up on a custom theme - a hacked GL1.3.6 version of aeon - and ended up modding the latest professional theme because upgrading the old theme seemed too daunting).

I currently do this, the only problem is that unless you change the permissons, you have a couple versions of the file for the search.

Also, I only need the feature when I forget to make a backup or the editor messes something up,

---

I work for a Wilmington NC Attorney

Ok here's one for you... Every new plugin has it's templates in the plugin folder, why is the plugin's templates not in the theme folder? I can't tell you how much frustration that has caused me recently, especially when trying to design multiple themes for the same site that are radically different. The forum does it (or did it, haven't looked at the latest version of that yet) why can't that be specified as a requirement in plugin design?

-Rob

Another big one, why not just have one template for a block instead of a featured story block, a left block, a right block, etc and pass the class to the template file from whatever function calls it? So if the function that builds the left blocks is running it knows to use the left blocks css when building a block.

-Rob

1. The event types need to be in a language file, not the config.
2. More international method for adding events, eliminate US states, maybe just have a text area
3. FCeditor for the description field
4. Improved Event Searching

thanks,

I have someone translating the events lang file to spanish, it will be done soon.

Andrew

---

I work for a Wilmington NC Attorney

First of all, I should thank you all for the way GL has developed over the years - I have been a GL user for my sites for a number of years and, apart from periods of frustration when things have not worked as expected (partly due to my lack of expertise in php, partly due to trying to keep up with changes), I have found GL serves my needs well.

If I may make a few suggestions for the next phase:

1. Implementation of XHTML or whatever is required to ensure that GL sites are accessible (i.e. meet disabled/accessibility standards e.g. http://www.w3.org/WAI/) - for example, giving the user the ability to change font size/colour as standard (rather than having to come up with alternative templates which I still haven't managed to get working ) and using access keys. This is increasingly a requirement for commercial, education or indeed most sites (it is a good thing to do, in addition to being a legal requirement in some countries). Plone provides an example of this in action http://plone.org/accessibility-info.

2. To get hierarchical/category base link system, perhaps using PhpLinks as the base (being slightly selfish as I am stuck using an old version of GL since Squatty stopped supporting the phplinks/GL integration and Links was moved out of the core code, so I cannot work out how to get it working with the recent versions of GL ).

3. Implement or integrate Mail2Forum, as this is a really useful - advanced - way of linking email based mailing lists and Forums (I have tried implementing through using GL/phBBbridge but have not quite managed to get it working yet!).

Many thanks

Anonymous

Accessibility doesn't depend on XHTML. Most, if not all, that is required for this would need to be done in a theme. There are probably a few places in Geeklog that would also need to be changed, though.

I'm no expert in WAI compliance. If anyone wants to work on this, please do so. We'd be willing to help in any way we can.


As for your #2: We already have a bounty for links subcategories and a contestant (two, actually). So that should be coming with the next release (maybe earlier, if we can roll it into a plugin that's compatible with 1.4.1).


A mail2forum gateway (your #3) is something that would best be done as a plugin. It sounds interesting, but I don't think it's something a lot of people would need.

bye, Dirk