#31974 closed feature request (wontfix)
Separation of Views and static data, such as mime-type arrays from logic code
Reported by: | LewisCowles | Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | 4.2 |
Component: | General | Keywords: | reporter-feedback |
Focuses: | Cc: |
Description
I propose that WordPress embedded views, and any HTML, CSS, JS, or any other textual output, and static data such as mime-type arrays, be put in a framework, to be separated from the logic of the WordPress code-base.
This would allow several advantages over the current system(s) in place.
- Shorter code files, with standardised syntax (lowers the bar for front-end editors / contributors, as the language files already have. These users may not be PHP savvy, allowing code editors to work on code, separately to data-structures, moving WordPress towards a more data-driven, presentation agnostic code-base.
- Simplified modification of data and portability of data-structures to systems beyond WordPress & Integrations / Migrations to WordPress, as well as better sharing with front-end CMS logic and back-end tooling.
Change History (3)
#1
@
10 years ago
- Keywords reporter-feedback added
- Type changed from defect (bug) to feature request
#2
@
10 years ago
sorry John, but none of this requires that much complexity, as it is essentially a class, maybe two (< 1k lines each), and reduces complexity, without harming features... Not sure why you thought this would harm features, but it wouldn't, and many of my plugins have used separate data and views within WP since pre 2009... I Just thought it might be nice for you core devs to have less work to achieve the same result was all.
#3
@
6 years ago
- Milestone Awaiting Review deleted
- Resolution set to wontfix
- Status changed from new to closed
Agreed with comment 1, and given the lack of traction on this idea, closing as wontfix. Separate trac issues can be opened with plans of action to consider individual pieces of such as transition if desired.
This is such a wide-ranging proposal that it needs to be broken down into pieces before anything can be considered. WordPress has twelve years of technical debt and backwards compatibility to consider.
Do you have a specific model you'd like to propose?