Wordpress: Difference between revisions

From Open Source Ecology
Jump to navigation Jump to search
No edit summary
No edit summary
Line 49: Line 49:
First of all, it is not uncommon for an attempt to update wordpress to result in an entirely broken site. If you do not have linux and bash literacy, do not attempt to update wordpress. Moreover, you should be well-versed in how to work with mysqldump, tar, rsync, chmod, chown, & sudo. If you are not confident in how all of these commands, do not proceed. Hire a someone with sysops experience to follow this guide; it should take them less than a couple hours to update and/or revert if the update fails.
First of all, it is not uncommon for an attempt to update wordpress to result in an entirely broken site. If you do not have linux and bash literacy, do not attempt to update wordpress. Moreover, you should be well-versed in how to work with mysqldump, tar, rsync, chmod, chown, & sudo. If you are not confident in how all of these commands, do not proceed. Hire a someone with sysops experience to follow this guide; it should take them less than a couple hours to update and/or revert if the update fails.


==Step 1: Trigger Backup Scripts==
==Step 0: Trigger Backup Scripts for System-Wide backup==


For good measure, trigger a backup of the entire system's database & files:
For good measure, trigger a backup of the entire system's database & files:
Line 63: Line 63:
</pre>
</pre>


==Step 2: Make Local backups==
==Step 2: Make Site-specific backups==


The backups made in the previous step are huge. Because it's easier to work with site-specific backups, let's make a redundant copy available in /var/tmp/:
The backups made in the previous step are huge. Because it's easier to work with site-specific backups, let's make a redundant copy available in /var/tmp/:


<pre>
<pre>
vhostDir=/var/www/html/osemain


dbName=osemain_db
dbUser=osemain_user
dbPass=CHANGEME
rootDbPass=CHANGEME
stamp=`date +%Y%m%d_%T`
tmpDir=/var/tmp/dbChange.$stamp
sudo mkdir $tmpDir
sudo chown root:root $tmpDir
sudo chmod 0700 $tmpDir
sudo pushd $tmpDir
sudo service httpd stop
# create backup of everything for good measure
sudo time nice mysqldump -uroot -p$rootDbPass --all-databases | gzip -c > preBackup.all_databases.$stamp.sql.gz
# dump obi wordpress db contents
sudo time nice mysqldump -u$dbUser -p$dbPass --database $dbName > $dbName.$stamp.sql
# files backup
rsync -av --progress "${vhostDir}" "vhostDir.${stamp}.bak/"
</pre>
</pre>



Revision as of 02:10, 27 August 2017

Wordpress Plugins

OSE Website - Known Bugs

  • Fields not filled in - Wpbugs1.png

Proper File/Directory Ownership & Permissions

This section will describe how the file permissions should be set on an OSE wordpress site.

For the purposes of this documentation, let's assume:

  1. vhost dir = /var/www/html/osemain
  2. wp docroot = /var/www/html/osemain/htdocs

Then the ideal permissions are:

  1. Files containing passwords (ie: wp-config.php) should be located outside the wp docroot with apache:apache-admins 0400:0400
  2. Files in the wp-content dir should be apache:apache 0660
  3. Directories in the wp-content dir should be apache:apache 0770
  4. All other files in the vhost dir should be apache:apache 0640
  5. All other directories in the vhost dir should be apache:apache 0750

This is achievable with the following idempotent commands:

vhostDir="/var/www/html/osemain"
wpDocroot="${vhostDir}/htdocs"

chown -R apache:apache "${vhostDir}"
chown apache:apache-admins "${vhostDir}/wp-config.php"
find "${vhostDir}" -type d -exec chmod 0750 {} \;
find "${vhostDir}" -type f -exec chmod 0640 {} \;
find "${wpDocroot}/wp-content" -type f -exec chmod 0660 {} \;
find "${wpDocroot}/wp-content" -type d -exec chmod 0770 {} \;

Updating Wordpress

First of all, it is not uncommon for an attempt to update wordpress to result in an entirely broken site. If you do not have linux and bash literacy, do not attempt to update wordpress. Moreover, you should be well-versed in how to work with mysqldump, tar, rsync, chmod, chown, & sudo. If you are not confident in how all of these commands, do not proceed. Hire a someone with sysops experience to follow this guide; it should take them less than a couple hours to update and/or revert if the update fails.

Step 0: Trigger Backup Scripts for System-Wide backup

For good measure, trigger a backup of the entire system's database & files:

sudo time /bin/nice /root/backups/backup.sh &>> /var/log/backups/backup.log

When finished, SSH into the dreamhost server to verify that the whole system backup was successful before proceeding

sudo bash -c 'source /root/backups/backup.settings; ssh $RSYNC_USER@$RSYNC_HOST du -sh backups/hetzner2/*'

Step 2: Make Site-specific backups

The backups made in the previous step are huge. Because it's easier to work with site-specific backups, let's make a redundant copy available in /var/tmp/:

vhostDir=/var/www/html/osemain

dbName=osemain_db
dbUser=osemain_user
 dbPass=CHANGEME
 rootDbPass=CHANGEME

stamp=`date +%Y%m%d_%T`
tmpDir=/var/tmp/dbChange.$stamp
sudo mkdir $tmpDir
sudo chown root:root $tmpDir
sudo chmod 0700 $tmpDir
sudo pushd $tmpDir
sudo service httpd stop

# create backup of everything for good measure
 sudo time nice mysqldump -uroot -p$rootDbPass --all-databases | gzip -c > preBackup.all_databases.$stamp.sql.gz

# dump obi wordpress db contents
 sudo time nice mysqldump -u$dbUser -p$dbPass --database $dbName > $dbName.$stamp.sql

