BackupBuddy: Frequent Support Issues - Revision history

Akers: /* HTTP Loopback Connections Disabled */

2013-05-08T22:16:40Z

HTTP Loopback Connections Disabled

Akers: /* BackupBuddy Tab Missing in WordPress */ added in part about wp-config.php define being needed

2013-04-17T19:09:51Z

BackupBuddy Tab Missing in WordPress: added in part about wp-config.php define being needed

Dustin: /* 500 Server Errors */

2013-03-30T02:41:32Z

500 Server Errors

Dustin: /* Compatibility Mode */

2013-02-13T23:53:02Z

Compatibility Mode

Lkraav: /* URL needs manually updated */ Teach wiki about Search-Replace-DB

2012-11-25T13:53:57Z

URL needs manually updated: Teach wiki about Search-Replace-DB

Akers: /* Scheduled Events Fail to Trigger */ changed title a bit

2012-10-02T22:32:15Z

Scheduled Events Fail to Trigger: changed title a bit

Akers: /* After import: The source site is now redirecting to the destination site (or vice versa): */ updated step number

2012-08-24T16:28:24Z

After import: The source site is now redirecting to the destination site (or vice versa):: updated step number

Akers: /* Restoring/Migrating */ Beta ImportBuddy is no longer beta

2012-08-15T15:51:28Z

Restoring/Migrating: Beta ImportBuddy is no longer beta

Akers: /* Links (permalinks) return 404 errors */ custom permalinks added

2012-08-10T16:02:38Z

Links (permalinks) return 404 errors: custom permalinks added

Lukescammell: Added Debian/Ubuntu Zip install instructions

2012-07-22T17:01:33Z

Added Debian/Ubuntu Zip install instructions

@@ Line 4: / Line 4: @@
 ==HTTP Loopback Connections Disabled==
 * Also known as '''Endless Ping'''.
 * This usually happens before the second Scheduled Cron in your backup is run. You can see the number of times "Scheduled Cron" is mentioned in the Advanced Logs shown on the backup page to see if this is the case.
 * If your Server Information page reports that HTTP Loopback Connections are disabled or the following occurs (see below), you need to either enable HTTP Loopback Connections or enter the WordPress Alternate Cron setting in your wp-config.php file. This is caused if your host is blocking loopback connections within their firewall. You will need to request that your host change this (this is very standard to have this available), enable the alternate cron method in your wp-config.php (as Solution below - often the '''only''' solution for those in a shared environment), or move to a new host.

