Really stupid question, you have reloaded your plugin events I assume? .... just askin' huh?

This works in one of my plugins :

	function DisplayRegisterFormFieldset( & $params )
	{
		$params['Form']->textarea( 'foo', 'your reason', 10, '', 'why do you want to register?', 40, 'bComment' );
	}

¥

Really honest answer: duh ... nope! But wait a minute: how could I reload my plugin if I was trying to register ;)

Okay so I forgot about that when adding a new hook. My bad. I'm thinking some of the junk I went through might have worked, but yeah I'll log in and reload then try your sample. Much cleaner yah? When that works I'll go ahead and try the select box again because I don't want someone saying "will large fit me" :roll:

I'm gonna LMFBO if that's the solution :D

¥

STEP AWAY FROM FURNITURE AND SHARP OBJECTS BEFORE READING THE NEXT LINE!

Yeah that worked :)

I live in a padded room, I'm safe :roll:

You just made my day :D

LMFBO :D

¥

Okay one more dumb question, if you don't mind.

How do I access the submitted content? I've been able to make the field show up in a couple of different ways, but can't seem to access the submitted content of the new field. What I am trying (just to see where it is) is using print_r( $params ) and print_r( $this ) in the AfterUserRegistration hook - to no avail. I know that's lame and it won't go live that way, but it seemed like a good way to start.

So instead of me plodding along mindlessly hoping to stumble across something obvious, can I get another clue? How the heck do I access the info submitted via the freshly added field?

I use this to record all the witty reasons why people wanna join my blog ;)

	function AppendUserRegistrTransact( & $params )
	{
		$foo = param( 'foo', 'string' );
		$bar = $this->SessionGet( 'login-register' );
		if( $fp = @fopen( dirname(__FILE__).'/../../../SpamHound/logs/login.txt', 'a' ) )
		{
			fwrite( $fp, 'Account created : '.$_SERVER['REMOTE_ADDR']."\n".'foo : '.$foo."\n".'bar : '.$bar."\n\n".'----------- ***** ------------------'."\n\n" );
			fclose( $fp );
		}
	}

¥

*edit*
Don't forget to reload your plugin events if you try that :roll:

Okay cool. That'll be the 18th hook this plugin is using. My goal: all of 'em!!!

Oh wait a minute... 3 of the hooks I'm using don't actually exist, so I guess I'm using 15 with a goal of using "all plus 3". Yeah: I hacked the core to make a plugin :>

* runs off to learn all about AppendUserRegistrTransact ...

I win, mine has 6 unique hooks :D

	function GetExtraEvents()
	{
		return array(
				'amImgEditor' => 'Hook to enable image editing',
				'Crop' => 'Crops an image',
				'Flip' => 'Flips an image',
				'Resize' => 'Resizes an image',
				'Rotate' => 'Rotates an image',
				'GetImageUrl' => 'Returns url with relevant key',
			);
	}

Still LMFBO, but at least the tears have slowed, it was making typing hard :D

¥

OFF TOPIC: I should post this over in the place where we can request hooks, but I'll describe what I've done anyway since I'm here studying your sample.

I moved the hook that lets plugins add fields to a post up above the official "title type locale link" fields because my plugin hooks need to be seen.

I then created a companion for that hook named WhateverItWasRight so I could move some inputs to the right column of the posting window.

Long ago I cloned TheToolBarHook to 2 more hooks so I can have toolbars above and below the posting textarea, and on the right side of the posting page. That'd be TheToolBarHookBottom and TheToolBarHookRight.

Between the three I get a lot more flexibility in what my users will see. I am able to get all the stuff my plugin has to do up top without driving the textarea off the visible area. Shuffling good old fashioned toolbars around helps me bring the textarea back up to where the blogger will see it without scrolling.

Cool? I mean, for a wannabe playa?

* studies AppendWhateverYabbaSaidHook some more*

[ot]Weirdly, I've also had reason to play with admin from a plugin where there just wasn't a hook to put what I wanted where.

Then I remembered that js is required for most of admin to function, so now I've started to use it to move my inputs from the ( very sparse ), trigger areas that are available to plugins to where I want them ... if all else fails I hack the core :D

