Rename FAPI type 'textfield' to 'text' globally

Erm... no!

"Text" is also the name of a module, and the name of the field and widget it provides. This will not reduce but increase confusion.

Damien, fine! Care to suggest a better name? Field should not be there. Esp not 'textfield' when have a 'text field' module....

Given that I was not part of the discussion between chx and David, I'm not sure I can make sense of this issue. Could some care to explain the finer points of the discussion?

Finer points....??? My take is this: There is a text module which provides a field type text which in short everyone calls a 'text field'. But 'textfield' is a one-line input form API element. David complained originally that we do not call them 'checkboxfield' so why 'textfield' but that's imo a lesser concern than the confuson between field and form API in this regard.

text.module isn't a great name for a module anyway - if anything we should prefix the field type modules with field_.

well that'd be good... but that does not change the problem with 'text field' and 'textfield' meaning two different things.

Forgot to mention I agree with the patch itself as well as disagreeing with Damien.

Considering that there is a general agreement to rename the "text" module to something else, I can support this patch. The code itself looks ok (mostly simple replacements of '#type' => 'textfield' to '#type' => 'text'), but:

* The patch changes the "textfield" profile type to "text", which means that we need an upgrade function
* The following replacements result in strange grammar:

- * to have any children, e.g. buttons or textfields, it can be used to render
+ * to have any children, e.g. buttons or texts, it can be used to render

- * This field provides a textfield which only accepts the value 1.
+ * This field provides a text which only accepts the value 1.

I did a quick scan of the latest patch. The grammar is a lot better and makes sense.

I did not apply the patch, though. But I guess it's ready to RTBC provided someone takes the time to apply the patch properly.

There is only one failed hunk in the patch. It is caused by a code-style error in the affected lines, which has been fixed in the meantime.

Here is a re-rolled patch.

... mh. There's something wrong here; the patch is 10KB larger than the previous one. I know that I diffed a clean working copy. What gives?

... I think the server has a hickup.

Anyway, I found out the reason for the 10KB.

=== modified file 'modules/user/user.pages.inc'
--- modules/user/user.pages.inc	2009-04-13 12:14:57 +0000
+++ modules/user/user.pages.inc	2009-04-14 00:25:49 +0000

and

Index: modules/user/user.pages.inc
===================================================================
RCS file: /cvs/drupal/drupal/modules/user/user.pages.inc,v
retrieving revision 1.34
diff -u -p -r1.34 user.pages.inc
--- modules/user/user.pages.inc	20 Apr 2009 04:41:35 -0000	1.34
+++ modules/user/user.pages.inc	26 Apr 2009 15:52:47 -0000

Differ by approximately 180 byte in size. 55 files were modified. 50*200 = 10kB.

Having 'text' and 'textarea' does not look like an improvement to me.

'text' might only work if the form element widget would be dynamic, i.e. depending on certain properties, it either becomes a one-line text input field or a multi-line textarea - effectively meaning that 'textarea' would be dropped. Although I am not sure whether that makes sense and does any better.

We also need to take #414424: Introduce Form API #type 'text_format' into account.

That said, I don't really understand why text.module has to provide two new form element #types 'text_textfield' and 'text_textarea', which - logically - are the same form #type elements as the existing #types...?

textarea and input are so radically different kinds of markup, and are handled in such different ways by browsers, that I don't think they should be lumped into one "magic" Form API element.

Considering the markup of HTML forms, "text" makes much sense. All other form API elements are named after their type attribute (for "input" elements like checkbox, radio, submit) or their element name ("select", "textarea").

That said, I don't really understand why text.module has to provide two new form element #types 'text_textfield' and 'text_textarea', which - logically - are the same form #type elements as the existing #types...?

No idea why. It seems to be the standard for almost all CCK widgets to reference a self-defined custom form element - even for simple form elements like text, radio options, etc.

Arancaytar is right, that's what this issue is about: rename textfield to text so that it is a) consistent with the HTML b) it's not called a field.

What happened to this one?

I withdraw my previous statement due to Arancaytar's reasoning. Mapping to DOM element types makes sense.

Though the text_* #type duplication issue remains, but that doesn't belong into this issue.

Tagging.

I'm merging #15 across the four intervening months right now.

This patch applies to HEAD again.

However, it is incomplete. After applying this patch, another careful replacement will have to be done.

Edit: It seems that some of the instances in the field_ui and text.module files will stay. However, there are some others that do have to be changed.

This one should fix some of the failures. I've left the text_textfield and related stuff unchanged.

This one required no manual merging, just an update of the patched code-base.

