How would we (can we?) use these to call the existing GL functions, like usermenu and the like?

Well, I'm not sure I am following you. In a block you would NEVER call usermenu() as it is called by showblock() in common.php

However, let's say you create a PHP block and your PHP Block function is phpblock_myfunction. You would implement that function in custom_code.php and, from there, you have full access to all the functions in common.php.

Make sense?

There should be a stronger committment to backward compatibility - ESPECIALLY if you hope to have third party plug-ins built. Upgrades will lag (again) if every time a new rev comes out, every underlying plug-in needs upgrading. With this free-wheeling approach to changes that affect the plug-ins, there won't be many plug-ins developed. If I had 3 third party plug-ins I may have to wait weeks or months for the plug-in authors to upgrade, so I can upgrade to the next version of Geeklog.

you have to realise, these changes as been a LONG time coming. The codebase has required some MAJOR overhauls, and there are major differences between 1.2 and 1.3.

After 1.3 though, the code will be a lot cleaner, so there will be less need for changes like this. It\'s just up to the plugin coder to keep his or her code up to date, not us.

I truly understand and appreciate what you are saying and I can agree with your sentiments 100%. However, keep in mind that 1.3 will be the first release with plugin support. Between now and the production release we may make more changes that would break away from legacy code that has long needed an overhaul. That is why we have not officially released the plugin documentation nor the How-to on building plugins. When we feel the core code is stable and ready for prime time we will release those documents. My recommendation is don\'t develop a plugin now unless you are willing to deal with a few changes between now and the release date.

Case-in-point, my first stab at adding plugin support, though workable, will need some modifications to make the coding easier to understand without having to know all the in\'s and out\'s of the GL internals. This will, undoubtedly, force me to rework all of the plugins I have built thus far. A pain, yes, but a necessary painful step to avoid confusion for plugin-developers after the release.

Bear with us...we\'ll get there.

Okay, I\'m going to say this calmly and three times slowly.

CVS is NOT release code.
CVS is NOT release code.
CVS is NOT release code.

Okay, now that is said, lets try to define a few things. 1.3 is turning into a fairly major release, which will include plugins and themes, as well as a tightening and reformatting of the code itself - and the changes are not finished yet. I\'m still altering the codebase to adhere to a workable set of coding standards. Additional developments, like a theme or plugin, cannot be accuratly workde on until a release is done.

This is one the whole POINTS between a CVS version and a RELEASE version.

\'nuff said.