Required fields on Sections pane

phiw13 · 2020-01-14 03:45:18

following this checkin.

On the sections page > new section, the “page” and “style” entries are now required and are pref-filled by default with the default page and style (that was already the case before). OK, I guess that makes sense. Especially as those are required.

However, the select widget for both (still) has a blank option at the top. I could see a point in that – if the entry is not required – as the user could decide to create the section now, and fill in the details later when “page” and “style” are set up.

That is now more of a nuisance and confusing than anything. Selecting a blank field triggers the browser validation for required fields.

Edit: screenshot, in case needed

Last edited by phiw13 (2020-01-14 08:15:34)

Bloke · 2020-01-14 09:09:23

If they’re required we need to remove the blanks (and probably from the multi-edit too). Originally, the blank entries were for “leave as it was” but that causes issues if you change theme. See issue 1456.

etc · 2020-01-14 09:10:41

The (invalid) blank option is there to indicate that some assigned asset (page, style) from the current theme is missing in the new theme when you switch them. Otherwise txp would just choose for you the first available asset without warning.

I guess adding some ‘Please select’ text for the blank option would make things clearer.

Bloke · 2020-01-14 09:16:28

Ah yes, that makes sense. Let’s leave the blanks in that case and see if we have a string for “Select…” (or similar) knocking around. If not we should probably add one.

Edit, presumably we can add this to selectList() when using the blank_first parameter without breaking anything?

Last edited by Bloke (2020-01-14 09:18:46)

phiw13 · 2020-01-14 11:22:43

etc wrote #321078:

The (invalid) blank option is there to indicate that some assigned asset (page, style) from the current theme is missing in the new theme when you switch them. Otherwise txp would just choose for you the first available asset without warning.

I guess adding some ‘Please select’ text for the blank option would make things clearer.

Hmm, ok. A ‘Please select’ would make things certainly less confusing.

etc · 2020-01-14 11:42:35

Bloke wrote #321081:

presumably we can add this to selectList() when using the blank_first parameter without breaking anything?

That’s what I thought, but it looks like all options are added (and pre-selected) via JS, dunno where.

phiw13 wrote #321086:

A ‘Please select’ would make things certainly less confusing.

Actually, style could be optional?

phiw13 · 2020-01-14 11:57:39

etc wrote #321087:

Actually, style could be optional?

From my POV yes, certainly. What the internal mechanics of TXP say, that you know better that me

I actually never really used the styles panel, there only is a comment in the default stylesheet reading: unused!

Bloke · 2020-01-14 12:20:28

etc wrote #321087:

That’s what I thought, but it looks like all options are added (and pre-selected) via JS, dunno where.

Drat, yeah. Forgot that the panel has to populate the dropdowns on demand when you change the theme. See function section_theme_show(skin) in textpattern.js.

Actually, style could be optional?

As long as it doesn’t leave anything orphaned if a theme is deleted, if there’s a way we can be clever about all this reassignment (like, maybe, if the newly selected theme shares an asset name with the one that is currently in force, perhaps pre-select those assets, otherwise set it to the first empty/please choose option?) then sure.

etc · 2020-01-14 12:36:49

Bloke wrote #321090:

As long as it doesn’t leave anything orphaned if a theme is deleted, if there’s a way we can be clever about all this reassignment (like, maybe, if the newly selected theme shares an asset name with the one that is currently in force, perhaps pre-select those assets, otherwise set it to the first empty/please choose option?) then sure.

As I get it, in dev

you can not delete an in-use (live or dev) theme.
when the newly selected theme has the current assets, they are pre-selected when switching themes. Otherwise the ‘blank’ asset is pre-selected.
quickly tested empty css for a section, it does not seem to break anything. If used, <txp:css /> selects default style in this case.
actually, empty page just yields ‘unknown section’ without further harm (save for admin UX quirks that I will fix).

So I would suggest that we leave page and css optional, removing the corresponding sections and their articles from <txp:article(_custom) /> and <txp:section_list /> (currently testing).

Bloke · 2020-01-14 13:14:30

That approach works for me!

colak · 2020-01-14 15:03:59

etc wrote #321087:

Actually, style could be optional?

With the recent functionalities which allow a section to be used for an xml sitemap, and other purposes, I think that attaching a style should be optional.

phiw13 · 2020-01-14 22:45:08

colak wrote #321096:

With the recent functionalities which allow a section to be used for an xml sitemap, and other purposes, I think that attaching a style should be optional.

Yeah, good point, it is confusing as well.

–~–~–

Oleg, your latest patch seems to do what you describe above (light testing so far). And now that empty entry in the select on the Edit panel does make sense again. TY.

etc · 2020-01-15 10:24:35

I’m feeling like opening a Pandora box here, but since pageless sections are allowed (by mistake?) in 4.7, we can not simply forbid them in 4.8. Instead the patch you cite excludes them (by default) from sections and articles lists. You can still access their content explicitly setting section or id attributes, just mind that their URL will land you on ‘unknown section’ 404.

This makes it possible to publish e.g. book-type articles containing many ‘pageless’ chapters included via <txp:article_custom /> tag.

jakob · 2020-01-15 10:35:47

etc wrote #321105:

I’m feeling like opening a Pandora box here, but since pageless sections are allowed (by mistake?) in 4.7, we can not simply forbid them in 4.8. Instead the patch you cite excludes them (by default) from sections and articles lists. You can still access their content explicitly setting section or id attributes, just mind that their URL will land you on ‘unknown section’ 404.

This makes it possible to publish e.g. book-type articles containing many ‘pageless’ chapters included via <txp:article_custom /> tag.

So, this is akin to what we were talking about before, but using ‘pageless’ rather than ‘themeless’ or ‘non-url permlink schemes’? I think your suggestion sounds more logical, and ‘pageless’ means they are effectively also ‘url-less’ too. Out of interest, what would happen if you plugged them into the url? A 404?

I like the idea. Removing them from processing using txp:article (if they’re ‘url-less’ they would never define context) and in automatic section_list lists makes sense to me. Being able to explicitly output them via section="pageless-section-name" or id="{article-ids-from-pageless-section}" makes them usable wherever one needs them.

Will test as soon as I can…

EDIT: Oh, and thank you!

Bloke · 2020-01-15 10:57:41

I’m gonna play too later today, thank you. This looks like a terrific (even if its origins are slightly inadvertent!) addition to officially support pageless sections.

Textpattern CMS support forum

#1 2020-01-14 03:45:18