More hooks are always cool ;)

Feel free to split these posts and move them to feature requests or bugs in x.xx, "shit that's lacking, put it in 3.0 before I storm off in a huff [ or whatever the yank equivalent is, you'd probably shoot somebody I guess?]" would probably make a good title ;)

¥[/ot]

Fatal error: Call to undefined method xccontest_plugin::SessionGet() in blah blah blah

Okay no problem. I think I've tried enough on this and am going to give up. I know that I can send an email to the contest boss
and remind him to ask for tee shirt size. I can also send an email to the registrant telling them they need to tell us the size tee
shirt they want, so that's gonna have to do. Getting and handling an input is a better way to do it, but I've got less than 18 hours
to have a fully functional installation out there is the thing. The actual plugin is nowhere near ready, but an installation with as
few hacks as possible shouldn't be that hard.

PS forcing line breaks to keep text visible on my monitor due to how the php button works

PS2 thanks for all your help!

PS3 anybody else remember when PS didn't mean Play Station?

Okay got it.

Wow you rock!

I'm using

$tee_shirt_size_2 = param( 'tee_shirt_size_2', 'string' );

then echoing it and seeing the text I inputed. This is the text string input (not the select box), but it's a good start.
I now know I can capture an input, so capturing the select box input can't be too far away.

EdB wrote:

Wow you rock!

It's a great feeling when the mist clears huh? :D

¥

Still LMFBO though ;)

GOT IT GOT IT GOT IT!!!

Damn you IE for putting a dynamic page in cache!

Viewing source to study *why* I could get "locale" select box but not "tee shirt" select box showed me that it is still thinking of when I was trying to fake the plugin_ID bits that are quite important when you are on your "tools->plugin" subtab. Forcing a page reload cleared up that, so now I can use a select box and access the value that the registrant selects.

Wanna know what sucks in all this? I've written ~120000 bytes so far and somewhere someone is going to say "how come I can't have a triple XL tee shirt" and someone else is going to say "we can't do small tee shirts because it costs too much" and everyone will say to themselves "that ed fella sucks at doing simple web stuff'.

awwww sad-face! frowny-face! cry-me-a-river-face! quit-yer-bitchin-and-start-coding-like-a-man-face!

Okay now I'll stop posting every AHA moment and just get cracking on producing an awesome installation (that maybe 50 people will register on) and a monster plugin (that no one else will ever need).

117.1875Kb plugin? Damn, it'd better rock!

¥

Yeah it will.

So dig this. When you do hang gliding (or paragliding) you have to have a SITE you fly from and a GLIDER you use. You also have to be a PILOT. So that's three tables. When you register you get to pick your tee shirt size because we (free flight pilots) like to get tee shirts from 'events' we go to. If you pay your money you get your shirt AND in this case you get points for flying. So the plugin needs to know where you flew from (sites), what you flew (gliders), who you are (users), how far you flew, how long you flew, where you landed. The last bits are part of the posting window fields (and the fourth table).

After that the plugin needs to give you points. You get points for distance and airtime, points for a "record for this year" and for "record for all time". So now the plugin needs to track points for each user. Because I'm a total geek I also track airtime and distance by site, but not points. Points are personal (users table) because if you've never left the nest you get more points for finally landing where you've never landed before.

One day soon I'll need to either have a monstrously huge skintag OR create multiple widgets so I can display information that the database knows. For example

who has the most points?
which HG pilot has the most points?
which HG pilot flew the farthest distance?
which HG pilot has the most cumulative airtime?
which HG pilot has the most cumulative airtime?

repeat all of the above for PG pilots - of course.

Now track second and third and fourth and fifth places - no brainer yah?

Oh and let's also track information by site!

Which site launches pilots (two cats: HG and PG) the furthest?
Which site launches pilots (two cats: HG and PG) the longest?
Which site gave up the most distance to an individual HG/PG pilot?
Which site gave up the most distance to all the HG/PG pilots (cumulative)?
Which site gave up the most airtime to an individual HG/PG pilot?
Which site gave up the most airtime to all the HG/PG pilot (cumulative)?

