Alex,

I'm getting a new appreciation for how the plugins work...

It would have been easier having a manual <G>... but I've almost got the upload files working -- under regular perl, no funny stuff and with the persistence tests commented out.

The big test will be if I can reverse engineer my files into the plug-in <G>...

I might wait til I have some sleep for that -- since everything else is working :

File upload, file display, file delete, file-size, etc.

PUGDOG®
PUGDOG® Enterprises, Inc.
FAQ: http://pugdog.com/FAQ

Got it! The first plug-in I have is working! I'm tweaking it a bit to get rid of the development code, but other than that it works great!



PUGDOG®
PUGDOG® Enterprises, Inc.
FAQ: http://pugdog.com/FAQ

did someone say a plugin... yummy :)

http://www.ASciFi.com/ - The Science Fiction Portal

Alex,

Also, is there a way for the plug-ins to "update" missing config options, while leaving existing ones set? So that if an update to a plug-in is setting up, it tests to see if the config options exist before setting them? To preserve existing settings?

In case you missed the other post, (this has been a fragmented weekend... little sleep)

1) Errors: How can a plug-in report errors to the install program. ie: fields not set, missing user input, conflicting user input, SQL errors, etc.

2) Also, I'm having problems with the _pre and _post hooks. They don't register correctly, so you need to "EDIT" the plug-ins user options, and just "update" them. That ensures they are reset properly. There should be a way to trigger this to make sure things are "updated" before install exits.

3) An official way of adding custom fields to the Admin. Such that, a field can have a meta-data attached that puts a link in the field_name box (the way alternate categories in links 1.1x did). That way, you can trigger a function or operation for a field that may need special setup. In this case, to view an image/link that is attached to the record, but it has wider scope.

4) Adding in directory management similar to FileMan so that routine maint can be done through the server without telnet or permissions conflicts (ie:nobody).

5) Plug-in clean up on aborted (error) installs... it leaves the plugin_name.pm file around in many cases, which causes an error on the next attempted install (plug-in exists but is not registered, or something similar).

6) A pop-up text window for editing the plug-in code, similar to the template editor?? :) The window is awefully small and limited, but it's really cool to be able to make changes. Also, since the changes are made directly-- an option to keep say -- 7 back-ups in case you have to roll back. It's kind of scarey making the changes on-line, then realizing there are no backups and that is your only 'working' copy!

7) There are other little things in getting the plug-ins to communicate (and vice versa) but I'll wait for the docs to see if they are addressed. I traced out the logic and figured some out, but still have lots of questions.:)



PUGDOG®
PUGDOG® Enterprises, Inc.
FAQ: http://pugdog.com/FAQ

Ahhhh... The two other things were:

1) a header and separator tag in the insertoptions features, such that you can add a header between tags and/or insert a separator. This is an array, so order is preserved, it would be nice to be able to break up the options into groups. If you are considering "hashing" this, then adding another field to the options "grouping" which would define which items were part of which administration group (or display page on multipage options) would be a good idea.

2) a "no-display" and/or "no-edit" option to the user tags. I know this may sound counter-intuitive, but sometimes there are options you'd like to display, but not let the user change, and there are sometimes install options you don't want the user to set and/or display. Especially during early development of plug-ins, and/or creating a "lite" version, this sort of feature would be invaluable.

Both these ideas are really extra field tags, not major changes to the logic (I would imagine).

PUGDOG®
PUGDOG® Enterprises, Inc.
FAQ: http://pugdog.com/FAQ

Hi Robert,

1. Your plugin install sub should just return, or return undef and set the error message in $Plugins::Yourpluginame::error variable. So the code would look like:

and the install won't happen.

2. Let me send you my copy as we have four plugins tested here and haven't seen anything like that.

3. Not current possible, you can add fields that will show up in the admin, but you can't add fields and then override them without altering the Link.pm or Category.pm file.

4. We are looking at putting this in.

5. This has been improved a lot since beta5.

6. We may make this available as part of 4.

7. Good idea, we'll look at improving that.

8. This has already been added. There is now a "registry" where plugins can save information that's not available to the users.

Cheers,

Alex

--
Gossamer Threads Inc.

What if I sent you my plug-in and see if you get the same result?

The first is always the hardest.


PUGDOG®
PUGDOG® Enterprises, Inc.
FAQ: http://pugdog.com/FAQ

I'd love to see it.. Mail away. =)

Cheers,

Alex

--
Gossamer Threads Inc.

on the way. :)

PUGDOG®
PUGDOG® Enterprises, Inc.
FAQ: http://pugdog.com/FAQ

Did you happen to be running under SpeedyCGI? You would have had problems with it if you had (I've fixed that bug now).

Cheers,

Alex

--
Gossamer Threads Inc.

Yes, I had tried speedyCGI. I had to drop back to plain old perl. I really should be doing that for development anyway... it prevents historical/caching errors especially when frazzled.

PUGDOG®
PUGDOG® Enterprises, Inc.
FAQ: http://pugdog.com/FAQ