Top Nav

Navigation

Archive | Web

Change WordPress User Password With WP-CLI

By on December 10, 2016 in WordPress

WP-CLI is a great tool for managing WordPress sites from the command line. As an example you can quickly change a WordPress user’s password with WP-CLI. This can be very handy on sites that you don’t have a WordPress admin login. First, if you don’t already have WP-CLI installed then follow the instructions here:

http://wp-cli.org/#installing

Then “cd” to the root of the WordPress site and run the following command:

Where <user> is the username and <pass> is the new password.

Here’s an example:

You can actually update other user parameters with the “user update” sub-command. See the full docs here:

http://wp-cli.org/commands/user/update/

 

 

 

0

Magento SUPEE-7405 Parse Error

By on January 22, 2016 in Magento, PHP

Applying the new SUPEE-7405 patch to Magento 1.7.0.2 (and probably other versions) results in a parse error in the sales order view page (admin/sales_order/view/order_id) if the site is running under PHP5.3. Here’s the error message:

The offending line is:

it can be changed to:

PHP 5.3 does not support the “[]” syntax for array initialization. Of course you should not be running PHP 5.3!

0

W3TC CDN – Updating Plugin Or Theme

By on November 4, 2015 in WordPress

If you’re using W3 Total Cache with an origin push CDN like RackSpace Cloud Files, then you may encounter problems when updating plugins or themes. After the new files are synced to the CDN there is a propagation delay before all nodes receive the new files. During this time the site may be broken for some users. Here’s a procedure to deal with this situation:

1. Install and activate the new plugin or theme.

2. In W3TC, syncronize the Custom files to CDN. (Performance -> CDN -> Upload Custom Files)

3. Add plugin or theme folder to the CDN exclusion list:

Performance -> CDN -> Rejected Files

Add this line:

{plugins_dir}/plugin_folder

or

{wp_content_dir}/themes/theme_folder

4. Save and clear the page cache.

Now the site will pull the plugin or theme from the server instead of the CDN. But the new files will be propagating through the CDN.

5. In 24 hours or whatever the TTL for your CDN container, after the files have had a chance to propagate, remove the plugin or theme folder from the Rejected Files list and clear the page cache.

Now the site will pull the plugin or theme from the CDN.

0

Updating W3TC Media Query String In WordPress Clusters

By on October 20, 2015 in WordPress

W3 Total Cache includes a feature to append a “media query string” to end of Javascript and CSS stylesheet URLs. By selecting “Performance -> Update Media Query String”, the WordPress admin can force the media query string to change. This in turn causes browser to fetch new copies of the JS and CSS files. This is very useful when browser caching is turned on with a long Expires value. Instead of waiting for the Expires timeout for a new change to become visible, the admin can force the change immediately.

But problems arise in a clustered environment with multiple web servers. The update works on the master server but the change is not reflected on slave servers. Here’s why:

  1. W3 Total Cache generates the media query string from the browsercache.timestamp configuration value which is stored in wp-content/w3tc-config/master.php.
  2. To optimize performance, W3 Total Cache stores a parsed copy of the master.php file in wp-content/cache/config/master.php.
  3. Typically we exclude wp-content/cache from replication to slave servers as the cache folders can be very deep and slow replication.
  4. When the media query string is updated the slaves do not know that they need to regenerate the cached version of master.php.

In fact this problem occurs with any config change to W3 Total Cache. The changes will not be seen on slave servers unless the wp-content/cache/config/master.php file is deleted.  After deletion the next request will regenerate the file with the new settings.

In our sync script we use a line like this to clear the config if needed:

No each time the sync script runs, if the W3 Total Cache config has changed then the cached copy will be deleted and regenerated on the next request.

 

1

Content Updates With W3 Total Cache & RackSpace Cloud Files

By on August 31, 2015 in Cloud Files, Uncategorized, WordPress

We get frequent questions from WordPress clients with W3 Total Cache (W3TC) and RackSpace Cloud Files (RCF) content distribution network (CDN) about how to make changes to the website visible.

