For WordPress environments, there is usually no reason to use ini_set because that is what the defined constants provided by WordPress Core are already achieving. The way that PHP works is that certain settings can be overridden within your CMS (WordPress), within individual scripts, and even on a per-user or per-directory basis (much to the frustration of web hosts and agencies).
To disable errors from displaying on-page in WordPress, the only setting you really need is:
define('WP_DEBUG', false);
...because when WP_DEBUG is disabled, the sub-options are then inactive:
define('WP_DEBUG_DISPLAY', false);
define('WP_DEBUG_LOG', false);
Keep in mind that the confusing WP_DEBUG_LOG option only refers to the creation of debug.log within the directory wp-content and does not effect other logging settings, etc.
Again, the settings in WordPress can override default PHP settings, so your PHP settings don't matter as much as having correct settings in your wp-config.php file, which loads before other WP components.
That said, it is a good idea to implement default settings like below in production:
error_reporting = E_ERROR | E_WARNING | E_PARSE
display_errors = Off
display_startup_errors = Off
log_errors = On
error_log = /var/www/logs/error.log
log_errors_max_len = 1024
ignore_repeated_errors = On
ignore_repeated_source = Off
report_memleaks = On
xmlrpc_errors = 0
html_errors = Off
For a complete example, refer to our SlickStack php.ini file optimized for Nginx and PHP-FPM.
In one case, after hours of research, we realized a plugin (or theme) was overriding the various error handling settings previously set in php.ini and wp-config.php. The only way to prevent this is to remove the WordPress plugin or theme that is trying to "hack" your PHP settings, or tell them to remove it because that is very bad practice for extensions to be overriding the debug options of your CMS.
In SlickStack, we created a Bash script that "flags" any ini_set and error_reporting lines from PHP files in the /themes/ and /plugins/ directories by highlighting such instances using a MU Plugin (PHP script) that displays a list of such "hacks" in the WP Admin Dashboard.