Is somebody willing to answer me, please? :-)

inc/_misc/_plugins.class.php has a list of all of the available events that you can hook into :-

	/**
	 * Get the list of supported/available events/hooks.
	 *
	 * @todo Finish descriptions
	 *
	 * {@internal
	 * Additional to the returned event methods (which can be disabled), there are internal
	 * ones which just get called on the plugin (and get not remembered in T_pluginevents), e.g.:
	 *  - AfterInstall
	 *  - AppendPluginRegister
	 *  - BeforeInstall
	 *  - BeforeUninstall
	 *  - BeforeUninstallPayload
	 *  - GetDefaultSettings
	 *  - GetDefaultUserSettings
	 *  - GetHtsrvMethods
	 *  - PluginSettingsUpdateAction (Called as action before updating the plugin's settings)
	 *  - PluginSettingsEditAction (Called as action before editing the plugin's settings)
	 *  - PluginSettingsEditDisplayAfter (Called after standard plugin settings are displayed for editing)
	 *  - PluginSettingsValidateSet (Called before setting a plugin's setting in the backoffice)
	 *  - PluginUserSettingsUpdateAction (Called as action before updating the plugin's user settings)
	 *  - PluginUserSettingsEditAction (Called as action before editing the plugin's settings)
	 *  - PluginUserSettingsEditDisplayAfter (Called after displaying normal user settings)
	 *  - PluginUserSettingsValidateSet (Called before setting a plugin's user setting in the backoffice)
	 *  - PluginVersionChanged (Called when we detect a version change)
	 *
	 *  The max length of event names is 40 chars (T_pluginevents.pevt_event).
	 * }}
	 *
	 * @return array Name of event (key) => description (value)
	 */
	function get_supported_events()
	{
		if( empty( $this->_supported_events ) )
		{
			$this->_supported_events = array(
				'AdminAfterPageFooter' => '',
				'AdminDisplayEditorButton' => '',
				'AdminDisplayToolbar' => '',
				'AdminDisplayItemFormFieldset' => '',
				'AdminEndHtmlHead' => '',
				'AdminAfterMenuInit' => '',
				'AdminTabAction' => '',
				'AdminTabPayload' => '',
				'AdminToolAction' => '',
				'AdminToolPayload' => '',

				'AdminBeforeItemEditCreate' => T_('This gets called before a new item gets created.'),
				'AdminBeforeItemEditUpdate' => T_('This gets called before an existing item gets updated.'),

				'AdminBeginPayload' => '',

				'CacheObjects' => T_('Cache data objects.'),
				'CachePageContent' => T_('Cache page content.'),
				'CacheIsCollectingContent' => T_('Gets asked for if we are generating cached content.'),

				'AfterCommentDelete' => T_('Gets called after a comment has been deleted from the database.'),
				'AfterCommentInsert' => T_('Gets called after a comment has been inserted into the database.'),
				'AfterCommentUpdate' => T_('Gets called after a comment has been updated in the database.'),

				'AfterItemDelete' => '',
				'PrependItemInsertTransact' => '',
				'AfterItemInsert' => '',
				'PrependItemUpdateTransact' => '',
				'AfterItemUpdate' => '',
				'AppendItemPreviewTransact' => '',

				'RenderItemAsHtml' => T_('Renders content when generated as HTML.'),
				'RenderItemAsXml' => T_('Renders content when generated as XML.'),
				'RenderItem' => T_('Renders content when not generated as HTML or XML.'),

				'FilterCommentAuthor' => T_('Filters the comment author.'),
				'FilterCommentAuthorUrl' => T_('Filters the URL of the comment author.'),
				'FilterCommentContent' => T_('Filters the content of a comment.'),

				/*
				not used yet..
				'DisplayItemAsHtml' => T_('Called on an item when it gets displayed as HTML.'),
				'DisplayItemAsXml' => T_('Called on an item when it gets displayed as XML.'),
				'DisplayItem' => T_('Called on an item when it gets not displayed as HTML or XML.'),
				*/
				'DisplayItemAllFormats' => T_('Called on an item when it gets displayed.'),

				'FilterIpAddress' => T_('Called when displaying an IP address.'),

				'ItemViewsIncreased' => T_('Called when the view counter of an item got increased.'),
				'ItemCanComment' => T_('Asks the plugin if an item can receive comments/feedback.'),

				'SkinTag' => '',

				'AppendHitLog' => T_('Called when a hit gets logged, but before it gets recorded.'),

				'DisplayCommentFormButton' => '',
				'DisplayCommentFormFieldset' => '',
				'DisplayMessageFormButton' => '',
				'DisplayMessageFormFieldset' => '',
				'DisplayLoginFormFieldset' => T_('Called when displaying the "Login" form.'),
				'DisplayRegisterFormFieldset' => T_('Called when displaying the "Register" form.'),
				'DisplayValidateAccountFormFieldset' => T_('Called when displaying the "Validate account" form.'),

				'BeforeCommentFormInsert' => T_('Called before a comment gets recorded through the public comment form.'),
				'AfterCommentFormInsert' => T_('Called after a comment has been added through public form.'),

				'BeforeTrackbackInsert' => T_('Gets called before a trackback gets recorded.'),
				'AfterTrackbackInsert' => T_('Gets called after a trackback has been recorded.'),

				'LoginAttempt' => T_('Called when a user tries to login.'),
				'AlternateAuthentication' => '',
				'MessageFormSent' => T_('Called when the "Message to user" form has been submitted.'),
				'MessageFormSentCleanup' => T_('Called after a email message has been sent through public form.'),

				'GetSpamKarmaForComment' => T_('Asks plugin for the spam karma of a comment/trackback.'),

				// Other Plugins can use this:
				'CaptchaValidated' => T_('Validate the test from CaptchaPayload to detect humans.'),
				'CaptchaValidatedCleanup' => T_('Cleanup data used for CaptchaValidated.'),
				'CaptchaPayload' => T_('Provide a turing test to detect humans.'),

				'RegisterFormSent' => T_('Called when the "Register" form has been submitted.'),
				'ValidateAccountFormSent' => T_('Called when the "Validate account" form has been submitted.'),
				'AppendUserRegistrTransact' => T_('Gets appended to the transaction that creates a new user on registration.'),
				'AfterUserRegistration' => T_('Gets called after a new user has registered.'),

				'SessionLoaded' => '', // gets called after $Session is initialized, quite early.

				'AfterLoginAnonymousUser' => T_('Gets called at the end of the login procedure for anonymous visitors.'),
				'AfterLoginRegisteredUser' => T_('Gets called at the end of the login procedure for registered users.'),

				'BeforeBlogDisplay' => T_('Gets called before a (part of the blog) gets displayed.'),
				'SkinBeginHtmlHead' => T_('Gets called at the top of the HTML HEAD section in a skin.'),
				'DisplayTrackbackAddr' => '',
			);

I haven't had a look at your plugin yet, but when I get the chance I'll see if I can help you further.

¥

I just had a play around on the demo, and it would appear that you've found a "glitch" in the way the system works.

*moved to bugs forum*

¥

Thanks for your answer.
I will keep track of this topic.

¥åßßå wrote:

I just had a play around on the demo, and it would appear that you've found a "glitch" in the way the system works.

*moved to bugs forum*

What "glitch"? Probably it has been a bug then when this topic was new.. currently (and with 1.8) it should work.

fralenuvol, regarding the "plugin event request":
What do you need exactly?
Should an event get triggered, when the user clicked the link in the email?
Or when the user has been validated after clicking the link in the email?
Or when the "validated" property of the user object gets set?

Moved to the CVS forum as it did not focus on an official 1.* release.

(Trying to be tidy!)

Blueyed : this was the original glitch (not tried it on a 1.8 Summer install) :-

1° question:
Using the CVS code, after registering, a confirmation email is sent >> I click on the link >> I am asked to login to validate my ACCOUNT >> I log in >> I am asked a 2° time to validate my EMAIL >> after clicking on the 2° email I am validated and log in.

¥

¥åßßå:

I used the validation code from the current CVS version in "register.php", "_main.inc.php" and "login.php".

1° question: [...]

Is this the way it is intended to work, with double confirmation, or did I just implement wrongly the code?

It seems he has re-used the code, by extracting/copy'n'pasting it..

So, seems like this is obsolete.

Re: the event request, the question(s) from above remain.

1) Yes I cutted & pasted the code from 1.6 CVS version.

2) But I also installed now the new 1.8 version from scratch without hacks and the validation procedure is EXACTLY the same:

