A Question On Plugins

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

A Question On Plugins

Andy Staines
I know you guys are in the middle of a big security conference but  
can a relatively newbie plugin author - struggling to find  
documentation to help him - ask a question or two? And - is this the  
right place to be asking?

One of my plugins requires two tables to be created. I coded this up  
as a process in the 'activate' plugin hook. But for at least two  
people (and maybe more) when they have activated the plugin, the  
tables have not been set up. They are administrators of their blogs.

Is this the 'right' way to ensure tables get created or is there a  
better hook to use? And, if so, any ideas why it should fail?

regards
Andy
www.yellowswordfish.com

_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: A Question On Plugins

Viper007Bond
http://codex.wordpress.org/Creating_Tables_with_Plugins

I have yet to code a plugin that uses it's own table (I prefer to store
my data in a big array in the options table), but I'd probably
personally avoid using the action hook as from you found out, it doesn't
always work for one reason or another.

So, the only other way I can think of is checking every time the plugin
is used (not on every page load) and only once per page. Either that,
using an option value to record that the table's been made. But of
course both of those make a query occur, so it's kinda up to you.

-Viper

Andy Staines wrote:

> I know you guys are in the middle of a big security conference but can a
> relatively newbie plugin author - struggling to find documentation to
> help him - ask a question or two? And - is this the right place to be
> asking?
>
> One of my plugins requires two tables to be created. I coded this up as
> a process in the 'activate' plugin hook. But for at least two people
> (and maybe more) when they have activated the plugin, the tables have
> not been set up. They are administrators of their blogs.
>
> Is this the 'right' way to ensure tables get created or is there a
> better hook to use? And, if so, any ideas why it should fail?
>
> regards
> Andy
> www.yellowswordfish.com
>
> _______________________________________________
> wp-hackers mailing list
> [hidden email]
> http://lists.automattic.com/mailman/listinfo/wp-hackers
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: A Question On Plugins

Andy Staines
Thanks Viper
I have coded up a 'version' option in the options table so I can at  
least check when the admin panel is loaded. As you say - painful that  
it is just another query but it was the only other thing I could  
think of.
There must be fixable reasons why the 'activate' hook doesn't work  
though. I actually now recall having this problem myself with a third-
party plugin...
Thanks again
Andy


On 11:49  AM |  Tue 25 Apr 06, at 11:49  AM |  25 Apr 06,  
Viper007Bond wrote:

> http://codex.wordpress.org/Creating_Tables_with_Plugins
>
> I have yet to code a plugin that uses it's own table (I prefer to  
> store my data in a big array in the options table), but I'd  
> probably personally avoid using the action hook as from you found  
> out, it doesn't always work for one reason or another.
>
> So, the only other way I can think of is checking every time the  
> plugin is used (not on every page load) and only once per page.  
> Either that, using an option value to record that the table's been  
> made. But of course both of those make a query occur, so it's kinda  
> up to you.
>
> -Viper
>
> Andy Staines wrote:
>> I know you guys are in the middle of a big security conference but  
>> can a relatively newbie plugin author - struggling to find  
>> documentation to help him - ask a question or two? And - is this  
>> the right place to be asking?
>> One of my plugins requires two tables to be created. I coded this  
>> up as a process in the 'activate' plugin hook. But for at least  
>> two people (and maybe more) when they have activated the plugin,  
>> the tables have not been set up. They are administrators of their  
>> blogs.
>> Is this the 'right' way to ensure tables get created or is there a  
>> better hook to use? And, if so, any ideas why it should fail?
>> regards
>> Andy
>> www.yellowswordfish.com
>> _______________________________________________
>> wp-hackers mailing list
>> [hidden email]
>> http://lists.automattic.com/mailman/listinfo/wp-hackers
> _______________________________________________
> wp-hackers mailing list
> [hidden email]
> http://lists.automattic.com/mailman/listinfo/wp-hackers

_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: A Question On Plugins

