Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Re: ied_plugin_composer - new plugins never came that easy
net-carver wrote:
just noticed that if I try editing ied_plugin_composer in itself, that the style section isn’t correctly being pulled into the style edit area.
True, that’s a pain and on the ToDo list.
As you know, when compiled and installed the plugin help is essentially just $css.n.Textiled($help) which is of course all stored in the help DB field as HTML not Textile. Since there are no pretty # -- BEGIN CSS SECTION -- blocks there’s no obvious way of separating it out again.
I suppose I could just split the blocks at the <style>...</style> markers and hope nobody uses those tags in the help itself, or find some way (perhaps <-- BEGIN CSS SECTTION --> ?) of putting the original markers in the compiled HTML help so it can be more easily pulled out. The extraction routine I wrote allows this (sort of; a minor mod to add the end marker and it will) so it’s not beyond the realm of possibility.
Either way though, the help has lost its Textile formatting, which is a shame. I’m kind of hoping there’s a way of storing it using the raw help mode but I couldn’t figure it out last night. Maybe with fresh eyes and some chocolate it’ll become obvious… or someone might point me in the right direction.
In addition, could you explain a little more how I can control the order of sections when the plugin is saved as a php file.
Sorry yeah, under the Setup button there’s a pref labelled ied_plugin_output_order. “Code first” or “Help first”. I will endeavour to make that more obvious and also add some much needed gTxt() to the help options and various stuff. I toyed with the idea of putting those radio buttons right next to the “save as php…” file link, and may yet do so. Just didn’t want to add to the confusion of having a prefs page and only some of the prefs on it, that’s all!
The prefs page needs an overhaul. The code’s simple behind it, just the layout and interaction I want to spruce up. If you or anyone has ideas on neat ways of generating HTML elements that can also be “intelligent” insofar as they have onchange ability to disable or update other elements depending on the select status, please let me know. I’m sure hand-coding the elements and adding some jQuery’s the answer; using the TXP core calls and the ‘onchange’ option in selectInput() just causes the form to have onsubmit="index.php" : not quite what I want. I’ll experiment.
iblastoff wrote:
not sure about the rest of you but i’ve always found using edit_area and codepress to be rather slow when editing a typical mid to large sized plugin
Yup, very very slow. Annoyingly slow in fact. I don’t use it — I tend to write code in a text editor with syntax highlighting then paste it into the pluign composer so I can test it, add the help/styles and release it. Plus of course there’s that weird Codepress issue that deletes the “code” block prior to posting it back to the plugin thus leaving your code block empty after saving. Urk; wish I knew why. But some people writing smaller plugins might like the editors so I’ll leave them in.
Certainly I wouldn’t advocate editing MLP or ied_plugin_composer in it (he says, from experience!)
EDIT: I wonder if perhaps the slowness of the initial loading of EditArea is due to me adding the javascript at the end of the page. Since I know in advance which editor a person wants I could very easily put that first so the javascript could be loading while the form is being rendered. I’ll also check the Edit Area code and see if I need to make it wait for domReady() or if it does it natively.
EDIT2: Nope, makes chuff-all difference. Still as slow as a slow thing behind a tractor.
Last edited by Bloke (2008-01-07 14:23:30)
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Txp Builders – finely-crafted code, design and Txp
Offline
Re: ied_plugin_composer - new plugins never came that easy
hakjoon wrote:
I’d love to make it [hak_tinymce] spit out textile. I have an idea on how to do it but I haven’t had time to prototype it yet.
Just stumbled upon detextile
I’ve just been musing about Steve’s above post and finding every way I turn to keep the mixed HTML/Textile and CSS blocks intact, TextileThis() — as implemented in the plugin page’s help viewer — gets in the way and renders any embedded HTML as a series of entities, thus it displays as plain text. Even stuff in so-called Textile ‘comments’ (the double equals) is converted. Urk.
So I’m kinda tempted to just always encode it as HTML when the plugin is saved but then detextile it when loading it back into the plugin composer. I have no idea how quick it is or whether it’s something I really want to be doing but I might resort to it.
Anyway, thought I’d post it in case it’s also of some use to you, Patrick. I don’t think the fact it’s written for the CakePHP framework impacts its usability much. Once the function names are converted to avoid clashes and/or updated to use more efficient calls from the core, looks like it might do the trick. Guess trying it under vanilla PHP will prove it one way or the other…
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Txp Builders – finely-crafted code, design and Txp
Offline
#51 2008-01-07 14:33:57
- net-carver
- Archived Plugin Author
- Registered: 2006-03-08
- Posts: 1,648
Re: ied_plugin_composer - new plugins never came that easy
Stef
Finally noticed the prefs button — thought it was MIA.
Thanks,
— Steve
Offline
Re: ied_plugin_composer - new plugins never came that easy
net-carver wrote:
Finally noticed the prefs button — thought it was MIA.
Hehe, I could make it bigger if you like ;-) Or red?
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Txp Builders – finely-crafted code, design and Txp
Offline
#53 2008-01-08 05:40:27
- net-carver
- Archived Plugin Author
- Registered: 2006-03-08
- Posts: 1,648
Re: ied_plugin_composer - new plugins never came that easy
Don’t worry. I think it’s just a side-effect of my age.
— Steve
Offline
Re: ied_plugin_composer - new plugins never came that easy
Another update to address (most of) the recent posts:
Version 0.7 (compressed) now sports:
- Re-importing compiled/uploaded plugins retains style block (thanks net-carver)
- Added ‘admin side plugin with client-side type’ warning (thanks net-carver)
- Changed button/link styling and positions (red should show up better ;-)
- gTxt() pref labels and ‘intelligent’ prefs now adjust depending on which options are chosen from the dropdowns
- Cached plugins now also have direct export ability from the bottom of the Edit page
- Added an internal ‘don’t textile HTML’ check to sidestep some odd encoding issues
- Better plugin Help
- Minor bugfixes
Enjoy, and shout if you find anything else or have any feature requests. Specifically:
- Is anyone using TinyMCE (which I notice isn’t so tiny any more!) in the Plugin Composer, or is Textile enough now?
- Are there any other mini HTML editors out there that might do the job?
- What about re-textiling HTML when editing compiled plugins? Useful or not? Or will keeping a .php copy in standard template format be enough?
- Any advances on why CodePress kills the code block? Or is it just my installation that does that?
- Anything more…?
Last edited by Bloke (2008-01-08 13:51:55)
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Txp Builders – finely-crafted code, design and Txp
Offline
Re: ied_plugin_composer - new plugins never came that easy
After a good ol’ chat on IRC with a bunch of cool folk, here’s a(nother) update, mostly thanks to variaas, but also to iblastoff for inadvertently giving me an idea from a screenshot he posted in lam_article_info :-)
New features in v0.71 (compressed) :
- Textarea widths increased slightly – still fits comfortably within 1024×768 by default
- Textarea width controllable via prefs; useful if you happen to use a humungous screen
- Textarea height controllable via a drag bar below the edit area (note: doesn’t work with Edit Area enabled). The size is retained as a cookie so it’ll resize whenever you enter the edit page
- Plugins can now be published from the List page as well as from the Edit Page
- Install button removed when prefs are all successfully loaded
- Couple of minor layout tweaks and some more styling; nothing drastic
Take it for a spin and report any oddities here as usual.
(P.S. apologies but my hoster is having a go-slow at the moment. grrrr)
Last edited by Bloke (2008-01-10 00:00:52)
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Txp Builders – finely-crafted code, design and Txp
Offline
Re: ied_plugin_composer - new plugins never came that easy
Eek, I’ll continue my monologue with another bug fix update.
v0.72 (compressed) fixes the following:
- Infinite loop if plugin help left empty
- Style section no longer exported if it is not used
Thanks to the_ghost and iblastoff for spotting this.
@iblastoff: You won’t be able to edit the current version of your lam_article_info plugin in the composer unless you manually delete the <!-- --- BEGIN/END PLUGIN CSS --- --> markers, sorry. Couldn’t find a neat way round it. If you blank out the help section manually in phpMyAdmin you’ll be able to edit it and it won’t happen again, promise :-)
EDIT: Bugger, just found another srupid bug. Back in a sec…
EDIT2: OK, link back up again sorry for the yoyo.
Last edited by Bloke (2008-01-10 09:51:59)
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Txp Builders – finely-crafted code, design and Txp
Offline
Re: ied_plugin_composer - new plugins never came that easy
Stef, I really appreciate the work you are doing on this. I haven’t really had a chance to play with the new versions but just seeing this plugin get some well deserved attention is great.
I need to look at that detextile thing. I don’t think it existed when I last went searching. I was thinking of doing it using a client side XSL transform now that Safari can support it too, but this might be easier.
Shoving is the answer – pusher robot
Offline
Re: ied_plugin_composer - new plugins never came that easy
Bloke wrote:
@iblastoff: You won’t be able to edit the current version of your lam_article_info plugin in the composer unless you manually delete the<!-- --- BEGIN/END PLUGIN CSS --- -->markers, sorry. Couldn’t find a neat way round it. If you blank out the help section manually in phpMyAdmin you’ll be able to edit it and it won’t happen again, promise :-)
thanks for the heads up! though using v0.72 i can’t seem to directly edit ANY of the plugins i have in my plugin cache directory anymore. clicking ‘edit’ for any of them just brings me to completely blank textareas. i’ll try to investigate a little further.
Last edited by iblastoff (2008-01-10 16:56:20)
Offline
Re: ied_plugin_composer - new plugins never came that easy
iblastoff wrote:
though using v0.72 i can’t seem to directly edit ANY of the plugins i have in my plugin cache directory anymore
Arse. Maybe I should backtrack on my “promise it won’t happen again” comment then ;-) Sorry.
When I get home I’ll investigate by putting your plugins in the cache dir and see why it falls apart. Aologies for messing you about. I’ll try and do more rigorous testing before the next rev!
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Txp Builders – finely-crafted code, design and Txp
Offline
Re: ied_plugin_composer - new plugins never came that easy
A tiny update. When I tried to upload the template source code of net-carver’s MLP, the Composer choked on one of the variables. Steve uses SVN and he’s modified his template to read $LastChangedRevision. I simply stole borrowed his code and incorporated the idea into the composer in case anyone else wants to use it this way.
You can add the following line to the top section of the standard template if you like:
$plugin['revision'] = '$LastChangedRevision: rev_number_goes_here $';
The Composer will do the rest, read the revision number and append it to the version number. Since there’s no place to store it in the database it is a read-only setting and will not output the revision separately upon export; it will become part of the version number. This feature is probably of limited use, but at least it stops the Composer from throwing its toys out of the pram if you supply any “unknown” plugin variables, and leaves the door open for you to add a truckload of other variables for your own use to the template that the Composer should now silently ignore.
[ Incidentally, you may also supply a fixed revision number like $plugin['revision'] = '42'; in case you want to do manual revision control (umm…) ]
I also took the opportunity to pass all the remaining hard-coded strings through a local gTxt() so i18n should be easier. All the replacement strings are at the very bottom of the plugin. Let me know if I’ve missed any.
(btw, we sorted out iblastoff’s mini problemette a couple of posts ago)
Last edited by Bloke (2008-01-11 23:46:46)
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Txp Builders – finely-crafted code, design and Txp
Offline