ied_plugin_composer - new plugins never came that easy

maniqui · 2010-10-14 23:23:24

Hi Bloke,
Thanks for the prompt reply.
Applied the change, job done. Thank you very much for that one too.

I can live with the [Options] link right there, next to the plugin name. Someday, having it on the Publish column will be a nice thing too :)

Bloke · 2010-11-03 16:48:11

For those waiting patiently for some fixes, you’ll be pleased to hear I have a version that has all the above problems nailed, plus a few other little niggles that have been bugging me for the last 6 versions or so. I could release it now (and probably will). But where I’m falling down is integrating textpacks.

The trouble I have is that if I add a textbox for the textpack — like the help/css boxes — then I need to store the contents of it somewhere on save. Without a DB field in the txp_plugin table I’ll need to stash it somewhere else — probably on disk or in my own DB table — and then simply marry the two when you Export the plugin. That’s pretty nasty so I can see why Rick added the textpack column to the txp_plugin table in his plugin.

However, I don’t think adding such a column to the core is viable/efficient. It’d effectively be duplicating effort and wasting space holding the same info as the txp_lang table — just in a different form. After all, the strings are designed to simply be inserted into the DB at plugin (or theme) installation time, or after the fact from the Language tab. It’s only people who want to use ied_plugin_composer or smd_amdin_themes who will ever need to edit them and link them to a plugin or theme and edit them in anger.

All other times I can see Rick’s plugin being the basis of a textpack manager which could keep track of who installed what and offer uninstall options, updates, installs, etc from a repository of textpacks (textpattern.org is an obvious candidate here — it’s on the “to investigate” pile).

When editing plugins in the plugin_cache_dir it’s pretty easy because the textpack can be stashed directly in the template file and retrieved when needed. It’s the plugins in the database that are the problem. But maybe I’m just not thinking outside the box enough and the solution is simple for the composer and the admin themer. Anyone have any thoughts on how it might be best achieved? Ta.

Bloke · 2010-11-04 14:29:51

Amazing what less than 24 hours of background processing can do. Think I’ve figured out how to handle textpacks:

Allow you to specify a prefix for each plugin which I’ll stash somewhere (probably in a tmp file). It’ll default to the name of your plugin
Add a smallish textarea (or two) to allow you to add strings one by one (or maybe one per line or something so you can add more than one at once)
Add a dropdown nearby which lists all the installed languages you have
The strings will be inserted directly in txp_lang under the given language, thus you can use them immediately in your code with gTxt('abc_plugin_some_string', array('{rep}' => 'replacement'))
At export time, the plugin composer will collect together all lang entries that are prefixed with your given prefix, group them by language and create a textpack from them on the fly. It will insert that at the relevant place in the plugin
I’ll add a dedicated export button at the bottom so you can export the pack as an entire file or as one pack per language for standalone redistribution
I guess I’ll also need a management screen so you can see which strings have been installed for the current plugin and edit, rename or delete them as necessary. Might be nice to do this in a floaty panel like wet_quicklink so you can see at a glance which are in use, filter them and maybe even insert the names raw or as a formatted gTxt() string into your code at the cursor location. Not sure yet if that’d be of any use
When editing the template file directly in the plugin cache dir, the strings will be written into the file as you go

Anyone see any flaws in the above, or can think of anything better / neater?

Last edited by Bloke (2010-11-04 14:30:26)

maverick · 2010-11-04 18:16:57

it doesn’t take much, but I’m impressed :)

Bloke · 2010-11-11 12:59:09

Until I can get round to the Textpack thing I mentioned above, here’s a quick bug fix update to v0.92.

Fixes:

Options link for plugins from cache dir (thanks maniqui)
Escaping of exported php files (thanks maniqui)
Escaping when importing from PHP file (hopefully… never fully got my head round magic_quotes_gpc in PHP)
jQuery bug on setup panel
Cosmetic tweaks:
- plugin_cache_dir section only displayed if there are valid PHP files
- View Help link improved slightly
Extended resizer cookie to one year expiry

Should tide you over until Textpack support comes along. Enjoy.

MarcoK · 2010-11-11 17:45:00

HI, i have installed now the v0.92 in my txp 4.3 localhost.

I obtain an error, when into the setup page of ied_plugin_composer i set the php editor as Editarea.
It change the input field below but when i save, it replace anything after / whit undefined!

Es. http://localhost/js/editarea -> save -> http://localhost/js/undefined
Es. http://localhost/pincopallino -> save -> http://localhost/undefined

Is a bug?

Bloke · 2010-11-11 20:26:05

MarcoK wrote:

Is a bug?

Yes, sorry. When I fixed the jQuery toggle behaviour I broke something else. Will fix asap.

Bloke · 2010-11-23 16:41:20

Finally got round to fixing my stupid ‘undefined’ setup bug in v0.93. Thanks MarcoK for finding that one.

Last edited by Bloke (2010-11-23 16:42:41)

jpdupont · 2011-03-07 22:51:11

I get this warning on some plugins :

