Hello,

I'm a recovering phpNuke admin and will be moving all my domain portals to GL once I know the GL code in more depth.

I *very* much appreciate all the hard work you guys are doing. GL is a fine effort and immensly easier to work with.

From an upgrade standpoint, I've had minor difficulties in upgrading and keeping my test portal current with the latest releases due to two reasons:

1) Each plugin has various bits installed in different areas of the server hierarchy, and then some injected functions in GL supplied files.

2) Some Plugins seem to extend existing GL tables, rather than staying entirely within their own tables. Is this simply an exception that breaks the rules?

The plugin developer's guide is a little old and I understand that it's purely a resource issue preventing the update. I know how that is!

The real question here is:

Have you guys recently considered any techniques for organizing the plugins in such a way that the code for each plugin can reside in a single dir hierarchy?

Possibly with an entry point file & function that handles "registering" the hooks that they implement, via the plugin admin page, the plugin admin function can discover the plugins installed the hierarchy.

This way, when we get a new version of GL core, we can overlay the new code and not have to worry about merging core files with plugin-specific modifications.

Also, (sorry to drag on), I currently use the the www.Aeonserv.com system to develop a Geeklog site prior to deploying. The HTMLArea (WYSIWYG) widget is one that many (but not all) find quite useful. It would be great to have a single core function that could be called throughout GL to produce/return multi-line TEXTAREAs. This might make it easy for developers install WYSIWYG plugin editors without diddling the GL Core code.

Anyway, thanks a ton for all your hard work on this system.

-Jeff Hare

If you are interested in discussing development-related issues, I would recommend posting to the geeklog-devtalk mailing list (link is to the left). Posts there tend to generate more discussion.

That's not entirely true. Plugins should only have code in a few directories. For example sake, let's assume our plugin name is myPlugin:

1) /path/to/geeklog/plugins/myPlugin
This is the primary plugin directory where the SQL files, docs and common code should go.

2) /path/to/geeklog/public_html/myPlugin
This is where the interface into your plugins will reside (everything except for the admin interface).

3) /path/to/geeklog/public_html/admin/plugins/myPlugin
This is where any administrative interface into your plugin should go.

4) (optional) /path/to/geeklog/system/lib-custom.php
This is where some plugins may recommend to add code for things like PHP blocks and what not. This, IMHO, isn't the best place...I'd instead put it in the functions.inc for the plugin instead.

Geeklog 2 is addressing this in one of two ways. First, we are going to encourage plugins to use the built-in Model-View-Controller (MVC) package. This will allow litterally all code to reside in a directory outside of the webtree. For those plugins who don't want to use the MVC package we will recommend how to still achieve putting code in only one directory.



Right, this is bad practice. We have tossed around the idea of "certified Geeklog plugins" which would require plugins to meet a basic set of requirements before we will recommend their use on their site. The biggest problem with this is finding someone who would be willing to devote time to review plugins (any takers?).

Keep in mind that any plugin that requires modification to core GL files is not a true plugin. Your HTMLArea widget is one such example. That doesn't diminish the usefulness of the code, it just means that coordination between the other and the developers of GL hasn't reach a point where we can discuss how to better integrate things so modification to the core GL code doesn't have to happen. In fact, we have made many modifications to the GL plugin API to meet the needs of plugin authors and we would recommend others do the same.

Thanks for your input.

--Tony

---

The reason people blame things on previous generations is that there's only one other choice.

[quote by jeffhare] Some Plugins seem to extend existing GL tables, rather than staying entirely within their own tables. Is this simply an exception that breaks the rules? [/quote]
Jeff, plugins generally use their own tables but there are also blocks and other modules that are not true plugins. Some of these components may require tables to be extended. True plugins are installed from the plugin Editor and contain their own SQL to create the necessary tables.

Also, some of the contributed components may be early projects by developers or quick projects. They certainly can be improved but we try to not be too critical and any contribution is better then none.

---

Geeklog components by PortalParts -- www.portalparts.com

Thanks for all the replies.

I monitor the devtalk mailing list, but since I haven't studied the entire implementation yet, I didn't really feel entitled to start a full discussion on the matter.

As for the HTMLAREA widget, I totally agree that it isn't a plugin, but if the instanciation of textareas were done with a central function call, then that would might it easier to "plug in" different wysiwyg editors. I'm just thinking that anything we can do to make it less necessary to edit the gl-core the better.

Again, Thanks! And perhaps I'll be able to help out in some substantial way in the coming year.

Cheers!
-Jeff

I haven't used HTMLarea (mainly because earlier versions only worked with Internet Explorer), so I don't know what's needed to integrate it into Geeklog.

There is, however, a tiny "hidden" feature that may help here: You can have "extended" versions of all of the editor templates. For example, the template for the story submission editor (for normal users) is submit/submitstory.thtml. Now if you have a submit/submitstory_advanced.thtml and the config option $_CONF['advanced_editor'] is set to 1, then Geeklog will use the extended template instead of the normal one.

Now, as I said, I don't know if this helps in any way, but maybe we can extend this idea to make the integration of alternative editors easier in future versions.

bye, Dirk