Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Re: zem_contact_reborn v4.5.0.0: contact mail form processing
gomedia wrote #299264:
It’s been covered already but … “zem_contact” is as descriptive as it gets, “form” was misappropriated by TXP a long time ago & it’s off-limits, and leave the tag names alone – backward-compatibility is essential.
Perhaps it has been covered before. I vaguely recall some of those discussions. That doesn’t mean the outcome to stay with the name was inherently the best outcome :)
Respectfully, I disagree that “zem_contact” is as descriptive as it gets. That says “zem” has a plugin that “offers a contact form. Except zem isn’t the person maintaining it, and I suspect zem is not the person who has contributed the majority of the code these days. More importantly, it is much more advanced than what most people consider a contact form. It can be pressed into use for a variety of services.
As for backward compatibility, I appreciate that, but I think as a community we came to the realization that we had over emphasized backward compatibility and have moderated a bit on that value. It was holding us back. I don’t see the issue of updating the front side as a particularly major deterrent. A good search and replace function goes a long way. And if the plugin ceased development, as so many other plugins have over the years, we would change our code to use whatever new alternative was available. It’s the same basic principle.
I believe it’s simple marketing. I love the txp community. But marketing isn’t about serving the insiders of the community who share the history. Even if it was, I doubt a majority of us care about the historical aspect of zcr. Certainly new people checking out Txp don’t care. What they care about is – “can I make x kind of form?” If they see a plugin that says “form maker” they immediately have their answer. No need to read a plugin forum thread to find out that it can do radio buttons and check boxes and mail chimp and form validation, etc.
But as Bloke so kindly pointed out – its easy to say – let’s rename it, when that means a lot of work for someone that’s not me. It’s a big job. It seems to me that when a plugin has its own api for other plugins to build off it, it has gone beyond a typical plugin. It begins to echo the “module” concept of crockery.
Perhaps a better suggestion is for a 5.0 road map goal that moves the form creation platform aspect of zem_contact into a core add-on module, designed from the ground up to interact with the new unlimited custom fields that will have been added. This then would allow multiple plugins that create specific forms – contact forms, mail chimp forms, user registration forms, upload forms, and perhaps even the base for commenting and/or forums. The level of change would merit the effort to make the change. Perhaps we could even tackle the issue of changing the current “form” nomenclature to something more intuitive as well. If I recall correctly no one particularly argued for retention of forms. It was more the size of the undertaking to make the change.
Anyhow. Just threw out the suggestion because I think there are better options.
Offline
Re: zem_contact_reborn v4.5.0.0: contact mail form processing
maverick wrote #299266:
That says “zem” has a plugin that “offers a contact form.
Trueish. It means that at some point in the past or present, zem was or is maintainer of said plugin. When people take over a plugin they don’t necessarily automatically rename it, out of respect for the work put in by those in the past. Plus, it avoids upgrade hassles for those that rely upon it.
The prefix is mainly there to help protect Txp from function name clashes, which harks back to its ‘global namespace-centric’ history. If Txp was more namespaced, the prefix wouldn’t be as important, which might eliminate the owner hurdle. Although it does aid branding, up to a point, of a particular plugin author. e.g. “Those damn smd_* plugins: functional, but so insecure!”
I don’t see the issue of updating the front side as a particularly major deterrent.
Tell that to those people who run fifty sites off a variety of codebases on a single server and use ZCR on each one! There are people that do that kind of thing. But yes, it’s not rocket science in ZCR’s case, just grunt work.
when a plugin has its own api for other plugins to build off it, it has gone beyond a typical plugin. It begins to echo the “module” concept of crockery.
Yes. Plugins like mem_form and now zcr allow a lot of additional functionality to be bolted on.
Perhaps a better suggestion is for a 5.0 road map goal that moves the form creation platform aspect of zem_contact into a core add-on module
Maybe. The argument has always been that contact form functionality is not a core feature. Just for a change, I’m on the fence.
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: zem_contact_reborn v4.5.0.0: contact mail form processing
Bloke wrote #299270:
it avoids upgrade hassles for those that rely upon it.
This could avoid upgrade hassles too:
Txp::get('\Textpattern\Tag\Registry')
->register('new_name', 'old_name');Who knows what hides itself behind <txp:article /> now…
Offline
Re: zem_contact_reborn v4.5.0.0: contact mail form processing
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: zem_contact_reborn v4.5.0.0: contact mail form processing
Bloke wrote #299270:
When people take over a plugin they don’t necessarily automatically rename it, out of respect for the work put in by those in the past.
I get that. But once it’s evolved long enough and far enough . . .
Bloke wrote #299270:
Tell that to those people who run fifty sites off a variety of codebases on a single server and use ZCR on each one! There are people that do that kind of thing.
I stand properly admonished on that point. There are situations where it would be a boatload of time and effort, and fairly, some people view that as a show stopper.
Over the years, those who value backward compatibility have usually been the loudest voices, and more often than not, to the benefit of Txp and the community. I appreciate that greatly. However, some of the time its also been to our detriment.
My intention was to offer another viewpoint – that there are those of us who come from a different perspective in our discussions on backward compatibility. – which is we don’t object to those types of change, and even expect change . . . that sometimes you have to break with the past to move ahead.
Finding the right balance – that’s where the fun is :P
Bloke wrote #299270:
The argument has always been that contact form functionality is not a core feature.
Having a way for someone to make contact with the person in charge of a website seems pretty basic these days. Even so, if I viewed zrc (and its potential) as a simple contact form (say three fields – name, email, message) that sends an email to the webmaster, I agree it probably does not belong in the core.
But if one steps back from the concept of a simple contact form, and thinks in terms of generalized form creation, I believe the broader use case and functionality argues for a more elegant integration.
Ultimately in managing content we have at least four core functions: adding content, organizing content, search and retrieval of content, acting on content (in Textpattern’s case this is most often publishing content as html).
The ability to elegantly create forms addresses the core functionality of adding content. Perhaps it might be a simple contact form that by passes adding content to Txp proper, emailing it instead. That would not be a core function in my opinion. A contact form that puts the message into the database in CMS would speak to core function, but weakly at best.
However, the generic ability to create all kinds of forms that add content for Txp to manage – imo that speaks directly to a core function. Perhaps it a user self-registration form. Perhaps it is front side article editing or a new article submission form. Perhaps it is a forum post, Perhaps it is an e-commerce order form. Perhaps it is a job application form. Or perhaps it is a simple contact form. Perhaps it is used on the front side. Perhaps it is used on smd_tabber on the backside. When the functionality is viewed as a whole, rather than as a specific use case, I think the argument for core capability becomes very strong.
All the more so with the advent of unlimited custom fields. More fields is likely to lead to more people wanting more ways to interact with those fields. :D
Obviously – just my perspective.
Last edited by maverick (2016-05-25 13:44:48)
Offline
Re: zem_contact_reborn v4.5.0.0: contact mail form processing
maverick wrote #299277:
Finding the right balance – that’s where the fun is :P
And that’s Textpattern all over! Trying to offload bloat non-essential functionality to plugins and keep the core lightweight and fast. Obviously errors have been made in the past *cough* Comments.
if one steps back from the concept of a simple contact form, and thinks in terms of generalized form creation, I believe the broader use case and functionality argues for a more elegant integration.
I like your thinking. Definitely something to bear in mind as work on unlimited custom fields progresses.
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: zem_contact_reborn v4.5.0.0: contact mail form processing
I always thought that this plugin would be hugely beneficial if merged into core – it’s an essential plugin and by being in core it then gets guaranteed support (in theory).
Then thankfully Stef stepped in and stabilised the code – as there were so many versions and hacks of this plugin floating about it got mighty confusing. A name change would be fine in my mind just to move away from all those old versions.
Just my opinion.
Offline
Re: zem_contact_reborn v4.5.0.0: contact mail form processing
Some Historical Context for anyone interested
- Day 1 – 2004-10-17 – Zem Contact Introduced – zem_contact, flexible mailto form
- Day 945 – 2007-05-20 – Zem makes last message board post to date – add id to $thislink array
- Day 1040 – 2007-08-23 – Zem Contact Reborn Released – zem_contact_reborn 4.0.3.20
- Day 4128 – 2016-02-05 – Zem Contact Reborn 4.5 Released – zem_contact_reborn v4.5.0.0: contact mail form processing
- Day 4238 – 2006-05-25 – This post
Offline
#93 2016-05-26 15:09:03
- debeo
- Member
- Registered: 2012-09-24
- Posts: 16
Re: zem_contact_reborn v4.5.0.0: contact mail form processing
Can someone point me to tutorial of any kind on how to make form submit via AJAX? I’m sure there was one before but can’t find it now. I have fairly complex layout which is navigated trough URL hash and form submission breaks it.
Offline
#94 2016-05-31 01:32:26
- gomedia
- Plugin Author
- Registered: 2008-06-01
- Posts: 1,373
Re: zem_contact_reborn v4.5.0.0: contact mail form processing
Are there any plans to support such attributes as autocapitalise etc?
autocapitalise, autocorrect etc etc are not currently in the HTML5 spec but browsers support them and they make life easier for mobile users.
Maybe a general purpose “additional freeform attributes” attribute would be suitable:
<txp:zem_contact_text attr='autocapitalize="off",autocorrect="off"' />Last edited by gomedia (2016-05-31 04:39:57)
Offline
Re: zem_contact_reborn v4.5.0.0: contact mail form processing
gomedia wrote #299370:
autocapitalise, autocorrect etc etc are not currently in the HTML5 spec but browsers support them and they make life easier for mobile users.
Maybe a general purpose “additional freeform attributes” attribute would be suitable:
<txp_zem_contact attr='autocapitalize="off",autocorrect="off"' />...
Yeah, now that Chromium (since v43, if I understand Chrome status correctly) has added support for those attributes, there is not much reason to omit them. But it probably should be a fine grained thing, only applied to individual fields not the whole form. Additional Google documentation.
Where is that emoji for a solar powered submarine when you need it ?
Sand space – admin theme for Textpattern
Offline
#96 2016-05-31 04:41:35
- gomedia
- Plugin Author
- Registered: 2008-06-01
- Posts: 1,373
Re: zem_contact_reborn v4.5.0.0: contact mail form processing
phiw13 wrote #299371:
But it probably should be a fine grained thing, only applied to individual fields not the whole form.
Agreed – it’s what I had in my head, but my fingers wandered off somewhere … original code suggestion edited accordingly:
<txp:zem_contact_text attr='autocapitalize="off",autocorrect="off"' />Offline