ied_plugin_composer - new plugins never came that easy

pieman · 2009-12-17 10:11:49

To get around this problem I’m going to pull all plugins into the db.

Yura’s original feature list suggests you can import .php plugins to the database from the plugin_cache_dir, but I can’t see any way to do that. Sounds quicker than exporting and copy/pasting.

Does that feature still exist, or am I misreading it?

Bloke · 2010-02-11 15:11:29

Minor update to v0.91 which adds a single feature: a ‘Jump to line’ entry system under the source code box.

If you’re editing away and want to jump to a particular line (or a plugin dev tells you to visit line NNN in the plugin to make an amendment), just tab or click into the Jump to line box, type a line number and hit enter. The plugin’ll do its best to get there and show you the corresponding line number. If it can’t figure out what you mean it’ll stick the cursor at the end of the file.

This works in Firefox 3.5+ and IE7 quite well. Not tested IE8 but it should be OK. Google Chrome does highlight the line but won’t scroll it into view so you have to hit another key (like an arrow key) to move the portion of the textarea into view. Opera, however, is a complete fail and seems to highlight random portions of code near the right area and then delete bits of it. Luckily there’s undo!

If anyone has any tips on how to make this more cross-browser compatible and/or some insight into how to do it more efficiently in jQuery instead of the awful DOM scripting I’ve cobbled together, please let me know. I had it working within a couple of hours on Firefox; the rest of the time has been spent hammering and googling trying to find out how to get it to work in the others, without much success. Grrrrr.

MattD · 2010-03-05 17:44:43

It may be to early to ask this question but can support for textpacks be added to the plugin?

Bloke · 2010-03-05 23:56:26

MattD wrote:

can support for textpacks be added to the plugin?

Certainly. It’s on the cards, I’ve just got to get my head round how best to implement it.

All I have right now are a bunch of questions floating round my noggin’, e.g. should there be another textbox on the main screen that allows you to write and edit the textpack information? Or should that be on a separate screen? Or even a separate/companion plugin that allows language management for installed plugins and textpacks to be generated? Should the composer be able to save out and import textpacks independently for different languages? Should they be allowed to be merged into one textpack or remain separate?

I’ve got a bit of scope blindness on this as to where the composer’s job ends and to what degree it should encompass textpacks. Of course, if you have any thoughts on how to approach it, please let me know as it might shape my thinking.

I think I’ll wait for the dust to settle a few days in case any other changes or ideas pop up that might nudge me in a particular direction and then I’ll start work on it.

rsilletti · 2010-03-06 00:52:18

I see a TODO line for language table cleanup and I can certainly see the need developing quickly as folks pick up on textpacks. A companion plugin, added facility to composer, or both; could include the choice of adding, editing, or deleting table contents. Of course this would lead to all the potential problems that go along with language updates, much like core code, where the method of clear and replace an entire language would remove changes made thru the plugin.

The, “insert” only what’s new and “update” what’s already present, method, that textpacks uses would add to a language or rewrite some already present elements.

A separate plugin for textpacks seems redundant given the textarea on the language screen. The plus side would be adding a DB field for textpack entries so they can be recalled by language and status ( textpack or not textpack ) settings, given that option – yes, separate plugin.

I would like to see a textarea to include a textpack with a plugin in composer ( to include with plugin metadata ), with the option to export that textpack separately as a text file for distribution for users to edit and adapt to whatever plugin language they desire, but more than that would create a second development function for composer ( language development ) and navigating around unused fields for one need would interfere with other – perhaps too much?

Just kinda peaking out over the edge to where this very neat new stuff might go :)

Last edited by rsilletti (2010-03-06 03:40:32)

MattD · 2010-03-06 01:01:22

As a plugin developer who speaks only one language I just want to be able to provide a default english textpack with my plugin and allow users to create their own textpacks for their languages.

candyman · 2010-03-06 08:35:13

+1 for MattD request.
The possibility of customizing a separate language_file.txt should
allow more customization from the final user, according his needs (puns, capitalization and so on…).

On the other hand, if the plugins should be upgraded with minor fixes (without more functions, features and buttons…) the custom language:file.txt could remain untouched.

Now, when MattD release a new version of his msd_google_map I have to translate the keywords in the code whenever.

Last edited by candyman (2010-03-06 08:47:44)

maniqui · 2010-04-13 04:11:14

Hi Bloke,

after exporting plugins (to be run directly from plugin cache dir) using ied_plugin_composer, a common issue arises when the text in the plugin description field includes an straight single quote. For example:

$plugin['description'] = 'Turn backend Write-tab's Status radio buttuns into a select field';

The error usually reads something like this:

Parse error: syntax error, unexpected T_STRING in /home/xxxxxx/textpattern-4.2.0/textpattern/plugins/active/rah_status_dropdown_v0.1.php on line 23

This happened to me with a few plugins that had some single quotes on their description.

