Lack of global theme association vs all other sections on logout

etc · 2019-09-22 21:15:37

Pat64 wrote #319348:

All sections need to be attached to (all) themes.

I’m not so sure. Some sections (say plugins) can use special forms (say file_download) that are not required in other sections. Hence a theme suitable for plugins articles is not necessary pertinent for other sections and vice versa.

etc · 2019-09-30 18:40:11

Now there is a global theme switcher in dev branch on Themes tab, but I have not found better text strings than Preview for dev theme and View for live theme.

Pat64 · 2019-09-30 21:29:08

Wahoo!

Nice: I’m going to test it.

Bloke · 2019-10-01 19:46:44

etc wrote #319458:

I have not found better text strings than Preview for dev theme and View for live theme.

Okay, I sorta see what this does. View sets the live theme for all Sections if the section has the same Page and CSS name as the new theme. If not, it leaves it as it was.

This is a nice way to set all Sections to the theme without having to reassign them from the multi-edit tool. My only reservation is it’s potentially destructive (to non-logged-in users). Just a stray finger on View instead of Preview and your site runs the chosen theme on the public side. The multi-edit gives you a confirmation step, which is safer.

So, two options, either separately or combined:

Make the wording of the links more explanatory so the admin knows the severity of the ‘View’ action. Both are (sort of) easily undone with multi-edit but ‘View’ doesn’t really cut it in terms of what the effect is. It seems too benign. Will get my thinking cap on for a better word.
When clicking on View, show a confirmation dialog asking if they’re damn sure they want to set this theme live for all Sections with matching Page and Stylesheet names.

Which is better / doable? Or both?

EDIT: How about using link names Dev and Live? Or Make live?

Last edited by Bloke (2019-10-01 19:49:02)

etc · 2019-10-01 21:32:19

Bloke wrote #319467:

EDIT: How about using link names Dev and Live? Or Make live?

That would be surely better, but they are not in [skin] section. The only alternative string I’ve found is active. We probably should make strings separation less granular.

Adding a confirmation dialogue is quite easy.

Bloke · 2019-10-01 22:30:45

etc wrote #319468:

That would be surely better, but they are not in [skin] section. We probably should make strings separation less granular.

We could move those two strings to the [admin-side] section. That’s what it’s for. We made the language strings more granular to try and improve performance with language table string loading per page, as it was getting out of hand. Though we may need to revisit it when we do multi-lingual public side content.

etc · 2019-10-02 08:48:51

Bloke wrote #319471:

We could move those two strings to the [admin-side] section.

Batch strings move is beyond my skills, I leave it with Phil if the wording seems clear. A basic warning is in dev now.

Pat64 · 2019-10-02 11:44:13

Good point for the warning message. But IMHO, only for the “View” link because it’s kind of a definitive change.

etc · 2019-10-02 12:14:41

Pat64 wrote #319489:

Good point for the warning message. But IMHO, only for the “View” link because it’s kind of a definitive change.

Yep, makes sense. We probably need a notion of storable “profile” for the whole set of section/theme/page/style associations (like Public, In Work etc). Then restoring the previous site state would be easy provided it is saved. Moreover, each logged in user could have its own dev set.

Bloke · 2019-10-02 13:01:10

etc wrote #319490:

Yep, makes sense. We probably need a notion of storable “profile” for the whole set of section/theme/page/style associations (like Public, In Work etc). Then restoring the previous site state would be easy provided it is saved. Moreover, each logged in user could have its own dev set.

I agree about only making the confirmation for ‘View’ (‘Live’) changes.

Intriguing about making the dev state per user. I can’t see any inherent problems with that.

But permissions might drive what we do here. For instance, one of the things I like about our current model of anyone logged in seeing dev is that all people involved in the process of bringing content and site structure to life can work on the “in dev” site if the admin (publisher/managing editor/whoever has access to Sections) switches it over.

Beforehand it was ‘soft switched’ per user whenever you worked on a particular theme. i.e if a Copy Editor was on the Pages panel and chose a new theme from the dropdown, they saw the new theme in use (if possible) when they viewed the public site.

Right now, that no longer happens. Only admins/site designers (1,2,6) can switch the theme for the Sections panel and (as of the commit yesterday) the Themes panel. This is fine and makes sense.

If, however, we bring in the notion of per-logged-in-user dev themes, we need to think carefully about who can access what. If you have a client to whom you only assign Copy Editor privs (might that happen?) so they can only create their own content, they will not be able to see the in-development site as they have no way to ‘switch’ to it. Regardless that an admin/site designer switches theirs over, the Copy Editor still sees the Live theme.

That might be far fetched, I’m not sure. But we just need to be aware of the impact of such a change. Because that could affect people’s workflow. The admin would then either need a face-to-face with the client, a web video call, or to elevate the client’s privs so they can see the dev site.

etc · 2019-10-02 14:15:38

Bloke wrote #319493:

If, however, we bring in the notion of per-logged-in-user dev themes, we need to think carefully about who can access what. If you have a client to whom you only assign Copy Editor privs (might that happen?) so they can only create their own content, they will not be able to see the in-development site as they have no way to ‘switch’ to it. Regardless that an admin/site designer switches theirs over, the Copy Editor still sees the Live theme.

The term “dev theme” is misleading, sorry. The idea is that only admins/designers could create (multiple) profiles and set a public one, but anyone who can preview the (currently unique) dev setup would be able to choose from all available profiles (some of them could be private, though). This choice would be per user, without affecting the public or other users setups. This way a dev could create many alternative profiles for the client to choose from. That would mean that instead of the binary Enable dev theme preview pref we would offer a list of available profiles.

Whether Copy Editors should be eligible is another question, they are more on the content rather than design side.

Bloke · 2019-10-02 14:43:30

etc wrote #319495:

I mean only admins could create (multiple) profiles and set a public one, but anyone who can see the (currently unique) dev setup would be able to choose from all available profiles

Gotcha, sorry for the confusion.

Not being facetious here. I’m genuinely curious: what’s the difference between a profile and a theme? And what features does this additional layer bring us?

Couldn’t the admin simply set up multiple themes with a ‘dev’ status. Anyone with theme editing rights (such as site designers) could work on any of the pages/forms/styles for any dev theme locally without anyone being affected.

When the theme(s) are “ready” the admin could set them to a “staging” status. They then become available to other logged-in users to choose from so all users – content creators, clients and so forth – can see the themes in use before one is chosen to go live.

Once agreed, the admin can then set the chosen theme live using either the Section on Themes panel.

EDIT: I admit that clients are likely to be Managing Editors so they’d be able to choose dev themes too at any time so I’m not sure if this is workable or whether we need to introduce a ‘client’ role and decide on suitable permissions.

Last edited by Bloke (2019-10-02 14:46:15)

Textpattern CMS

Textpattern CMS support forum

#13 2019-09-22 21:15:37

Re: Lack of global theme association vs all other sections on logout

Pat64 wrote #319348:

#14 2019-09-30 18:40:11

Re: Lack of global theme association vs all other sections on logout

#15 2019-09-30 21:29:08

Re: Lack of global theme association vs all other sections on logout

#16 2019-10-01 19:46:44

Re: Lack of global theme association vs all other sections on logout

etc wrote #319458:

#17 2019-10-01 21:32:19

Re: Lack of global theme association vs all other sections on logout

Bloke wrote #319467:

#18 2019-10-01 22:30:45

Re: Lack of global theme association vs all other sections on logout

etc wrote #319468:

#19 2019-10-02 08:48:51

Re: Lack of global theme association vs all other sections on logout

Bloke wrote #319471:

#20 2019-10-02 11:44:13

Re: Lack of global theme association vs all other sections on logout

#21 2019-10-02 12:14:41

Re: Lack of global theme association vs all other sections on logout

Pat64 wrote #319489:

#22 2019-10-02 13:01:10

Re: Lack of global theme association vs all other sections on logout

etc wrote #319490:

#23 2019-10-02 14:15:38

Re: Lack of global theme association vs all other sections on logout

Bloke wrote #319493:

#24 2019-10-02 14:43:30

Re: Lack of global theme association vs all other sections on logout

etc wrote #319495:

Board footer