This is breaking faster than I can keep up.

Blogapi's removal this time.

Remerged.

#394182: DBTNG search.module broke HEAD. Re-test.

No no, this time the testbot has it right. File field added a couple of textfield form elements that have to be replaced.

Local copy didn't diff modules/file for whatever reason. Maybe third time's the charm.

Introducing a new tag for feature freeze: API clean-up.

Too late for D7. Let's try again in D8.

Pinging. Obviously there was a lot of passion on this one and it can be done now before the next string freeze :)

Here's an updated patch. Let's see what testbot thinks.

Patch fails. directory structure has changed. [/includes no longer exists]

Here's an updated patch which accounts for the /core move.

#49: textfield-text-049.patch queued for re-testing.

Hello,
Submitting a new patch generated with the last codebase.
Hopefully it goes green !

Seems like all these patches generated from "one-liner command"

most of them are very bad changes.

eg:

+++ b/core/misc/autocomplete.jsundefined
@@ -213,7 +213,7 @@ Drupal.jsAC.prototype.populatePopup = function () {
-  // If no value in the textfield, do not show the popup.
+  // If no value in the text, do not show the popup.

+++ b/core/includes/form.incundefined
@@ -1895,7 +1895,7 @@ function form_builder($form_id, &$element, &$form_state) {
-    // If a form contains a single textfield, and the ENTER key is pressed
+    // If a form contains a single text, and the ENTER key is pressed

Are they changing the meanings ?

textfield == text field
textfield == text input
textfield == text form element

BUT

textfield != text

#52: rename_textfield_to_text-431812-52.patch queued for re-testing.

pzula added a new issue summary for d8

Updated the issue summary

This is riddled with rejections, I'll see what I can do in an hour to fix it up. ALOT has changed since last july.

chx: that's what this issue is about: rename textfield to text so that it is a) consistent with the HTML b) it's not called a field.

These issues with the wording of 'text field' in no way warrant a global s/textfield/text/g on the entire code base. On top of that, this patch is absolutely unmaintainable with its broad reach given the current pace of D8 development. It will end up breaking far too many things, and is not worth the effort.

I could understand if the scope of this issue was narrowed and was just a patch against some unclear description of a field in an admin form. But this is so broad reaching (s/textfield/text/g) and seems very misguided.

Are the chx's issues raised above truly impediments to either UX or development in any way? If not, I'd recommend close: won't fix.

pzula updated summary

Adding a new patch

I'm working on it now.

We should all try and use the same sprint tag. According to https://groups.drupal.org/node/447258 it should be SprintWeekend2015 with no #.

PLEASE IGNORE;

Try to reroll.
Not shure about some tests which uses 'textfield' value as name for items.

Please review.

IMHO it's better unassigned.

@rahulbaisanemca if want to do the reroll, reassign it, please.

Rerolling.

Now atleast php error is gone :)

The error was a new line before <?php tag.

This should fix few tests.

Here is missing interdiff file.

Hi, I've found this issue. Looks like all references to text_textfield were overlooked. Investigating...

I am removing the Novice tag from this issue because it was added back in 2009, this issue has changed version numbers, and the comments are closing in on triple digits. That is a lot of comments to read through for new contributors.

I’m using this documentation as a source: https://www.drupal.org/core-mentoring/novice-tasks#avoid

I re-rolled the patch.

Fixing syntax error in last patch.

Submitting to test bot again to have updated test failure list.

A normal-priority Task must go in 8.1.x, usually.

@Sharique Patch is not working in drupal-9.3.x-dev
Needs to re-roll for this version for ref sharing screenshot

- Patch #105 is not working in drupal 10 version.
- Needs to re-roll for this version.
- Attaching screenshot for reference.

Patch or MR doesn't apply anymore
The last patch or MR doesn't apply to the target branch, please reroll the code so that it can be reviewed by the automated testbot.

D10 version needed
At this time we would need a D10.1.x patch or MR for this issue.

Before proceeding further I would like to have some input on how to proceed with textfield string yml,css,js files ?
For now I replaced textfield to text in .php files.

A global find and replace is too broad; several comments have been changed that don't make sense.

We also need to consider backward compatibility, we need to support both text and textfield until the next major version.

I even think this might have to be won't fix, as there is probably contrib/custom code somewhere that relies on #type => 'textfield' and I don't see a way of handling that in a backward compatible manner; not sure the benefit outweighs the disruption here.

I'd be fine with that, up to the committers to make a call on this :)

Wouldn't we just leave the existing textfield type in place as an extension of the text type?