[geeklog-devel] Plugin help --- Package Extractor

[Joe Mucchiello]

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
>coffee).

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
>location.

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 
root. Only images/media, css and javascript files should be 
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).

----
Joe Mucchiello
Throwing Dice Games
http://www.throwingdice.com