Jamie Talbot
In reply to this post by Andy Staines
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Andy Staines wrote:
> One of my plugins requires two tables to be created. I coded this up as
> a process in the 'activate' plugin hook. But for at least two people
> (and maybe more) when they have activated the plugin, the tables have
> not been set up. They are administrators of their blogs.
>
> Is this the 'right' way to ensure tables get created or is there a
> better hook to use? And, if so, any ideas why it should fail?

One thing to remember is that the activate hook is dependent on the plugin name.  At first, I was
confused because I'd installed the plugin to its own directory, but not included that in the plugin
hook.  As in using:

add_action('activate_pluginname.php', array(&$this, 'activated'));

instead of:

add_action('activate_pluginname/pluginname.php', array(&$this, 'activated'));

Where the plugin files were in the directory 'wp-content/plugins/pluginname/'.  Other than them
installing to the wrong directory, no idea why it might be failing.  In any case, I decided to add
my tables on the first view of an options page, then used the activate hook to redirect the user
straight to that page when the plugin was first installed, instead of going back to the plugins
page.  That way, even if the activation screws up, my tables will still be created when they look at
the config page.

Cheers,

Jamie.

- --
http://jamietalbot.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFETiVJrovxfShShFARAkyBAJ9lQ8ipxBQHIDrZozETx8GXOJQMHgCeNtfG
hL0s97J+lBzz3z/fiWdsq64=
=m6yF
-----END PGP SIGNATURE-----
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: A Question On Plugins

Andy Staines
Thanks Jamie. I am doing that bit OK. The weird thing is that I have  
quite a few users of this plugin - all successful - but just two have  
reported this problem.
They are the sort of bugs you just hate!
andy

On 02:34  PM |  Tue 25 Apr 06, at 02:34  PM |  25 Apr 06, Jamie  
Talbot wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Andy Staines wrote:
>> One of my plugins requires two tables to be created. I coded this  
>> up as
>> a process in the 'activate' plugin hook. But for at least two people
>> (and maybe more) when they have activated the plugin, the tables have
>> not been set up. They are administrators of their blogs.
>>
>> Is this the 'right' way to ensure tables get created or is there a
>> better hook to use? And, if so, any ideas why it should fail?
>
> One thing to remember is that the activate hook is dependent on the  
> plugin name.  At first, I was
> confused because I'd installed the plugin to its own directory, but  
> not included that in the plugin
> hook.  As in using:
>
> add_action('activate_pluginname.php', array(&$this, 'activated'));
>
> instead of:
>
> add_action('activate_pluginname/pluginname.php', array(&$this,  
> 'activated'));
>
> Where the plugin files were in the directory 'wp-content/plugins/
> pluginname/'.  Other than them
> installing to the wrong directory, no idea why it might be  
> failing.  In any case, I decided to add
> my tables on the first view of an options page, then used the  
> activate hook to redirect the user
> straight to that page when the plugin was first installed, instead  
> of going back to the plugins
> page.  That way, even if the activation screws up, my tables will  
> still be created when they look at
> the config page.
>
> Cheers,
>
> Jamie.
>
> - --
> http://jamietalbot.com
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.5 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFETiVJrovxfShShFARAkyBAJ9lQ8ipxBQHIDrZozETx8GXOJQMHgCeNtfG
> hL0s97J+lBzz3z/fiWdsq64=
> =m6yF
> -----END PGP SIGNATURE-----
> _______________________________________________
> wp-hackers mailing list
> [hidden email]
> http://lists.automattic.com/mailman/listinfo/wp-hackers

_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: A Question On Plugins

Andy Skelton
In reply to this post by Andy Staines
On 4/25/06, Andy Staines <[hidden email]> wrote:
> I know you guys are in the middle of a big security conference but

hehe

> Is this the 'right' way to ensure tables get created or is there a
> better hook to use? And, if so, any ideas why it should fail?

I do it a bit differently. This method had the added benefit of
letting you upgrade the tables just like WP does.

Save your plugin db version as an option. Check the option on every
page load. It's autoloaded so the cost of this operation is trivial.

