#38129 closed enhancement (wontfix)
Rename `dynamic_sidebar` to something more understandable
Reported by: |
|
Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | 2.2 |
Component: | Widgets | Keywords: | |
Focuses: | Cc: |
Description
Currently, widget areas are registered using register_sidebar
and defining widget areas in templates are done using dynamic_sidebar
. Other related functionalities seem to follow the same naming pattern ("sidebar").
This most probably originates from the 2000s blog-like template structure where sidebars were the only logical places to place widgets into. Currently, many people are defining widget areas to places which are not sidebars (footers, headers, article sections, etc.).
After working with people who are relatively new to WordPress theme development, I've heard multiple complaints about how this is confusing and "why can't it be called something that actually reflects what it does".
Would it be possible to rename all widget-related functions and features to something else than a "sidebar"? E.g. register_widget_area
and dynamic_widget_area
.
A proper approach might be a tad longer deprecation period (two major versions perhaps) because these functions and features are used in so many themes.
Change History (3)
#2
@
8 years ago
- Keywords close added
- Resolution set to invalid
- Status changed from new to closed
@ojrask it's not a good reason to rename that functions lots of theme and plugin use this function to register sidebar and to get sidebar in template so if WP developer change this function then all theme and plugin developer need to change this, if you want to change this then try to make new function like below.
Add this code in function.php
<?php function dynamic_widget_area( $sidebar_id ){ dynamic_sidebar( $sidebar_id ); } ?>
Call sidebar in template like page.php
<?php dynamic_widget_area( $sidebar_id ); ?>
I would suggest if this is considered...renaming the function but having the old name call the new function for backward compatibility. Otherwise you would break too many things.
Possibly revisiting the implementation at the same time.