After registering, a confirmation email is sent >> I click on the link >> I am asked to login to validate my ACCOUNT >> I log in >> I am asked a 2° time to validate my EMAIL >> after clicking on the 2° email I am validated and log in.

What I would need are 2 things:

1) Regarding the validation process:
To validate just once, and not first my account, then my email.

2) Regarding the plugin event request:
Trigger an event after it is sure the user has validated, i.e. when the "validated" property of the user object gets set.

Thanks for your attention.

Ah.. I see..

1)
Yes, the progress during registration of a new user was "mis-leading": it automagically sends the "account validation" email, but this action requires the user to be logged in. So, when clicked from the email, the error shows up and after logging in he gets the "validate your account" message again - this is the same validation.

I've now fixed it, so that the validate-request from the email gets passed on in the login form and I've changed the message from "You have to be logged in to validate your account" to "Please login to validate your account".

2)
I've added the events AfterUserInsert, AfterUserUpdate and AfterUserDelete: if you hook those, you can check $params['User']->validated.

Both are committed to v-1-8 branch and should show up in 1.8.1 therefor.

Thanks.
It is exactly what I needed.
So I will update the "New Blog on new User Registration" to make it compatible with 1.8 version.

Is there a place where I can already get this changes and could you give me an idea of how long it will take the 1.8.1 version to be out?

You can get it from CVS, the "v-1-8" branch or wait some more days until 1.8.1 should get released.

Hi,
I finished the "Autoblog Plugin" and it seems me to work very nice:
http://www.fralenuvol.com/albero/servizi/webmaster/scripts/b2evolution_autoblog_plugin.php

Just one doubt:
In order to catch all, and only the 3 cases when it has to be triggered (user registration, admin creating new user, and user validation) I inserted a "dirty hack" in htsrv/login.php :

AFTER:

 $redirect_to = $Session->get( 'core.validatemail.redirect_to' );

I ADDED:

 $Plugins->trigger_event( 'AfterUserInsert', $params = array( 'User' = > & $current_User ) );

Because "AfterUserInsert" catches correctly the first 2 cases, but not the user validation.

I know I should use the "AfterUserUpdate" event instead of hack, but I am not sure how to use it in order to hook it ONLY right after a new user has validated and in NO other case in which a user is updated.

Have you any hint about how exactly to proceed?

You should just hook AfterUserInsert and AfterUserUpdate. Then, if validation is required, only re-act, if the "validated" property gets set to true in AfterUserUpdate.

There's no need for the above hack and it would be nice, if the other hacks also would not be needed, that can be seen on the plugin's installation page (like disallowing the user to change certain fields).. I'm not sure though, how to do that.. it should be a method that allows changing the form, but unfortunately forms get outputted right away.. so, it should be a hook that gets asked for when printing form elements and getting those as params..

I am still not fond in the b2evo system.

If I check the "validated" property in "AfterUserUpdate", would it not be triggered EVERY time there is an update of a validated user?
For example user updating his profile, or admin changing user settings?

While I need to trigger it just ONCE, after validation.
Or do you mean that

$current_User->validated ==1

is exatly doing that?
Sorry, I need to understand better how it works.

For the 2°part, to include all hacks in the plugin, I will work on it.

Yes, AfterUserUpdate would be triggered always and there's no way to see what has changed.

I would suggest using

$this->UserSettings->set('blog_created', 1, $user_ID);

and

if( $this->UserSettings->get('blog_created', $user_ID) ) ...

to manage this.

