Undeletable Forms and Form types

Bloke · 2017-05-03 14:00:31

This topic has been debated for close to a decade and I want to finally address it. Especially in light of the new beefed-up parameterized Form/Yield ability landing in 4.7.0.

Textpattern has always tried to adopt ‘convention’ over ‘configuration’. It makes things easier to use (and code) in some ways because some stuff is always there, so you don’t spend ages having to configure the system just to get up and running. It’s our “Just Write” mantra.

Part of this wisdom extends to Forms. There are a bunch of forms that are currently undeletable so that your article tag will always fall back on a known entity name and can guarantee it exists. This has benefits such as reducing support requests like “my article content isn’t showing” because, unless you change the form attribute, nothing can go wrong.

For some people, however — and I’m thinking in terms of the upcoming Themes support here too now — having enforced Forms such as ‘files’ and ‘plainlinks’ cluttering up your panel when you have no intention of using them, is annoying.

Part of me thinks that we should ship with a default set of Forms, as we do today, so new users benefit from the ‘convention’ approach and stuff doesn’t break out of the box. But if you delete one of these “essential” forms, you get a message as you do for any missing Form when you employ the form attribute: Form does not exist while parsing page YYY.

But on the other side of the fence is the fact that a bunch of key tags (txp:article, txp:file_download, txp:comments, etc, but NOT images!) have a hard-coded form attribute set internally, which is set to the known Form name. Thus you don’t need to set one. If you were permitted to delete the default article Form, for example, you would get a message Form 'default' does not exist, but new users who inadvertently delete that Form might search for ‘default’ (using something like smd_where_used) and not find it, so not know how to fix the problem.

Here are some issues we’d face if we were allowed to delete all Forms:

UI issues on Forms panel. If all Forms are missing the entire sidebar panel isn’t rendered, which breaks the layout.
Defensive code required to trap the ‘override form’ feature on the Write panel, i.e. not display it if there are no ‘Article’ Forms or the Use override form pref is off.
Defensive code required in the event an ‘unused’ (special, currently undeletable) Form is deleted. This might be as simple as setting default content directly inside the tag (like we do for <txp:images> in the event both form and container are omitted). It does make the article tag tricky, as the default content is quite involved. It also means if we want to change the default out-of-the-box theme in future, part of it needs to be done in code (not very friendly).
If we implemented the previous point, someone who wants to know why their articles are displaying ‘posted’ and ‘category’ info, can’t see the tags that make up the article, as they’d be hidden in code. This makes learning Textpattern more difficult, as the beauty of having a fixed, known entity is that it can be used as training content.
As mentioned above, not having to specify a form for tags that have fixed Form names leads to difficult-to-find bugs if one of the Forms is deleted.

I’m sure there are more. The downsides are obvious for new users, based on that list. The downsides for power users of not being able to delete things is a mere annoyance. But it is an annoyance. I would love to come to some arrangement whereby we could satisfy both camps.

One possible avenue (though I dislike it) is to introduce a pref Protect default Forms. It’d be on by default so Txp works like now, but if you toggle it off, you could kill any Forms. Or of course, the inverse: Allow deletion of protected Forms and have it off by default. I’m not sure which is better logic. I don’t like bloating prefs for no reason if there’s some other way of addressing it, so any ideas are welcome.

I’d also like to use this as a springboard to reopen investigation into allowing arbitrary Form types. If we permit deletion of all Forms, then the ‘specialness’ of Article types is handled by virtue of hiding the override_form widget on the Write panel if no Article Forms are present. We could continue to offer a dropdown of ‘useful’ types — and get rid of that awful ‘Miscellaneous’ option — and permit you to define your own on top of the preset list. This way, the ‘article’ type is preserved if you ever need it. Without this, if you delete all Article Forms and created a new type called ‘Artikle’, the override_form feature wouldn’t reappear, which is not very helpful for users in other languages. That’s part of the overall issue: hard-coded Form types don’t need a ‘name’ and a translation, because we already know their names and thus translations already exist.

Please help us shape the future of Txp Forms. Ideas, mockups, options, issues, jot them here.

philwareham · 2017-05-03 14:11:20

Why not just have ‘default’ article form as the only one that you cannot delete (like we have to have a ‘default’ section)? Avoids the panel breakage if no forms are present too.

Default kind of means its a prerequisite anyway, so I’d be fine with that. All other forms should be deletable though – oh yes indeed. Especially as a lot of sites won’t need any of the comment forms.

Bloke · 2017-05-03 14:27:40

philwareham wrote #305592:

Why not just have ‘default’ article form as the only one that you cannot delete

That works for me.

What should we do with tags that rely on the other content? In the absence of a form attribute, what should they display if their designated default Form is missing? Default content? (which is quite involved for the comment_form, comments, comments_display and files Forms) Or an error?

Is there any way we can make it easy to maintain the default content without having to hack code?

philwareham · 2017-05-03 14:30:13

Warning: form 'form_name' called by tag 'tag_name' doesn't currently exist - please create that form or specify an existing form.

Bloke · 2017-05-03 14:59:31

philwareham wrote #305596:

Warning: form 'form_name' called by tag 'tag_name' doesn't currently exist - please create that form or specify an existing form....

If the parser can do that: win!

philwareham · 2017-05-03 15:02:16

Disclaimer: I have no idea if the parser can do that, it’s just my ideal suggestion :)

michaelkpate · 2017-05-03 15:29:09

Looking through the default forms…

Article – default

I agree that should be non-deletable

Comments

popup_comments should have been removed in 2006. The other three and the whole section should be removable if you have “Comments on by default?” set to No. (Not sure how much work that would be)

File – Files

Should also be removable/not even there.

Links – Plainlinks

Should also be removable/not even there.

Miscellaneous

I would love to be able to create my own categories and have been lobbying for this whenever it comes up. I just counted and the current version of CMS Styles has 31 forms in this category (I like to break code into what I hope are logical chunks whenever possible).

philwareham · 2017-05-03 15:37:53

michaelkpate wrote #305599:

popup_comments should have been removed in 2006.

The only reason that one is in the initial theme is because of some convoluted legacy template and tag. Anyway it is deletable by users so not really part of this discussion (although yes it should be burnt to the ground).

colak · 2017-05-03 16:25:59

philwareham wrote #305600:

The only reason that one is in the initial theme is because of some convoluted legacy template and tag. Anyway it is deletable by users so not really part of this discussion (although yes it should be burnt to the ground).

Although I agree with you, I’m sure that I saw a post recently by someone trying to implement this, so much outdated, feature.

michaelkpate · 2017-05-03 17:18:30

colak wrote #305601:

Although I agree with you, I’m sure that I saw a post recently by someone trying to implement this, so much outdated, feature.

I have always maintained that Dean only included it because it was popular in Movable Type in 2001 when he was first getting started.

If you use any other type of archiving—in other words, a type of archiving where more than one entry is on an archive page—it may not make as much sense to include the comments inline. In that case, Movable Type supports dynamically-built popup windows for your comments (à la Blog Voices and others). The default templates that ship with Movable Type support popup comments automatically – Comments

jpdupont · 2017-05-03 20:20:27

For my part, I propose to have the ability to delete all forms and pages except the default elements that would prevent a basic operation of textpattern.

When I start a site, I use sed_cleaner which empties everything and removes all (sections, categories, pages, forms, …) superfluous elements.

GugUser · 2017-05-03 22:53:57

michaelkpate wrote #305599:

The other three and the whole section should be removable if you have “Comments on by default?” set to No.

I think the same.

Textpattern CMS

Textpattern CMS support forum

#1 2017-05-03 14:00:31