Warning: file_get_contents(/tmp/tti_fbox_help.txtl) [function.file-get-contents]: failed to open stream: Aucun fichier ou répertoire de ce type in /home/www/ee1d834bc4a24e2803fc7f7db26ab389/web/textpattern/lib/txplib_misc.php(638) : eval()'d code on line 1068

or

Warning: file_get_contents(/tmp/adi_gps_help.txtl) [function.file-get-contents]: failed to open stream: Aucun fichier ou répertoire de ce type in /home/www/ee1d834bc4a24e2803fc7f7db26ab389/web/textpattern/lib/txplib_misc.php(638) : eval()'d code on line 1068

Bloke · 2012-08-01 01:51:23

For the first time in absolutely ages, ied_plugin_composer has a new beta. But please note it only runs on Txp 4.5.0.

Features:

Many more installation options hidden under the Installation twisty. Although the panel isn’t very pretty because I suck at design (layout improvements welcome, btw) you can now upload .txt files in addition to .php files, and install plugins by pasting exactly like the regular plugins panel (but without the verification step). The New Plugin Name box has been improved too so if you upload a plugin and specify a name, it takes that name instead of the one in the plugin file.
Textpack support. Once you assign a prefix to your gTxt strings, the composer automatically tracks their usage in your code and allows you to write translations in any language. You may also import strings from your existing plugin and convert them to standard gTxt() calls (see plugin help for step-by-step instructions). Textpacks can be bundled with the plugin or exported separately when publishing.
Support for more syntax editors, and complete control over their configuration (see Setup).
Save Code button{^*} which saves just the code via AJAX for rapid saving. More goodies will appear on this toolbar soon.
AJAX enable / disable.
Multi-edit.
Hide some interface elements for speeding up your workflow.
Control over lifecycle event firing (tools will appear soon for manually testing them to simulate installation, deletion, etc).

^* Note that for reasons best known to Phil’s CSS and my shoddy markup, the position of the Save Code button is hidden under the twisty panel (and also the Setup button is partially hidden). Hopefully between me & Phil we’ll figure out a fix sometime soon.

It’s a significant upgrade that’s been months in the making. I hope it’s worth it.

It still has one or two little things I’d like to polish and I want to find a way round the Hive button bar bug, but I think it’s robust enough to unleash. So if you’re running a nightly version of 4.5.0 grab a copy of v1.00 beta and please report your findings. I’m especially interested in the Textpack integration and whether it fits with people’s workflows. I think it’s flexible enough to work in any way you prefer, but if I’ve made any stupid assumptions or you can think of a way to improve it, please let me know.

The composer itself uses a Textpack now, so if anyone wants to submit a translation I’ll roll it into future plugin versions. When .org finally hits the ground we’ll have an area where people can share Textpacks directly so others can download them. More details as and when we get time to focus on it.

Many thanks in advance for testing this. I hope it serves you well.

colak · 2012-08-01 03:42:58

Hi stef.

Installed it on 4.5 beta but when I click on any of the edit links in the composer page I get

I’m sorry. I’m afraid I can’t do that. I think ied_plugin_composer ied_plugin_edit is no safe operation at this time.

Bloke · 2012-08-01 08:44:33

colak wrote:

I’m sorry. I’m afraid I can’t do that. I think ied_plugin_composer ied_plugin_edit is no safe operation at this time.

Weird. Works ok for me. You could try changing the line near the top of the plugin that reads:

'ied_plugin_edit' => true,

and change the true to false. But that’s only a temporary fix. It sounds, especially given your problems with rvm_privileged and this plugin, that things aren’t quite installed or set up correctly on your server. Not sure why though. I assume you’ve done a complete hard-refresh to flush any browser cache?

Last edited by Bloke (2012-08-01 08:45:21)

Textpattern CMS

Textpattern CMS support forum

#133 2010-10-14 23:23:24

Re: ied_plugin_composer - new plugins never came that easy

#134 2010-11-03 16:48:11

Re: ied_plugin_composer - new plugins never came that easy

#135 2010-11-04 14:29:51

Re: ied_plugin_composer - new plugins never came that easy

#136 2010-11-04 18:16:57

Re: ied_plugin_composer - new plugins never came that easy

#137 2010-11-11 12:59:09

Re: ied_plugin_composer - new plugins never came that easy

#138 2010-11-11 17:45:00

Re: ied_plugin_composer - new plugins never came that easy

#139 2010-11-11 20:26:05

Re: ied_plugin_composer - new plugins never came that easy

#140 2010-11-23 16:41:20

Re: ied_plugin_composer - new plugins never came that easy

#141 2011-03-07 22:51:11

Re: ied_plugin_composer - new plugins never came that easy

#142 2012-08-01 01:51:23

Re: ied_plugin_composer - new plugins never came that easy

#143 2012-08-01 03:42:58

Re: ied_plugin_composer - new plugins never came that easy

#144 2012-08-01 08:44:33

Re: ied_plugin_composer - new plugins never came that easy

Board footer