@@ Line 281: / Line 281: @@
 *If the BackupBuddy Tab is missing in your WordPress Admin area, there could be a few reasons for it:
 **'''MULTISITES:''' If you are activating BackupBuddy on a single site inside a Multisite instead of using the NETWORK ACTIVATE option, BackupBuddy options will be hidden on purpose for security reasons. You must use [http://ithemes.com/codex/page/Installing_BackupBuddy#Multisite Network NETWORK ACTIVATE] instead.
 **Try disabling other plugins which may be causing a conflict OR not allowing BackupBuddy tab to show up in WordPress admin area, even if direct links to such areas work.

@@ Line 440: / Line 440: @@
 ====500 Server Errors====
-* [[.htaccess]] (click for details) file is causing URLs to be redirected improperly or is malformed. Sometimes the front end simply won't load.
+* [[.htaccess]] (click for details) file is invalid or contains unsupported directives. Often an "AddHandler" line exists from the source server that is not supported on the new destination server.
 ** Regnerating the .htaccess file can solve. To do this login to your admin dashboard and go to Settings -> Permalinks -> and click the "Save Changes" button.
 *** Note: You don't have to actually make any changes on the page to regenerate the .htaccess in this manner by clicking to "Save Changes".
 * PHP is not functioning or enabled for the site. Check with basic [[phpinfo()]].
-* A 404 error is occurring but the server is not set up correctly to return a 404. Do sanity check with .htm file.
+* A 404 error is occurring but the server is not set up correctly to return a 404
-* Manually edit the [[.htaccess]] file in a text editor following the format on the [[.htaccess]] page.
-* Delete or manually remove your OLD .htaccess file from the extracted folders after it passes the step of extracting files, from the backup file (and then zip it again) OR before you do a backup.
-* Edit your OLD .htaccess file to be basic without any extra comments that may be interfering on the new server.
-* Make sure your new OR old .htaccess does NOT have any directive that is resulting in any website file, including the index, to be blocked.
-* See `.htaccess being overwritten on unzip` below if it happens on Step 2 of import.
-* Ask your host to look at the .htaccess file and to fix any errors with it, OR to delete the EXISTING AND/OR GENERATED .htaccess file OR to generate a new .htaccess file for you.
 *Related links:

@@ Line 45: / Line 45: @@
 * If your server does not support command line Zip then BackupBuddy will fall back into a compatibility mode to help aid you in creating a backup. This mode is significantly slower and less reliable.  It is not intended for persistent use and is provided to aid you in backing up in poor hosting environments, for instance to move to another host.
 * Directory exclusion is not available in this mode.  Even existing backups will be backed up, resulting in rapidly growing backup file sizes.
-* If you are running on a Windows server you will need to install the [http://pluginbuddy.com/wp-content/uploads/2010/05/backupbuddy_windows_unzip.zip Windows zip.exe executable] (we do not provide support for setting this up, though the readme.txt in the file does help).
+* If you are running on a Windows server (or developing locally, ie on Xampp) you will need to install the [http://pluginbuddy.com/wp-content/uploads/2010/05/backupbuddy_windows_unzip.zip Windows zip.exe executable] (we do not provide support for setting this up, though the readme.txt in the file does help).
 * Solutions:
 ** If you are running CentOS on a VPS or similar type of server then running the command <pre>yum install zip</pre> as root will install the zip package and any dependencies. This may also apply to other environments using rpm packages and the yum package manager front-end. The yum manager can also be used to query installed packages and update packages, etc. If you have any issues with this then please consult your host support for additional assistance.

@@ Line 516: / Line 516: @@
 <pre class="brush:html">update wp_posts set post_content = replace(post_content, 'http://OLD_URL', 'http://NEW_URL');</pre>
 * Command line zip test to check if exec is enabled and zip can create a file. Download: [[Media:Zip_test.zip]]
 ==The unzip process reported success but the backup data file...==

@@ Line 157: / Line 157: @@
 ** Email: port 25 (if using external mail server)
-==Scheduled Events Fail to Trigger==
+==Scheduled Events Fail to Trigger/Using Real Cron to Trigger==
 * The scheduled date is wrong and has not passed.
 * Not enough visitors are visiting to trigger the schedule.  Someone must visit any page on the WordPress site on or after the scheduled time for the event to occur.  If no one visits during the time-frame then the event may be missed or occur at an unscheduled time.

@@ Line 373: / Line 373: @@
 ==After import: The source site is now redirecting to the destination site (or vice versa):==
-* This occurs if the new database settings were not entered during Step 4 of importbuddy.php.  Because of this, both sites are now sharing the same database so one of them (usually source) is redirecting to the other (usually destination).  importbuddy.php needs to be re-run inputting the source URL on Step 4 and using the source database settings.  This will reconfigure the source database to use its proper URL.  Next importbuddy.php needs to be run again inputting the destination URL on Step 4 with the NEW database settings for the new database.  This way both sites will have their own database for their respective URLs.
+* This occurs if the new database settings were not entered during Step 3 of importbuddy.php.  Because of this, both sites are now sharing the same database so one of them (usually source) is redirecting to the other (usually destination).  importbuddy.php needs to be re-run inputting the source URL on Step 3 and using the source database settings.  This will reconfigure the source database to use its proper URL.  Next importbuddy.php needs to be run again inputting the destination URL on Step 3 with the NEW database settings for the new database.  This way both sites will have their own database for their respective URLs.
 * importbuddy no longer overwrites existing WordPress databases by default so this issue is not as common as it used to be.
 ==After import: WordPress Error: `You do not have sufficient permissions to access this page`==

@@ Line 417: / Line 417: @@
 *Related customer thread with easy solution:
 **http://ithemes.com/forum/index.php?/topic/17989-update-in-progress-after-migrate/
 ==Links (permalinks) return 404 errors==

@@ Line 442: / Line 442: @@
 *** 3) Continue the import to completion
 *** 4) Regenerate the .htaccess file in WordPress by going to Settings -> Permalinks -> and clicking to "Save Changes"
 * [http://codex.wordpress.org/Using_Permalinks#Fixing_Permalink_Problems See WordPress' official page on Fixing Permalinks for more solutions.]

@@ Line 48: / Line 48: @@
 * Solutions:
 ** If you are running CentOS on a VPS or similar type of server then running the command <pre>yum install zip</pre> as root will install the zip package and any dependencies. This may also apply to other environments using rpm packages and the yum package manager front-end. The yum manager can also be used to query installed packages and update packages, etc. If you have any issues with this then please consult your host support for additional assistance.
 ** If you are operating a Media Temple DV server then please make sure you have the Developer Tools installed as this contains the package necessary to provide zip capability.
 ** If your server is configured to disable access to the PHP exec() function and if you have access to configure your server then remove any blocking of the PHP exec() function in php.ini and configure permissions to allow running the Linux command line function `zip`.
@@ Line 53: / Line 54: @@
 ** Ask your host to enable access to the Linux command line Zip command via PHP's exec() function.
 *** Example message to send to your host:
-<pre>
+<pre>Dear Sir/Madam,
 Dear Sir/Madam,
 I am attempting to use the highly popular WordPress backup software, BackupBuddy by PluginBuddy.com.
@@ Line 69: / Line 69: @@
 available to the process executing the command passed to the exec() function
-Thank you for your time and consideration.
+Thank you for your time and consideration.</pre>
 </pre>
 ** Also possible that even though that zip via exec() is enabled it still may not work if host does not have zip's path location currently as a part of PATH (or the path is not one of the "well known" locations that more recent versions of BackupBuddy with search). The below code is an example of how to add the directory of the zip executable to PATH after you ask your host where it is being kept and whether this is the correct way to do it on their servers or if not what is the preferred way (please note the colon that precedes the path being added):
 *** <pre>putenv( "PATH=" . getenv( 'PATH' ) . ":directory zip exe is" );</pre>
 *** The line has to be added anywhere in the wp-config.php file after the first line ( <?php ) but at least before the line that says /* That's all, stop editing! Happy Blogging */
 ** If all of the above are either impossible or unsuccessful and you absolutely must have the native zip command capability then you only option is to move your site to an alternative server or host that provides this capability.
 ==Unable to create directory /public_html/yourdomain/wp-content/uploads/2012/03. Is its parent directory writable by the server?==