It only affects the output of your MySQL dump in the file that is created.
It isn't necessary. It is just there so that if you import the created dump file into a database that already has a table with the same name, it will drop that table and then add the new table in its place. Otherwise you will get an error, and the dump file won't be imported.
You must export all table beginning with your WordPress prefix.
Open your phpmyadmin panel.
Then open your wordpress database.
Click "export" from top menu.
Select "Export Method:" as custom.
Select your all tables beginning your prefix.
Then go to bottom of page click "go".
You got your SQL file. Move all files to new directory. If you create a new ...
On your old site go to Tools > Export in the admin area.
You can select what you want to export. In your case "Posts." Click Download Export File
On the new site you'll go to:
Tools > Import > WordPress
You'll have to hit a button to install the core plugin, but you can remove it after the import.
Import the file you downloaded from the old site.
You're damned if you do, and you're damned if you don't. But it's typically better to "do".
I have been working in WordPress support and development for a number of years now - and I can certainly say it's much better to keep everything up to date.
Wait a little bit (2 weeks or so) after major updates before making the change to allow time for maintenance ...
phpMyAdmin is software typically installed by your host and available via your hosting control panel, it is not part of WordPress.
A search on web for [your host] phpMyAdmin will probably tell you what you need to do.
If you still have access to your wife's blog, I would recommend:
Running a regular WordPress export of the content
Downloading the entire /wp-content directory over FTP
These are the two most important parts of the site - the content and the uploads. From this, you should be able to recreate the site on a clean installation by FTPing the uploads to the ...
I've seen a bunch of ways of doing this, but here are a couple:
Use a plugin, like BackupBuddy (paid): http://pluginbuddy.com/purchase/backupbuddy/
Export your whole DB using phpMyAdmin and run a search-and-replace tool that properly deals with the serialized data, e.g. https://interconnectit.com/products/search-and-replace-for-wordpress-databases/ (I use ...
And when I need to restore, I do a search replace in the sql file all
localhost to that dns...
Doing a find/replace in a text dump of the database will break the serialized data stored in theme options.
Use interconnectit.com WordPress Serialized PHP Search Replace Tool to correctly find/replace serialized data. Some simple themes without options don't ...
In essence: This is almost correct.
Exporting/Saving your database handles all options, settings, configuration, and content.
The other thing is saving all the neccessary files. In general, all you need (unless you have altered anything else) is:
Just the theme is not enough, as you also might want to backup the ...
Your issue likely lies somewhere within wp-config.php. You should not need to run any install if your tables already exist, the wp-admin/install.php is only used when no tables are detected with the settings in wp-config.php.
Going through parameter by parameter, I'll give you some idea of what everything is.
DB_NAME is the name of the database that ...
Looking at the second screenshot, it seems like the question and answer fields are generated by the Advanced Custom Fields (ACF) Plugin with Repeater add-on. The symptom that only the item number is tracked, but not the item contents, reinforces this assumption. The ACF Plugin can either be installed as a plugin, but I think the necessary code can also be ...
You can use a plugin like backwpup that lets you:
Store backup to Folder
Store backup to FTP Server
Store backup to Amazon S3
Store backup to Google Storage
Store backup to Microsoft Azure (Blob)
Store backup to RackSpaceCloud
Store backup to DropBox (free)
Store backup to SugarSync (free)
and manage the number of backup copies to store which means for ...
WP-Cli, definitively, as explained here.
In you localhost:
wp db export
Upload the SQL file and the wp-content/uploads to your live server:
wp db import <sqlfile>
wp search-replace http://localhost http://live-location
The database still has the domain as the URL to use so it will always redirect you to the old server.
The best solution is to change your hosts file.
By using the NEW IP address you are forcing your computer to use the new server when going to yourdomain.com. That way you can login and do everything, making sure all is ...
If you are not moving to a different domain name, the file path shouldn't really matter.
Try these first:
Made a copy of your original backup bd
Open the new copy and search/replace example.com/ to example.com/blog/
This should get you going no matter what server setup you have.
If it doesn't, and you already have a fresh install on the right place, ...
It sounds like you probably need to go into the wp_options table and change the rows 'site_url' and the 'home_url' to match up with the new location. site_url is on the first page of the wp_options table, and 'home_url' is on the second page.
If you can access the wp dashboard those can be changed in the 3rd and 4th text boxes on the Settings >> General ...
Another way to seamlessly switch from localhost to live (for MS Windows):
install WP on the live site.
from your site control panel download a database copy and a site back-up of your files, and copy them to your localhost (for eg C:/wamp/www/) and import the db in your phpmyadmin; it's better to do this the other way around to make sure your live site ...
BackWPup http://wordpress.org/extend/plugins/backwpup/ will run on a cron job to backup just the database and/or wp-content or any other folders and files.
If you have access to any FTP accounts (or amazon S3 bucket, etc.) other than where your site is, the plugin can also send the files there; very good for security to have a completely separate place for ...
I believe the wordpress URL and site URl are not set right.
Please try to edit your wp-config.php adding these lines:
Is your index on same folder as wp installation? if not, you need to place it there.
I'm talking about placing the URL in the above lines, not the index on ...
You have to search the wp_options database table for option_name's that contains widget.
That search results in:
Using the values of your backups, you'll then proceed to restore the option_value of the missing widgets. And also the value of the option of sidebars_widgets.
Goes without saying that backing up before doing this modifications is essential.
When deleting a user, WordPress displays a warning that unless you attribute the user's posts to a new user, it's posts will be deleted and you cannot undo those deletions.
That means the only way to restore the posts and media is to restore a backup of the WordPress instance or database which you hopefully have.
If you have already run sudo a2enmod rewrite command but your URL Rewrite is not working.
To make .htaccess files work as expected, you need to edit this file:
Step1 : sudo vi /etc/apache2/sites-available/default
Step2 : Look for a section that looks like this:
Options Indexes FollowSymLinks MultiViews
There's 2 steps required to take a full backup.
Backup your content
Backup your files
To backup your content, you can use the WordPress export tool.
Or you can take a database dump or export copy of your database directly from phpMyAdmin which is the best method.
Another way to backup your content is to install a plugin which also copies ...
To backup only posts,pages and related media files for 3 week.
You need to do the following:-
Backup Database of website for post/page text.
Backup wp-content\uploads folder for media.
Then you can delete all files and restore old files.Once all old files uploaded then you can upload wp-content\uploads folder of current site.
PS: check uploads and ...
You can use the WP-CLI command wp db export <filename>
Run the command from within the home directory for the install.
Now, you have a database included in your files. Zip up the directory and move it aside. Now you can perform the upgrade, and if something breaks, replace with the old site and import the old database. voila, previously working site ...
There's not a one-to-one relationship between the WordPress database and the .wxr file.
We can find this line in the exported .wxr file:
<!-- This file is not intended to serve as a complete backup of your site. -->
Skimming through the export_wp() function, we can see what's excluded, for example:
The data stored in the wp_options table isn't ...