ied_plugin_composer - new plugins never came that easy

Bloke · 2008-07-18 15:33:18

variaas wrote:

I keep getting a badly formed code/empty code when I try to install 0.75. Anyone else?

Even with the compressed version?

maverick · 2008-07-18 16:07:49

On my extensions page I also have tabs for Ruud’s plugin differences and Mary’s plugin restore (I edited to show with my other plugin pluins :) along side of my ied_plugin_composer tab. Would they be candidates (with their authors’ permission of course) for inclusion ied_plugin_composer? I guess I’m thinking of fighting tab multiplication pollution :P

Also cool would be including rss_pluginstaller (or asv’s or manfre’s versions) in a super plugin composer/manager plugin. But I think I’m probably just dreaming too big LOL.

Mike

Bloke · 2008-07-19 09:21:22

maverick wrote:

I also have tabs for Ruud’s plugin differences and Mary’s plugin restore… along side of my ied_plugin_composer tab. Would they be candidates (with their authors’ permission of course) for inclusion ied_plugin_composer?

My Extensions tabs is getting rather crowded I must admit!

If the authors don’t mind, then it’s possible. Whether desirable, well, I’m not sure. The upcoming v0.8 — which includes support for the plugin load order — would be a candidate, although it needs a minor mod because the table name changed recently.

Plugin restore is interesting because the original code is stored on upload. However, I think it’s stored:

when a plugin is loaded from the admin->plugins tab (easy to restore)
every time you click Save in the plugin composer editor window

I can’t remember off the top of my head how the composer handles it, but I think that’s right. Thus, if a plugin is started from scratch in the composer, and is constantly updated until it’s ready for release, at what point does the plugin get marked as ‘the one’ that you can roll back to? i.e. at that point, it would be put in the code_restore column and not touched.

I suppose I could add a checkbox that states “when I save, commit this version as my baseline”. That would then store the code in the restore column, mark the plugin as “clean” and would remove the “Yes” from the Modified column. Any further mods would make the plugin “dirty” again until the checkbox was ticked and the plugin saved. Then, a simple plugin restore (+ “Are You Sure”) could be done with no bother. Does that sound workable?

Regarding rvm_diff, yes it’s useful, but my gut feeling is it’s perhaps too specialist to be included. Plus I wouldn’t know where to begin putting the functionality!

One thing I have been considering, but not yet implemented, is a way of reducing the number of columns. e.g. from the Setup you can specify which columns you want to display. There are “core” columns of course, but others could be optional to save space. If that’s desirable let me know.

Also cool would be including rss_pluginstaller (or asv’s or manfre’s versions) in a super plugin composer/manager plugin.

I’d love to see that, but until such time as there’s a central plugin repository or an agreed standard way of checking for new versions (e.g. a known directory structure or naming convention) it’s probably quite tricky to implement. I’m all ears if someone has done a generic system or has some ideas on setting a standard. I know Rob’s was only for his own plugins — I’ve not looked at manfre’s or variaas’ attempts yet so they may approach it in a different manner.

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.

Textpattern CMS

Textpattern CMS support forum

#73 2008-07-18 15:33:18

Re: ied_plugin_composer - new plugins never came that easy

#74 2008-07-18 16:07:49

Re: ied_plugin_composer - new plugins never came that easy

#75 2008-07-19 09:21:22

Re: ied_plugin_composer - new plugins never came that easy

#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

Board footer