ied_plugin_composer - new plugins never came that easy

pepebe · 2008-08-11 12:03:20

Hi there even though I have failed to properly use this plugin, I want tp express that I believe it is very important for anyone envolved in textpattern plugin creation.

Regarding the integration of plugin_composer into your php working environment, I would like to recommend It’s all Text a firefox plugin. It will create a button near any textfield that will open the content of this textfield within your favourite editor. Saving the file in your editor will automatically update the content of your textfield. Try it, ou will love it!

Another thing. I don’t want to ring the BUG bell, but I have encountered a rather strange behaviour of ied_plugin_composer

I’m working on some hacks for zem_event .

When I try to upload code copied to the textfield, it is always cut off at line 2189. I don’t think this is a filesize problem and I also don’t think the problem is related to the code itself. Is anyone out there with a similar problem?

Thanks,

pepebe

Last edited by pepebe (2008-08-11 12:04:23)

Bloke · 2008-08-11 12:16:43

pepebe wrote:

When I try to upload code copied to the textfield, it is always cut off at line 2189.

Thanks for the tip about “It’s all text”. Will have to try it.

With regards the “bug” I think 2189 lines is cutting it close. I had to split my recent in-development plugin into two pieces because it was aruond 2000 lines of code. There is an internal database limit of 65535 characters for plugin code, and a similar size limit for plugin help (take into account it adds the CSS to the help text as well).

My guess is you’ve hit that code limit; if your text editor can count characters, check that, or ensure the file size isn’t over 64kB.

pepebe · 2008-08-11 14:36:44

Thanks Mr. Dawson!

Regarding “‘It’s just Text”. I really recommend this tool, so give it a try and spread the word. It’s worth it. Used to play around with all kind of plugins and javascript things to have something like a WYSIWYG Editor while working within textfields all over the net. But now it’s only IJT and my favourite editor.

Regarding internal databaselimit: A total of 67837 characters would be in favour of your guess. If thats all I just have to split the whole thing into two or more parts. That’s fine with me.

By the way – since you have your fingers in the plugin’s development – would’nt it be a good idea to let the user know, that an uploaded file is exceeding database limits?

Thanks again,

pepebe

Bloke · 2008-08-11 15:07:48

pepebe wrote:

would’nt it be a good idea to let the user know, that an uploaded file is exceeding database limits?

Probably :-)

When I finally figured the “syntax errors” I received were due to the database truncating the field — even though the stuff in the composer text box looked fine — I considered adding something like that in the next release. May still do so.

Depending on what’s possible/easy, I’m in a few minds here:

Just issue a warning on saving, and save what it can
Issue warning + refuse to save the plugin if the code is too big to avoid corrupting what is there already
Use JS to count characters in the textbox and indicate when there are too many
Refuse entry of any more than 65535 chars in the textbox via JS

Each has merits and drawbacks: #1 may lead to syntax errors and lost code; #2 carries the risk that if you don’t spot the warning at the top of the screen your edits aren’t saved; #3 still allows an oversized plugin to be saved (thuis requires #1 or #2 server side); #4 is probably safest but if pasting a whole hunk of code, some way of indicating the box is full is required.

There may be other, better, methods. Any thoughts on a preferred mechanism?

P.S. though it’s probably obvious, for anyone hitting limits and not wishing to split the plugin up during development, using a template file in the plugin dev directory bypasses the database limits entirely. Though if you wish to distribute the plugin in that form, it requres special instructions for users!

pepebe · 2008-08-11 16:15:46

First of all I would go for door number 2. This will prevent a plugin from being currupted without anybody knowing that “sometime” in the past, “something” went wrong. To make people sensible for this problem, you could add some kind of message next to the save button.

Something like “Your plugin was successfully safed. It is made up of “n” Charaters. You may add another “m” characters before the plugin reaches it’s limit” would tell people in advance, that they might be facing a problem in the future.

Door number three and four are niece addons. This depends on how much work are you willing to put into the plugin in the near future.

Anyway,

any improvement would be appreciated.

Yours,

pepebe

Bloke · 2008-11-03 02:41:59

