[geeklog-devel] Plugin help --- Package Extractor
joe at ThrowingDice.com
Sat Jun 16 15:37:47 EDT 2007
At 10:56 AM 6/16/2007, Chris 'Chipper' Chiapusio wrote:
>I still see plugins refrence their compatability with geeklog by the geeklog
>version. You might consider versioning the GeekLog PLugIn API, thought its
>honestly too early for me to be posting (and i've only finished on cup of
That's not usually a problem actually. Most plugins are dependent of
a specific function existing and so the geeklog version is just a
minimum. I would assume PEAR allows compatibility with version 1.2.3
__and up__. Also the plugin API changes with just about every
version. It is far more likely that the Geeklog version is changing
to accommodate changes to the plugin API since new functionality
usually means new APIs.
>OK, here is where I wander into themes....
>I've been a die-hard redhat/fedora user for over ten years so I don't know if
>other distros do this but... for example apache. In Fedora apache reads in
>all the config files named /etc/httpd/conf.d/*.conf. Themes should have a
>capability API level, and a structure so the aforementioned PEAR installer
>will drop the appropriate plugin theme templates into an automagicly useful
Actually themes are almost always invalidated by each new version. At
least one template file gains/loses fields each version.
>I guess to tie this all together and have it make sense: Plugins and Theme
>templates are in the same boat. You should be able to use them for GL 1.4,
>1.5, 1.6, etc. if there has been no significant changes. Your PEAR mechanism
>to retrieve plugins must chech compatability, and will that be a massive
>1-to-1 GLver-to-Plugin ver list? or a GL Plugin API Ver ->Plugin List?
That would make sense if Geeklog used sane version numbers. The "1."
at this point is just decoration. The .3 and .4 are major version
numbers. Major API changes occurred between 1.3.11 and 1.4.0 and
that's why it was not called 1.3.12. The last digit is more what most
projects call minor releases, which can contain new features as well
as bug fixes. If you go back a few weeks Dirk was debating whether or
not to release a 1.4.1-1 with just bug fixes or cutting CVS current
over to 1.4.2. What's new in 1.4.2? The entire story system was
revamped. Most projects would be calling that 1.5 or 2.0. Not
Geeklog. We don't have fast climbing version numbers.
The other reason the 1 is just decoration of course is because GL1
and GL2 will share not a single line of code. They are independent
projects linked only by history of the developers.
>or will it be more granular and the plugins request explicit capabilities? I
>guess the current API is not designed for that type of structure (My brain is
>thinking of ESMTP at this point).
You could write a plugin that would do a functions_exists() to
determine what functionality exists in core. But there are usually
security problems with older versions and it is just easier to assume
no one is running them any more.
>This new installer method might also work for themes, but then we need a
>theme package structure that would support multiple versions/capabilities, or
>a range of version/capabilities.
I have a few rants about themes. The Package Extractor was going to
support them but I find there are few standards when it comes to
theme packaging. I think this is because themes don't follow the
normal geeklog rules for most things.
* Themes don't exist in the database. This means they ignore the
geeklog permissions system. If the theme files are in the right
directories, they just work and are available to all users.
* Plugins have a hard time supporting themes because their templates
would have to be duplicated to every theme directory.
* Themes can have a functions.php file that if it is present, it will
be loaded. Somewhere that must be exploitable but I have figured out
how yet. If someone faked their theme cookie in some manner, an
arbitary file could be loaded by geeklog. If themes were loaded only
via the database, this would require both the bogus cookie and a
bogus database entry.
* ALL of the thtml files in a theme should be outside the document
accessible from the web.
* The name of the theme is the name of the directory. It would be
nice if there were a public name and a directory name for each theme
so you could have the theme called "Silver Bullet" and the directory
was "silverbullet". This would be made easy by the database having
two name fields. The database tables would be something like
public_name, dir_name, is_enabled, gl_ver, and the perms sextet.
I would like to see a project for fixing those problems. There should
be a layout directory at the same level as system and plugins where
all the interior theme files (and the functions.php file) are
located. And the current /public_html/layout structure would only
contain files that need to be web accessible. There'd be
$_CONF['path_layout'] which would move to /path_to_gl/layout and
$_CONF['path_public_layout'] which would be the old path_layout value.
Yes, I know. Another one of my major refactoring projects....
>This has never been an issue previous because every install was manual and
>humans are (usually) very good at pattern matching (Read the William Gibson
>book by that name BTW) but now we are going to make it a pretty point n'
>click interface and we probably dont want 17 copies of the forum plugin in a
>repository so you can support GL 1.4.1, 1.4.2, 1.4.2b, ad nauseum, the
>everyones filemgmt plugin has become.
Again, this is really not a problem. Forum 2.3 runs on GL 1.3.8 to
1.4.1 (in my experience).
Throwing Dice Games
More information about the geeklog-devel