New Settings API and workflow
|Reported by:||nacin||Owned by:|
A new Settings API should ideally be less painful.
That includes registration of options, creating fields and forms, and handling errors.
Quick suggestions, which Ryan and others can elaborate on, as well as offer justification for:
- Stop using options.php as a POST handler.
- Object-oriented approach, rather than passing handles around everywhere.
- Should be flexible enough to leverage the new Settings API in the Network and User admins.
- Form/field construction should be easy, and core should use it.
- Core should also show/hide relevant fields based on the UI, perhaps with some sort of caps integration. Likewise, authorization for saving options should be incorporated beyond the sanitization callback.
Table markup should also be moved to CSS, which requires #16413 and core leveraging the fields API.
Anything that is not done, can be moved to 3.4. We should not rush this API, and we should be absolutely satisfied with it.
Change History (122)
5 years ago
- Cc mpretty@… added
in reply to:
5 years ago
- Keywords 3.4-early added
- Milestone changed from 3.3 to Future Release
- Type changed from task (blessed) to feature request
- Keywords 3.4-early removed
- Milestone Future Release deleted
- Resolution set to maybelater
- Status changed from new to closed