If the db version in the option is outdated or missing:
$my_queries = "CREATE TABLE foo (...); CREATE TABLE bar (...);"
require_once(ABSPATH/wp-admin/upgrade-functions.php);
dbDelta($my_queries);
update your db version option.

Of course, you'll have to clean up that code and make it your own.

When you update the plugin with new table schema, just update
$my_queries and bump the db_version coded in your plugin. It'll see
the outdated version in the options table and run the upgrade.

Cheers,
Andy
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: dbDelta and duplicated indices (WAS: A Question On Plugins)

Jamie Talbot
Andy Skelton wrote:
> If the db version in the option is outdated or missing:
> $my_queries = "CREATE TABLE foo (...); CREATE TABLE bar (...);"
> require_once(ABSPATH/wp-admin/upgrade-functions.php);
> dbDelta($my_queries);
> update your db version option.

Incidentally, (and just to hijack a little bit) does dbdelta handle multi-column primary keys?  When
the table already exists (say I'm upgrading), I get errors like "multiple key not allowed" unless I
turn errors off.  Also, it seems like UNIQUE indices are duplicated when calling dbdelta repeatedly.
-  Instead of being overwritten, they are just added, without being removed first.  I'm pretty sure
this isn't intended behaviour?  If it isn't, I'll open a ticket...  Can anyone else confirm this
behaviour for other kinds of indices?

Jamie.

--
 http://jamietalbot.com
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: A Question On Plugins

Rob Miller-4
In reply to this post by Andy Staines
Andy Staines wrote:
> Thanks Jamie. I am doing that bit OK. The weird thing is that I have
> quite a few users of this plugin - all successful - but just two have
> reported this problem.
> They are the sort of bugs you just hate!
> andy
>
> On 02:34  PM |  Tue 25 Apr 06, at 02:34  PM |  25 Apr 06, Jamie Talbot
> wrote:
Are they using an old version of WP? IIRC, the activation hook was only
added in 2.0.

--
Rob Miller
http://robm.me.uk/ | http://kantian.co.uk/

_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: A Question On Plugins

Andy Staines
In reply to this post by Andy Skelton
Thanks Andy

This is EXACTLY what I have re-coded it to do this morning except not  
knowing about 'dbDelta' I constructed mg own update routine. But I am  
now keeping the db version in Options.

The WP version they are using is a good question and I will enquire -  
but I have specified that the plugin needs Wp2 or above.

On the issue of things like 'dbDelta' are there other, more  
comprehensive resources than the Codex for finding this stuff short  
of trawling through the whole of the WP admin code?

And - as an associated question - having watched this list and read  
Ryans and Owens blog on some things to come in the next release, is  
there a definitive document available to plugin authors detailing all  
the changes so we know what needs to be done to our code to make it  
work? Trac is Ok up to a point but hardly gives a decent description  
of what we really need to know...

thanks again
andy


On 03:47  PM |  Tue 25 Apr 06, at 03:47  PM |  25 Apr 06, Andy  
Skelton wrote:

> On 4/25/06, Andy Staines <[hidden email]> wrote:
>> I know you guys are in the middle of a big security conference but
>
> hehe
>
>> Is this the 'right' way to ensure tables get created or is there a
>> better hook to use? And, if so, any ideas why it should fail?
>
> I do it a bit differently. This method had the added benefit of
> letting you upgrade the tables just like WP does.
>
> Save your plugin db version as an option. Check the option on every
> page load. It's autoloaded so the cost of this operation is trivial.
>
> If the db version in the option is outdated or missing:
> $my_queries = "CREATE TABLE foo (...); CREATE TABLE bar (...);"
> require_once(ABSPATH/wp-admin/upgrade-functions.php);
> dbDelta($my_queries);
> update your db version option.
>
> Of course, you'll have to clean up that code and make it your own.
>
> When you update the plugin with new table schema, just update
> $my_queries and bump the db_version coded in your plugin. It'll see
> the outdated version in the options table and run the upgrade.
>
> Cheers,
> Andy
> _______________________________________________
> wp-hackers mailing list
> [hidden email]
> http://lists.automattic.com/mailman/listinfo/wp-hackers

_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: dbDelta and duplicated indices (WAS: A Question On Plugins)

Ryan Scheuermann
In reply to this post by Jamie Talbot
Jamie Talbot wrote:

> Andy Skelton wrote:
>  
>> If the db version in the option is outdated or missing:
>> $my_queries = "CREATE TABLE foo (...); CREATE TABLE bar (...);"
>> require_once(ABSPATH/wp-admin/upgrade-functions.php);
>> dbDelta($my_queries);
>> update your db version option.
>>    
>
> Incidentally, (and just to hijack a little bit) does dbdelta handle multi-column primary keys?  When
> the table already exists (say I'm upgrading), I get errors like "multiple key not allowed" unless I
> turn errors off.  Also, it seems like UNIQUE indices are duplicated when calling dbdelta repeatedly.
> -  Instead of being overwritten, they are just added, without being removed first.  I'm pretty sure
> this isn't intended behaviour?  If it isn't, I'll open a ticket...  Can anyone else confirm this
> behaviour for other kinds of indices?
>
> Jamie.
>  
I can confirm this for UNIQUE KEY creation.  dbDelta does not play well
with UNIQUE KEY at all.  I found that if you change it to simply KEY and
not UNIQUE KEY, dbDelta handles the recreation of the key correctly - or
it ignores it completely if it already exists.

It won't duplicate the unique indices for me, it simply gives me an
error stating I can't create an index of the same name.  Whatever the
symptom, dbDelta is attempting to recreate a UNIQUE KEY index every time.

Ryan
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: dbDelta and duplicated indices

Owen Winkler
Ryan Scheuermann wrote:
> I can confirm this for UNIQUE KEY creation.  dbDelta does not play well
> with UNIQUE KEY at all.  I found that if you change it to simply KEY and
> not UNIQUE KEY, dbDelta handles the recreation of the key correctly - or
> it ignores it completely if it already exists.
>
> It won't duplicate the unique indices for me, it simply gives me an
> error stating I can't create an index of the same name.  Whatever the
> symptom, dbDelta is attempting to recreate a UNIQUE KEY index every time.

I have a vague recollection of something about the structure of the SQL
required for specifying keys.

In any case, you can see which indexes it can and can't find by
uncommenting two lines in dbDelta().   dbDelta() attempts to build SQL
that would create the indexes in the existing table, and then compare
them to what it found in the SQL schema it was provided.  If what it
generates does not exactly match what is in the schema, then it attempts
to create the index as described in the schema.

So you can see, if that schema attempts to generate an index that
already exists using a method that doesn't exactly match what dbDelta()
generates, it causes an error.  There may be a way to do what you want;
you might need to form your schema more precisely.  If dbDelta() is
incomplete, then it can be tweaked to include it.

Owen

_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: dbDelta and duplicated indices

Ryan Scheuermann
Owen Winkler wrote:

> Ryan Scheuermann wrote:
>> I can confirm this for UNIQUE KEY creation.  dbDelta does not play
>> well with UNIQUE KEY at all.  I found that if you change it to simply
>> KEY and not UNIQUE KEY, dbDelta handles the recreation of the key
>> correctly - or it ignores it completely if it already exists.
>>
>> It won't duplicate the unique indices for me, it simply gives me an
>> error stating I can't create an index of the same name.  Whatever the
>> symptom, dbDelta is attempting to recreate a UNIQUE KEY index every
>> time.
>
> I have a vague recollection of something about the structure of the
> SQL required for specifying keys.
>
> In any case, you can see which indexes it can and can't find by
> uncommenting two lines in dbDelta().   dbDelta() attempts to build SQL
> that would create the indexes in the existing table, and then compare
> them to what it found in the SQL schema it was provided.  If what it
> generates does not exactly match what is in the schema, then it
> attempts to create the index as described in the schema.
>
> So you can see, if that schema attempts to generate an index that
> already exists using a method that doesn't exactly match what
> dbDelta() generates, it causes an error.  There may be a way to do
> what you want; you might need to form your schema more precisely.  If
> dbDelta() is incomplete, then it can be tweaked to include it.
>
> Owen
>
You're right.  I know when I started using dbDelta for plugin tables, I
had to really play around with the SQL syntax to get it to work just
right.  It seems to be quite finicky even with spaces in the wrong
places.  If there is a correct syntax for specifying UNIQUE KEY, I
couldn't figure it out - but I didn't spend all that much time
investigating the code or uncomment those lines and compare the statements.

Maybe if we are going to recommend plugin authors to use dbDelta, we
should have some documentation on its precise syntax?  Might benefit
those not willing to fiddle and peruse the core code until it works?  
"We" referring to the collective of WP developers/documenters.  :-)

Ryan
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: dbDelta and duplicated indices

Owen Winkler
Ryan Scheuermann wrote:
> Maybe if we are going to recommend plugin authors to use dbDelta, we
> should have some documentation on its precise syntax?  Might benefit
> those not willing to fiddle and peruse the core code until it works?  
> "We" referring to the collective of WP developers/documenters.  :-)