And let's not forget that each pilot wants to brag about their short (distance or airtime) flight that happens to be their personal best! So get ready to show that yah?

Oh and if you don't pay you don't get points so keep that in mind.

Oh and each user (pilot) has to be able to add to the list of sites, including all historical records so that the plugin can track records for this year and maybe update the record for all time.

And OMFG it never ends. My users are all good peeps, but they're getting kinda old ya know? Especially the ones I care about: the hang glider pilots. Paraglider pilots are generally younger and therefore a bit more tuned in to clicking on stuff ya know? So that means I have to make sure it is NOT scary to register and log in and ... experience the back office.

The last bit is why I hacked the core to add my hooks. My users absolutely MUST see where they can post their story BEFORE they have a bunch of blah blah blah they need to click on. So they default to 'simple' right? Cool: if they haven't included a glider in their plugin-profile then they can't post, and they get a link to the tools-subtab where they can add a glider ... which defaults to their selected glider.

See how this shit gets complicated? See why I needed (and now have!) a select box for tee shirt size? This is freakin awesome software. I've got my complaints with it and hack in my solutions, but OMG there is *nothing* out there that has a chance of coming close to what I need.

b2evolution (or as we'll all call it when v3 comes out "EdB") is awesome. Francois is both a good man to have met AND a damned genius AND and arrogant bastard. Weird eh? Same goes for the rest of the core players: you guys are totally fucking awesome ... even if you happen to be women (noting that the term "guys" implies 'male' and I've no clue to the dev team's gender ... especially that one that does all that gardening stuff ;) ). This software is powerful beyond most people's wildest dreams ... and it is FREE!

Signing off for a while. Now that I can get the tee-shirt-size I have to rethink when I add a user to the plugin's Users table. If I add them upon registration I can add the tee-shirt sizes by size, but currently I add them when they finally find the "Tools" tab. Something that also requires me to give them visibility of settings that will scare the freakin' pants off off them, but OMG I was not able to hack "you can't see settings but you can see tools" into it.

Anyway I gotta focus on getting an installation ready for a group of users who will run the gamut from "old fart" to "hip young playa".

And ¥åßßå you totally rock. If you ever find yourself in the US anywhere near Arizona and you want to farking fly without a girly-mon motor please lemme know. I will make it a point to make sure you get the experience of a lifetime.

You can hack the settings from within a plugin by using summat like :

	function AdminAfterMenuInit()
	{
		global $adminUI;
		if( empty( $adminUI->_menus['tools'] ) )
		{
			$adminUI->add_menu_entries( NULL, array(
					'tools' => array(
						'text' => T_('Tools'),
						'href' => 'admin.php?ctrl=tools&tab=plug_ID_'.$this->ID,
					),
				) );
		}
		$this->register_menu_entry( 'My tool' );
	}

ish ;)

¥

YAY!!!

Sort of... Had to clean up a couple of things (AdminUI vs adminUI and plug_ID_ vs plugin_ID_) but yeah that takes global and blog settings tabs out of the picture for those who don't need them. The only drawback is that it also takes away all the other subtabs under tools for me when I'm admin and other players when they are in a higher group. Since I can't really recall what they were I guess it don't matter eh?

For those that would like a cleaned up version of this, and don't mind how I like to do my {s and tabs different than everyone else, here ya go:

function AdminAfterMenuInit() {
	global $AdminUI;
	if( empty( $AdminUI->_menus['tools'] ) ) {
		$AdminUI->add_menu_entries( NULL, array( 
			'tools' => array( 'text' => T_('Tools'), 
			'href' => 'admin.php?ctrl=tools&tab=plug_ID_'.$this->ID ) 
			) );
		}
	$this->register_menu_entry( '¥åßßå does it again' );
	}

PS: Down to 118824 bytes on the server. Don't really need to see a success message for oninstall database prefills cuz not seeing an error message is good enough eh?

Me and my untested free typing :roll:

if( empty( $AdminUI->_menus['entries']['tools'] ) )

¥

Thanks again. It is kinda nice to not have stuff turned off eh? ;)