Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Re: Dev news
Bloke wrote #320446:
If we’re going that route, I’d rather investigate ProseMirror again and have togglable inputs on each textarea in conjunction with the Textfilter selector somehow. But, as you say, future.
Maybe the ProseMirror guy could do it, but not me. Spent two weeks trying to integrate txp tags – no way. And implementing the whole set of php-textile features is completely out of reach.
Morgen, morgen…
Offline
Re: Dev news
Man, that Gutenberg crap looks ridiculous. The toggles on the Classic editor is more how I was envisioning things here.
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: Dev news
etc wrote #320449:
Spent two weeks trying to integrate txp tags – no way. And implementing the whole set of
php-textilefeatures is completely out of reach.
Yeah, I struggled too. There’ll be a way (somehow) to do enough of it to make a rudimentary formatting toolbar, but not the entire Textile feature set. I need to sit down and grok the builder toolset… when I have a spare few weeks to dedicate to understanding it!
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: Dev news
michaelkpate wrote #320448:
How WordPress would handle this in the Classic Editor. Users toggle back and forth between Visual and Text in the upper-right corner.
And their new Gutenberg Editor – adds a lot more feature but kind of buries where you make the switch.
We has them here and there, but they suit only for basic text (no txp tags or advanced Textile).
Offline
Re: Dev news
Bloke wrote #320451:
Yeah, I struggled too. There’ll be a way (somehow) to do enough of it to make a rudimentary formatting toolbar, but not the entire Textile feature set. I need to sit down and grok the builder toolset… when I have a spare few weeks to dedicate to understanding it!
The main difficulty I had is ‘txp is not xml’. The standard DOM parser used by ProseMirror is confused by things like
<txp::shortform attr='<txp:tag />' />I have partly succeeded in ‘hiding’ them on parse and then injecting back, but only one way, iirc.
Offline
Re: Dev news
philwareham wrote #320443:
Basically where the (now removed)
#view-modes divwas, yes. Since it governs the whole of that region (title, main, excerpt, potentially custom fields one day, etc.).
[[ Putting the “Preview” link at the very top of the column, before the title input field ]]
Hmm. I’m not so sure it is a good idea (it is currently in core). The link looks and feels like completely disconnected from the rest of the column.
On the other hand, what is discussed further in the thread (preview for each textarea / CF – with preview link connected to each) does seem quite interesting.
Where is that emoji for a solar powered submarine when you need it ?
Sand space – admin theme for Textpattern
Offline
Re: Dev news
phiw13 wrote #320479:
On the other hand, what is discussed further in the thread (preview for each
textarea/ CF – with preview link connected to each) does seem quite interesting.
Yep, that’s my preferred route too now, after thinking about it further.
Offline
Re: Dev news
phiw13 wrote #320479:
On the other hand, what is discussed further in the thread (preview for each
textarea/ CF – with preview link connected to each) does seem quite interesting.
That wouldn’t be quite bw-compatible, I’m afraid. We will rather start implementing it in custom-fields branch.
Offline
Re: Dev news
I like the idea of preview per major textarea – not for keywords or meta description :)
Not sure where the link would go for the best. Maybe to the left of the Format: dropdown? Or after it? Or alongside the pophelp after the label?
The popup dialog is looking sweet. If each textarea gets its own preview then I think keeping the state of the live_preview checkbox (and the timeout value) is a good idea. Since the handler is switched off when the dialog is closed, performance is not impacted if you choose to hide the preview dialog. And if you switch to another article, the dialog is automatically closed anyway.
Only the act of opening it invokes the handler so if your live preview is still checked, that’s when the preview is generated. And if you don’t want it after that, for whatever reason, just flick the switch off and it’ll stay that way until you switch it back on again.
That makes sense – to me at least – but if I’ve missed anything, feel free to change my mind.
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: Dev news
etc wrote #320489:
That wouldn’t be quite bw-compatible, I’m afraid.
Why not? We don’t officially support textareas in custom fields in core. So the only textareas the preview needs to attach to in 4.8.0 is body and excerpt. We can worry about modifying the handler to attach to CFs that are defined as textareas when unlimited custom fields land.
Or am I being dim?
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
Offline
Re: Dev news
A softly-softly approach is fine by me if you think plugins are at risk here. I can’t honestly think of any that would be affected, besides tom_write_editor (but that’ll probably break anyway since the HTML/preview/text tabs are gone). Maybe bot_wtc, but that breaks pretty much every version anyway due to the fragile nature of the DOM selectors?
If we’re not going to put two preview links in – body and excerpt – then we need to decide where to put the single link until such time as we do have more than one. Floating up there where the tabs used to be looks a bit… odd, imo.
Last edited by Bloke (2019-12-12 12:18:00)
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