Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Undeletable Forms and Form types
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 bothform
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.
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Txp Builders – finely-crafted code, design and Txp
Offline
Re: Undeletable Forms and Form types
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.
Offline
Re: Undeletable Forms and Form types
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?
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Txp Builders – finely-crafted code, design and Txp
Offline
Re: Undeletable Forms and Form types
Warning: form 'form_name' called by tag 'tag_name' doesn't currently exist - please create that form or specify an existing form.
Offline
Re: Undeletable Forms and Form types
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!
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Txp Builders – finely-crafted code, design and Txp
Offline
Re: Undeletable Forms and Form types
Disclaimer: I have no idea if the parser can do that, it’s just my ideal suggestion :)
Offline
Re: Undeletable Forms and Form types
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).
Offline
Re: Undeletable Forms and Form types
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).
Offline
Re: Undeletable Forms and Form types
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.
Yiannis
——————————
NeMe | hblack.art | EMAP | A Sea change | Toolkit of Care
I do my best editing after I click on the submit button.
Offline
Re: Undeletable Forms and Form types
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
Offline
#11 2017-05-03 20:20:27
- jpdupont
- Member
- Registered: 2004-10-01
- Posts: 752
Re: Undeletable Forms and Form types
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.
Offline
#12 2017-05-03 22:53:57
- GugUser
- Member
- From: Quito (Ecuador)
- Registered: 2007-12-16
- Posts: 1,473
Re: Undeletable Forms and Form types
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.
Offline