Although TXP 4.0.7 is not yet upon us, it’s kind of useful for developers running SVN to be able to get their plugins into ship-shape order ready for the release. I’ve been sitting on a new version of the Composer for a while and I think it’s probably the right time to release it now the core changes are thinning.

So, if you are running a recent copy (r2948 or later) of TXP then feel free to grab Plugin Composer v0.8 | zipped. It’ll fall over — rather unceremoniously — on anything earlier.

Features:

Re-jigged the layout to reclaim some space (e.g ‘Edit’ link now gone: click the plugin name to edit it)
Recommended plugin load order supported
New admin-only plugin type supported (the Composer uses it!)
New official plugin template used + net-carver’s code-first version
Rollback / restore a plugin to a previous point (just one – don’t get too excited!) — thanks maverick
Filename output format is now configurable for those who hate _zip or gangly file names
Character countdowns under the textareas and a hard limit on chars entered to try and prevent database field overrun — thanks pepebe
Speed improvements when exporting/saving plugins and a few other internal clean-ups
Documentation overhaul
Few corner-case bug fixes and improvements (like empty plugin name handling, missing quotes in templates, better detection of admin-side code in a client side plugin, better Textile detection…)

As usual, if you have any comments, concerns, words of encouragement or derision, chuck ‘em my way.

Bloke · 2008-12-01 10:29:51

With the official release of TXP 4.0.7, there were of course some last minute changes to the core that impacted the composer (removal of the incredibly useful sanitizeForFile() boooooo!) so I’ve re-issued Plugin Composer v0.8 | zipped with my own smd_sanitizeForFile() function which is a direct clone of the way the core does it now.

I also fixed a tiny problem with the “plugin code for distribution” textarea: the help chunk is now properly passed through Textile.

If you had an earlier version of v0.8 please re-download it if you are running the final TXP 4.0.7. Sorry for any hassle.

Bloke · 2009-01-03 11:40:50

Maintenance release to improve the dire performance with large plugins.

A new option in the Setup page (on by default when you install the new prefs) enables help cacheing. The default is to use TXP’s temporary directory but you can move it anywhere you like or empty it out (not recommended) if you prefer the slow boat.

The plugin spent an incredible amount of time passing the help file through textile again and again, so I simply put a system in place to cache the textiled output. It makes a massive difference: Saves (after the first, and when the help hasn’t been changed) are quicker and exports/plugin help views are several orders of magnitude faster.

OT geek time: bitten with the speed bug I then spent the rest of the morning profiling the code wth this class and shaving off milliseconds here and there. It all adds up, and I was surprised to find that Steve’s simple check to see if an admin-side plugin was set as Client was one of the biggest culprits. Darn regexes! Even more surprising was that eliminating the regex, and running 2x str_replace() and 6x strpos() was quicker across the board (up to 4x quicker on average) than a single preg_match(). Crazy! Adding some short circuiting logic at the head of the function helped enormously too. Same for reading template files: dropping out of the loop earlier instead of needlessly undulating to the end of file gave some measurable performance boosts.

Anyway, download the speedier Plugin Composer v0.81 | zipped and let me know how you get on.

Last edited by Bloke (2009-01-03 11:43:11)

vaughn-taylor · 2009-02-09 14:23:01

Bloke: I’m getting a “Badly formed or empty plugin code.” message when I try to install this plugin with 4.08.

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.

Textpattern CMS

Textpattern CMS support forum

#76 2008-08-11 12:03:20

Re: ied_plugin_composer - new plugins never came that easy

#77 2008-08-11 12:16:43

Re: ied_plugin_composer - new plugins never came that easy

#78 2008-08-11 14:36:44

Re: ied_plugin_composer - new plugins never came that easy

#79 2008-08-11 15:07:48

Re: ied_plugin_composer - new plugins never came that easy

#80 2008-08-11 16:15:46

Re: ied_plugin_composer - new plugins never came that easy

#81 2008-11-03 02:41:59

Re: ied_plugin_composer - new plugins never came that easy

#82 2008-12-01 10:29:51

Re: ied_plugin_composer - new plugins never came that easy

#83 2009-01-03 11:40:50

Re: ied_plugin_composer - new plugins never came that easy

#84 2009-02-09 14:23:01

Re: ied_plugin_composer - new plugins never came that easy

#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

Board footer