risks on hosting wordpress - with the wrong configuration - note: weve discussed this bout 1.5 years ago. from time to time its a good idea to refresh the discussion again...
this discussion helps to make up ideas, and mindet - if it gives some ideas to others - i am happy. I am the one who benefits from writing about these mattes - i am benefiting the most!!
for all those who may be tired of re-reading these kinds of stuff - a big big SORRY - hopefully some of you might find it helpful
regards... unleash
When working with WordPress in a more secure environment where websites are not entirely world-writable,
you will notice upgrades request FTP or FTPS credentials as the server itself does not typically have write access in properly-configured environments. Entering these credentials for every upgrade can become quite tedious, and WordPress has implemented some constants you can define within wp-config.php to make upgrades automatic.
It should be noted here that you can also make upgrades automatic by setting the file ownership of all files within the WordPress directory to the same user/group under which the webserver is running. THIS IS HORRIBLE SECURITY PRACTICE!
While storing your FTP credentials for a specific user can also be considered insecure in certain instances, it can be a very safe method to automate WordPress updates under the proper conditions. Some general considerations which can make stored credentials MUCH more secure include:
end of cit: see more here https://www.serverstack.com/blog/2013/0 ... r-ssh/0020
well can you advice me
– what is needed to run the automated updates of plugins!?
– do i need to have suPHP enabled
– what else do i need to have?
by the way
– i need to have a overview on all necessary conditions and things…. – there a plugin suggests to get done all the things – i t is called infinitewp – but i guess that – to run this – i need to have the horrible server conditions too!?[/quote]
update: Well i want to dig into the processes of the automatic-update: at the moment my server does not fullfill the needs that are mandantory to be met if one wants to run the automatic-updates:
Well in this posting i want to gather togehter all i can get - to understand these porcesses - in order to dive into this technique and to enlarge my understanding: the Wordpress site had been automatically updated to the latest version. I knew about the feature but I've always wondered exactly how it works. Therefore i gathered some information about hte update-process how it works and which credentials at serverside we need.
furthermore i have found some ideas about a shorter way to automatically update WordPress? here some infos on the updating WordPress plugins, there’s a prompt for the FTP login:
Connection Information:
To perform the requested action, WordPress needs to access your web server. Please enter the FTP credentials to proceed.
If we do not remember the credentials, we should contact our web host.
Hostname: host
FTP Username: user
FTP Password: pass
Connection Type: FTP or FTPS (SSL)
This will work fine, except if it’s host uses SFTP over SSH with Port 22.
Failed to connect to FTP Server host:21
It will attempt to always use port 21 as well.
This is the user’s permission problem.
step-1: First open wp-config.php file of your WordPress installation folder.
step-2: Copy below code and paste it at the end of the wp-config.php file.
define('FS_METHOD','direct');
we need to make sure ownership permissions are set to Apache so that WordPress can update and/or
install plugins without requiring FTP credentials. We can set permissions via SSH.
Single site hosting:
chown -R apache:apache /var/www/html
basically, it’s easy to set up wordpress-server to do the automated update:
- Permissions in the wordpress tree: 755 on directories, 644 on files.
- Ownership of files: The same user under which PHP is running
Once we have that, WP is able to update itself. By default, that means it will do minor update (e.g., 5.2.3 to 5.2.4),
but not major ones (5.2.x to 5.3.x), nor will it auto-update plugins. We can add constants to wp-config.php for core updating.
See https://wordpress.org/support/article/e ... re-updates.
For auto-updating themes and plugins, see https://www.wpbeginner.com/plugins/how- ... s-plugins/
Also a good read https://wordpress.org/support/article/e ... -constants
here i found a shorter way to automatically update WordPress?
cf: https://wordpress.stackexchange.com/que ... -wordpress
This is how we can start to update WordPress daily:
- Code: Select all
cat <<-"CRON_DAILY" > /etc/cron.daily/nses_cron_daily
for dir in /var/www/html/*/; do cd "$dir" && /usr/local/bin/wp plugin update --all --allow-root; done
for dir in /var/www/html/*/; do cd "$dir" && /usr/local/bin/wp core update --allow-root; done
for dir in /var/www/html/*/; do cd "$dir" && /usr/local/bin/wp theme update --all --allow-root; done
chown www-data:www-data /var/www/html/* -R
find /var/www/html/* -type d -exec chmod 755 {} \;
find /var/www/html/* -type f -exec chmod 644 {} \;
CRON_DAILY
chmod +x /etc/cron.daily/nses_cron_daily
I create the file with the heredocument, change permissions, and run daily.
Is there a shorter, pluginless way to update (less rows, hahaha)?
Update: I didn't change basically anything inside wp-config.php besides database credentials.
the Wordpress site had been automatically updated to the latest version. I knew about the feature but I've always wondered exactly how it works. PHP isn't a permanently-running process: it only runs when requested. So as far as I can tell, Wordpress can only update itself when someone loads a web page. But the update process is not instantaneous, so surely a user visiting the site would have a really slow page load. Is there a different trick they use for automatic updates? I've searched all over the place but haven't found any explanation.
some more into depth going details on the auto-update-process: the automatic update is pushed from wp.org. The update process still runs on our site, but in the background via wp-cron.
When a new minor update is released, the guys at WordPress start to roll out the update. The actual update process is started after our site checked wp.org for updates, an update is theoretically available, and our site is chosen by random to be updated. As every site checks with wp.org for new versions (usually twice dayily using wp-cron), the rolloutserver knows how many sites need an update. Then the rollout begins, starting slowly - 1 out of 128 sites gets updated automatically. This is being monitored, and if the successrate indicates no problems with the rollout, more of the sites get the automatic update (usually the next step would be 1 out of 64, and continuing to increase that way) until all automatic updates are delivered.
This enables the developers to stop the rollout if any problems occur, but the last update from 3.8 to 3.8.1 has had a 100% success rate. The sites selected by the 1 out of 128 is actually random. Well, not really, but if you want to know, it works like this: The Url of the site needing an update gets hashed using MD5. Using just the first three characters of this hash and converting it to base10, this results in 4096 possibilities. The update started for sites having a calculated number between 0 and 31 (4096 / 32 = 128).
cf: https://wordpress.stackexchange.com/que ... dates-work
and futhtermore i found more infos:
WordPress Automatic Updates :: There are four typologies of updates and WordPress automatic updates:
Core updates
Plugin updates
Theme updates
Translation files updates
Core updates are divided into three sub-typologies:
Core development (only available for development installations)
Minor core updates (maintenance and security) – enabled by default in stable installations
Major core updates
WordPress allows us to automate the update process for any of these typologies providing two wp-config.php constants and a good number of API filters.
Controlling Background Updates Through wp-config.php
WordPress provides a couple of wp-config.php constants that allow us to control auto-updates. Setting AUTOMATIC_UPDATER_DISABLED to true will disable any kind of automatic upgrade:
define( 'AUTOMATIC_UPDATER_DISABLED', true );
WP_AUTO_UPDATE_CORE allow us to control core updates (minor, major and development releases). This constant can be defined as follows:
# Disables all core updates:
define( 'WP_AUTO_UPDATE_CORE', false );
# Enables all core updates, including minor and major:
define( 'WP_AUTO_UPDATE_CORE', true );
# Enables minor updates:
define( 'WP_AUTO_UPDATE_CORE', 'minor' );
In development installations WP_AUTO_UPDATE_CORE defaults to true. In stable installations it defaults to minor.
For the sake of completeness, I should mention an additional constant that can be defined to disable auto-updates. However, setting its value to true will disable any file edits, even themes and plugin installations and manual updates.
define( 'DISALLOW_FILE_MODS', true );
Instead, you may prefer to define the DISALLOW_FILE_EDITS constant, which would disable the file editor, but keeping safe the installation and update functionalities.
Related tutorial: wp-config.php File – An In-Depth View on How to Configure WordPress
Controlling Background Updates Through API Filters
Configuration constants provide a general way to enable or disable auto-updates. But WordPress provides a number of filters which grant a deeper control over any kind of updates.
Note: Filters should be used within plugins, and “must use plugins” are a good option for background updates. mu-plugins reside in a specific folder inside /wp-content and are automatically enabled by WordPress. These plugins do not appear in WordPress Plugins Screen, so they could not be accidentally disabled or removed by the site admins. For a deeper view, refer to the Codex documentation
First, returning true through the automatic_updater_disabled filter has the same effect as defining the AUTOMATIC_UPDATER_DISABLED constant to true in wp-config.php:
add_filter( 'automatic_updater_disabled', '__return_true' );
We can control any of the update typologies through the auto_update_$type filters which enable or disable updates depending on the value of $type ('core', 'plugin', 'theme' or 'translation').
So, we can automate all core updates by returning true through the auto_update_core filter:
- Code: Select all
add_filter( 'auto_update_core', '__return_true' );
In the following example, we’re enabling automatic updates for themes, plugins and translations:
add_filter( 'auto_update_theme', '__return_true' );
add_filter( 'auto_update_plugin', '__return_true' );
add_filter( 'auto_update_translation', '__return_true' );
In the examples above we’ve ju st enabled auto-updates. But these filters give us a greater control over updates. In the following example we’re automating auto-updates for two specific plugins:
function cb_auto_update_plugins ( $update, $item ) {
$plugins = array ( 'hello', 'akismet' );
if ( in_array( $item->slug, $plugins ) ) {
// update plugin
return true;
} else {
// use default settings
return $update;
}
}
add_filter( 'auto_update_plugin', 'cb_auto_update_plugins', 10, 2 );
The callback function keeps two arguments:
$update: a boolean which sets wether to update or not;
$item: the update offer object. The function checks wether the item to update is in $plugins array, then returns true or false accordingly.
Last, we can make difference between development, minor and major updates, by returning true or false through the following filters:
- Code: Select all
add_filter( 'allow_dev_auto_core_updates', '__return_false' );
add_filter( 'allow_minor_auto_core_updates', '__return_true' );
add_filter( 'allow_major_auto_core_updates', '__return_true' );
We know that occasionally an update can fail. In the worst case, the website can go down after an update failure. But luckily we can ask WordPress to notify us with an email after any update (or attempt).
suPHP is a tool for executing PHP scripts with the permissions of their owners. It consists of an Apache module (mod_suphp) and a setuid root binary (suphp)
but generally speaking bout the Automatic WordPress Updates Using FTP/FTPS or SSH - in a more secure environment
Introduction When working with WordPress in a more secure environment where websites are not entirely world-writable, you will notice upgrades request FTP or FTPS credentials as the server itself does not typically have write access in properly-configured environments.
cf https://www.serverstack.com/blog/2013/0 ... or-ssh/20/
Entering these credentials for every upgrade can become quite tedious, and WordPress has implemented some constants you can define within wp-config.php to make upgrades automatic.
It should be noted here that you can also make upgrades automatic by setting the file ownership of all files within the WordPress directory to the same user/group under which the webserver is running. THIS IS HORRIBLE SECURITY PRACTICE! While storing your FTP credentials for a specific user can also be considered insecure in certain instances, it can be a very safe method to automate WordPress updates under the proper conditions. Some general considerations which can make stored credentials MUCH more secure include:
FTP:
1. Creating a separate user and restricting its access to only allow connections from localhost
2. Ensuring your FTP daemon is “chrooting” the user to their own directory only
3. Configuring your FTP daemon to listen only on localhost, thus preventing external connections
4. Using something more secure than FTP, such as SSH — Yes, we realize this one does not actually improve FTP security
SSH:
1. Creating a separate user (usually an alias with the same UID, different GID) and restricting access to only localhost for this specific user in sshd_config with the AllowHosts option
2. Creating some advanced SSH configuration such as chrooted SFTP-only users
3. Using public key authentication, which can be further secured by specifying a “from” address in the user’s authorized_keys file
There are several other ways one can make their FTP/FTPS or SSH setup more secure, but they are far beyond the scope of this post and can vary greatly in their application due to the hosting environment and several other factors. We are going to assume you’re already working with a secure setup for the purposes of this guide.
again Well in this posting i want to gather togehter all i can get - to understand these porcesses - in order to dive into this technique and to enlarge my understanding: the Wordpress site had been automatically updated to the latest version. I knew about the feature but I've always wondered exactly how it works. Therefore i gathered some information about hte update-process how it works and which credentials at serverside we need
Nemesis wrote cf: viewtopic.php?f=2&t=78850&p=266927&hilit=wordpress+suphp#p266927
....or short, a cronjob runs (normaly) on the host that should perform an action from time to time. So, when you allowed to use cronjobs on your site - that are running your wordpress installation - you don't must deal with an ftp/rsh/scp remote file connection, to update the files at your own.
Before you do automated updates, it would be better to do a backup of your wordpress installation. The files in your webserver Documentroot (apache) and the database tables of your wordpress installation. Also do from time to an checkup of your backups, that those are realy functional and could be rolled out on another webspace.
Practice that, when you are responsible for that installation.
With ZFS and i guess btrfs (Linux) too, you can also do snapshots of your filesystem.