Thanks,
your solution worked very fine and allowed me to handle better all exceptions and special cases.

Now I will dedicate to get rid of the 2° hack.

As said, it would require to add hooks into both the Form class and where params are taken.. this is probably not easy/trivial, but I hope you come to some great solution.. :)

Well... I give up. :)

How the hell can I add a param inside the Form class function ($Form->text).
Is it possible?

Hope you have again a hint to sort me out.

My idea would be to have a method Plugins::get_form_info() which would be used by b2evo to ask if a certain form element is disabled.
If so, the Form class would not add the element to the form (just skip it) and the param() method would also ignore it/use the default value (also, if the value gets validated further, like "login has to be non-empty", this would need to know about ignoring the param).

OTOH, it would be probably easier and cleaner to have a hook in all form element generating methods, e.g. Plugin::CreateFormElement(), which would allow to make the input element disabled or hide/discard it (while adding a hidden field with the default value).

This are just quick thoughts about it - unfortunately the Form is not related to the collecting of its values in any way, except that param() can add error messages to fields.

Hello again,

I implemented the method Plugin::CreateFormElement() to disable the concerned form elements.
It seems to work an this got me rid of 2 hacks.
As I already said, I am not really a programmer, so I would know your advice if my approach is correct:

In
$Form->text_input()
I inserted

$Plugins->trigger_event( 'CreateFormElement', $params = array('field_name' = > $field_name ) );

before

return $this->input_field( $field_params );

and this is my function

function CreateFormElement( $params )
{
	global $current_User, $field_params;

	$is_autoblog = $UserSettings->get('autoblogblog_created', $new_User->ID);
	$is_field_editable = ( $params['field_name'] == 'blog_urlname' || $params['field_name'] == 'edited_user_login' ) ? false : true;
	$is_admin = ( $current_User->Group->ID == 1 ) ? true : false;

	if( ( $is_autoblog && ! $is_field_editable && ! $is_admin ){
		$field_params['disabled'] = true;
	}else{
		$field_params['disabled'] = (isset($field_params['disabled']) && $field_params['disabled'] != true ) ? $field_params['disabled'] : false;
	}
}

Regarding the last hack, which disables checkboxes for admin group in group permissions, in order to disallow autoblogger to take permissions away to admins, the checkboxes are builded on the fly and not through the class $Form methods, it seems me not possible to "hook" it.

In the function

function list_groups( $layout, $query )

the addition of

if( ( $lrow['grp_ID'] == 1 ) && ( $current_User->Group->ID != 1 ) ) continue;

after

foreach( $DB->get_results( $query, ARRAY_A ) as $lKey = > $lrow )
{ // Go through groups:

seems me the most clean approach I have found.

If you give me your ok, I would publish the plugin this way as quite final.

The hook seems ok, but it should apply to all form elements, e.g. also to textarea_input().

And, you should pass $field_params by reference (which should include $field_name as $field_params['name']). Passing the params by reference allows to modify them more easily (without "global").
Also, $this should get passed as "Form", so you can check for the form's name (see below, why you should do that). I'm not sure though, if it should get passed by reference (which allows to modify it) or without.

While at it, the hook should start with "Form", because there may be other hooks in the form handling later and so they are grouped by name.

So, the hook would look so:

$Plugins->trigger_event( 'FormCreateElement', $params = array('field_params' => & $field_params, 'Form' => & $this ) );

For your plugin's hack instructions, it would be alright to ask the users to place the hook only in text_input(), but when it gets added to an official release, it would have to get added to all form generating methods.

In your plugin function not much have to be adjusted for the new hook, but you should also check if $Form->name is what you expect - so your plugin only handles the form it's meant for.

About the checkboxes, which do not get handled by the Form class: your hack seems ok, but you should also handle/hack the controller which gets the params and applies them: only hiding form elements would still allow the users to manually update those settings, e.g. by manually editing the URL (not that trivial, but possible).
The same applies for the fields you disable in your plugin (e.g. "blog_urlname").

Therefor I'm not sure, if the approach to have two hooks (creating element and getting it from params) is the best/right solution.
It should probably rather be a callback that gets used/asked on both actions and defines e.g. if a field is disabled.

But it will take a while to decide on the way to implement it and actually do so, so you should just adjust the hook like stated above and perhaps additionally make sure that the users cannot change the fields, by manually crafting the URL.

I made some of the changes you suggested.

This are the things left off:
1) I passed $field_params by reference in function FormCreateElement(), anyway I did not know how to set the parent $field_params in text_input(), so I left it global.

2) I have at the moment not the time to handle the controller to avoid editing the URL. Sorry.

