Why re-invent the wheel ?

$sql = 'SELECT blog_ID from T_blogs WHERE blog_owner_user_ID='.$edited_User->ID;
pre_dump( $DB->get_results( $sql ) );

¥

Thanks ¥åßßå.

It looks like a nice function. Here's how I'm using it:

$sql = 'SELECT user_login,user_blog_ID from T_users WHERE user_ID='.$edited_User->ID;
pre_dump( $DB->get_results( $sql ) );

The result is:

array(1) {
  [0]=>
  object(stdClass)#115 (2) {
    ["user_login"]=>
    string(8) "testuser"
    ["user_blog_ID"]=>
    string(1) "5"
  }
}

I know I'm tired, but how to extract 'user_blog_ID' from this? :?:

Thanks again.

I think you must have missed me, the code I posted will list all blogs that a user owns ?

¥

blogmeister wrote:

My b2evolution Version: 2.x

Hello.

I added a new field called 'blog_ID' or formally 'user_blog_ID' to T_users. I'm trying to get that value for the AdminUI Profile page for that user.

I see in usercache.class.php 'function get_by_login( $login )' where I put the value for the $login argument. It pulls up most but not all of the data for that user.

What am I overlooking? That function says to SELECT *...

To see what it pulls up, I used the following in 'inc/users/views/_user.form.php':

$CURR_USER = & get_Cache( 'UserCache' );
$CURR_LOGIN = $CURR_USER->get_by_login( $edited_User->login );
print_r($CURR_LOGIN);

The 'blog_ID' var/value is not listed. :-/

Thanks in advance.

Thanks ¥åßßå.

This is what I'm trying to do - capture the new field I added in T_users called 'blog_ID' or 'user_blog_ID' into a usable variable when in the user's profile.

Thanks again.

I understand, but what I'm saying is that you have no need for your extra column, it's already part of the core.

¥

Thanks ¥åßßå.

Now I understand how you're looking at it.

The reason I need to do this is because I'm tracking which blog the new member registers through. I've already created that functionality since only selected blogs will be able to accept registration. I've moved the feature from Global Settings->General Settings->newusers_canregister to Blog Settings. Now I need to get access to that param from within T_users; not sure why it is not available via UserCache nor $edited_User in _user.form.php.

Thanks again.

Use the core luke :roll:

<?php
$UserSettings->set( 'foo', 'bar', $edited_User->ID );
$UserSettings->dbupdate();



......



echo $UserSettings->get( 'foo', $edited_User->ID );
?>

¥

Hmmm...very interesting...

If I'm following you correctly, I should probably remove 'user_blog_ID' from T_users and add it to the usersettings table as a record instead. That I can do. I guess I really never looked at the contents of that table. It looks quite similar to how the coll_settings table works.

I like doing it 'your way' better. That way, I don't have to modify the table structure. If this is not what you're saying, please let me know.

I'll give it a whirl later today.

~~~
One more question if it's okay: Regarding your earlier reply when you used 'pre_dump()', how would data be extracted as a usable variable? I'd like to use that function for some other things if possible.

Thanks!

P.S. It's nearly daylight here and I need to get some sleep. I'll check back later today. Thanks again.

That is what I was saying ;)

pre_dump is just a way of seeing variables values ( it's just php's var_dump() on steroids )

Most "variables" in b2evo are objects so you reference them with $var->property

¥

¥åßßå wrote:

Use the core luke :roll:

<?php
$UserSettings->set( 'foo', 'bar', $edited_User->ID );
$UserSettings->dbupdate();



......



echo $UserSettings->get( 'foo', $edited_User->ID );
?>

¥

Thanks for your reply, ¥åßßå.

I now have that added that code to register.php after writing the new user into T_users via:

		$new_User->dbinsert();

// New:  Add blog_ID to T_usersettings table
		$New_User_ID = $new_User->ID; 

		$UserSettings->set( 'referred_blogID', $referral_blog, $New_User_ID ); 
		$UserSettings->dbupdate();

// TO DO:  Need to incorporate new T_usersetting record into the rollback routine below

How to rollback that new T_usersettings record (to avoid an orphaned record) if the new user entry is rolled back per the code in register.php? :?:

Thanks again.

You really should be trying to do this from a plugin ;)

Hooks :
AfterUserDelete()
AfterUserInsert()
AfterUserUpdate()

¥

¥åßßå wrote:

You really should be trying to do this from a plugin ;)

Hooks :
AfterUserDelete()
AfterUserInsert()
AfterUserUpdate()

¥

Thanks for your reply, ¥åßßå.

Are there instructions on how to do this? :?: Also, I see 2 of the 3 functions have no code within the functions, too so that eludes me even more.

