Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Is correcting the way form ID's named worth spending time on? #4706

Open
alanmels opened this issue Oct 14, 2020 · 4 comments
Open

Is correcting the way form ID's named worth spending time on? #4706

alanmels opened this issue Oct 14, 2020 · 4 comments

Comments

@alanmels
Copy link

alanmels commented Oct 14, 2020

I find it inconsistent the way some form ids are named. For example, we have post_node_form for Post content type nodes and comment_node_post_form for its comments. Should've they been named either:

post_node_form
comment_post_node_form

or

node_post_form
comment_node_post_form

Haven't checked how Drupal forms' ids named, but most probably we inherited this mess from Drupal. It's really minor nuance that could be ignored, but then maybe consensus says we should correct it?

@stpaultim
Copy link
Member

That makes sense to me. Sounds like something that might have to wait for 2.0 or do you think it would be possible to fix this without breaking backwards compatibility?

@alanmels
Copy link
Author

alanmels commented Oct 14, 2020

I believe if it's fixed everywhere in the core, then no functionality should break. It's not likely that some Backdrop projects relied on those particular id namings. Most of the custom alterations operate the values of variables like $form_id anyway, so functionality should be intact.

@indigoxela
Copy link
Member

This is definitely a 2.x task.

Think of all the potentially broken hook_form_FORM_ID_alter() in contrib and custom modules.

@ghost ghost added this to the 2.x-future milestone Oct 15, 2020
@ghost
Copy link

ghost commented Oct 15, 2020

I agree with the suggestion that naming should be consistent, but it will cause breaking changes as @indigoxela suggested.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants