Opened 4 years ago
Last modified 4 years ago
#47635 new feature request
expand wp-config.php file with default settings
Reported by: |
|
Owned by: | |
---|---|---|---|
Milestone: | Awaiting Review | Priority: | normal |
Severity: | normal | Version: | 5.3 |
Component: | Bootstrap/Load | Keywords: | reporter-feedback |
Focuses: | Cc: |
Description
It would be very beneficial to add some settings into wp-config.php file like:
define('WP_TIMEZONE', 'UTC');
define('WP_DATEFORMAT', 'F j, Y');
define('WP_TIMEFORMAT', 'g:i A');
define('WP_WEEKSTARTS', 'Monday');
so it should work the same way as WP_URL settings. In case of MU this still might apply to default blog.
then consider (General,Writing,Reading,Discussion,Permalinks):
WP_SITETITLE
WP_TAGLINE
WP_EMAIL
WP_MEMBERSHIP
WP_DEFAULT_ROLE
etc...
Hope there is no obligation like security or functionality breakdown for such request.
Change History (3)
#1
follow-up:
↓ 2
@
4 years ago
- Component changed from General to Bootstrap/Load
- Keywords reporter-feedback added
#2
in reply to:
↑ 1
@
4 years ago
Replying to SergeyBiryukov:
Hi @tradik, welcome to WordPress Trac! Thanks for the ticket.
Please note that the WordPress core team generally avoids introducing new constants, as they are not very flexible. New filters or actions can be introduced instead.
I would think, for these settings, the whole point seems to be to make them immutable (not filterable) by software, like plugins and themes, or messed up by admin mistakes.
#3
@
4 years ago
Use cases:
- Security, protection against extensions messing with things they should not.
- Agencies/developers setting up sites for clients with warranty and/or support, and still letting the client be administrator to be able to manage plugins, themes and other options than the above. Restricting the above settings for admin is complicated.
These constants should not be introduced in wp-config-sample.php
so I suggest limiting this ticket to just let those constants have the desired effect, like most other constants.
- Make the controls in settings page be disabled.
- Removed from accepted keys when posting to options.php.
- Protect options from being filtered or saved through set_option.
I am fully aware this is not security from malicous code, as the database is fully open to any extension. This is against unintended or clueless messing up, like setting default role to Administrator and open registration.
A WP_SITE_LANGUAGE
should also be in. Deprecated WP_LANG
was (is still?) for adding new translations, or if not, it can be reintroduced to lock the site language. Users have their own personal language setting.
Hi @tradik, welcome to WordPress Trac! Thanks for the ticket.
Could you share a use case for these constants? Please note that the WordPress core team generally avoids introducing new constants, as they are not very flexible. New filters or actions can be introduced instead.