I tested it with b2evolution Serenity and saw that there are no changes to do.

Thanks for all your help.

Hi, again.
I have now some little time to dedicate to the plugin. :-)

Problem:
If I don't declare global $field_params in text_input method (this could screw up some unwanted params), I am not able to set $field_params['disabled'] from inside FormCreateElement.

There is no problem in reading params passing them by reference to FormCreateElement, but how can I get to set the parent $field_params inside the text_input function?

Without declaring $field_params global also in text_input I found no way.

Probably the solution is really trivial, but not to me. :-)

You would have to pass $field_params to the plugin function, by reference, so the plugin function can change it.

$Plugins->trigger_event( 'Event', $tmp_params( 'Form' => & $Form, 'field_params' => & $fieldparams ) );

Ok, finally it was trivial...

setting
$params['field_params']['disabled'] = true;
instead of my $field_params['disabled'] = true;
it works.

Many thanks.

To blueyed:
I am keeping slowly to bugfix, update and add little features to the plugin ( http://forums.b2evolution.net/viewtopic.php?t=8146 ).
The thing that is still left off, is this suggestion of yours:

you should also handle/hack the controller which gets the params and applies them: only hiding form elements would still allow the users to manually update those settings, e.g. by manually editing the URL (not that trivial, but possible). The same applies for the fields you disable in your plugin (e.g. "blog_urlname").

As I already told, currently it is enough to my purposes. Also users using it reported me it works well.

But if you think that this plugin may be of interest for b2evolution, I am willing to help. If yes, I would really need some starter guidelines on where to look in the code and how to implement that.

Hear you soon. :)

Currently that still needs to be hacked in.. where param() gets called and the settings get applied. I've added a specification for this into our todo list, but there's no feedback from François yet.

Question to blueyed:
Concerning the matter of handling the controller which gets the params and applies them, would this makes sense?

Relying on a default PHP configuration with "register_globals = off":
to initialize the proper variables in the plugin in order to prevent to manually edit the url?

Sorry, I don't understand what you mean.. is this one question or two different topics?
Manually editing the URL would pass the params to controller that sets them (in this case it seems to be blogs.php, which stores the blog settings).
AFAICS this has nothing to do with register_globals, as param() gets called anyway.

Yes... sorry for not being clear enough. The question is one.

What I mean is, that in the PHP manual ( http://it.php.net/register_globals ) I read that initializing a variable when register_globals = off, prevents the possibility to set it through the url.

So (if I understood well), I was wondering if it could be applied in the plugin in order to prevent to manually edit the url.

fralenuvol, though register_globals is off, b2evo itself will use the param() function to get it from the URL and apply the setting.
That's why there need to be hooks in both Form and param() to prevent a given setting from being editable.

Thanks for the answer.
Will see if and when I am able to handle that. :)

In order to prevent manually editing login name and blog urlname, what about something like this in blogs.php:

	switch( $action )
..................................................
	case 'update':
..................................................
	case 'general':
		if ( $current_User->Group->ID != 1 && $UserSettings->get('autoblog_created', $edited_User->ID) && isset($_GET['blog_urlname']) )
		{
			$Messages->add( T_('You are not allowed to change your blog\'s urlname!'), 'error' );
			$action = 'edit';
			break;
		}

and in b2users.php:

switch( $action )
{
	case 'new_user':
...........................................................
	case 'userupdate':
		if ( $current_User->Group->ID != 1 && $UserSettings->get('autoblog_created', $edited_User->ID) && isset($_GET['edited_user_login']) )
		{
			$Messages->add( 'You are not allowed to change your login name!', 'error'  );
			$action = 'edit_user';
			break;
		}

Some little doubts:

1) If somebody registers in b2evo (without autoblog), and does not authenticate:
He waits for validation email, then clicks on validation link, then authenticates, but $redirect_to redirects him to admin.php which, as new user without rights nor blog, produces an error page (you are not allowed...)

Is it so?
------------

2) I would like to provide the translation files for autoblog, but for the moment, without including them in the _global.php language file.

If I provide for example in autoblog_plugin folder the file locales/en_EN/_autoblog_translation.php, how can I make the additional translated strings work in addition to the _global.php messages array?

This way, users would have autoblog localized in their language from inside the download, without editing the language file, until eventually the strings get included in _global.php.

(Because I see many french have some problems and I could translate into it)

Further, if moderators agree,
I would like to change the topic's title to somethink like "Autoblog development" in order to keep this topic as main reference for the plugin development, before somebody tells me I am off-topic. :)

fralenuvol wrote:

1) If somebody registers in b2evo (without autoblog), and does not authenticate:
He waits for validation email, then clicks on validation link, then authenticates, but $redirect_to redirects him to admin.php which, as new user without rights nor blog, produces an error page (you are not allowed...)

Is it so?

If $redirect_to is set to an admin URL, this _may_ happen. I'm not sure though and it may work better in 1.9.
There's some magic involved..

fralenuvol wrote:

2) I would like to provide the translation files for autoblog, but for the moment, without including them in the _global.php language file.

You should provide this for 1.9 and up, because it's supported there (and the beta is just out).
See http://manual.b2evolution.net/Localization#Plugins

If you want to also support it for 1.8.x, you could copy the T_() function from the v-1-9 _plugin.class.php file into your plugin (overwriting the default one, which just uses the global T_() function [in 1.8.x])

Perfect :-)

I can translate to dutch for you ;)
And you can do italian yourself
I also know a german girl who will do german..

Do you need estonian ?? ;)

Well, whatever is useful also to others is welcome. :)

The plugin works with the locales folder (also 1.8.2 and up) and I included in the download the italian translation.
Now who is next? ;)

(By the way I also added notification emails to users for their newly created blog).

I upgraded the plugin for 1.9 (I see many things changed!).
But for backwards compatibility with 1.8 I made some changes in plugin code and even if it works, I would like to know if it is right:

1) I used version_compare to eventually include the function "convert_charset". Would it be bad to use nested function?

if( ! function_exists( "convert_charset" ) ){
function convert_charset(){
...

2) It seems that $User->Group->ID is no more available, and that $User->group_ID must be used instead.
Is the following code ok?

$User_Group = & $User->Group->ID;
if( ! $User_Group ) $User_Group = & $User->group_ID;

blueyed, remember always I am not a coder...
thanks for your patience. ;)

1) seems ok.. though you should use it in your plugin itself:

class autblog_plugin {

  function convert_charset( $same_signature_as_the_original_one )
  {
     if( function_exists( 'convert_charset' ) )
        return convert_charset(...);

     // copy here, which does the same
  }
}

and then use $this->convert_charset() in your Plugin.

2):
The check should look like:

if( isset($User->group_ID) ) {
  $group_ID = $User->group_ID;
}
elseif( $User->Group ) {
  $group_ID = $User->Group->ID;
}
else PANIC;

User->Group->ID is still available, but requires a call to $User->get_Group() before.

I did not use convert_charset() inside the plugin, because it is not the plugin calling it, but the new internal function T_()

$r = convert_charset( $r, $evo_charset, $this->_trans_charsets[$messages] );

and I didn't want to change that code.

Ah.. I see.. then copy the convert_charset() method, too, into the global scope, outside of your class (with function_exists() check of course).

Ok, it seems to work.
I also fixed all PHP warnings and committed.

Can it be considered to add the hook "FormCreateElement()" in _form.class.php?
(at present in functions text_input() and radio_input() )

This would get rid of any hack for Autoblog Plugin.