First some general notes:

  1. Content changes or updates to pages or posts do not involve the CDN so no special actions are required. W3TC will automatically flush old pages and post revisions from it’s caches.
  2. Media files uploaded through WordPress admin will be automatically uploaded to the CDN and can be immediately used in post or pages with no additional action.
  3. Files that are changed via FTP will required additional action. This included media files, CSS and Javascript as discussed below.

As an example, let’s assume that you’ve modified you themes primary stylesheet at:

wp-content/themes/mytheme/style.css

You made the modification by downloading the file, editing on your workstation and then uploading via SFTP back to the server. In this case W3TC has no way of knowing that you’ve made a change to the file so it does not know that the file needs to be uploaded to the CDN.

First you’ll need to sync or upload the file to the CDN:

  1. Login to WordPress admin.
  2. Go to Performance -> CDN
  3. Click the appropriate upload button in the General section. The button will depend on what type of file you’ve changed. In this example we need to click the “Upload theme files” button. W3TC_CDN_General
  4. A popup window will open when you click the button similar to this: W3TC_CDN_UploadIn the popup window, click the “Start” button. The sync process will start and you’ll be able to see as each file is examined. If the file has not changed since the last sync the it will be marked “Object up-to-date”. If the file is now or has changed then it will be marked with “Ok”. W3TC_CDN_Upload2
  5. After the sync process completes you can close the popup window. If you have many files it may take several minutes to several hours to fully sync.

Now the new or changed file has been uploaded to the CDN. If it’s a new file then it will be immediately available for use in your site.  If instead you are changing a file then we have to take an additional step and “purge” the file from the CDN.

CDN’s function by distribution content to access points close to the user. For large CDN’s there might be dozens or even hundreds of access points. When a user requests a file, the request is routed to the closest access point. The CDN infrequently check back with your web server for changed or updated files. The frequency of these checks is call the “Time to Live” or TTL. By default RCF sets a 24 hour TTL on all files. So after uploading a change, it may take up to 24 hours before the change if visible on on access points. This can be a problem for our CSS change as users on different access point might get different versions of the file.

W3TC includes a “purge” feature which you can use as follows:

  1. Login to WordPress admin
  2. Go to Performance -> CDN
  3. Look for the Purge button above the General section. Click the Purge button to open the CDN Purge Tool popup window. W3TC_CDN_Purge1
  4. Enter the relative paths of each file that you want to purge into the “Files to purge” field.
  5. Click the Purge button and wait for the process to complete.W3TC_CDN_Purge2
  6. Close the CDN Purge Tool window.

Purging on the CDN is not an instantaneous process. I may take up to about a half hour for all access point to receive and honor the purge request but this is still much faster then the 24 hour TTL.

We have had mixed success with the W3TC CDN Purge Tool. If I need a change purged as fast as possible then I prefer to run the purge from the RackSpace Cloud Files control panel as follows:

  1. Login to https://mycloud.rackspace.com
  2. Go to Storage -> Files
  3. Drill down on your container and then to the file that you want to purge.
  4. Click on the Gear icon next to the file to open the drop down menu. RSCF_Purge1
  5. Select “Refresh File (Purge)” from the menu. A small confirmation dialog will open. RSCF_Purge2
  6. Click “Purge File” button in the dialog to complete the process.

Again purging on the CDN is not an instantaneous process. I may take up to about a half hour for all access point to receive and honor the purge request.

Is there anyway to make updates to the CDN faster?

Short answer is “no”. The TTL and propagation delay is the nature of the CDN. Generally the benefits of distributing content win out over the update delays.

But two notes:

  1. New files do not experience any propagation delay. If you want to change a file and have it propagate instantly then change the name of the file so it is seen as a new file by the CDN.
  2. You can lower the TTL of the CDN container. If you have a big setup of updates planned, then it might be a good idea to lower the TTL a few days in advance so that you minimize propagation delay.

 

 

0