Plugin hook suggestions for cpg1.5.x

[Αndré]

Both suggestions can already be done without new plugin hooks.

upon upload, have uploader remember last location of last image

Check for the 'album' parameter and if it isn't submitted, get the latest upload from the database (there's also stored the album) and redirect the user accordingly.

remove time limit on selecting images to upload

That's related to the form token config setting.

[Veronica]

I have now been working on this plugin and want to release the plugin version 1.0.
In the install/uninstall functions I have code which will add/delete this hook until an official hook is released.

I'm currently working on an Youtube URL user upload plugin which will work with this plugin Remote videos for cpg1.5.
I have added a third upload form in addition to swf and single file uploads.
Also I have made a conversion tool for the old Youtube hack for cpg1.4 by Nibbler so Coppermine sites still on cpg1.4 can upgrade and keep their Youtube links.

To make this plugin installable by anybody I want a new hook in db_input.php to process "uploads" which are not file uploads.
My suggestion for a new hook is like this in the last lines of db_input.php:

default:
    if(CPGPluginAPI::action('upload_process',$event)) break;

    // Unknown event
    if ($CONFIG['log_mode'] != 0) {
            log_write('Denied privileged access to db_input.php (unknown event) for user '.$USER_DATA['user_name'].' at ' . $hdr_ip, CPG_SECURITY_LOG);
    }
    cpg_die(CRITICAL_ERROR, $lang_errors['param_missing'], __FILE__, __LINE__);
}

?>

[Αndré]

Why do you need a plugin hook in db_input.php? Isn't it possible to submit the third upload form to another file (which will reside in your plugin folder)? I've currently no time to look into this in detail.

[Veronica]

OK I will do input to another plugin script without going via db_input.php

[Veronica]

Why do you need a plugin hook in db_input.php? Isn't it possible to submit the third upload form to another file (which will reside in your plugin folder)? I've currently no time to look into this in detail.

I made the correct set_include_path to get all script includes to execute with form processing directed to the plugin folder.
Using a submit destination to a script in the plugin folder will make init.inc.php fail in testing

if (file_exists('include/config.inc.php'))

giving me an attempt to reload install.php from the plugin folder.

Now I will go back to my first setup with a hook in db_input.php

[Αndré]

Access the file via index.php?file=your_plugin_folder/file_name_without_extension. That way it runs in Coppermine's scope and you don't need to include init.inc.php.

[Veronica]

Thanks works OK now

[Veronica]

Access the file via index.php?file=your_plugin_folder/file_name_without_extension. That way it runs in Coppermine's scope and you don't need to include init.inc.php.

Disadvantage with this method is that language file setup is according to index.php requirements and not as db_input.php
which will not give me standard phrases for define('DB_INPUT_PHP', true); like error messages
I can add these texts used in the plugin to my plugin language file but it's not a good solution with duplicates so my hook request is still best solution for me.

[gmc]

Email on comments:
Building on thread http://forum.coppermine-gallery.net/index.php/topic,71072.0.html which sends email when a comment is posted.
I adapted a variation on this for a customer - looking at implementing a plugin to handle this function, but lacking appropriate hookpoints from what I can see.

The related thread updates db_input.php, but this only addresses comment submission, and not approval (if approval is required...)

Looking for hookpoints in db_input.php and reviewcom.php...
A zip of patch file based on SVN 8668 is attached to detail my thoughts.  All 'action' plugins with no data returned.
Addition of 5 hookpoints:

• 'comment_updated' in db_input.php
• 'comment_posted_anonymous' in db_input.php
• 'comment_posted_registered' in db_input.php
• 'comment_approval_processed' in reviewcom.php
• 'comment_multiple_approvals' in reviewcom.php

If this looks acceptable, I'll work on the plugin code to exploit... Obviously will have a min version at whatever level the hookpoints get included.  I haven't done any testing with this in plugin form yet - wanted to see if I was approaching this correctly, and if additional plugin points like this would be considered.

Thanks!

[Αndré]

Without reviewing the core code parts or your patch file yet, some hook names should be replaced in my opinion:

• Replace comment_posted_anonymous and comment_posted_registered with comment_posted, or is there a good reason to use 2 different hook names?
  
• Replace comment_approval_processed and comment_multiple_approvals with comment_approved, or is there a good reason to use 2 different hook names?

[gmc]

Without reviewing the core code parts or your patch file yet, some hook names should be replaced in my opinion:

• Replace comment_posted_anonymous and comment_posted_registered with comment_posted, or is there a good reason to use 2 different hook names?
  
• Replace comment_approval_processed and comment_multiple_approvals with comment_approved, or is there a good reason to use 2 different hook names?

Thanks for the input...
For #1, I can easily change to one name.  I didn't need the distinction, was just thinking about other possible uses, but enough data is passed (or will be in next revision) for the plugin to easily determine if needed.

For #2, the parameters passed are quite different... (as is the core code)
For single comment, I was passing the 'single approval array' from base code while for the multiple, an array containing 2 strings - list of approved and list of rejected as generated by the base code...  I could reformat the single case to look like the multiple if a single hook name is desired...

I'll do a little testing with it and post a revised patch.

[gmc]

Revised proposal:
Looking for hookpoints in db_input.php and reviewcom.php...
A zip of patch file based on SVN 8668 is attached to detail my thoughts.  All 'action' plugins with no data returned.
Addition of 3 hookpoints:

    'comment_updated' in db_input.php - called when an existing comment is updated in database
    'comment_posted' in db_input.php - called when a comment is inserted to the database
    'comment_approvals' in reviewcom.php - called when a comment(s) are approved/rejected with list of approved/rejected comments

I've syntax checked - but haven't yet written the plugin code to process (convert existing mod code with some additional features)...
If acceptable to add these hooks, I will proceed.
Greg

[Αndré]

I slightly renamed all hooks and the variable names of the comment_approve hook (formerly comment_approvals) for consistency reasons. Patch file attached.

I had no closer look at the hooks (i.e. if the submitted data is sufficient), so please report if we can use them as they are and I'll commit them to our SVN repository.

[gmc]

Modifications look fine (of course )
Name changes are fine in hooknames and variables (I almost made that variable change myself... ) - and moving cpg_db_last_insert_id() into the API call makes sense over a separate assignment.

Plugin now on the 'todo' list...

[Αndré]

Added plugin hooks 'comment_update', 'comment_add' and 'comment_approve' in SVN revision 8671.