forum.coppermine-gallery.net
Support => cpg1.5.x Support => cpg1.5 plugins => Topic started by: Joachim Müller on July 31, 2009, 08:02:26 am
-
Although cpg1.5.x is in the feature freeze stage, which means that no more features can/will be added before the release, the dev team has decided that there will be an exception to this rule: plugin hooks can still be added.
We want to encourage plugin authors to request additional plugin hooks at this stage, with an alpha release being available to test things with.
So if you want to start porting a plugin written for cpg1.4.x to cpg1.5.x or if you have an idea for a new plugin for cpg1.5.x that you want to write, please go ahead and let us know in this thread what plugin hook you need.
@newbies/non-coders: this thread does not deal with plugin requests, so please do not ask for plugins to be written or ported for you here. This thread is for coders who already know what a plugin hook (http://documentation.coppermine-gallery.net/en/dev_plugin_hooks.htm#plugin_hooks) is. This thread only exists for coders to request additional plugin hooks.
If you actually want to request a new hook, just roughly explain what your plugin is suppossed to do and where exactly you want your hook to reside at (between line X and line Y in file Z). Please also state what the expected return value will be (if any).
Joachim
P.S. All unrelated replies to this thread will be deleted without further notice
-
May I add this plugin hook to include/mailer.inc.php?
$sender_email = CPGPluginAPI::filter('cpg_mail_sender_email', $sender_email);
Explanation: I use a free hoster for my CPG. I figured out, that emails from the sender 'xyz@googlemail.com' will not be sent but a message is displayed, that the email has been sent successfully. If I change the sender address to '@gmail.com' everything works fine.
Maybe there are some limitations on other free hosters and someone else can use this hook.
Edit:
I just remembered, that it's also not possible to sent emails with more than one recipient on my webhost. So I'd need another hook to sent multiple emails with only 1 recipient or to sent emails sent to 'admin' only to 'gallery_admin_email'.
Additional plugin hooks can't hurt, right? 8)
-
Plugin hook requests. Pages with user (guest level) input. Purpose - spam control, adding captcha or other methods to user's form submissions.
This is for three pages now not protected by captcha: Ecard + Report to Moderator + Login.
Example used here is ecard. I am not sure if I have the right line numbers or if the concept/request
is being communicated properly. In any case I didn't want to write a long post and will be happy to reply if needed.
Ecard example hook 1 validate submission - somewhere between lines 149 - 156 and similar to:
$error = CPGPluginAPI::filter('captcha_ecard_validate', $error);
Ecard example 2 display a captcha or alternative - at or below line 425 and similar to:
$subecard_print = CPGPluginAPI::filter('ecard_submit_print',$subecard_print);
The same concepts also for Report and Login: A hook to show a captcha on the form at or near the Submit button and a hook prior to where the submission is processed and data is written to db, etc..
This is not a direct request for the exact same Captcha hooks to be placed into Ecard, Report and Login as the ones now being used. However if that would be more compatible/consistent with the overall way 1.5 is to run then please consider it as a suggestion only.
-
May I add this plugin hook to include/mailer.inc.php?
Added plugin hooks 'cpg_mail_to_email' & 'cpg_mail_sender_email' in r6545.
-
Please, if it is possible and not too much trouble, could this hook be added?
File: index.php
Location: Directly below this: (around line 1122)
$elements = explode('/', $CONFIG['main_page_layout']);
Similar to:
$elements = CPGPluginAPI::filter('alt_page_layout', $elements);
Purpose: Plugin to allow differences in page layout (from home page) when visitor clicks on "Album list"
I hope that it is not too late for requests here. At the moment I have a rough working version of a plugin using that hook. It seems to function OK without interference elsewhere.
Thanks!
-
Did as you suggested.
-
Hey,
I needed a hook to do an md5 dupe check on uploads. These get triggered right before the file is moved to it's final location.
For HTML upload in file db_input.php
Find line 619:
$uploaded_pic = $dest_dir . $picture_name;
After that add:
// Give plugins a chance to error check
$upload_plugin_error = CPGPluginAPI::filter('upload_html_pre_move');
if ($upload_plugin_error) {
cpg_die(ERROR, $upload_plugin_error, __FILE__, __LINE__);
}
For SWF upload in file upload.php
Find around line 1015:
// prevent moving the edit directory...
if (is_dir($path_to_image)) {
echo 'error|'.$lang_upload_php['failure'] . " - '$path_to_image'|0";
exit;
}
After that add:
// Give plugins a chance to error check
$upload_plugin_error = CPGPluginAPI::filter('upload_swf_pre_move');
if ($upload_plugin_error) {
echo 'error|'.$upload_plugin_error.'|0';
exit;
}
Works great for me ...
Cheers
Jayhunter
-
Hey,
I needed a hook to do an md5 dupe check on uploads. These get triggered right before the file is moved to it's final location.
For HTML upload in file db_input.php
Find line 619:
$uploaded_pic = $dest_dir . $picture_name;
After that add:
// Give plugins a chance to error check
$upload_plugin_error = CPGPluginAPI::filter('upload_html_pre_move');
if ($upload_plugin_error) {
cpg_die(ERROR, $upload_plugin_error, __FILE__, __LINE__);
}
For SWF upload in file upload.php
Find around line 1015:
// prevent moving the edit directory...
if (is_dir($path_to_image)) {
echo 'error|'.$lang_upload_php['failure'] . " - '$path_to_image'|0";
exit;
}
After that add:
// Give plugins a chance to error check
$upload_plugin_error = CPGPluginAPI::filter('upload_swf_pre_move');
if ($upload_plugin_error) {
echo 'error|'.$upload_plugin_error.'|0';
exit;
}
Works great for me ...
Cheers
Jayhunter
Your hook suggestion is too specific imo. I suggest to add the following hooks.
Instead of adding
// Give plugins a chance to error check
$upload_plugin_error = CPGPluginAPI::filter('upload_html_pre_move');
if ($upload_plugin_error) {
cpg_die(ERROR, $upload_plugin_error, __FILE__, __LINE__);
}we should add
CPGPluginAPI::action('upload_html_pre_move');
And instead of adding
// Give plugins a chance to error check
$upload_plugin_error = CPGPluginAPI::filter('upload_swf_pre_move');
if ($upload_plugin_error) {
echo 'error|'.$upload_plugin_error.'|0';
exit;
}we should add
CPGPluginAPI::action('upload_swf_pre_move');
You can check for errors directly in your plugin code and let Coppermine die etc.
-
Your hook suggestion is too specific imo.
You're right. Your suggestions are way cleaner. Wasn't thinking right. ;)
-
Will add that hooks probably tomorrow after reviewing the code. Maybe there's also another (better) solution ;)
-
Will add that hooks probably tomorrow after reviewing the code. Maybe there's also another (better) solution ;)
Yeah. Actually, the upload handling in total is a bit unclean imho. Kind of massed up to have the SWF upload and HTML form output in one file but the HTML upload processing in another. A clean separation into an upstream upload plugin/method handler and the different proccesing methods would be nice.
Back to topic.
In picmgnt.inc.php line 36 or so
$add_file_error = CPGPluginAPI::filter('add_file_start');
if ($add_file_error) {
return $add_file_error;
}might do the trick. But as i see it there is not much to work with at that point. For my purpose i'd need $work_image (or similar) to be global or to be passed with the filter.
An action hook wouldn't do me any good here, as I don't want to have to deal with further error handling (like unlinking files that have already been moved) only because my dupe check machted something. Also the different upload methodes need different output to die properly.
Well, maybe you come up with the ultimate idea. :)
Thanks very much.
Jayhunter
-
Hey there. Me again. :)
First I wanted to ask: Any news on the upload_pre_move or add_file_start hooks?
Secondly I got a new hook suggestion. I use it in conjunction with add_file_data_success and after_delete_file to keep a keyword cache up-to-date. Would love to see this one added.
In editpics.php find line 367
cpg_db_query("UPDATE {$CONFIG['TABLE_PICTURES']} SET $update WHERE pid = $pid");
After that add:
// Plugin filter to be called after a file update is committed
CPGPluginAPI::filter('after_edit_file', $pid);
And in edit_one_pic.php find line 165
$query = "UPDATE {$CONFIG['TABLE_PICTURES']} SET $update WHERE pid='$pid' LIMIT 1";
cpg_db_query($query);After that also add:
// Plugin filter to be called after a file update is committed
CPGPluginAPI::filter('after_edit_file', $pid);
Cheers
Jayhunter
Gallery @ http://htbackdrops.com (http://htbackdrops.com)
-
Hello jayhunter. I finally found some time to have a look at this topic again.
Regarding your dupe check:
- Hook 'upload_html_pre_move': if your plugin uses cpg_die(); everything should be okay. The file resides in the temp directory and will be deleted automatically I think.
- Hook 'upload_swf_pre_move': I currently don't know if Coppermine has a garbage collection for the edit folder, but I think it hasn't. So you'll have to unlink that file within your plugin before you return your error message.
- Hook 'add_file_start': I also think that hook isn't the best solution for your purpose because of the different output to die properly.
Regarding your keyword cache:
- Hooks 'after_edit_file': as you don't want to filter anything but you just want to perform something (without modifying the passed values) I suggest to use an action hook. It's been a while I had a look at the plugin API, but I afaik the only difference between filter and action hooks is the name (= they work the same way, can return something or do anything else).
-
Hey André.
Thanks for your response.
I actually already use simple action hooks for 'upload_swf_pre_move' and 'upload_html_pre_move'.
And I don't perform any file unlinking. upload.php and db_input.php don't do it either at that point. That would just have been necessary with the 'add_file_start' hook as the files already would have been moved to their final location here.
An action for 'after_edit_file' is okay for me too. I used filter here .. well, because I copied it from 'before_delete_file' or 'after_delete_file', which should be action hooks, too. Atleast by your definition. :)
Cheers
Jayhunter
-
I'll add the discussed hooks (except add_file_start) soon, probably tomorrow.
-
Added hooks in r7968.
-
I think that there should be a hook for displaying additional content in some special case pages or pages that show up in response to post, like information message after registering but when only admin can activate account - it would simplify making additional register futures like account activation only after payment.
Short example - user registers, only admin can activate account, user gets a message of this, the line 632 in register.php i responsible for this:
msg_box($lang_register_php['information'], $lang_register_php['thank_you_admin_activation'], $lang_common['continue'], 'index.php');
Now i would like to not change anything in register.php but i would like to display some additional markup with payment options to activate account, instead of only showing a msg_box, it should also give access to registered user data in case i would like to generate payment markup from that data.
In simple scenario this would work with an iframe that generates output based on user name or email sent as query string to that iframe script and showing the return html instead of that message.
As for now i need to change the register.php code, because there are no other way.
-
What's your actual hook suggestion? We already have some hooks for the registration process (register_form_create, register_form_submit, register_user_activation) and you can always use the page_html hook to modify every page.
-
It would be cool if the appearance of the album information in the "alblist" (index.php, function list_albums) could be customized by a plugin, to e.g. add a small button (social_sharing plugin (http://forum.coppermine-gallery.net/index.php/topic,70221.msg343858.html#msg343858))
Not sure if the hook should be best inside function list_albums (then probably just before calling theme_display_album_list)
- in the hook the plugin would have to go through all the $alb_list allbum datastructure at once, and could add to all albums' titles or descriptions or whatever it finds in the data structure.
or in function theme_display_album_list (then probably just before calling template_eval($album_cell, $params) )
- the plugin could adjust the $params and would be called individually for each album in a hook like this
- would it be a disadvantage for a plugin to use a hook which is "themed" and might not be called by all possible themes?
-
unsure if this is a revival, or will even be viewed, but i searched, and have ideas...but don't know code **yet))
upon upload, have uploader remember last location of last image (this is useful in single item upload) as many pics are 3 or more levels deep, and there seems to be a time limit on selection
remove time limit on selecting images to upload
-
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.
-
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__);
}
?>
-
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.
-
OK I will do input to another plugin script without going via db_input.php
-
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
-
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.
-
Thanks works OK now
-
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.
-
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!
-
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?
-
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.
-
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
-
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.
-
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... :)
-
Added plugin hooks 'comment_update', 'comment_add' and 'comment_approve' in SVN revision 8671.