ied_plugin_composer - new plugins never came that easy

vaughn-taylor · 2009-02-09 14:24:11

Correction, I only get that message with the non-zipped version above.

azw · 2009-02-19 09:57:09

I’m having trouble getting going with ied_plugin_composer. I think it’s something I’m not doing correctly.

If I fill in the name of a new plugin in the field at the top of composer’s main page and click on “Create new plugin”, I get this error:

<br />
<b>Warning</b>:  Field 'description' doesn't have a default value
insert into txp_plugin set 
			name='azw_hello_world-v0.1.php',
			status='0',
			type='0',
			version='0.1',
			load_order='5'

C:\server\sites\my_site\public_html\textpattern\lib\txplib_misc.php(570) : eval()'d code:494 safe_insert() in
 <b>C:\server\sites\my_site\public_html\textpattern\lib\txplib_db.php</b> on line <b>82</b><br />

I’ve tried different ways of naming the file (azw_my_plugin.txt, azw_my_plugin.php, and azw_my_plugin).

The ied_plugin_composer does create a file: azw_my_plugin_help.txtl in the plugin_cache_help directory. It’s an empty file. There is nothing created in the plugin_cache_dir.

If I go ahead and type in content for all of the fields and then click on “save”, nothing is saved. Text at the top says the file has been saved, but it doesn’t appear in the file manager listing. Instead, I see a long list of “Notice: Undefined variable: help in …” which is essentially a list of all the variables for the fields I had just filled in.

If I edit the standard plugin_template in a text editor first and save it in the plugin_cache_dir, then I can edit it in ied_plugin_composer without problems.

What am I doing wrong?

I’m working on a localhost server on my desktop computer with TXP 4.08. This installation of TXP has just glz_custom_fields and this plugin installed. The server and TXP seem to work, but it could be a problem with one of them.

Last edited by azw (2009-02-20 01:01:05)

Bloke · 2009-02-21 19:22:36

azw wrote:

Field ‘description’ doesn’t have a default value

Weird. Doesn’t do that on my 4.0.8 with composer 0.81. Hmmmmm. What version of PHP / MySQL are you running? I’m using an ancient version so it may be something PHP5ish.

I’ve tried different ways of naming the file (azw_my_plugin.txt, azw_my_plugin.php, and azw_my_plugin).

Right, that’s a stupidity of the plugin that I’ll have to see if I can address. The plugin assumes (always has) that any new plugin created this way goes in the database, not the cache dir. The help will be created because that’s separate. If you want to use the plugin_cache_dir you have to upload a template to the directory or write a line or two of PHP in a file and use the Upload plugin from PHP file option at the bottom of the composer’s plugin list (don’t forget to name it as well in the field to the right of the Browse button!) EDIT: that’s a lie, the lower box always uploads to the database.

What I probably should do is check your plugin name that you put in the top box and if it ends with .php, save it in the cache dir (if it exists/is set up). I’ll look into doing that for you. In the meantime I’ve no idea on the errors but if you can check your PHP/MySQL versions I might be able to figure something out.

P.S. you are on TXP 4.0.8 I assume?!

Last edited by Bloke (2009-02-23 13:18:31)

azw · 2009-02-22 01:19:20

Thanks for the help, Stef. This may sound weird, but when I saw that you had replied it brought a big smile to my mug.

Here’s my setup:

Textpattern version: 4.0.8 (r3085)
Server: Apache/2.2.11 (Win32) PHP/5.2.8
Apache version: Apache/2.2.11 (Win32) PHP/5.2.8
PHP version: 5.2.8
MySQL: 5.1.30-community
Active plugins: cbs_maintenance_mode-0.3, glz_custom_fields-1.1.3, ied_plugin_composer-0.81
all running on Windows Vista Home Premium 64-bit

I think you may be right. About the underlying configuration being the problem. I can get composer to work on a Linux server.
That server’s configuration is different:
Apache/1.3.39
PHP Version 5.2.5
MySQL: 5.0.67

I keep wondering if the fact that the localhost server is on a Windows Vista machine is what’s causing the problems.

It was helpful to read your instructions on the different ways one can begin work on a new plugin. Thanks!

Last edited by azw (2009-02-22 01:20:00)

Gocom · 2009-02-22 02:29:05

azw wrote:

I keep wondering if the fact that the localhost server is on a Windows Vista machine is what’s causing the problems.

No. It’s just “misusage” of not null.

You are running MySQL in strict mode, right? If so, the reason is simple; in strict mode every not null -field in an insert query needs a default value, or something to be inserted.

Thus, it’s a bug compined by plugin composer and/or Textpattern core:

Every not null field requires default value (Textpattern core).
Or alternative fix: plugin composer needs to add description='' (etc) to safe_insert()s, so always defining value which is required by strict mode.

Fix should be made from plugin composer’s side, by adding empty field inserts (description='' & not_null_field='') to the safe_insert().

Last edited by Gocom (2009-02-22 02:38:47)

azw · 2009-02-22 02:59:08

Hey, Gocom, I think you’ve nailed it. I was just reading about not null for something else and should have picked up on that! Thanks so much for figuring that out. I’ll also know now how to avoid the same problem with my plugins.

azw · 2009-02-22 03:18:50

Hmm. What about the instances in which I upload a php template and try to save it in composer but it won’t save it?

Yep. That could still be the fact that the status variable (which I can’t fill in) is null.

<b>Warning</b>:  Incorrect integer value: '' for column 'status' at row 1
update txp_plugin set name='azw_test2',
				status = '',
				type = '0',
.... and so on.

Bloke · 2009-02-22 13:09:59

Gocom / azw

Thanks for the pointers/testing; I didn’t know that. The SQL statements in the code are pretty much the same as they were back when Yura coded the thing up and I guess things have moved on a tad. I’ll make sure any not null fields are declared in the insert statements in the next rev and also look into the feasibility of being able to directly start a new plugin in the plugin_cache_dir. Watch this space.

Bloke · 2009-02-23 13:14:55

v0.82 | compressed released.

Adds the ability to directly create plugins in the cache directory by specifying the plugin name with .php appended to it in the Create new plugin box (thanks azw)
Is more aware of database column ‘types’ so should now not complain when using MySQL in strict mode (thanks Gocom / azw)
Fix for huge documentation files (*cough cough guilty*) so they don’t overspill the allocated size
Major internal rewrite for template generation so keeping the standard template up-to-date is easier for me

azw, please check the new functionality with your setup and verify that all warnings disappear. Don’t think I’ve stuffed anything up in the process but I’m on PHP4 so anything’s possible.

Last edited by Bloke (2009-02-23 13:15:49)

azw · 2009-02-23 19:31:56

I’ll test it more a bit later, but after a quick test seems it seems to be working great! Thanks, Stef!

azw · 2009-02-24 05:11:32

Oh, boy, this is a weird one. I’m not sure what the problem is, but maybe you’ll have an idea.

I used the “Create new plugin” option and typed in simple code:

phpInfo.php;

When I save that file, which is placed in the plugin_cache_dir, I lose control of the site, on both the admin and public sides. Any page I go to is my new phpInfo.php page. I have to remove the .php extension (adding .txt works) to be able to access anything else. Disabling composer doesn’t affect this odd behavior, except that I can’t create another zombie file! It’s a cool affect, but quickly irritating.

Once I regain control of the site, I have to login again to get into the admin side.

I have edited an existing file in composer and not had the same problem occur.

What do you think causes this?

Last edited by azw (2009-02-24 05:38:07)

Bloke · 2009-02-24 09:12:04

azw wrote:

I used the “Create new plugin” option and typed in simple code: phpInfo.php;… Any page I go to is my new phpInfo.php page.

Uhhh, isn’t that because cached plugins are loaded on every page automatically? If you put the phpInfo() call inside a function () { ... } you’ll be fine I think :-)

Last edited by Bloke (2009-02-24 09:12:57)

Textpattern CMS

Textpattern CMS support forum

#85 2009-02-09 14:24:11

Re: ied_plugin_composer - new plugins never came that easy

#86 2009-02-19 09:57:09

Re: ied_plugin_composer - new plugins never came that easy

#87 2009-02-21 19:22:36

Re: ied_plugin_composer - new plugins never came that easy

#88 2009-02-22 01:19:20

Re: ied_plugin_composer - new plugins never came that easy

#89 2009-02-22 02:29:05

Re: ied_plugin_composer - new plugins never came that easy

#90 2009-02-22 02:59:08

Re: ied_plugin_composer - new plugins never came that easy

#91 2009-02-22 03:18:50

Re: ied_plugin_composer - new plugins never came that easy

#92 2009-02-22 13:09:59

Re: ied_plugin_composer - new plugins never came that easy

#93 2009-02-23 13:14:55

Re: ied_plugin_composer - new plugins never came that easy

#94 2009-02-23 19:31:56

Re: ied_plugin_composer - new plugins never came that easy

#95 2009-02-24 05:11:32

Re: ied_plugin_composer - new plugins never came that easy

#96 2009-02-24 09:12:04

Re: ied_plugin_composer - new plugins never came that easy

Board footer