Recent Topics

1 Apr 23, 2009 02:47    

Doing another pointless plugin, although it will begin with Z so it'll help fill my alphabetical goal. And write readme.html files that work well with BOPIT so maybe it's not totally pointless.

Anyway I was pretty sure it was maybe gonna run so I gave it a shot. Did a few simple debugs and hit a wall. In my function AdminTabPayload() I do a little query to list the readme files you've already written in case you want to edit or update one of them. That works.

	$plugin_list = $DB->get_results('SELECT ID, name FROM '.$this->get_sql_table('balrog').' ORDER BY name ASC');
	echo '<h3>'.$this->T_('Edit a Plugin').':</h3>'."\n".'<p>';
	foreach( $plugin_list as $a_plugin ) { ?>
		<?php $text_string = $this->T_('edit this plugin...'); ?>
		<a href="?ctrl=tools&tab=plug_ID_<?php echo $this->ID ?>&what=edit&plug=<?php echo $a_plugin->ID ?>" title="<?php echo $text_string ?>"><?php echo $a_plugin->name ?></a>
		<?php 
		echo ' ';
		}


Repeat for updating and it makes two little P tags of links. Okay no problem. I then open up a form with a million form fields. That too works. The thing is if I click a plugin's name to edit or update it crashes on a get_sql_table that should go get the million values for the million form fields.

		$query = "SELECT * FROM ".$this->get_sql_table('balrog')." WHERE ID = '{$plug}'";
		if( $this_plugin = $DB->get_row( $query, ARRAY_A ) ) {

What I'm getting is the pair of H3 & P tags for listing plugins, then a big red box with a fairly generic "An unexpected error has occured!" message followed by "Additional information about this error:" in a gray box. The additional information of note is

MySQL error!
Table 'wonderw_bvlt3.evo_plugin_zythepsary__balrog' doesn't exist(Errno=1146)
Your query:
SELECT * FROM evo_plugin_zythepsary__balrog WHERE ID = '1'

Obviously it is missing the plugin's ID, but I can't for the life of me guess why. I tried replacing the * with the only two fields my default content contains - no luck. I tried changing " for ' even though I copied the bit from a working plugin that uses " - no luck. I tried going to the dentist and getting some work done - no luck.

I started thinking maybe I can't do this inside AdminTabPayload and should move it to AdminTabAction but heck the query that makes the list of editable plugin readmes works in AdminTabPayload so ...

Any ideas?

2 Apr 23, 2009 03:05

Try this


die($this->ID);

$query = "SELECT * FROM ".$this->get_sql_table('balrog')." WHERE ID = '{$plug}'";
      if( $this_plugin = $DB->get_row( $query, ARRAY_A ) ) { 

Do you get the ID?

3 Apr 23, 2009 03:16

And there you go! I put it in as die('die here '.$this-ID); just to make sure I saw where it was supposed to be in the event there was no ID ... which was fairly obviously the problem ... and sure enough it had no ID value. So I moved it up one line - above the IF that decides if we're going to bother with that query. STILL no value for ID. So I started asking myself what changed between a query that knew the plugin's ID and a query that didn't. Are you ready?

I TOLD IT $this-ID = ''; as the default value for a field in the table that happens to be autoincremented. I don't even *need* that value because it never shows up in the form - just gives me something to use to keep track of what's being edited or updated.

So to be double-plus certain that the problem doesn't rear it's ugly head again I'll rename the ID field as something like myID, and, not bother having it handy for a form that doesn't care about it.

Well done sam2kb!

4 Apr 23, 2009 03:30

YAY! Took a bit to do the edits and upload and test, but I can now report success in this mission. Onward and upward eh? This plugin has NO settings. THAT is completely unacceptable! Oh and it doesn't actually do anything yet. I mean, it does stuff but nothing that actually adds value to anyone's life. So if I had a lot of settings and an actual product it'd be way cooler.

5 Apr 23, 2009 03:34

I TOLD IT $this-ID = '';

:D

Make sure you don't kill other properties like 'name', 'version' etc.

6 Apr 23, 2009 04:01

Yeah it's messed up. Initially and normally I gave/give table fields uselessly long names. In this case since it is a readme writer I had called them all "rmw_whatever". Well with 122 fields I decided that rmw_ represented 4*122 characters I could pull out of multiple locations, thus shrinking the file size a wee bit.

So the bestest answer, rather than worrying about what might be officially used by the core, is to put that 'bloat' back in eh? Meaning a plugin that writes a table always has field names that begin with something reasonably unique to the plugin itself.

Blech. It was easy to find all of them and replace them with nothing. Not so easy to put 'em back where they belong :(


Form is loading...