Try $DB->quote() instead of escape.

You can also run the update script and if $DB->query() returns 'true' that means the field was updated.
If values are equal $DB->query() returns 'false'

Will try the quote thing soon ... thinking about a new avatar first :)

Am doing it with if DB->query - that's how I know it's not working. I use this->msg( 'whatever', 'error or success' ) to let me know. Currently works when there is content from the form. Fails when the change it to empty a previously occupied field.

Okay got it. echoing the query as part of the error message revealed that it was "updating" every freakin field EXCEPT the one I tried to empty. So that tells me it thought the original was empty because "if empty != empty" skipped. Also, it threw the error because it tried to update no changes. That's the only reason to first ask if a change happened to a field and keep track of in any changes happened before doing the DB->query thing yah?

This is one of those cases where $this->variable doesn't do what one expects it to do, else I'm using it backwards or wrong or whatever.

In AdminTabPayload() I do a query and populate the form with the current info. I do "$this->variable = $from_table['rmw_variable'];" to all the fields in the table and the form. I then edit a field or two and submit the form.

By the time it gets back to AdminTabAction() it has (obviously) forgotten what $this->variable is all about. So now I can either set_param everything, or run the query again. I'll go with running the query again because in this case it really doesn't matter if the plugin is "efficient" given the limited target audience.

Note to self: don't trust it :-/

In AdminTabPayload() I do a query and populate the form with the current info.

If you do this why do you need to store variables in $this->my_var when you can and should get them from

param( $this->get_class_id('my_var'), 'string' )

Or do you compare them in AdminTabActions before updating? then why don't you want to update vars with the new submitted values?

I don't get it :-/

$this->new_variable = param( $this->get_class_id('variable') );

The form gets populated with the current values, someone changes something, then AdminTabAction gets the new values from the form. That lets me compare new_variable to variable yah? Problem is $this->variable didn't carry from AdminTabPayload to AdminTabAction, so now I'll try it differently.

Rather than duplicate the query I'm going to move it from AdminTabPayload to AdminTabAction and see if $this-variable will be remembered in that direction. I'm thinking it will given that AdminTabAction actually directly feeds AdminTabPayload. IF this works then I populate the form in Payload from a query in Action. The query still gets used twice, just doesn't exist in the code twice.

What a PITA!

sam2kb wrote:

In AdminTabPayload() I do a query and populate the form with the current info.

If you do this why do you need to store variables in $this->my_var when you can and should get them from

param( $this->get_class_id('my_var'), 'string' )

Because that only gets me the NEW value. I can't compare it to nothing is the thing, so I need the pre and post submit values.

sam2kb wrote:

Or do you compare them in AdminTabActions before updating? then why don't you want to update vars with the new submitted values?

That is EXACTLY what I am trying to do! The problem is that the current (or pre submit) values are getting lost so there is nothing to compare the new values to. Of course I want the new values submitted. In order to do that one must know if something changed right? Therefore the original and the new must be available. By setting $this->original_values in the Payload function it is okay to pre-populate the form, but it is not okay when the Action function tries to compare. Thus I'll try it the other way.

If it too fails I'll just go with set_param because I *know* that is fully reliable.

Maybe I'm too tired to understand that, but why do you compare old and new values???
Just send new values (changed or not, empty or not, who cares) directly in DB.

I hope you'll release this plugin soon cos I'm very intrigued what the heck you are doing with this 122-fields form :)

Good luck

The problem with doing it whether there are changes or not is that the key piece will return FALSE if there are no changes. Lemme look ...

		// execute the query and hope for the best...
		if( $query_changed ) { 
			if( $DB->query( $query ) ) {
				$this->msg('Big Giant Query worked :)', 'success' );
				} else {
				$this->msg('Big Giant Query failed :(', 'error' );
				//$this->msg('Big Giant Query failed :( <br />'.$query, 'error' );
				}
			}

Straight from my plugin. In this case $query is might be an UPDATE, so the returned value will be the number of rows affected. If everything in is the same as it was then there are no affected rows, so it returns 0 even though it was technically successful. I feel a desire to know that it was successful, and provide a this->msg either way, so I can't accept 0 as a useful response. Therefore I need to know that I am only sending values that have actually changed. Hope that makes sense.

ANYWAY I am happy to report that I now know $this is a one-way street when it comes to AdminTabAction and AdminTabPayload. In other words, if I set all my $this->variable values in ATA then ATP will know about them, but not the other way around. So by restructuring the whole thing and getting almost all my actions up to the ATA section I am capable of doing a worthy comparison.

Also I'm not sure if I still have 122 fields or not. I added a few for some bits, then took a few away for other bits, and added one more to replace the removed ones. AND I think I need to add quite a few more just to cover the plugins I've already written.

The point of this entire plugin is to allow plugin authors a reasonably workable method of writing README files that work well with BOPIT. To do that I need to store all sorts of information about the file it will eventually create. Right now it can handle 18 plugin settings (6 in each of three groups) and the same amount of user settings. It can only handle 6 widget setttings though. (6*3)+(6*3)+6 is 42 settings, so that alone is 84 fields because I need a field for each setting's label and description. I want to bump that up to 8 per, which now isn't so hard, but I wish I had done that from the beginning. Anyway that'll be 28 more fields.

Revision history is important to BOPIT, and I personally like to keep it in there instead of just having the latest info. So I have 12 fields for 6 different rev/reason pairs. Another field is for overflow so that when you make your 7th update (and beyond) to a plugin this thing will begin to lump all the older stuff into the overflow field. Unseen during editing or updating, but there when you actually tell it to write your readme.

5 Fields for how to use the plugin, 5 more for credits, 5 more for "additional info". All of those become LIs in ULs, so if you need more I figure simply cheat them in with something like this:

blah blah blah</li><li>more blah blah blah

So it is a HUGE plugin with a VERY small audience of peeps who should be able to figure out quite a bit of it on their own. It'll make readme's that look fairly close to what Yabba came up with as part of his recent BOPIT upgrade ... with some changes by me - of course. So I have a setting where you can make it have your own styles ... and a setting for your own javascript if you want.

Anyway lots of fun. Did in in javascript already but that is lame because it doesn't remember anything. So when I update a plugin I either edit the current readme, or plug it all into a javascript again, or trust this plugin to know it all and simply fill in a few more form fields.

Plus it'll move me one step closer to having plugins from A to Z :)