themes on 4.8beta

etc · 2020-01-16 22:39:41

Bloke wrote #321154:

Intriguing. I like that!

Please test and revert if needed.

etc · 2020-01-16 22:42:50

Destry wrote #321155:

That’s kind of how I thought the preference worked, to be honest, which is why I was having some trouble understanding the need for the ‘Live’ check box.

Sorry for the confusion. With ‘dev preview’ disabled you were still able to follow theme development on the admin side, but would be served ‘live’ version on the public side. If enabled, you get ‘dev’ version on public side too.

Destry · 2020-01-16 22:46:44

Oh right. That sounds familiar. I think one of you explained that to me before in repo threads.

Bloke · 2020-01-17 01:10:55

Okay, I’ve promoted the developer preview options to first class citizens on the multi-edit dropdown. Please test.

If this is okay, the switch_dev_live string can be removed.

phiw13 · 2020-01-17 01:37:11

Bloke wrote #321159:

Okay, I’ve promoted the developer preview options to first class citizens on the multi-edit dropdown. Please test.

If this is okay, the switch_dev_live string can be removed.

That is of course a little tricky. What does it means “Deploy/Reset to Live” for a section that already is set to use a Live theme?

In the screenshot, 2 sections are already live and using the Live theme. The top one is still on Dev.

p.

Bloke · 2020-01-17 10:16:55

phiw13 wrote #321160:

What does it means “Deploy/Reset to Live” for a section that already is set to use a Live theme?

Nothing. It’ll be ignored. Same way as, before the commit, you could:

Select a bunch of sections (some dev, some live as in your example).
Choose ‘Developer preview’ from multi-edit.
Pick Deploy to live to push dev->live themes on those selected sections (and ignore the ones that had no dev).
Pick Reset to live to ditch the dev themes on those selected sections (and ignore the ones that had no dev).

No change in functionality, it’s just fewer clicks now to achieve the same thing.

etc · 2020-01-17 10:25:26

Bloke wrote #321148:

Are you going to make the live/dev checkboxes remember their state? I presume that’s possible?

On a second thought, this state should not be browser-dependent, rather a user preference?

etc · 2020-01-17 10:50:33

Bloke wrote #321159:

If this is okay, the switch_dev_live string can be removed.

I second @phiw13, without this string the wording is fuzzy.

Bloke · 2020-01-17 11:14:51

etc wrote #321168:

without [switch_dev_live] string the wording is fuzzy.

Maybe. If it’s more confusing, I’m fine if the commit is reverted. Just trying it out.

etc wrote #321164:

On a second thought, this state should not be browser-dependent, rather a user preference?

Do you mean a per-user pref that’s automatically updated to store the checkbox states when you perform a change theme/page/style action, as opposed to storing it in localStorage?

Or do you mean a physical pref setting on the Prefs panel?

I’m fine with the former. Not sure the latter would help!

phiw13 · 2020-01-17 11:29:16

etc wrote #321168:

I second @phiw13, without this string the wording is fuzzy.

:-)

I find it unclear (and I could be considered on the geeky side), In TXP 4.7.3 the “Developper Preview” and subsequent action (2 radios) was conceptually much easier to understand, even if you had a ‘Live’ section included in your selection.

etc · 2020-01-17 11:29:38

Bloke wrote #321169:

Do you mean a per-user pref that’s automatically updated to store the checkbox states when you perform a change theme/page/style action, as opposed to storing it in localStorage?

Yes, a hidden server-stored private pref, if any. Now that dev-preview-disabled admins can see and manage only live assets, and ‘dev’ is checked by default for admins involved in dev-preview, storing the checkbox states looks like an overkill.

And I come back to ‘Development’ pill on Sections tab: it should be attached to sections, not themes, or removed.

Pat64 · 2020-01-17 11:40:26

I’m reading the excellent documentation about “Theme” by Destry, and I had a suggestion (see: the ‘In use’ pill indication section here):

The difference by colors for the “In use” notification (green or orange depending of “live” and “In development” theme) isn’t suffisant, IMHO. May be a tooltip attached to these informations could be less confusing (assuming nobody choose a mobile device when configuring a theme).

Last edited by Pat64 (2020-01-17 11:41:03)

colak · 2020-01-17 11:45:55

Bloke wrote #321169:

Maybe. If it’s more confusing, I’m fine if the commit is reverted. Just trying it out.

Do you mean a per-user pref that’s automatically updated to store the checkbox states when you perform a change theme/page/style action, as opposed to storing it in localStorage?

Or do you mean a physical pref setting on the Prefs panel?

I’m fine with the former. Not sure the latter would help!

I think that this has to do with privileges and also, the hopeful future addition of guest privileges. For now, I believe that it would be prudent to keep it as a preference set by designers and over, which can be viewable by all who are logged in.

Bloke · 2020-01-17 11:58:26

etc wrote #321171:

Yes, a hidden server-stored private pref, if any.

Sounds like a plan.

And I come back to ‘Development’ pill on Sections tab: it should be attached to sections, not themes, or removed.

Try it against the section name by all means. I’m not sure, though. The split ‘Theme’ row with the dashed line might look a bit strange or require further explanation if the development pill isn’t there to indicate which is dev vs live.

Destry · 2020-01-17 12:35:56

etc wrote #321171:

And I come back to ‘Development’ pill on Sections tab: it should be attached to sections, not themes, or removed.

With regard to attaching it to section names, I’m not so sure about that. I wouldn’t like that.

With it on the Theme column, it aligns nicely with the assigned assets making it very clear, visually, that is the theme/page/style assiged in development. (It’s better now since you added the ‘None’ value for blank asset selections on new sections.)

Which is also why I don’t think you need a similar ‘Development’ pill on the assets too.

As for removing the pill entirely, I think it could make sense to us long-time people avidly looking at this now, but anyone new to Txp and themes would benefit greatly from such an indicator. I vote keeping it, and not just because I would have to edit these doc images, again (which is not as important as fixing usability first without stepping over into obscurity).

(Btw, I will not be around after today until Monday.)

Textpattern CMS support forum

#16 2020-01-16 22:39:41

Re: themes on 4.8beta

Bloke wrote #321154:

#17 2020-01-16 22:42:50

Re: themes on 4.8beta

Destry wrote #321155:

#18 2020-01-16 22:46:44

Re: themes on 4.8beta

#19 2020-01-17 01:10:55

Re: themes on 4.8beta

#20 2020-01-17 01:37:11

Re: themes on 4.8beta

Bloke wrote #321159:

#21 2020-01-17 10:16:55

Re: themes on 4.8beta

phiw13 wrote #321160:

#22 2020-01-17 10:25:26

Re: themes on 4.8beta

Bloke wrote #321148:

#23 2020-01-17 10:50:33

Re: themes on 4.8beta

Bloke wrote #321159:

#24 2020-01-17 11:14:51

Re: themes on 4.8beta

etc wrote #321168:

etc wrote #321164:

#25 2020-01-17 11:29:16

Re: themes on 4.8beta

etc wrote #321168:

#26 2020-01-17 11:29:38

Re: themes on 4.8beta

Bloke wrote #321169:

#27 2020-01-17 11:40:26

Re: themes on 4.8beta

#28 2020-01-17 11:45:55

Re: themes on 4.8beta

Bloke wrote #321169:

#29 2020-01-17 11:58:26

Re: themes on 4.8beta

etc wrote #321171:

#30 2020-01-17 12:35:56

Re: themes on 4.8beta

etc wrote #321171:

Board footer