Tag Archives: Wordpress

Home / Wordpress
4 Posts

One of the beautiful things of our Diskstation is that Synology provided it with a plug-and-play feature to give your NAS even more functionality. It’s called Package Center. Synology offers a lot of packages out of the box. These packages have to be maintained by Synology. That is not a big issue if these packages are kept up-to-date within an acceptable period of time. However Synology (and probably other NAS-providers who are using these kinds of mechanisms to offer more functionality to their products) can’t always keep up the update pace of the software in their packages.

If you are using packages that has a large install base then you are more vulnerable to attacks of hackers. Especial when you use the software as a public internet service. It’s is critical you can update these packages as soon as the producer makes the (security) updates available. When you are using the Synology package, you have to wait until they update the package. Unfortunately this seems not to have any priority at Synology’s. I noticed this when using the WordPress package. WordPress kept updating but my installation stay’s on the version that was delivered by the Synology package.

I tried to find a solution for this without compromising my content.  The following steps describes how I did it.

  1. Make sure you have a fallback in case anything goes wrong. Don’t underestimate this. It’s like an insurance: You invest in something you hope never have to use. I use Duplicator to make a backup of my complete WordPress site. It’s a plugin for WordPress and makes it possible to rebuild the complete site even if the only thing left is an empty web server. I wrote a complete post how this work previously and can be found here.
    Another measure to minimize the risk of losing anything, is the possibility to test the modifications on a place where it can’t do any harm and comes as close as possible to the real world situation. Most of the time you have no spare Diskstation available to do your experiments. Modifications must be done in a ‘production’ environment without being sure the outcome doesn’t compromise your NAS. Scary Huh?. Fortunately there is a reasonable alternative: a virtual Diskstation.
    In a previous post here you can read how to get your own virtual Diskstation. These two measures gives you the opportunity to try anything you like without compromising your NAS. If you build your own virtual NAS and made a backup of your site, I encourage you to test your backup before you go further. (Having a backup is good, knowing the restoration of this backup works is better!)
    Now you have all the equipment to practice the upgrade procedure before you do this on your physical NAS. USE THIS! When anything goes wrong, you’ll be more than happy you did.
  2. Your WordPress installation is located in the web share of your Diskstation. In that share you’ll find a folder with the obvious name wordpress. There is the location your WordPress files are stored. However the best way is to use FTP or SSH to manage your WordPress files. In that case you have to look into /volume1/web/wordpress/ (or another volume where your website is stored.) Make sure you have write access here and you might have to set the owner of this folder to nobody:nobody. (DSM 5.x users have to use http:http)
  3. To update this you have to follow the exact description of a manually update of a WordPress installation described on the WordPress site: http://codex.wordpress.org/Updating_WordPress. Read the whole page and follow the manual update instructions carefully. (It isn’t hard)
  4. After visiting the wp-admin page as stated in the update instructions, the job is done. The next available update will come from WordPress and you have not to wait until Synology brings it’s update.
  5. You CAN NOT remove the WordPress Package form the package center. This will uninstall your WordPress and leaves you with an empty site.  The only thing you can probably do is to delete the package information on your NAS. You need SSH access to the filesystem of your Diskstation for this. Go to the /var/packages/ folder. There is a wordpress folder. When you delete this folder, the WordPress package disappears from your Package Center. Doing this is at your own risk. I don’t know what the consequences are for the stability of your Diskstation.

It is not complex to do. Just take your time and act carefully. With a good strategy and enough testing of your backup scenario’s, there is not much that can go wrong.

I dealt a long time with an issue in my WordPress installation, but didn’t trust me to experiment around and have a non working WordPress installation at the end. I decided to find a way to clone my whole WordPress installation and satisfy my experimental drift there. When I find a way to clone my WordPress installation, I also find a way to do something about disaster recovery of my WordPress blog.

