Rebrand contact form plugin

Bloke · 2017-04-26 09:44:15

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.

etc · 2017-04-26 10:24:23

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).

Destry · 2017-04-26 13:40:12

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.

maverick · 2017-04-26 13:47:43

Bloke & etc – thanks for the insight and explanation!

Txp has a great looking future with the ideas and improvements underway.

Thanks!

Bloke · 2017-07-17 21:59:46

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)

gomedia · 2017-07-17 22:17:16

sys_ ?

gomedia · 2017-07-17 22:21:21

But pub_ would be my preference if you wanted the “community” feel.

Bloke · 2017-07-17 22:32:27

gomedia wrote #306290:

sys_ ?

Good option. Added to the list.

phiw13 · 2017-07-17 22:41:17

“Connect” sounds good for a name. As for the prefix, hmmm. Perhaps, mod as in “module”?

mod_connect_checkbox, mod_connect_text, mod_connect_select, … that seems to work reasonably well – as in: human readable strings.

Bloke · 2017-07-17 23:49:37

phiw13 wrote #306293:

“Connect” sounds good for a name. As for the prefix, hmmm. Perhaps, mod as in “module”?

They were my first choices too. Not that I want to sway anyone’s decision. Although mob has appeal, as we’re a disparate bunch who come together to do stuff :-)

bici · 2017-07-17 23:50:04

phiw13 wrote #306293:

“Connect” sounds good for a name. As for the prefix, hmmm. Perhaps, mod as in “module”?

mod_connect_checkbox, mod_connect_text, mod_connect_select, … that seems to work reasonably well – as in: human readable strings.

+1

phiw13 · 2017-07-18 00:01:08

Bloke wrote #306294:

Although mob has appeal, as we’re a disparate bunch who come
together to do stuff :-)

Sure, that kinda reflect & defines the peeps around here :-) Not a fan to use that kind thing for branding though. Because (and this applies to some other suggested prefixes as well):

too much “internal-joke” for any kind of branding
feels a bit childish and pseudo-playful alla silicon valley startup culture (not liking that at all)

Last edited by phiw13 (2017-07-18 00:01:44)

gomedia · 2017-07-18 00:04:48

Would rather be in the pub_ than in a mob_ …

philwareham · 2017-07-18 06:07:28

Either mod or pub get my vote. Contact or connect I’m fine with too (probably mod_contact slightly edging it for me).

colak · 2017-07-18 06:19:02

philwareham wrote #306299:

Either mod or pub get my vote. Contact or connect I’m fine with too (probably mod_contact slightly edging it for me).

+1

Textpattern CMS support forum

#31 2017-04-26 09:44:15

Re: Rebrand contact form plugin

maverick wrote #305497:

#32 2017-04-26 10:24:23

Re: Rebrand contact form plugin

Bloke wrote #305502:

#33 2017-04-26 13:40:12

Re: Rebrand contact form plugin

philwareham wrote #305493:

#34 2017-04-26 13:47:43

Re: Rebrand contact form plugin

#35 2017-07-17 21:59:46

Re: Rebrand contact form plugin

#36 2017-07-17 22:17:16

Re: Rebrand contact form plugin

#37 2017-07-17 22:21:21

Re: Rebrand contact form plugin

#38 2017-07-17 22:32:27

Re: Rebrand contact form plugin

gomedia wrote #306290:

#39 2017-07-17 22:41:17

Re: Rebrand contact form plugin

#40 2017-07-17 23:49:37

Re: Rebrand contact form plugin

phiw13 wrote #306293:

#41 2017-07-17 23:50:04

Re: Rebrand contact form plugin

phiw13 wrote #306293:

#42 2017-07-18 00:01:08

Re: Rebrand contact form plugin

Bloke wrote #306294:

#43 2017-07-18 00:04:48

Re: Rebrand contact form plugin

#44 2017-07-18 06:07:28

Re: Rebrand contact form plugin

#45 2017-07-18 06:19:02

Re: Rebrand contact form plugin

philwareham wrote #306299:

Board footer