Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
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.
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
Re: Rebrand contact form plugin
maverick wrote #305497:
Is it conceivable of having a certain set of plugins/modules… 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?
Anything’s possible. Besides author branding, the only technical reason behind our (albeit not rigorously enforced) prefix policy is to reduce the possibility of collisions with internal functionality that’d break a site. That’s a holdover from the fact that Txp populates all its tags in the global PHP scope.
In order to free us of the legacy shackles, we need to do one or more of the following in core:
- Migrate the tags to their own namespace or somehow insulate them from PHP’s global scope. This, however, impacts and breaks all plugins that call tags by their function name rather than via invoking the parser. I’m guilty of that.
- Check when a plugin registers a tag that it’s not already in use and complain if it is. Now we have tag registration as a pre-requisite (again, not yet enforced, just advisory) this is possible.
- Namespace plugin tags.
- Reduce our reliance on the global scope overall. This is work in progress, and we’re chipping away at it every so often.
Regarding using prefixless tags for plugins, well, for the reasons stated above that’s not a great idea at present. But if some of the above are implemented (especially the second one), then there’s no technical barrier to offering the functionality. We might not need to do that, however: unofficially at present, we can already get partway there. If you toggle a special (hidden) pref enable_short_tags to 1 in your txp_prefs table, the parser will permit you to use any prefix instead of txp:, with the additional burden of using double-colon. So, for example:
<txp:smd_if ...>would become:
<smd::if ...>I believe (though haven’t checked, so Oleg will I’m sure correct me if I’m wrong) that this extends to else:
<smd::if ...>
Do some stuff if the conditions match
<smd::else />
Do some other stuff if the conditions fail
</smd::if>All that should be available now — plugins don’t need to do anything to benefit — and has some great code readability benefits, because you won’t necessarily drown in a sea of <txp:else /> tags on complex pages and wonder which is attached to which tag (unless you’re nesting lots of plugins by the same author).
We’re still testing the functionality so it’s not set in stone yet — hence the softly softly approach — but this is just another step in the direction of making plugins more integrated with core.
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: Rebrand contact form plugin
Bloke wrote #305502:
I believe (though haven’t checked, so Oleg will I’m sure correct me if I’m wrong) that this extends to
else:
<smd::if ...>...<smd::else />...
Yes, it should work. In 4.6, only three-letters prefixes are enabled (without any preference), but in 4.7 (with a preference) short tags like <if::individual_article /> or <article::title /> are working too. The preference is only justified by a 5% parsing slowdown with short tags enabled, but you start to notice it only in thousands articles loops, which is a bad practice anyway (or should be cached at least).
Offline
Re: Rebrand contact form plugin
philwareham wrote #305493:
When the top result comes from textpattern.org (Textpattern Resources) – aka. the shittiest place to find or read anything for Textpattern…
Yeah, the ranking is trivial, IMO. Re-indexing isn’t hard, and a relatively quick return to rank if the content is tight. And I should probably add, being I planted the seed, that it makes no sense, at least to me, to still be giving credence to “zem” in the name, which is why I said anything originally. It’s one thing to still use a functional zem plugin, but something else to call a plugin ‘the rebirth of the previous developer’s plugin’, and especially a third incarnation of it nearly 10 years later. Cut the cord already, that guy jumped ship a long time ago.
If that’s not being friendly, then I’m not friendly. My cognizance of software licenses is another matter, however.
Offline
Re: Rebrand contact form plugin
Bloke & etc – thanks for the insight and explanation!
Txp has a great looking future with the ideas and improvements underway.
Thanks!
Offline
Re: Rebrand contact form plugin
Okay, I’m going to do this within the next 24 hours. But I still can’t make up my mind on the name. I spent some time with the thesaurus and, on the basis we go with a community prefix and move the plugin to our Textpattern GitHub account so collaboration can continue, here’s my shortlist of possible prefixes, all available for us to bag:
- mod – module, moderated.
- mob – a disparate group of people coming together.
- soc – social, society.
- kin – kinship, kindred.
- gen – general, generic.
- pop – population.
- pub – public.
- grp – group, community.
- ppl – people.
- org – organisation.
- fed – federation, federated.
- out – outsourced.
- com – community.
- sys – system (thanks, gomedia).
Then there’s the plugin name itself. Again, the thesaurus gave me some ideas:
- contact.
- touch.
- unity.
- connect.
- hello.
- reach.
- talk.
Combining prefix and plugin name gives some cute ideas:
- mod_connect.
- mod_contact.
- com_unity (!)
- soc_hello.
- ppl_talk.
- out_reach (!)
- gen_touch.
- …
Consider how it sounds on its own and how it works as part of the other tags (i.e. with _text, _email, _select, _option, _checkbox, _radio, etc. after it).
So put your thinking caps on and combine prefix + plugin name to come up with your favourite (or suggest an alternative).
Last edited by Bloke (2017-07-17 22:32:08)
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
#36 2017-07-17 22:17:16
- gomedia
- Plugin Author
- Registered: 2008-06-01
- Posts: 1,373
Re: Rebrand contact form plugin
sys_ ?
Offline