It has to be a reliable method and must be more or less foolproof, because I wouldn’t like to spend much of the time repairing if it is not nesessary. I think I’ve found a solution that ticks all the boxes: a plugin called Duplicator (http://wordpress.org/extend/plugins/duplicator/)

Duplicator can be installed as a regular WordPress plugin. The interface is simple but effective. A complete manual can be found here at LifeInTheGrid website.

The first time you are getting acquainted with Duplicator is with the screen above wihout the list of packages. Once you have created a backup of your WordPress site, the list with packages will grow. To create a backup simply press the Create Package button witch is located in the red circled area in the image above. Just give it a logical name and press the Create Package Set button , sit back and wait. When the backup is finished, a package set will appear.

To transport your site to another location you just press the two buttons (in the green area) behind your package. These buttons start two downloads. One of a zip-file containing your WordPress site and another to download the installer (installer.php). Save these files on your computer.

To rebuild your site on another location (or in case of a disaster on your original location) you have to make sure that you have created an empty wordpress rootfolder and an empty wordpressblog database schema on your target location. Make sure you have the appropiate rights on the database schema and the wordpress rootfolder. (I assume you have a working Apache and MySQL on your targetsystem.)

copy the zipfile and the installer.php to the WordPress rootfolder on your target system and open installer.php in your favorite browser (ie. http://myaddress/wordpress/installer.php) and follow the instructions on the screen.

If you met the requirements, the installer has three steps to follow:

  1. The first one is the step that asks you for your MySQL credentials. (This is also the last opportunity to drop all the tables in the wordpressblog schema by ticking the box before Table Removal.) Enter here your MySql credentials to let the installer create the database and tables.

  2. The second step lets you changing the url and the physical location of your WordPress rootfolder. Hardcoded locations in the pages and posts will not be changed. It also allowes you to decide witch plugins should be started or not. Disable all plugins during the installation but not the login redirectors. Enable the plugins after the installation in the Admin page of your WordPress site.

  3. This last step will give you directions to follow to make sure your WordPress is able to run again. Make sure you remove the following files from the WordPress rootfolder: installer.php, installer-log.txt, installer-data.sql

You now must be able to open your working WordPress site from the new location.

I have modified the php.ini in the section:

[eaccelerator]
eaccelerator.shm_size = 256 (16)
eaccelerator.shm_max = 4M (1M)
eaccelerator.shm_prune_period = 0 (3600)

and in the section:

[apc]
apc.shm_size = 256 (64)
apc.ttl = 0 (300)
apc.user_ttl = 0 (300)

The values between parantheses are the defaults. Don’t enter them in your php.ini.

After that restart Apache:

/usr/syno/etc/rc.d/S97apache-user.sh restart

You can also give your MySql a boost. Open a SSH session with your Syno.

Before you do so be aware of the following:

  • There are templates to use for this: „my-huge.cnf ” (for 1-2 GB RAM systems), „my-large.cnf” (for 512 MB RAM systems), „my-medium.cnf” (for 128 MB RAM systems)
  • If you already have a /etc/my.cnf please save this elsewhere or increase the value of “query_cache_size” from 0 to for example 32M.
  1. Stop the MySql Service:
    /usr/syno/etc/rc.d/S21mysql.sh stop
  2. Copy the desired template:
    cp /usr/syno/mysql/share/mysql/my-huge.cnf /etc/my.cnf

    if you didn’t choose to alter your current my.cnf or you haven’t a my.cnf at all.

  3. Start the MySql Service:
    /usr/syno/etc/rc.d/S21mysql.sh start

Source: German SynologyWiki

Use this for a plugin in /wp-content/plugins or /wp-content/mu-plugins (for auto-activation). Or functions.php.

<?php
/*
Plugin Name: [RPC] XMLRPCless Blog
Plugin URI: http://earnestodev.com/
Description: Disable XMLRPC advertising/functionality blog-wide.
Version: 0.0.7
Author: EarnestoDev
Author URI: http://earnestodev.com/
*/
// Disable X-Pingback HTTP Header.
add_filter('wp_headers', function($headers, $wp_query){
    if(isset($headers['X-Pingback'])){
        // Drop X-Pingback
        unset($headers['X-Pingback']);
    }
    return $headers;
}, 11, 2);
// Disable XMLRPC by hijacking and blocking the option.
add_filter('pre_option_enable_xmlrpc', function($state){
    return '0'; // return $state; // To leave XMLRPC intact and drop just Pingback
});
// Remove rsd_link from filters (<link rel="EditURI" />).
add_action('wp', function(){
    remove_action('wp_head', 'rsd_link');
}, 9);
// Hijack pingback_url for get_bloginfo (<link rel="pingback" />).
add_filter('bloginfo_url', function($output, $property){
    return ($property == 'pingback_url') ? null : $output;
}, 11, 2);
// Just disable pingback.ping functionality while leaving XMLRPC intact?
add_action('xmlrpc_call', function($method){
    if($method != 'pingback.ping') return;
    wp_die(
        'Pingback functionality is disabled on this Blog.',
        'Pingback Disabled!',
        array('response' => 403)
    );
});
?>

Activate the plugin afterwards.

Source: WordPress Answers