# files backup
 rsync -av --progress "${vhostDir}" "vhostDir.${stamp}.bak/"

CLI guides

This section will provide commands to achieve certain actions for managing wordpress

replace strings everywhere in wp database backend

Use these commands to safely backup & do a string replacement for all occurrences from a given $fromString to $toString. This was used to replace links in the wordpress posts/pages to the ip address instead of using the domain name (which creates migration issues & https issues)

dbName=obi_db
dbUser=obi_user
 dbPass=CHANGEME
 rootDbPass=CHANGEME

fromString=138.201.84.223
toString=openbuildinginstitute.org

stamp=`date +%Y%m%d_%T`
tmpDir=/var/tmp/dbChange.$stamp
mkdir $tmpDir
chown root:root $tmpDir
chmod 0700 $tmpDir
pushd $tmpDir
service httpd stop

# create backup of everything for good measure
 time nice mysqldump -uroot -p$rootDbPass --all-databases | gzip -c > preBackup.all_databases.$stamp.sql.gz

# dump obi wordpress db contents
 time nice mysqldump -u$dbUser -p$dbPass --database $dbName > $dbName.$stamp.sql

# make backup
cp $dbName.$stamp.sql $dbName.$stamp.sql.orig

# sed
sed -i "s/$fromString/$toString/g" $dbName.$stamp.sql

# verify
grep "$fromString" $dbName.$stamp.sql | less
grep "$toString" obi_db.$stamp.sql | less

# delete db tables
 mysql -u$dbUser -p$dbPass $dbName -sNe 'show tables' | while read table; do mysql -u$dbUser -p$dbPass -sNe "DROP TABLE $dbName.$table;"; done

# verify
 mysql -u$dbUser -p$dbPass $dbName -sNe 'show tables' 

# import
 mysql -u$dbUser -p$dbPass < obi_db.$stamp.sql

# verify
 mysql -u$dbUser -p$dbPass $dbName -sNe 'show tables' 
service httpd start

migrate to svn-backed wordpress install

These commands were used to migrate the existing & outdated wordpress installs to a subversion-backed, ephemeral clone of the site. Changes were iterated to these commands documented here as validation by the site owners exposed issues with the upgrades, missing content, etc. Once the clone was validated entirely, the live site could be brought down & confidently updated per the findings with the ephemeral clone.

obi

oldVhostDir=/var/www/html/obi
newVhostDir=/var/www/html/obi2
oldDbName=obi_db
newDbName=obi2_db
newDbUser=obi2_user
 newDbPass=CHANGEME
 rootDbPass=CHANGEME

rm -rf $newVhostDir
mkdir -p $newVhostDir/htdocs
pushd $newVhostDir/htdocs

yum install subversion
svn co https://core.svn.wordpress.org/tags/4.8.1 .

find $newVhostDir -type d -exec chmod 750 {} \;
find $newVhostDIr -type f -exec chmod 640 {} \;
chown -R apache:apache $newVhostDir

stamp=`date +%Y%m%d_%T`
tmpDir=/var/tmp/dbChange.$stamp
mkdir $tmpDir
chown root:root $tmpDir
chmod 0700 $tmpDir
pushd $tmpDir
 time nice mysqldump -uroot -p$rootDbPass --all-databases | gzip -c > preBackup.all_databases.$stamp.sql.gz
 time nice mysqldump -uroot -p$rootDbPass --databases $oldDbName > $oldDbName.$stamp.sql
cp $oldDbName.$stamp.sql $newDbName.$stamp.sql

# replace the first 2 (non-comment) occurances of $OldDbName with $newDbName
vim $newDbName.$stamp.sql

# update links for 3Dmodels, which we're moving to the 'wp-content' dir
sed -i 's^/3Dmodels/^/wp-content/3Dmodels/^g' "$newDbName.$stamp.sql"

 time nice mysql -uroot -p$rootDbPass -sNe "DROP DATABASE IF EXISTS $newDbName;" 
 time nice mysql -uroot -p$rootDbPass -sNe "CREATE DATABASE $newDbName; USE $newDbName;"
 time nice mysql -uroot -p$rootDbPass < "$newDbName.$stamp.sql"
 time nice mysql -uroot -p$rootDbPass -sNe "GRANT ALL ON $newDbName.* TO '$newDbUser'@'localhost' IDENTIFIED BY '$newDbPass'; FLUSH PRIVILEGES;"

popd

rsync -av --progress $oldVhostDir/wp-config.php $newVhostDir/
chown apache:apache $newVhostDir/wp-config.php
chmod 400 $newVhostDir/wp-config.php

# change DB_NAME, DB_USER, DB_PASSWORD, WP_HOME, & WP_SITEURL
vim $newVhostDir/wp-config.php

# we want to copy files that don't exist yet in our new install dir. if a file exists in both, don't overwrite the new from the old
rsync -av --progress --ignore-existing $oldVhostDir/htdocs/wp-content/ $newVhostDir/htdocs/wp-content/

# delete unnecessary & empty upgrade dir
rm -rf $newVhostDir/htdocs/wp-content/upgrade

# migrate '3Dmodels' dir, but put it in 'wp-content' for future migrations (the wp upgrade docs migrate this dir already)
rsync -av --progress $oldVhostDir/htdocs/3Dmodels $newVhostDir/htdocs/wp-content/

# take the old .htaccess; overwrite existing if needed
rsync -av --progress $oldVhostDir/htdocs/.htaccess $newVhostDir/htdocs/

# finally, log into the new wordpress site. After authenticating, wp will ask you to update, if necessary. Then you can test.