Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Re: Rebrand contact form plugin
Hi,
input is for me the most generic word after form, but honestly I would prefer form, even if it may be confusing with Txp forms. form is just how it is called and how people would search for it. Txp forms should maybe not be named forms. I know that it won’t change but is it a reason to spread alternative tag names?
Furthermore, we are talking about a new plugin name isn’t it, not a core tag?
Last edited by NicolasGraph (2017-04-25 13:13:49)
Offline
Re: Rebrand contact form plugin
form isn’t going to fly, sorry, unless it’s prefixed with a plugin author prefix like <txp:pub_form /> or was <txp:contact_form />. Otherwise you’d get something like <txp:form form="my_form" /> which looks confusing to me.
Offline
Offline
Re: Rebrand contact form plugin
Offline
Re: Rebrand contact form plugin
Wooooooah, hold up everyone!
It’s a plugin, it still needs a prefix. All this talk of making it a core plugin/module is somewhat premature, imo. Bottom line, the plugin adds a slew of tags for creating different types of input control. I don’t want to add this plugin to core, because we already have waaay too many tags.
txp:contact is a noble idea, but what of the 10-15 other tags? txp:contact_text, txp:contact_email, txp:contact_textarea, txp:contact_radio, …it gets daft.
This is really just about the plugin getting a more useful title, with suitable prefix. One day I’d like to expand core’s email ability now everything’s in a lovely central class so maybe at that point we can revisit the plugin and integrate it more tightly with the core’s mail system.
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Hire Txp Builders – finely-crafted code, design and Txp
Offline
Re: Rebrand contact form plugin
Bloke wrote #305480:
[…] It’s a plugin, it still needs a prefix. […]
Ok, that’s what I thought, so I would be ok for a name change (but I honestly wouldn’t have a lot of changes to apply on my side), and for now I would vote for smd_form or smd_user_form.
Offline
Re: Rebrand contact form plugin
smd_ or pub_ prefix would be fine by me. The docs prefix list seems to indicate that pub_ is a community built plugin – which I guess this plugin is now if you don’t want to adopt it directly Stef (which of course you are quite welcome to do or not).
Offline
Re: Rebrand contact form plugin
Well I’ve kind of adopted it, but the author is still ‘Txp community’. What we could do I suppose (if GitHub allow it) is to move / fork development to our own ‘textpattern’ GitHub channel and then either:
- manage PRs as we do now and release updates.
- invite any community members with a GitHub account who want to contribute to its development to be able to commit directly.
Either would be good. Or a mix of both. It would then free it from my direct control, and make it more of a community plugin deserving of the (currently unused) pub_ prefix (or something similar, if we feel that ‘pub’ might be confused with pub-sub-hub).
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Hire Txp Builders – finely-crafted code, design and Txp
Offline
Re: Rebrand contact form plugin
Bloke wrote #305486:
Well I’ve kind of adopted it, but the author is still ‘Txp community’. What we could do I suppose (if GitHub allow it) is to move / fork development to our own ‘textpattern’ GitHub channel…
That would be nice, I could then see about doing that Composer package for it.
Offline
Re: Rebrand contact form plugin
For the record, pub_ was originally produced following my brief and laughable foray into plugin development land, standing on Bloke’s shoulders, to create the pub_draft plugin, which was quickly obviated by another, which in turn was rendered obsolete by inclusion of the functionality into core. Win!
So, no need to keep pub_ (nor keep it in the prefix list) if you guys think of something more fitting for the same reason — collaborative/community plugin dev. Oi, cpd_?
Offline
Re: Rebrand contact form plugin
Why bother renaming a plugin that shows up in all the top search results when searching for “textpattern contact form”?
Renaming the current use of “form” in TXP, that I would vote for ;)
Offline
Re: Rebrand contact form plugin
ruud wrote #305491:
Why bother renaming a plugin that shows up in all the top search results when searching for “textpattern contact form”?
When the top result comes from textpattern.org (Textpattern Resources) – aka. the shittiest place to find or read anything for Textpattern, I don’t think a plugin rename would be a problem – especially if we showcase that plugin on the new Textpattern site as I want to. If Stef renames it on GitHub the whole project 301 redirects.
Anyway, the name change was only a suggestion I made during another issue – I’m more interested in getting the plugin to install via Composer than anything. It made sense to confirm a long-running name before putting it on Packagist.
Offline
Re: Rebrand contact form plugin
1) I have no issue in changing the name. It has been ten years now since Zem left.
2) I am not a big fan of html_form because forms are so confused in Textpattern anyway. Change forms to snippets, though…
3) Not a big fan of pub either. I checked the stone tablets and com is available.
Offline
Re: Rebrand contact form plugin
com has merit if we bag it for internal use. Hmmm, com_contact though…
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Hire Txp Builders – finely-crafted code, design and Txp
Offline
Re: Rebrand contact form plugin
Bloke wrote #305480:
Wooooooah, hold up everyone!
It’s a plugin, it still needs a prefix. All this talk of making it a core plugin/module is somewhat premature, imo. Bottom line, the plugin adds a slew of tags for creating different types of input control. I don’t want to add this plugin to core, because we already have waaay too many tags.
Bloke wrote #305486:
the author is still ‘Txp community’ . . . move / fork development to our own ‘textpattern’ GitHub channel and then either:
- manage PRs as we do now and release updates.
- invite any community members with a GitHub account who want to contribute to its development to be able to commit directly.
Either would be good. Or a mix of both. It would then free it from my direct control, and make it more of a community plugin
W/out no desire to “free it” of bloke’s control per say, this is more along the lines of what I personally meant. Some plugins are so critical that the community has ended up developing them after the original author is long gone. This is one of them. What I intended to communicate was that the new name reflect the reality of this.
Is it conceivable of having a certain set of plugins/modules – like this one, (or let’s say in the future comments are moved out of the core proper and made into a plugin/module like zcr-reborn has become) – whose development is overseen and moderated by the core dev team, and allowed to use tag prefixes of txp: w/out actually being in the core?
re whether it should end up in the core per say. Actually, other than an robust api for inputs/forms, I don’t believe it belongs in the core.
Offline