Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Shouldn't Textpattern textilize plugins help file on install?
Hi there,
I come back to an old issue I had and where Stef started to reply here.
Here was/is the problem…
I used MassPlugCompiler and saw that my plugins help file was not textilized correctly (it was also the case when I used the plugin template); Id’s and classes were removed, notextile. tags ignored, etc.
Stef told that the plugin template and the compiler both parse help files on compilation, so I forked the MassPlugCompiler to quickly include Textile and parse my files. It worked.
However, I now started to make my plugins available via Composer and see that the problem started again when using the textpattern/installer. I opened an issue on the GitHub repo, but I’m still not sure why Textpattern does not correctly parse .textile plugins help file on install by itself from plugin['help_raw'], shouldn’t it?
Last edited by NicolasGraph (2017-06-05 14:16:34)
Offline
Re: Shouldn't Textpattern textilize plugins help file on install?
I get something.
If I replace textileRestricted by textileThis in /textpattern/include/txp_plugin.php, the help file seem to be correctly parsed on install: in my test the class is not removed.
Now I guess that textileRestricted is used for safety (?); but couldn’t we find a way to keep the ability to customize Textile formated plugins help file via styles and embed codes (with notextile.)?
Last edited by NicolasGraph (2017-06-06 10:08:45)
Offline
Re: Shouldn't Textpattern textilize plugins help file on install?
Up?
If you took a look at my last plugins, you know I try my best to make my help files user friendly by using Phil’s design patterns with some JS when the documentation is big.
Should I really go back to a too long page of not styled text without any anchor to be able to use Composer or the plugin template?
Offline
Re: Shouldn't Textpattern textilize plugins help file on install?
NicolasGraph wrote #306054:
Should I really go back to a too long page of not styled text without any anchor to be able to use Composer or the plugin template?
It’d be great if we could permit this in the help system. But I can’t see a way round it, like Gocom said, without bundling the parser with Composer.
How about we try a different approach? What if you were to just export your full help text as one looong document (as normal) using Textile. Once it’s installed and someone views the help from the Plugins panel, we could maybe automatically add a JS Table of Contents as part of the plugin help viewer system. It’s only a case of reading the <hN> tags, assigning an ID and building a menu. There are plugins available that do it or we could very simply build our own if necessary.
Your doc will still be one long document, but it’d be indexed with anchor jump points, which would save you doing it (leaving more space in the 64KB limit for actual docs instead of navigation elements). We might even be able to automaticaly insert ‘back to the top’ links efore each heading, or make the TOC sticky / floaty or something like that.
I’d be more than willing to implement something like that. I’d even accept a Pull Request :-)
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: Shouldn't Textpattern textilize plugins help file on install?
Bloke wrote #306055:
I’d even accept a Pull Request :-)
Let’s do that, I need jQuery to be my friend. I already have something messy, hopefully I will be able to send some tidy code next friday. Thanks for your reply Stef!
Offline
Offline