I tried fixing it by simple escaping the quote like this Blablabla\'s. Although that fixed the error message, this solution trimmed all the text (on the plugin description field) that was before the escaped quote.

Bloke · 2010-04-13 08:05:08

maniqui wrote:

after exporting plugins (to be run directly from plugin cache dir) using ied_plugin_composer, a common issue arises when the text in the plugin description field includes an straight single quote

Thanks for the report. The plugin doesn’t do the escaping properly which is very naughty. I’ve noticed that before but never got round to fixing it, sorry.

There’s a similar issue with importing from a PHP/template file; from memory I think if the code has backslashes in it they’re stripped off when the code is imported which causes syntax errors until you track them all down and add the backslashes again (or something like that — I’ll have to do some diagnostics).

I’ll see what I can do in the next revision. Still haven’t decided what to do about textpacks, btw. Rick’s tentative new plugin has perhaps obviated the need for the composer to do anything aside from export/import the textpack string to/from the plugin template format. Another option would be to roll Rick’s code into the composer (or at the very least allow a shortcut link from the composer screen to Rick’s panel if the plugin is installed) to allow textpacks to be added/deleted.

I think there’s definitely a need for some kind of textpack export (export textpack in language xx-yy), it’s just finding the right place for it — the composer? a separate plugin? — and how to easily manage the strings. Any thoughts from anyone please send them this way.

Gocom · 2010-04-13 09:38:53

Bloke wrote:

I think there’s definitely a need for some kind of textpack export (export textpack in language xx-yy), it’s just finding the right place for it — the composer? a separate plugin? — and how to easily manage the strings. Any thoughts from anyone please send them this way.

I vote for better TXP core implemention. Like additional textpacks column to txp_plugin table which stores the raw array. Would make adding and removing string easy. Also, would make re-packaging plugins almost too easy.

Last edited by Gocom (2010-04-13 09:40:35)

maniqui · 2010-10-14 20:59:20

Hi Stef,

you know, I like to run plugins from plugin_cache_dir. It makes my life easier, it let me do versioning and other crazy things, like having a /txp_plugins/ folder, full of TXP plugins (and its versions) somewhere on my system and symlink each plugin I need on a per-TXP-installation basis.

But there is one thing that I miss from installing/activating/running plugins from DB, and that is, that some plugins (glz_custom_fields, arc_twitter, and others too), when activated, they add an “Options” link in the “Manage” column (on “Admin -> Plugins”).

Do you think it would be possible to have this “Options” link on the “Publish” column, in “Extensions -> Plugin composer”, for those plugins that have options.

If not, there is no way to easily access/find-out that a plugin have an Options tab. And that always catch me…

Of course, it may be the price to pay for being so über-cool and run plugins from filesystem, but, hopefully, it’s just that you forgot to add it :)

Thank you.

Bloke · 2010-10-14 22:45:39

maniqui wrote:

Do you think it would be possible to have this “Options” link… hopefully, it’s just that you forgot to add it :)

I didn’t forget to add it. It’s a bug. The new template file format introduced something near the top of the file that I previously checked to signify the end of the header block. So the header portion bombs out early before it reaches the plugin flags. Simple one-line fix until I get round to it officially. Find line 922ish where it says:

if (strpos( $content[$idx], 'if (!defined' ) === 0) {

and change it to:

if (strpos( $content[$idx], 'if (!defined(\'txpinterface\')' ) === 0) {

Job done. You’ll get the [Options] link on the left after the plugin name, just like you do with DB-installed plugins (of course, now you’ll say you desperately want it in the Publish column, right? :-)

Sorry about that, and thanks for spotting this bug. I’ll fix it along with the stupid backslash bugs (with luck, when I find them) in the next version.

Last edited by Bloke (2010-10-14 22:48:50)

Textpattern CMS

Textpattern CMS support forum

#121 2009-12-17 10:11:49

Re: ied_plugin_composer - new plugins never came that easy

#122 2010-02-11 15:11:29

Re: ied_plugin_composer - new plugins never came that easy

#123 2010-03-05 17:44:43

Re: ied_plugin_composer - new plugins never came that easy

#124 2010-03-05 23:56:26

Re: ied_plugin_composer - new plugins never came that easy

#125 2010-03-06 00:52:18

Re: ied_plugin_composer - new plugins never came that easy

#126 2010-03-06 01:01:22

Re: ied_plugin_composer - new plugins never came that easy

#127 2010-03-06 08:35:13

Re: ied_plugin_composer - new plugins never came that easy

#128 2010-04-13 04:11:14

Re: ied_plugin_composer - new plugins never came that easy

#129 2010-04-13 08:05:08

Re: ied_plugin_composer - new plugins never came that easy

#130 2010-04-13 09:38:53

Re: ied_plugin_composer - new plugins never came that easy

#131 2010-10-14 20:59:20

Re: ied_plugin_composer - new plugins never came that easy

#132 2010-10-14 22:45:39

Re: ied_plugin_composer - new plugins never came that easy

Board footer