Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
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.
Hire Txp Builders – finely-crafted code, design and Txp
Online
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.
Hire Txp Builders – finely-crafted code, design and Txp
Online
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.
Hire Txp Builders – finely-crafted code, design and Txp
Online
Re: Dev news
Bloke wrote #320493:
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?
The tabs are hidden, not gone, but I have not tested any of these plugins. They are possibly broken but shouldn’t be difficult to patch.
Floating up there where the tabs used to be looks a bit… odd, imo.
We can put a link per textarea, by they would open a common dialog atm?
Offline
Re: Dev news
etc wrote #320494:
We can put a link per textarea, by they would open a common dialog atm?
That’s fine. Click the body preview, you see that one. Click the excerpt preview link, the dialog content is replaced with the excerpt. The live checkbox and timeout (when/if we add that) remain in the same state.
In that case, we don’t need the title in the preview box, and don’t need those headers announcing each area, making the dialog smaller too. Well, maybe just the one heading indicating which field is currently being shown.
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Hire Txp Builders – finely-crafted code, design and Txp
Online
Re: Dev news
etc wrote #320489:
That wouldn’t be quite bw-compatible, I’m afraid. We will rather start implementing it in custom-fields branch.
???
I was not implying you needed to implement this illico subito presto, only that it was an interesting possibility.
What I was saying is that the current layout of having that “Preview” link at the top of the page, before the title input field was less that optimal as it feels like completely disconnected from the rest of the column. My suggestion had been to put that link/button after the “Title” input area.
Where is that emoji for a solar powered submarine when you need it ?
Sand space – admin theme for Textpattern
phiw13 on Codeberg
Online
#100 2019-12-12 12:53:36
Re: Dev news
I appreciate all the work and levelheadedness going into these things for upcoming releases. A long time coming and well anticipated. Hang in there. Don’t get discouraged. Good things ahead. No doubt.
Offline
#101 2019-12-12 15:06:14
Re: Dev news
phiw13 wrote #320496:
What I was saying is that the current layout of having that “Preview” link at the top of the page, before the title input field was less that optimal as it feels like completely disconnected from the rest of the column. My suggestion had been to put that link/button after the “Title” input area.
I have commented on preview for each textarea / CF – with preview link connected to each, sorry if there is any misunderstanding.
Destry wrote #320497:
I appreciate all the work and levelheadedness going into these things for upcoming releases. A long time coming and well anticipated. Hang in there. Don’t get discouraged. Good things ahead. No doubt.
Thanks!
Offline
#102 2019-12-13 11:29:03
Re: Dev news
This modal Preview is better now, with the trigger links next to the textarea. The positioning of the live preview checkbox inside the dialog is still a bit problematic imho.
It is less disturbing than when this layout (checkbox first in the pane) originally landed – the content of the dialog being different. But I’m not really comfortable with it. The story line does not seem to fit. It also depends, you (oleg) were talking about some kind of timeout control or similar. Is that still something you plan to add (prolly next to the checkbox) ? In that case, that (both) should go after the Preview/HTML chooser, I think.
Where is that emoji for a solar powered submarine when you need it ?
Sand space – admin theme for Textpattern
phiw13 on Codeberg
Online
#103 2019-12-13 14:16:09
Offline
#104 2019-12-13 14:21:10
Re: Dev news
etc wrote #320507:
Yes, I think it could be useful to accommodate fast/slow writers.
Agreed. And to balance server load/bandwidth if you write longform on a slow connection via a mobile, for example.
Storing the timeout value in localStorage along with the state of the live_preview checkbox will give a nice way of handling content previews across devices.
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Hire Txp Builders – finely-crafted code, design and Txp
Online
#105 2019-12-14 14:47:08
Offline