Resolving migration issues after renaming wp-content

by Leave a Comment

I recently ran into a strange issue after performing a clone of a WordPress site using Infinite WordPress (my preferred WordPress management platform). The clone had worked great and I logged in and started to modify the new site. I quickly noticed something was wrong after WordPress admin panel started generating 404 errors. When I looked at the source code for the page it looked like I was still trying to load a number of CSS and JS files from the site I had cloned from. My first thought was that there was an issue with the clone and the old domain name was still being referenced in the database. I searched the database but everything seemed to be fine.

The Solution

Finally while looking for the cause of the problem I noticed that there were two lines at the top of my wp-config file that referenced the old domain name and old website install location. These two lines were added when I renamed the wp-content folder on the original site. I quickly updated the code to point to my new site and I was off an running. This is something to be aware of when using automated WordPress migration tools, they don’t always catch all references to the original site. I really like using the cloning functionality in Infinite WordPress and this doesn’t cause an issue as long as you are aware of the problem and include it in your work flow.

 More on Renaming wp-Content

If anyone is interested in renaming their wp-content folder either for security reasons or just so your site looks less like WordPress, take a look at the iThemes Security Plugin. The plugin will do it automatically for you along with allowing a ton of other security tweaks. Please make sure you back up your website before trying though!

 

For those who are interested the two lines I needed to change were something like this (where site-assets would be the new name for wp-content)

define( 'WP_CONTENT_URL', 'http://mennosites.ca/site-assets' );
define( 'WP_CONTENT_DIR', '/home/mennosites/public_html/site-assets' );

Modify WordPress AutoSave interval

by Leave a Comment

WordPress automatically saves revisions to your posts and pages every 60 seconds. You are able to modify decrease the time interval if you’d like to reduce the chance of losing changes or increase it to cut down on the load to your database.

You can change the autosave frequency by adding the one of the following lines to the site’s wp-config.php file.

Examples:

/* Set AutoSave to 30 Seconds */
define ('AUTOSAVE_INTERVAL', 30); 
/* Set AutoSave to 5 Minutes */
define ('AUTOSAVE_INTERVAL', 300);

Limiting the number of post/page revisions that are saved in WordPress

by Leave a Comment

Whenever you modify a post or page on your WordPress site, a copy of is saved to make it possible to revert any changes that have been made.  Although this is a great feature when you quickly need to revert site content, the number of revisions can quickly add up and begin to take up a large amount of space in your database.  It is possible to set a maximum number of revisions that will be saved for each post/page by adding the following snippet to wp-config.php

Examples:

/* keep a maximum of 5 revisions for each post/page */
define('WP_POST_REVISIONS', 5);
/* disable revisions for post/pages */
define('WP_POST_REVISIONS', 9);

Empty WordPress trash automatically

by Leave a Comment

Ever since the release of version 2.9 WordPress automatically deletes posts, pages, attachments, and comments, from the trash bin every 30 days. You are able to change this default behaviour by adding a snippet of code to the wp-config.php file of your WordPress install. This can be handy if you want to empty the trash more often to save space, or if you want to disable the trash altogether.

The following snippet would empty the trash every 7 days. You can set this to whatever number works best for you or even 0 to disable the trash feature completely.

Example:

define('EMPTY_TRASH_DAYS', 7 );