I was able to add the new param for T_usersettings via AdminUI, although I noticed a [few minutes] ago that there is a param related to a user settings* hack that disappears off the page after the page finishes loading in 'edit user' - located just below Smilies=>Use smilies toolbar. (I saw it in View Source, too). Should this be a concern? :?: I see its value is '1'.

EDIT: * I found the hack pertains to user settings and is from the avatars plugin. It is not a rollback hack. It works as designed.

Thanks again.

I believe Walter is on the middle of writing a "how to" for plugins, but you'd need to be able to understand portugese.

There's no code in any of the functions, you have to write it.

I'd need a crystal ball to know what the param is, and what the hack is, and what appears in your source ... but, generally speaking, if you're getting unexpected output then you need to revisit your code

¥

blogmeister wrote:

¥åßßå wrote:

Use the core luke :roll:

<?php
$UserSettings->set( 'foo', 'bar', $edited_User->ID );
$UserSettings->dbupdate();



......



echo $UserSettings->get( 'foo', $edited_User->ID );
?>

¥

Thanks for your reply, ¥åßßå.

I now have that added that code to register.php after writing the new user into T_users via:

		$new_User->dbinsert();

// New:  Add blog_ID to T_usersettings table
		$New_User_ID = $new_User->ID; 

		$UserSettings->set( 'referred_blogID', $referral_blog, $New_User_ID ); 
		$UserSettings->dbupdate();

// TO DO:  Need to incorporate new T_usersetting record into the rollback routine below

How to rollback that new T_usersettings record (to avoid an orphaned record) if the new user entry is rolled back per the code in register.php? :?:

Thanks again.

Again, thanks for your reply, ¥åßßå.

Since I probably can't go the plugin route (unless it were adding a widget which is not applicable in this case), I'm sticking to the old-fashion method of hacking the code file-by-file.

All I need to do here, I would think, is to add a few lines of code to add my new param 'referred_blogID' to the existing rollback routine in register.php as I've quoted here from my previous reply re: your reply on using $UserSettings. Currently, the rollback is only on T_users. I need to incorportate it for T_usersettings. Once I have that, that hack would be complete minus some tweaking.

Thanks.

Plugins and widgets are like rectangles and squares. Pretty much everything your doing could be done from inside a rectangle ;)

¥

That's cool ¥åßßå. I think I may be able to figure out how to create a plugin -- I'll give it a whirl on something else though.

In the interim, I'm looking to find how to include code to rollback the record from within the existing rollback code for T_users used in register.php that would have been added via $UserSettings now that I've added data to T_usersettings during registration instead of adding the extra field to T_users (according to your suggestion). Instead of taking the risk of not having all of the right steps, I'm at the point where I may just settle on removing the record manually (writing original code) for the T_usersettings record if it comes down to it if the new user is removed.

As a last ditch effort before moving on, I saw the rollback() and dbdelete() functions used elsewhere and if I remember correctly, in some cases each was combined with other functions and other cases it may have been by itself. Hopefully I can just add a few lines to the existing rollback routine in register.php to add the removal of that new user's T_usersettings record and not upset the database/user's profile. If not, I'll just move on the old-fashioned way.

Thanks again.

I'm just trying to save you some pain when the core gets upgraded ( 2.4.6 is on the horizon ) ;)

¥

I appreciate that ¥åßßå, thanks. I'll try to adapt. I currently have no other info regarding v.2.4.6.

Right now though, all I know is that I'm running out of time to work on this software application and may have to walk away from it in the interest of time.

I need to finish the registration feature. Any additional help with this last item of registration would be greatly appreciated.

Thanks again.

In that case just forget rolling back the setting ( how many times will that occur in reality ? And you're only talking a single row in a 3 column table ;) )

Have a play with plugins when you get a chance though ... whilst they're not quite as enjoyable as great sex or decent drugs ( preferably both together :D ) they can be a lot of fun once you see what you can do with them ;)

¥

Thanks for your reply again, ¥åßßå.

Regarding the rollback in register.php, I'm glad I don't have to do more on that. I'll try to remember to remove that record if the situation arises (I'd probably just do it through phpMyAdmin) or if not, it wouldn't be a big deal. I was just trying to maintain as much code consistency with b2evo as I could as I am still am in the early stages of learning, relatively-speaking, about how this software truly works. I appreciate your opinion.

Now for the most important part of your reply...

Although the latter is much more fun and reluctantly, I had to come up for air :oops: for time-sake, I did manage to find a small window of time to see what I can do to try to figure out the plugin feature as 'hooks'.

The software I was introduced to that used hooks was vBulletin in early v.3.6.x. Their hooks structure was completely different than what it seems to be like in b2evo. Having said that, I will discuss my findings in a different thread. I'll come back shortly and provide the link.

'til then...

EDIT: Here's the link I was referring to: http://forums.b2evolution.net/viewtopic.php?t=17597