Originally, I had written it so that it would respond to the format that
phpMyAdmin was producing when I asked for the database struture as SQL.
  I think that's generally the SHOW CREATE TABLE format.

Owen


_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: dbDelta and duplicated indices

Ryan Scheuermann
Owen Winkler wrote:

> Ryan Scheuermann wrote:
>> Maybe if we are going to recommend plugin authors to use dbDelta, we
>> should have some documentation on its precise syntax?  Might benefit
>> those not willing to fiddle and peruse the core code until it works?  
>> "We" referring to the collective of WP developers/documenters.  :-)
>
> Originally, I had written it so that it would respond to the format
> that phpMyAdmin was producing when I asked for the database struture
> as SQL.  I think that's generally the SHOW CREATE TABLE format.
>
> Owen
>
OK, that makes sense.  I just tested a single column UNIQUE KEY with
this syntax and dbDelta works 100%, but with a multi-column UNIQUE KEY,
dbDelta does attempt to recreate the index every time even with the
exact phpMyAdmin syntax.

Ryan
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: dbDelta and duplicated indices

Ryan Scheuermann
Ryan Scheuermann wrote:

> Owen Winkler wrote:
>> Ryan Scheuermann wrote:
>>> Maybe if we are going to recommend plugin authors to use dbDelta, we
>>> should have some documentation on its precise syntax?  Might benefit
>>> those not willing to fiddle and peruse the core code until it
>>> works?  "We" referring to the collective of WP
>>> developers/documenters.  :-)
>>
>> Originally, I had written it so that it would respond to the format
>> that phpMyAdmin was producing when I asked for the database struture
>> as SQL.  I think that's generally the SHOW CREATE TABLE format.
>>
>> Owen
>>
> OK, that makes sense.  I just tested a single column UNIQUE KEY with
> this syntax and dbDelta works 100%, but with a multi-column UNIQUE
> KEY, dbDelta does attempt to recreate the index every time even with
> the exact phpMyAdmin syntax.
>
> Ryan
>
And actually, I just tested it again - with a single column UNIQUE KEY
when the key already exists but you change the key column, dbDelta
attempts to ADD the unique key index but it doesn't drop the old index
first.  That's probably the problem.

Ryan
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: dbDelta and duplicated indices

Mark Jaquith
On Apr 25, 2006, at 1:12 PM, Ryan Scheuermann wrote:

> And actually, I just tested it again - with a single column UNIQUE  
> KEY when the key already exists but you change the key column,  
> dbDelta attempts to ADD the unique key index but it doesn't drop  
> the old index first.  That's probably the problem.

I encountered a problem like this while testing a patch that bumped  
the database version... upgrade.php was throwing that error while  
dealing with one of WordPress' new multi-column keys.
--
Mark Jaquith
http://txfx.net/


_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers